The permission scheme and the workflow conditions have to be checked and applied.
It makes sense to restrict this permission, because users are not always aware about processes behind an issue and Project Leads might want to keep issues unclosed until the Customer has accepted the Solution.
But sometimes an issue is created by mistake, so it makes sense, to give the reporter the permission to close an issue, if the status is still open (this permission is given in the workflow step)
No. That applies when an issue has been broken by a crash, corruption or dodgy code. We have no evidence that that is the case here, the question strongly implies many issues with the default workflow, which really does mean the conditions. Before slinging a pointless "fix" at a problem, you need to know *why* there is a problem, and we don't know what the root cause is yer.
Hi David, You've requested for help on this a while ago but since I was having the same issue I wanted to post my solution here for others to see. When we noticed that users were unable to close issues, even with the project group assigned to the Close issues permission, We started messing around with the rights in the permission scheme to see if the rights were linked to each other in some way. So in the end we discovered that the group has to be assigned to the 'Transition Issues' permission before the users in the group are able to edit/close issues in the Jira Project. I hope this can help someone out!
In other words, check the permissions! Transition issues is a new permission for JIRA 6.3 I think. It does NOT control "edit" as you suggest here, it just stops people using transitions if they do not match the rule. I'd also recommend using roles over groups in your permission schemes, and I'm a bit worried that one of your administrators removed the right from the permissions!
Hi Nic, Thanks for your response. We are a medium sized software company and use the Projects for web and back-end development. The project I created was new so no rights were removed from the permissions. Why would the use of roles be better instead of using groups? You would still have to assign a group to the roles if I'm right? Thanks!
>The project I created was new so no rights were removed from the permissions. The default permissions scheme says "Grant transition rights to Role: Users". You might not have removed or changed permission schemes while creating this project, but someone probably has changed the schemes in the past. Or, on the other hand, if you're using groups instead of roles, it might be that you didn't notice that the defaults are all set up to work with roles. This is one minor reason for sticking with roles. The major reasons are that you can reuse things better - I've seen huge JIRA systems with only 3 permission and notification schemes because roles simplify things vastly for schemes. They allow you to delegate the user maintenance to your project owners so that you don't need 5 administrators hacking around groups and having to create new workflows and schemes *Every* time a group behaviour needs to be changed. As a general rule, I advise everyone to avoid the use of groups in the configuration for anything other than global permissions, reporting and for those odd projects with really odd security requirements. Groups are great for grouping people up... then adding to roles when you don't want to handle individuals.
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot