This bug was introduced by the fix to CONF-5453

Andy, 2.7.1 should be released Wednesday 23rd January.

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.

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.!

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?

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.

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"

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...

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

Thanks for the additional investigation Doug. It all helps.

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.

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.

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.

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.

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.

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.