security level: issue disappears by assigning to not permitted user

We re using one security level (and none security) for our issues. It is possible to assign an issue having a security level to a user, who is not having any permission on security levels.

So the issue dissappears: the assigned user is not seeing it and the one who has assigned it is thinking that the other one is working on it. Strange behaviour, isn t it?!

-> Is there a way to avoid that one can assign issues with sec-level to persons who will not be able to see it?

1 answer

1 accepted

This widget could not be displayed.

Not really, this is correct behaviour. You've got a rule that says "people have to be in group X to see this issue", so when someone outside the group is assigned the issue, they can't see it. You need to grant the assignee the right level of security for that issue.

But shouldn t than JIRA check on assigning if security levels fit? I don t see a reason for assigning an issue to somenone who won t be able to process or even see it. This leads into "dead-ends" in the process, especially because the person that assigns an issues to soemone else doesn t necessarily know if the desired person really has a corresponding permission.

And I assume it would be cheap/simple to check if desired assignee has the corresponding security level. So JIRA could permit or at least warn the user.

Definitely would be a good check to have, but I don't think it's always right for everyone to enforce it.

I've not noticed a feature request for it though. My searching on jira.atlassian.comhas failed me again.

I once implemented a custom field for a client that was really simple - if you assigned an issue to someone who didn't have access, it put a huge red box on-screen saying "assigned user can't see this". I suspect you might be able to do this with a script-runner scripted field. It is a bit after-the-fact though.

I did have a better fix in an older version - another derived field, done in a plugin - it was a "multi user" type field, but it derived the contents from "can see this security level" and "assignable user". Then we used it in the "assignable user" permission, so the list was chopped down to just those who could see it. (Yes it looks recursive, we had to code with that in mind)

Suggest an answer

Log in or Sign up to answer
Atlassian Summit 2018

Meet the community IRL

Atlassian Summit is an excellent opportunity for in-person support, training, and networking.

Learn more
Community showcase
Posted Wednesday in New to Jira

Are you planning to trial, or are currently trialling Jira Software? - We want to talk to you!

Hello! I'm Rayen, a product manager at Atlassian. My team and I are working hard to improve the trial experience for Jira Software Cloud. We are interested in   talking to 20 people planning t...

215 views 3 0
Join discussion

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