When granting permissions, the Service Management Customer Portal Access Permission is missing

Still need help?

The Atlassian Community is here for you.

Ask the community

Platform Notice: Server and Data Center Only - This article only applies to Atlassian products on the server and data center platforms.

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:

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)

(info) 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:

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.

(info) 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:

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")
    );

(info) 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.

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 performing any modifications to the database. If possible, test any alter, insert, update, or delete SQL commands on a staging server first.


DescriptionThe
ProductJira Service Management
Last modified on Nov 23, 2020

Was this helpful?

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