When granting permissions, the Service Management Customer Portal Access Permission is missing
Platform Notice: Data Center Only - This article only applies to Atlassian products on the Data Center platform.
Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Summary
Problem
When attempting to grant permissions in a permission scheme, the "Service Management Customer - Portal Access" grantee is missing. Alternatively, when opening a permission scheme with those permissions already in it, you receive a 500 error in the browser.
Removing the permission manually from those schemes in the database (by deleting sd.customer.portal.only entries in that scheme via the database) allows the scheme to be displayed correctly.
The following stack trace accompanies the 500 error message in the atlassian-jira.log:
1
2
3
4
2019-02-03 23:33:24,841 http-nio-8080-exec-120 ERROR aleksey.moskalyov 1413x4302x3 omre3k 10.50.15.17,0:0:0:0:0: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.management.ManagedPermissionSchemeHelperImpl.buildGrants(ManagedPermissionSchemeHelperImpl.java:367)
at com.atlassian.jira.permission.management.ManagedPermissionSchemeHelperImpl.lambda$generatePermissionSchemeBean$4(ManagedPermissionSchemeHelperImpl.java:249)ℹ️ The ID shown in the URL (0 in this case) may change -
Additionally, upon restarting, you may see the following appear in the atlassian-jira.log:
1
2
2019-02-04 23:13:59,123 active-objects-init-JiraTenantImpl{id='system'}-0 ERROR anonymous [n.java.ao.sql] Exception executing SQL update <ALTER TABLE jiraschema.AO_54307E_CAPABILITY DROP CONSTRAINT U_AO_54307E_CAPABIL1680206402>
com.microsoft.sqlserver.jdbc.SQLServerException: 'U_AO_54307E_CAPABIL1680206402' is not a constraint.ℹ️ This problem may occur in other database types, and the constraint name may be different - the key factor is the table, AO_54307E_CAPABILITY.
Diagnosis
Check to see if the schema has been altered from the default:
1
2
3
4
5
6
7
8
9
10
11
12
CREATE TABLE
"jira3161"."public"."AO_54307E_CAPABILITY"
(
"CAPABILITY_NAME" CHARACTER VARYING(255) NOT NULL,
"CAPABILITY_VALUE" CHARACTER VARYING(255) NOT NULL,
"ID" INTEGER DEFAULT nextval('"AO_54307E_CAPABILITY_ID_seq"'::regclass) NOT NULL,
"SERVICE_DESK_ID" INTEGER NOT NULL,
"USER_KEY" CHARACTER VARYING(255),
PRIMARY KEY ("ID"),
CONSTRAINT "fk_ao_54307e_capability_service_desk_id" FOREIGN KEY ("SERVICE_DESK_ID")
REFERENCES "jira3161"."public"."AO_54307E_SERVICEDESK" ("ID")
);ℹ️ The example is from Postgres on Jira Service Management 3.16.1, but should be reasonably similar across other database types. Note that there is a primary key, and a foreign key constraint that references another table - but no other types of constraint or index
Cause
There are variations in the table structure that Jira is attempting to remove, but failing. In the example above, U_AO_54307E_CAPABIL1680206402 was a unique index, that Jira attempted to drop as a constraint, which failed.
Solution
Resolution
Remove the variations from the table structure. It may be necessary to use a fresh installation on a test instance, to determine what the correct, default structure is for your specific database type and version.
Always back up your data before making any database modifications. If possible, test any alter, insert, update, or delete SQL commands on a staging server first.
Was this helpful?