How to Fix Case Mismatches in Permissions

Still need help?

The Atlassian Community is here for you.

Ask the community

Symptoms

Some customers have reported problems with permissions, where some space and/or global permissions have been lost if using a case-sensitive database. The problem arises when the case of the username or group name, as referenced by the permission, does not match the case of the user's username or the group name.

Examples

1. User John Doe has username jdoe but the permission was created for JDOE.
2. User John Doe has username jdoe but the permission was created for JDoe.

In some cases, situations like those above may result in the space permission or global permission being ignored.

This issue should only affect Confluence 3.4.x and earlier. Confluence 3.5 introduced a different user management scheme that is not susceptible to DB case sensitivity.

Cause

In Confluence 2.7.2 and later:

  • The space permissions and global permissions screens will display a message highlighting any case-sensitivity mismatches.
  • We have also provided a routine to fix existing permissions affected by the case sensitivity problem, as described below. This routine is provided up to Confluence 5.1.x. Most recent versions of Confluence do not include the routine.

Resolution

To run this routine,

  1. Go to the following location in your browser:

    http://{CONFLUENCE-BASE-LOCATION}/admin/fixCaseInSpacePermissions.jsp
    
  2. Read the information on the page, to verify that you do indeed want to run this routine.
  3. Click 'Proceed' to run the routine.

What will the routine do?

If both the following are true: The username referenced by the permission,

  • does not exactly match any user's username, and
  • does match a username except for the difference(s) in upper/lower case.

Then the routine will change the permission's username to match the user's username exactly, in terms of upper/lower case.

Similarly for group permissions, the routine will change the permission's group name to match the related group name exactly, in terms of upper/lower case.

If one or more duplicate permissions exist as a result of this change, the duplicates will remain i.e. the routine will not remove any duplicated permissions. In these rare cases, you may see the following behaviour:

  • When you view the permissions on the screen, you will only see one row even if duplicates exist.
  • If you delete a permission which has a duplicate, the duplicate will show on the screen. So you may need to delete the permission again.

 

 

 

 

 

 

 

 

 

 

 

 

 

   

 

 

 

 

 

 

 

 

 

 

 

 

 

Last modified on Feb 26, 2016

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.