Issue permissions: modify task, not epic

Andrea Marchesini
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
September 25, 2024

Hello everyone,

I'm a newbie to jira.

On an organization project, I need to set users permissions in order to allow edit tasks and subtasks, but not epics. 

Example:

Progect Members - can view Epics, Tasks and Subtasks. Can edit Tasks and Subtasks. Can't edit Epics

Project Managers - can create/edit Epics, Tasks and Subtasks.

What is the best practice?

Thank you

 

2 answers

1 accepted

2 votes
Answer accepted
Walter Buggenhout
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
September 25, 2024

Hi @Andrea Marchesini and welcome to the Community!

My first advice would be: don't do that. Communicate with your users and make working agreements about who does what. Jira keeps track of all changes to issues, so if someone does change something he/she actually shouldn't, you will be able to trace that from the issue's history tab.

If you really have to implement the restriction, one way might be to keep your epics in a separate (company managed) project and your tasks / sub-tasks in a different project. That way, you can set edit issues permissions differently at project level. One of the downsides of this approach is that bringing your epics and other issues in different projects, will require you to set up a board based on a filter from those 2 projects. That will work, but you will no longer be able to view your work on the timeline view, as that does not support your issues coming from multiple projects.

Other solutions (when you keep your issues in the same project), would be to use issue level security, setting up different security levels for your bespoke roles. You then have to make sure to assign the right security scheme to your epics and other issues every time.

You could also make sure your Epics use a different workflow than the other issue types and then apply workflow properties to restrict editing to certain groups or project roles.

Both last options don't scale very well and the first one (with the epics in different projects) may (not) cause unwanted side effects. That's why I would recommend to see if you can't work together first based on work agreements and good communication amongst your team members.

Hope this helps! 

Dick
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
September 25, 2024

As @Walter Buggenhout mentioned, communication is key in agile projects. It blossoms only in a safe environment, where people can freely speak their minds.

If the project managers described by the OP have multiple projects under their wings (read: have a wider-scoped interest across these teams) the two-tier-project approach is certainly a way to go, and by far the easiest to set up and maintain. 

 

Like Andrea Marchesini likes this
1 vote
Fabio Racobaldo _Herzum_
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
September 25, 2024

Hi @Andrea Marchesini and welcome,

Edit Permission are per project basis and not for specific issue type. My suggestion is to associate epic to a specific workflow and set workflow properties (https://support.atlassian.com/jira-cloud-administration/docs/use-workflow-properties/) for each status of epic workflow in order to not allow edit.

Hope this helps,

Fabio

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PERMISSIONS LEVEL
Product Admin
TAGS
AUG Leaders

Atlassian Community Events