Loading...

Details

Type: Bug
Resolution: Unresolved
Priority: Low
Fix Version/s: None
Affects Version/s: 7.1.0-OD-05, 7.1.6, 7.1.7, Archived Jira Cloud
Component/s: Project Administration - Permissions
Labels:

Introduced in Version:
7.01
Support reference count:
14
Symptom Severity:
Severity 3 - Minor
UIS:
0
Bug Fix Policy:
View Atlassian Server bug fix policy

Description

NOTE: This bug report is for JIRA Server. Using JIRA Cloud? 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

JRASERVER-60080 Permission Scheme 500 Error and Nullpointerexception

Gathering Impact

is related to

JRASERVER-59781 Permission Scheme cannot be edited when it includes a single user

Closed

relates to

JRACLOUD-59683 Permission schemes with non-existent users that have been explicitly granted a permission cannot be edited

Closed

Permission schemes with non-existent users that have been explicitly granted a permission cannot be edited