Serendipity Forums

I always thought this was some weird bug in 2.0, but it turns out this doesn't work in 1.7, either. Probably hasn't worked in a while and no one noticed since it's a rarely used function.

Reproduce: Backend -> Manage groups -> edit any group; first form field in the edit form is “Name” which seems to “find” the correct name, but doesn't propagate the corresponding input field with the actual (localized) name. Instead, the name of the lang constant is emitted.

Example: it should emit “Administrator”, but it does emit “USERLEVEL_ADMIN_DESC”.

YL

Same bug shows up in the warning message emitted when trying to delete a group.

YL

Hi!

Not a bug, that's how it's supposed to read. Otherwise, those hardcoded author groups would never be translated depending on the language.

Try it out with a custom usergroup, those should be editable.

Regards,
Garvin

I already fixed it.... Please urgently see some last commits in master and 2.0. I wondered why these constants weren't parsed already...
Does that mean a group submit would now emit the translation and confuse the security... ?
Good you dropped in! Sorry, if these commits brought destruction.

Hi!

No time for that, sorry. All my planning for last week vaporized when a new project came around. I hate that. The time-fairy no longer seems to be on good grounds with me. So please probably better revert the patch (though I couldn't look at it yet)

The way it's supposed to work is that the internal groups for Admin, Editor, chief, should always remain the CONSTANT names, and saving should never override that. Only that way, when a constant exists for a groupname, it will properly name the groups depending on the language the person is logged in.

Regards,
Garvin

done!

If the group name for default groups isn't meant to be editable (which is what I read between Garvin's lines), we should probably (for those groups, if that's possible) set the readonly attribute there …?

YL

yellowled wrote:If the group name for default groups isn't meant to be editable (which is what I read between Garvin's lines), we should probably (for those groups, if that's possible) set the readonly attribute there …?

As long as there's a constant, the users should be able to edit the groups name to one with another constant... Honestly I don't know if setting readonly could maybe break anything for that, but it's not a bad idea to do that...we could try it out and see if it affects anyone

garvinhicking wrote:As long as there's a constant, the users should be able to edit the groups name to one with another constant...

Huh? Does that mean users should be able to rename “Administrator” to “Editor”, but only by exchanging the lang constants? Because that doesn't make sense (to me) at all. Most, (end) users don't know these constants anyway in most cases. I assume that it confuses most (end) users that the actual group name is not emitted in that field.

garvinhicking wrote:Honestly I don't know if setting readonly could maybe break anything for that, but it's not a bad idea to do that...we could try it out and see if it affects anyone

Well, I'm not sure if there are browsers which don't support readonly. Other than that, the only effect would be that the group name would still be displayed in an input field, but it wouldn't be editable. (We could just as well emit the group name as e.g. a heading or something.)

YL

I assist. These pre-defined user group names as constant STRINGS do IMO never need to be changed by name. Why should they? As Clones to free groups? This could be done else. These STRINGS can get submitted hidden and displayed translated inside a heading tag, contrary to the free ones.

I don't know if this matters or not....

Once upon a time, I played around with aMember and s9y. They have their own plugin that allows it to work with s9y. One of the features of aMember allows it to interact with user groups.... allowing certain user groups access to entries, and changing a user's default group to a specified group when their aMember membership expires. I don't know how many s9y users are using aMember, but be careful with any modifications so as not to break functionality with 3rd party apps like aMember.

I am very far behind in testing the latest s9y, but will try to get caught up soon. I will also try to reinstall aMember - if I can - and see if any of these proposed changes affects it.