I want to allow only a few selected users to create and manage releases (versions) in Jira without granting them full Administer Projects permissions.
Currently, the "Manage Sprints" permission is assigned to the following roles:
I would like to create a setup where only specific users (not everyone in "Project Member") can create releases while keeping other project settings restricted.
Hello @Sundram Trivedi
There is not a direct way to give a user only the permission to create Release Versions for a project without giving them the Administer Projects permission for that project. However, there might be a work around.
You could create an Automation Rule that uses a Manual Trigger and prompts the user for the new Release Version name.
You can restrict the ability to run a manually triggered rule to specified user groups, so you would have to create a user group for these users that should have the permission to create Release Versions.
The Automation Rule, running as the Automation for Jira user, could then use the Create Version action to create the specified Release Version.
Hi @Trudy Claspill ,
Thanks for the suggestion! 😊 I like the idea of using an Automation Rule to create release versions. However, I want the rule to automatically create a new version based on the previous version.
I noticed that you mentioned using a Manual Trigger—does that mean the user has to trigger it manually each time? If so, is there a way to make it fully automated, so the rule runs automatically whenever a release is closed or a new sprint starts?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I noticed that you mentioned using a Manual Trigger—does that mean the user has to trigger it manually each time? If so, is there a way to make it fully automated, so the rule runs automatically whenever a release is closed or a new sprint starts?
The problem you asked to solve originally was giving "a few selected users" the ability to create releases. If you really want only a few users to be able to create releases, then it would have to be a Manual Trigger rule. Manual Trigger rules are the only ones where you can limit who can execute the rule. And yes, the user would have to manually trigger the rule when they want to create a new Release Version.
If you want a fully automated rule to create a new release, that is a separate issue.
You can create a rule that is triggered by the Start of a sprint. You have to specify the Scrum Board in the trigger, so if you wanted that rule to work for multiple boards then you would need a rule for each board.
Within that rule you could use the Create Version action to create a Release Version.
I'm not sure what you mean by a "release is closed". There is a trigger for Version Released.
You could use that trigger and include, again, the Action for Create Version.
If you are new to constructing Automation Rules you may want to take advantage of the free, on-demand training available at https://university.atlassian.com, and you can find the documentation here:
https://support.atlassian.com/cloud-automation/docs/jira-cloud-automation/
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Welcome to the community,If you want to restrict to create fix version/Releases then you can update the resolve issues permission in project permission scheme and you can give access in single user and if you want to add many users you can add in single user many times so only that users can create fix versions in the project
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Your answer is incorrect.
That permission applies to setting the Fix Versions field in an issue. It does not apply to being able to create a Release Version for a project.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Trudy Claspill Thanks for letting me know If I created releases in my project it will show in fix versions right.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Trudy Claspill , @Pasam Venkateshwarrao
I appreciate your response, and thanks for the detailed explanation! 🙌
I tried searching for this solution but couldn’t find a direct answer, like assigning users to the "Resolve Issues" permission it needs a Admin permissions.
Yes, @Trudy Claspill you are right we can create automation rule for this.
One more doubt I have:
👉 Is it possible to create a separate project role specifically for release creation and assign users to it, without giving full Admin access? That way, users could manage releases but not have broader project admin rights.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Is it possible to create a separate project role specifically for release creation and assign users to it, without giving full Admin access? That way, users could manage releases but not have broader project admin rights.
No, that is not possible. There is not a separate permission for managing releases. That function is available only as part of the Administer Projects permission.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I am bemused as to why a Project Permission for create a release is set in the Highest tier of Administrator Permission.
This breaks the protocol of least privilege access.
Why would any org want to risk giving an un-trained person Administrative access to their products when all they require is a Create Release permission !!
Absolutely crazy scenario !
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.