Details
-
Bug
-
Resolution: Won't Fix
-
Low
-
13
-
Severity 3 - Minor
-
Description
NOTE: This bug report is for JIRA Cloud. Using JIRA Server? See the corresponding bug report.
Summary
Permission schemes that have non-existent users explicitly added to a permission type cannot be edited (the header and sidebar load, but where the permissions should be listed is blank).
There's two situations where this can occur:
1) A user exists in a user directory, is granted explicit permission in a permission scheme, and the user directory that the user is in is subsequently disabled.
2) Back in the days of JIRA Studio and Enterprise Hosted instances, there were two special users with the usernames "enterprise-hosted-support" or "contegix" (or both) that were the equivalent of the current "sysadmin" user. There's several places in JIRA's codebase that check for this username and exclude it from various operations.
Steps to reproduce
- Start a local JIRA, connect it to an external user directory of some sort.
- Add a user that exists only in that directory (and not the internal JIRA directory) to a permission scheme.
- Import that JIRA data into a Cloud instance.
- Try to edit the permission scheme.
Expected results
The permission scheme page loads.
Actual results
Where the permissions should be is blank, and this stack trace is thrown in the logs:
2016-02-03 14:23:31,764 http-nio-2990-exec-53 ERROR sysadmin 863x4563x1 15k3ark 103.233.242.8,104.192.140.242,127.0.0.1 /rest/internal/2/managedpermissionscheme/0 [c.a.p.r.c.error.jersey.ThrowableExceptionMapper] Uncaught exception thrown by REST service: null java.lang.NullPointerException at com.atlassian.jira.permission.DefaultPermissionSchemeService.updateSchemeToReturnUsername(DefaultPermissionSchemeService.java:436) at com.atlassian.jira.permission.DefaultPermissionSchemeService.access$2200(DefaultPermissionSchemeService.java:58) at com.atlassian.jira.permission.DefaultPermissionSchemeService$13.apply(DefaultPermissionSchemeService.java:331) at com.atlassian.jira.permission.DefaultPermissionSchemeService$13.apply(DefaultPermissionSchemeService.java:327) at com.atlassian.fugue.Option$Some.fold(Option.java:421) at com.atlassian.fugue.Option.flatMap(Option.java:287) at com.atlassian.jira.permission.DefaultPermissionSchemeService.getScheme(DefaultPermissionSchemeService.java:327) at com.atlassian.jira.permission.DefaultPermissionSchemeService.getPermissionScheme(DefaultPermissionSchemeService.java:105) at com.atlassian.jira.permission.management.ManagedPermissionSchemeHelperImpl.getManagedPermissionScheme(ManagedPermissionSchemeHelperImpl.java:92) ... 3 filtered at java.lang.reflect.Method.invoke(Method.java:497) at com.atlassian.plugin.util.ContextClassLoaderSettingInvocationHandler.invoke(ContextClassLoaderSettingInvocationHandler.java:26) at com.sun.proxy.$Proxy131.getManagedPermissionScheme(Unknown Source) ... 3 filtered at java.lang.reflect.Method.invoke(Method.java:497) [...]
Workarounds
Workaround 1
For Cloud specifically, the following SQL will find the individual user and which permission scheme they're part of:
SELECT distinct(p.name), s.perm_type, s.perm_parameter FROM permissionscheme p, schemepermissions s WHERE p.id = s.scheme AND s.perm_parameter NOT IN ( SELECT user_name FROM cwd_user WHERE directory_id = ( SELECT id FROM cwd_directory WHERE directory_name = 'Remote Crowd Directory' ) ) AND s.perm_type = 'user' ORDER BY p.name asc;
To remove all of the missing users from the permission schemes:
DELETE FROM schemepermissions WHERE perm_type = 'user' AND perm_parameter NOT IN ( SELECT user_name FROM cwd_user WHERE directory_id = ( SELECT id FROM cwd_directory WHERE directory_name = 'Remote Crowd Directory' ) );
Workaround 2
- Create a user with the same username for any broken reference
- Change the Permission Scheme to remove the reference
- Remove the users
Attachments
Issue Links
- is duplicated by
-
JRACLOUD-60080 Permission Scheme 500 Error and Nullpointerexception
- Closed
- is related to
-
JRACLOUD-59781 Permission Scheme cannot be edited when it includes a single user
- Closed
-
JRASERVER-59683 Permission schemes with non-existent users that have been explicitly granted a permission cannot be edited
- Gathering Impact