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; } } }

Is it possible to have groups within the same project alter the same issue but have different fields according to that group?

Johann Pinga

Say person A from project xyz is working on board abc with issue 123, and person B is working on project xyz, on a different board, with the same issue, 123.

Would it be possible for both persons from different groups to edit this issue but alter what information is seen by both groups?

e.g. I want person A to see updates that person B makes regarding issues being assigned to a sprint.
But I do not want person A to see all the technical updates, development procedures etc.

AND
I want person B to see the status of the workflow but cannot edit or move issue along workflow

I basically want to see if it is possible for fields to be developed according to the different groups
where:

some information is shared, but cannot be altered dependent on the group they are from.
certain information is shared only to that specific group
fields are mandatory from that specific group.

Accepted answers

Nic Brough -Adaptavist-

The first part of the question is really simple - no. A JIRA issue has a collection of fields. Who you are is irrelevant when you look at it - you see everything for the issue. (Except hidden comments)

Atlassian have stated that they will not be doing "field security", mainly because it goes against the principle of openness and collaboration at the heart of of JIRA. But there is an add-on that can do most of it - Quisapps Field Security add-on (Much as I dislike the principle, the add-on does work very well. Your users will be able to work out a field that they cannot see is there, but they will not get to the content)

On the second part, yes, that's easy. You need to have different "conditions" on the workflow. A very blunt example is "You have to be in group A to use this transition". Person B is not in that group, so they can't move it on.

All comments

Nic Brough -Adaptavist-

Johann Pinga

Okay, so everything by default is seen, but is it possible to have some groups only alter specific fields?
e.g. I don't want the dev team to alter specific portions of the BA team's information on that issue

Nic Brough -Adaptavist-

Yes. I concentrated on the Quisapps add-on because if you have requirements around visibility, you might as well use it for "edit" as well.

However, if you're happy with "if user can see issue, they can see all the fields", then we can talk about "edit" being limited by standard JIRA without add-ons.

The basic principle is that you move the field edit into the workflow. Let's assume you have a field called "colour" (the type of field is not important, as long as it's data a user can enter). A simple JIRA setup will include the Colour field on View, Create and Edit screens, which are controlled by the "Issue type screen scheme"

To protect it, you need to separate it out. Use a different screen for "edit" and "create". Make sure that you remove it from the "Edit" screen. This will stop anyone from changing the value after the issue is created.

Now add another screen that contains Colour. Go into your workflow, and add transitions that go back to the same status, with your new screen as the transition screen. Then, add conditions like "only people in the BA team can use this transition". You know have an issue where everyone can see Colour, but only the BAs can change it.

MattS

Nic, what about using the Behaviours add-on, part of ScriptRunner?

Welcome!

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

Quick Links

Find more posts tagged with

custom-field

jira

filter

field

group