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 Security based on custom field not inherited by subtasks

Tamsin Slinn

We have an issue security scheme where the issue is visible to the user identified in an "Employee" custom field on an issue.

However, if I try to add a subtask to the issue the subtask just seems to disappear.

I'm guessing I can't see it as the subtask does not have the "Employee" custom field, but I though subtasks inherited security from the parent?

Will I need to copy the value from the parent to all subtasks? Not sure how this could be kept in sync if the parent is edited.

Thanks for any help!

Accepted answers

Nic Brough -Adaptavist-

It is inheriting the security from the parent.

It is NOT inheriting the Employee custom field - that's why it vanishes. Fields are dynamic and carry different values for different issues. What you're doing is setting security which says "For the current issue, look at the employee field, and show the issue if the user is in there". No employee field on the sub-task means the security setting goes "oh, they're not there, hide it"

Another way of putting it might be that it is inheriting the security level data from the parent, but then being hidden because the data doesn't match the "is visible" rule.

All comments

Nic Brough -Adaptavist-

It is inheriting the security from the parent.

Another way of putting it might be that it is inheriting the security level data from the parent, but then being hidden because the data doesn't match the "is visible" rule.

Tamsin Slinn

Hmm, I guessed that was the case - it's not inheriting "the visibility of the parent to the current user", just the security level id, and then applying the rules to itself.

Slightly irritating behaviour! As suibtasks are not allowed their own security level, I thought the intention was that if you could see the parent, then you could see the subtasks.

It means we could get in a situation where a user could view a subtask but not the parent. Not sure how Jira would cope with that. I'll have to look at keeping the fields in sync somehow.

Nic Brough -Adaptavist-

Well, it is applying the rules correctly, the problem is that you've introduced a rule that's based on variable issue data instead of a fixed data item.

Sadly, "visibility by parent" is the simple approach, but it's inadequate. I have been in places where people should see a parent and not a subtask (in fact, one place migrated to Jira just so they could do it!), so the current system is better than parent inheritance. But it is more complex to explain, debug or use.

Tamsin Slinn

I understand how it work, and I can see why people might want it that way, just not me

I tried using a script runner field in the subtask to display the parent field value, but the field isn't available to use in the Security Level popdown, I guess because it isn't a standard "User field". So it looks like I have to use a Post Function to copy the value over when subtasks are created, and then hope the values don't get out of sync.

Thanks for the help

Tamsin Slinn

For anyone interested, I've now used the Field Sync plugin (https://marketplace.atlassian.com/plugins/com.obss.plugin.fieldSync) to keep the values in the subtasks in sync with the parent. I've used a screen scheme to make the employee field none editable in the subtasks, so it can only be changed in the poarent, and then propogates to all subtasks. Now the issue security works how I want!

Nic Brough -Adaptavist-

Not far off what I did. I'm pretty sure it's the best way to get what you need (and better than my fix, because my plugin coding is weak at best!)

Welcome!

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

Quick Links

Find more posts tagged with

jira

jira-administration

issue-security