|
[
Permlink
| « Hide
]
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.
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. 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. 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 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. 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 is the second screen shot that shows that the second group does not have view permissions even though the check box is checked properly.
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. Thanks for the additional investigation Doug. It all helps.
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 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... 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.
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"
Amen to that!! If http://jira.atlassian.com/browse/CONF-4063 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. 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, 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.
Ok fab, can't ask for more, other than a 2.7.1 due date
Andy, 2.7.1 should be released Wednesday 23rd January.
This bug was introduced by the fix to
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||