As a workaround, we have hidden the warning about changed / "custom" permissions with CSS (JSDSERVER-3657) and i can't find any other way that a project admin can do this. Since that we don't have changed permissions anymore.

Ping: Anyone at Atlassian able to comment on when this might get fixed to at least allow JIRA administrators from disabling the prompt?

If it's "working as designed," then the design is incorrect, given that the design of JIRA Core is that only global administrators can change a project's permission scheme. Why isn't this capability in Service Desk considered as grievously contradictory of basic JIRA principles?

This is preventing our organization from using JSD without breaking our legal department's compliance requirements. Frankly, I'm not sure what line of thought led to this implementation. Only a global administrator can edit and 'break' the project's permission scheme in the first place, so what's the point in allowing project admins to 'fix' it? Surely global admins should be the ones to actually apply the fix, even if everyone sees a message about it. Perhaps having a JSD setting to toggle for whether project admins see the button, or even the whole message if that's easier, is a reasonable solution.

Thank you for taking a look at the suggestion, and I hope it gets some traction!

Hi,

This is currently working as designed.

We override JIRA's permission to allow project administrators to make this decision, as our default schemes are project specific.

However, I have not closed this, and instead moved to a Suggestion that it can come to the attention of our Product Managers for another look.

Regards
Matt
JIRA Service Desk developer

Please don't allow project admins to spawn new permission schemes. This is very bad for organizations that are standardized on permission schemes.

I hope new features will be more cognizant of this as we encountered a similar problem in the past where end-users could create unlimited Custom Fields via new SLA definitions.

I would say this is a major issue, as this potentially enables 'delete all issues' permission to the wrong people.

We don't delete issues, ever, because we have a very strict data retention policy. I've deleted only a few issues, and those were ones that had extraordinarily sensitive information. In fact, no one has the Delete Issues permission so that, if it becomes necessary to delete one, I have to go grant myself the permission, delete the issue, and then revoke the permission.

Imagine my surprise to discover that Service Desk was helpfully allowing project administrators to change their projects' permissions to those that include very broad Delete Issues! We've already had at least one issue deleted by someone who didn't realize that Deleting Issues Is Forever™

FWIW and with a tip o' the hat to Atlassian support peeps, I have observed that if someone accepts Service Desk's generous offer to modify permissions, then that user will POST to /rest/servicedesk/1/permission/configuration/PROJECT_KEY/misconfiguration/fix. Support's suggestion is to redirect that POST to something else. While I haven't implemented that yet, at least that knowledge allows me to determine when someone has changed a project's permissions. I can switch their permission scheme back and let them know that they should just dismiss the warning next time.

Furthermore, if a user dismisses the warning, the POST is to /rest/servicedesk/1/permissions/configuration/PROJECT_KEY/misconfiguration/dismiss. My weekend project is to build a robot that will automatically deliver that user a food pellet. With that kind of positive reinforcement, the problem won't persist for long! However, it would still be good to fix this.

I just submitted a support request for this. We had a user hit the "Migrate this Project" button on Friday and locked over 200 users out of one of our flagship projects as the developer role was removed from the permission scheme when the JSD permission scheme got applied by a project admin not a jira-administrator. This is bypassing a core feature of JIRA that limits this permission and a classic reason why it should limit this permission. (IE: https://jira.atlassian.com/browse/JRA-3156). We have 500+ project in JIRA and many using JSD. This is a major security leak IMHO.

I agree in 100% and this is not minor issue. I already had 3 cases when Project Administrator created Service Desk without awareness what he did. Automatically people lost access to the project because permission scheme had changed (we use non-standard roles and permission scheme).