Hi Atlassian

Can this be reopened please? Users are able to escalate their permissions and give themselves the ability to delete, which is a serious problem for us.

If your users want the "feature" changed, then shouldn't they be able to vote on it?

Regards

Maree

lgoodhewcook Thank you for your reply.

It isn't happening every day. However, the approach being taken by Atlassian in this regard has meant that we've had to take compromises in regards to our setup of Service Desk.

This issue was raised initially because I had adopted very tight permissions in Service Desk for customers. The default permissions set up by Atlassian were, I felt, too permissive without there apparently being any need for them at this time. Indeed, in an exchange of messages with the support engineer, it was clear that this was forward planning on Atlassian's part but there wasn't currently any way for customers to take advantage of those permissions.

So, Service Desk complains about the fact that my stricter permissions are not appropriate and wants to reset them. A project lead sees that message, clicks on the button and, hey presto!, that project now has default permissions (which I don't want) AND now has its own set of permissions rather than a single set of centrally managed permissions.

The fact here is that if a project administrator does not have the correct permission to modify the permission set, taking the approach of copying the existing permissions into a new permission set is just wrong. If a JIRA administrator has decided that project administrators shouldn't be able to modify permissions, why are Atlassian overruling the JIRA administrator's decision? That's what my beef is with this approach. I've set up permissions to control how I want JIRA and Service Desk to operate and you are riding roughshod over that.

Given that this bug report has already been closed as won't fix, why should a suggestion do any better? This is simply an incorrect philosophy that Atlassian have implemented here but it doesn't look like anyone at Atlassian is going to agree with me.

Regards

Philip

Hi philip.colmer,
thanks for your feedback.

In terms of this issue, there are a couple of points that we ought to clarify.

1) Maintaining Customer data is more important than just about anything I can think of.
Because of this, when we design features we make trade-offs in favour of preserving Customer data.  When automatically fixing permission schemes we could just update the permission scheme in place, and this would certainly match your use case better, but this could risk accidental or unintentional loss of data for other Customers and that's something that we will not allow. By making a copy of the old scheme it is possible to revert back to it at any time. The new scheme should be identical in every way to the old scheme with only the necessary changes made to make it functional.

2) The behaviour of creating a new permission scheme and modifying it is the same regardless of whether a Project Administrator does the fixing or a JIRA Administrator does the fixing.

3) The scenario where a permission scheme needs fixing should occur rarely. If this is happening for you every day then we would like to hear why that is the case and/or how that is occurring.

4) We are always open to Customer feedback.  This is why jira.atlassian.com is open and why Customers are able to comment, vote and watch tickets - even if they are Closed.
If we receive feedback from many users on this issue, we have the option to re-open.

5) Given the outcome on this bug ticket, you are welcome to create a suggestion and our Product Managers will review along with all other suggestions.

Thanks,
JIRA Service Desk Team.

Isn't it a bit arrogant to just close an issue permanently, thus preventing customers from adding useful feedback that may then result in a positive engagement with those customers?

It may be the expected behaviour but it is the WRONG behaviour.

In order to work around the fact that the project administrator doesn't have enough rights, the system ends up creating NEW permission schemes, thus breaking all of the hard work that the JIRA administrator has put into creating as few permission schemes as possible.

This needs fixing.

mnassette 

This is expected behaviour outlined here: https://confluence.atlassian.com/display/JIRAKB/Standard+permissions

In JIRA Service Desk, project administrators are allowed to change permissions. You do not need to be a JIRA administrator with global privileges to modify permissions schemes in your service desk projects.

Thanks,

JIRA Service Desk Team

This also affects version 3.1.0.