New and Improved 3.13 Beta. Highlights: Shareable filters and dashboards and lots of other goodies. Any feedback can be raised as JIRA issues in the JIRA project.
Issue Details (XML | Word | Printable)

Key: CONF-9469
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Paul Curren [Atlassian]
Reporter: Anatoli Kazatchkov [Atlassian]
Votes: 12
Watchers: 9
Operations

If you were logged in you would be able to see more operations.
Confluence

Upper case letters in user names don't work with space permissions

Created: 13/Sep/07 09:10 PM   Updated: 14/Feb/08 10:57 PM
Component/s: External User Management, Permissions
Affects Version/s: 2.5.5, 2.6.0
Fix Version/s: 2.7.1

Time Tracking:
Not Specified

File Attachments: None
Image Attachments:

1. GroupPermissions1.jpg
(43 kB)

2. Grouppermissions2.jpg
(42 kB)

3. User_KClarke-1.jpg
(101 kB)

4. User_KClarke-2.jpg
(86 kB)
Issue Links:
Cause
 
Duplicate
 
Reference
 

Participants: Anatoli Kazatchkov [Atlassian], Andy Brook, Andy Brook, Don Willis [Atlassian], Doug Smart, Gurleen Anand [Atlassian], Igor Minar, Matt Ryall [Atlassian], Max Vit, Paul Curren [Atlassian], Per Fragemann [Atlassian] and Vishal J
Since last comment: 27 weeks, 6 days ago
Internal Complexity: 3
Resolution Date: 15/Jan/08 11:42 PM
Internal Value: 8
Labels:


 Description  « Hide
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.



 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
Gurleen Anand [Atlassian] added a comment - 04/Nov/07 06:51 PM
As a workaround to this problem, please use the "User or Group Picker" for selecting a user or group while assigning space permissions in Confluence.

Matt Ryall [Atlassian] added a comment - 05/Nov/07 06:06 PM
There is currently no simple way of removing the incorrect group/users. It is possible to do so with an SQL query on the database.

1. Shut down Confluence.
2. Back up your Confluence database.
3. Run the SELECT to check which rows you are going to remove (replace 'KEY' with the space key and 'UPPERCASE-GROUP' with the group name):

select *
from spacepermissions
where spaceid = (select spaceid from spaces where spacekey = 'KEY')
and permgroupname = 'UPPERCASE-GROUP';

There should be one row per permission granted to the group (view, edit, admin, etc).

4. Run the DELETE to remove the rows (again replacing the two variables).

delete from spacepermissions
where spaceid = (select spaceid from spaces where spacekey = 'KEY')
and permgroupname = 'UPPERCASE-GROUP';

6. Start Confluence again.

You can do the same for users by changing the column name 'permgroupname' to 'permusername' in the two queries.


Gurleen Anand [Atlassian] added a comment - 11/Nov/07 07:53 PM - edited
This problem has been observed and is reproducible on "Global Permissions" page as well, for both "Group Permissions" and "Individual Permissions".
The problem is related to both LDAP and local groups for "Group Permissions" but only related to LDAP users for "Individual Permissions"
Steps to reproduce:

1) Without using the "Group Picker", type the name of the group in lowercase
2) Add this group and grant "Can Use" permission
3) Save
4) Edit the permission and remove the "Can Use" rights
5) Save

Result: The "Can Use" permission is still assigned to this group via UI and in the DB as well.

As a workaround to removing the "Can Use" permission for an individual user/group, please run the following query on your DB:

SELECT * FROM SPACEPERMISSIONS WHERE PERMTYPE = 'USECONFLUENCE' AND PERMUSERNAME = '<Username>'  - For user permissions
SELECT * FROM SPACEPERMISSIONS WHERE PERMTYPE = 'USECONFLUENCE' AND PERMGROUPNAME = '<Groupname>' - For group permissions

Ensure that correct entries have been listed by this query and then delete these entries by:

DELETE FROM SPACEPERMISSIONS WHERE PERMTYPE = 'USECONFLUENCE' AND PERMUSERNAME = '<Username>' - For user permissions
DELETE FROM SPACEPERMISSIONS WHERE PERMTYPE = 'USECONFLUENCE' AND PERMGROUPNAME = '<Groupname>' -For group permissions

Please avoid manually typing in the name of the user or group while adding them to the global permissions, instead use the "Group/User Picker", to avoid this problem.


Doug Smart added a comment - 14/Nov/07 02:21 PM
This is the first of 2 screen shots depicting my problem. You can see that all of the permissions are checked for both groups. However on the second screen shot you will see that "WHStaff" does not have view permissions after saving.

Doug Smart added a comment - 14/Nov/07 02:22 PM
this is the second screen shot that shows that the second group does not have view permissions even though the check box is checked properly.

Doug Smart added a comment - 14/Nov/07 02:25 PM
I believe I'm having the same problem as everyone else. When I assign multiple active directory groups permissions on a space only one group will save the view permissions (see attached screen shots Grouppermissions1.jpg & Grouppermissions2.jpg).

I definitely need to be able to assign multiple groups access to the same space.


Paul Curren [Atlassian] added a comment - 21/Nov/07 12:47 AM
Thanks for the additional investigation Doug. It all helps.

Doug Smart added a comment - 21/Nov/07 08:22 AM
I created a new space and added a lower case group as the first group given permissions. I was then able to add subsequent groups (even ones with uppercase letters) and give them view access. The big problem is that my lower case group contained nested LDAP groups and those permissions did not apply. I have not had a chance to test this on the spaces that were causing the problem previously.

Doug


Andy Brook added a comment - 23/Nov/07 05:35 AM
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...


Paul Curren [Atlassian] added a comment - 25/Nov/07 06:56 PM
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.

Max Vit added a comment - 20/Dec/07 09:27 PM
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"


Igor Minar added a comment - 21/Dec/07 05:43 AM

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.


Andy Brook added a comment - 03/Jan/08 03:55 AM
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?

Vishal J added a comment - 10/Jan/08 11:23 PM
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.!

Paul Curren [Atlassian] added a comment - 11/Jan/08 12:33 AM
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.

Andy Brook added a comment - 11/Jan/08 04:41 AM
Ok fab, can't ask for more, other than a 2.7.1 due date

Paul Curren [Atlassian] added a comment - 15/Jan/08 11:44 PM
Andy, 2.7.1 should be released Wednesday 23rd January.

Don Willis [Atlassian] added a comment - 14/Feb/08 10:57 PM
This bug was introduced by the fix to CONF-5453