-
Bug
-
Resolution: Fixed
-
Medium
-
2.5.5, 2.6.0
-
None
Users who have upper case letters in their usernames cannot be assigned space level view permissions.
Steps to reproduce:
- Create a user with a upper case letter ('User')
- exclude this user from any groups
- give the user "can use" global permissions
- go to a particular space and try to give the user all permissions for this space. You can verify that permissions are not set by logging in as this user.
The same steps for a username without upper case produce the expected result.
NOTE: These steps to reproduce are no longer valid. On creation of the user, the user name is converted to lowercase. It can only then be referred to by lower case.
Update: I've been told that if you create user via XMLRPC you can reproduce the problem as described here.
The particular problem is mentioned in this support issue. (I tested it against the trunk)
In general when solving this issue we should probably review how we deal with usernames (currently when creating a new user we modify username to lowercase).
We should also investigate this issue in conjunction with LDAP as LDAP is case insensitive.
Ideally we should always reference user by id in all tables. This will eliminate a big chunk of potential problems and also will make username modifiable. But as it is quite complex we may fix this particular bug first.
- causes
-
-
- Closed
-
- is duplicated by
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
- relates to
-
-
- Closed
-
-
-
- Closed
-
[CONFSERVER-9469] Upper case letters in user names don't work with space permissions
Andy Brook (Javahollic Software)
added a comment - Ok fab, can't ask for more, other than a 2.7.1 due date 
Andy Brook (Javahollic Software)
added a comment - Ok fab, can't ask for more, other than a 2.7.1 due date Andy, this fix is intended to include an upgrade task that will consolidate the permissions that are for the same user or groups differing only by case.
Vishal J
added a comment - Please get this issue fix ... or atleast make a arrangement that we can remove the incorrect username from the permission with frontend. I don't want to play with database... 
Thanks.!
Vishal J
added a comment - Please get this issue fix ... or atleast make a arrangement that we can remove the incorrect username from the permission with frontend. I don't want to play with database...
Thanks.! Andy Brook (Javahollic Software)
added a comment - It would be nice if this issue were to 'go away' during an upgrade, ie, usernames and references were lower cased automatically, any prospect of this?
Andy Brook (Javahollic Software)
added a comment - It would be nice if this issue were to 'go away' during an upgrade, ie, usernames and references were lower cased automatically, any prospect of this? 
Igor Minar
added a comment - Ideally we should always reference user by id in all tables. This will eliminate a big chunk of potential problems and also will make username modifiable. But as it is quite complex we may fix this particular bug first.
Amen to that!!
If http://jira.atlassian.com/browse/CONF-4063 was fixed this problem would most likely not exist.
Atlassian promised us 6 months ago that CONF-4063 will be fixed by 2.7 and we were patiently waiting for the fix because we understand that this is major change in the database schema.
2.7 is out now and no one even touched this issue and we are starting to see more and more issues that are connected to this major flaw in the Confluence db schema.
Igor Minar
added a comment -
Ideally we should always reference user by id in all tables. This will eliminate a big chunk of potential problems and also will make username modifiable. But as it is quite complex we may fix this particular bug first.
Amen to that!!
If http://jira.atlassian.com/browse/CONF-4063 was fixed this problem would most likely not exist.
Atlassian promised us 6 months ago that CONF-4063 will be fixed by 2.7 and we were patiently waiting for the fix because we understand that this is major change in the database schema.
2.7 is out now and no one even touched this issue and we are starting to see more and more issues that are connected to this major flaw in the Confluence db schema. 
Max Vit
added a comment - Don't know if this helps but we have found that if you add the user twice, the UI will show you both users added on the Space Permission screen!
So if you apply the permissions to the 1st user shown on the UI and save it then it works as intended - the only thing is that your user appears twice on the Space Permission UI.
See attachments "User_KClarke-1.jpg" & "User_KClarke-2.jpg"
Max Vit
added a comment - Don't know if this helps but we have found that if you add the user twice, the UI will show you both users added on the Space Permission screen!
So if you apply the permissions to the 1st user shown on the UI and save it then it works as intended - the only thing is that your user appears twice on the Space Permission UI.
See attachments "User_KClarke-1.jpg" & "User_KClarke-2.jpg" OK, thanks Andy. I think we've got a good handle on the importance of this problem and we will try to get a fix scheduled very soon.
Andy Brook
added a comment - I just had this after an upgrade from 2.5.6 to 2.6.1. in edit mode, the View permission appears checked but in rendered mode, the (X) is present. I was trying to add myself (user ID is all upper case, eg ABC) which failed to mark the View permission.
The problem is most of my users have upper case IDs, so this may start biting...
Andy Brook
added a comment - I just had this after an upgrade from 2.5.6 to 2.6.1. in edit mode, the View permission appears checked but in rendered mode, the (X) is present. I was trying to add myself (user ID is all upper case, eg ABC) which failed to mark the View permission.
The problem is most of my users have upper case IDs, so this may start biting...
This bug was introduced by the fix to
CONF-5453