Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Deleted user
0 / 0 points
badges earned

Your Points Tracker
  • Global
  • Feed

Badge for your thoughts?

You're enrolled in our new beta rewards program. Join our group to get the inside scoop and share your feedback.

Join group
Give the gift of kudos
You have 0 kudos available to give
Who do you want to recognize?
Why do you want to recognize them?
Great job appreciating your peers!
Check back soon to give more kudos.

Past Kudos Given
No kudos given
You haven't given any kudos yet. Share the love above and you'll see it here.

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Issue security level flagged as wrong even when not necessary

I have an external team ("Community Villa" below) unable to access the issue type they are supposed to be able to see:


Basically, Community Villa is supposed to have access only to a certain type of issues (called "Content idea").

I've set the security scheme by putting our employee group as default Security Level field, so every task that has that field automatically prevents Community Villa from entering.

However, Content idea issue types don't have the Security Level field: 



Project permission for their group to browse the project is active. Therefore, the alert makes no sense to me, seems more like a bug (especially because they seem to be able to access other tasks of the same type).


2 answers

0 votes

The isssue you are looking at has a "security level" set on it.  Community Villa is not named in the level as someone who has access to the issue.

It's not a bug, you've just hidden the issue from them with issue security.

Either change the security level on the issue to one that does include the user, or amend the security scheme so that it includes the user in the level

But why? The security level field is not even enabled on the issue screen, which (to my understanding) should mean there's no security level required for that type of issue. And even if that was the case, that doesn't explain how is it possible that only this one task is not accessible by them while other of the same type are.

The screen definition is simply what fields are presented to a user when they take a particular action (create, edit, view, or transition)

It does not matter whether you have "level" on the screen or not.

For this issue, someone has set a level, I'd guess at a time when level was available on screen, or it may have been set by a script or automation.

However it got set is not the point here though.  The fact is that it has been set on this issue, and Community Villa is not named in the level so they can't see the issue.

So, either change the level to include Community Villa, or change (or remove) the level - to do that you may need to (temporarily) add the security level back on to the edit screen and then have someone who is in the current level to edit it.

Ack, sorry, not quite the right answer, Community Villa is not supposed to be seeing the issue, so you don't want to include them in the security.

However, the principle about where the security level applies is the same.  You have two things in the permissions analysis - first Community Villa is not in the security level, and second, they also do not have permission to see the project.

So, you need to do two things:

1. Grant Community Villa the right to see the project

2. Have another look at the security level - the scheme is applied at a *project* level and it does not matter whether the field is on the screen or not.  If a security scheme is associated, it applies to all issues in the project, the screen is irrelevant.

Like Giorgio Crosali likes this

@Nic Brough _Adaptavist_ thanks for taking the time to explain this. May I take advantage of your knowledge to ask you what would be the best way to ensure that the group visibility is limited to a certain type of issue? Issue-level permissions have been the cause of my biggest headaches with Jira so far.


For the sake of simplicity, let me pose my question in the form of a problem:

  • There are two groups (Group A and Group B) and three types of issues (X, Y, Z)

How do I set security levels in such a way that:

  • Group A can be able to browse, create and edit issues X but must not see Y, Z
  • Group B can be able to browse, create and edit all types of issues


There is no way to do that easily or directly by issue type, but it can be done with some setup and a bit of education for group B.

I'll try to give the most simple structure for it here.

  • Set up the project so that Group A and B all have Browse, Create and Edit rights.
  • Create two workflows (probably get the easy one right first, then copy it and add the complicated bits to get the second).
  • Set up an issue security scheme with only one single level, such that
    • <no issue level set> means everyone can see the issue
    • Secret (or whatever level name you want) = Group B only
  • Set up issue type X to use workflow 1
  • Tell the project to use workflow 2 for Y and Z types, and workflow 2 needs to
    • Set the security level to "Secret"
  • Educate Group B that they should not change the security level to "none", otherwise it will let Group A see them.  Or if you don't need them to change it, don't put it on screen for them to edit

This leaves you with one quirk - Group A will still be able to create Y and Z type issues, but they will create invisible (to them) issues, which is a little confusing.  You could add a validator that will block the creation with a more useful message, but then the users will lose what they've start to add to the issue

0 votes
Dirk Ronsmans Community Leader Feb 25, 2021

Most likely the security is set as Default? So that applies to all then.

Even if the field is not on the screen that doesn't mean it isn't applied. It is just not shown on the screen. On the issue level tho it will still be there (just not visible)

Suggest an answer

Log in or Sign up to answer
Site Admin
Community showcase
Published in Jira Service Management

ThinkTilt is joining the Atlassian Family!

This morning, Atlassian announced the acquisition of ThinkTilt , the maker of ProForma, a no-code/low code form builder with 700+ customers worldwide. ThinkTilt helps IT empower any team in their or...

281 views 16 17
Read article

Community Events

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

Find an event

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

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you