Issue Security based on custom field not inherited by subtasks

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!

2 answers

1 accepted

0 votes
Accepted answer

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.

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.

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.

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

Yes, it is a bit of a pain, I know.

Very nice try at a dynamic fix you tried there, using the script runner to derive a field. I've done something similar by writing a custom field that extracted the users I needed and then presented itself as a user list field and that worked. But that's an extra plugin and coding to maintain.

For anyone interested, I've now used the Field Sync plugin ( 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!

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!)

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Wednesday in Jira

Make your Atlassian Cloud products more secure: our NEW admin security guide

Hey admins! I’m Dave, Principal Product Manager here at Atlassian working on our cloud platform and security products. Cloud security is a moving target. As you adopt more products, employees consta...

85 views 0 4
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you