nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Issue permissions: modify task, not epic

Andrea Marchesini_42ju8v

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

Accepted answers

Walter Buggenhout

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!

All comments

Fabio Racobaldo _Catworkx_

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

Walter Buggenhout

Hi @Andrea Marchesini and welcome to the Community!

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.

Hope this helps!

Dick

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.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud