Issue security level flagged as wrong even when not necessary

[Giorgio Crosali]

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

[Dirk Ronsmans]

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)

[Nic Brough -Adaptavist-]

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

[Giorgio Crosali]

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.

[Nic Brough -Adaptavist-]

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.

[Nic Brough -Adaptavist-]

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.

[Giorgio Crosali]

@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

?

[Nic Brough -Adaptavist-]

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