User can create an issue they can't see (Issue Security Level)

[Brendan Andrews]

In previous instances I had setup a Security Level of private to which I'd granted permission via project roles and group assignments. Typically issues would be private by default.

So if a user didn't have permission they couldn't see private issues. Clients wouldn't be in a group or Project Role which had permission. 

Similarly if a client created an issue, the Security Level would be empty because they didn't have permission to set it. So they could see the issue.

I believe that behaviour has changed. Someone without permission to set the Issue Security Level creates an issue and the Issue Security is set to private and of course they can't see it.

Is my impression of the designed behaviour and use of it correct and regardless - how can I work around this?

In an attempt to workaround this I've tried using workflow to set the level, but it doesn't work:

[Brendan Andrews]

I have found that if I move the line to set the issue security to the first line of the post functions it will work. Though this means workflows need to be paired with issue security schemes.

[Remi]

Not sure if entirely your use case but solved my desired scenario:

• By default issues created by our internal team should be private.
• Post-create the security level can be changed manually to make issues visible for guests.
• Guests should be able to create and see their own issues immediately after.

Would take too long to explain the many ways I tried. But here's the crux: We need multiple post-functions in the Create transition to achieve this.

--

Our setup:

• We have two Issue Security Levels configured in our scheme:
  • Internal Only
  • Shared with Guests
• "Internal Only" is the default security level.
• Only internal team members have the "Set Issue Security" permission and can hide / share an issue by changing the level.
• Three post-functions are added to the "Create" transition in privilege-ascending order: Guests > Developers > Admin

[Ismael Jimoh]

Hi @Brendan Andrews 

I assume you do not want to set a security level for tickets by your clients. If this is true check the following:

1. Is there a default security level configured in the project? If yes remove it.
2. As you correctly guessed, you can set the security level from the workflow however if you want it to be conditional then you would likely need to use an add-on like scriptrunner to script this.

To my knowledge JIRA has never been able to automatically set a security based on groups by just using the default security level configuration.

Cheers.

[Brendan Andrews]

Thanks @Ismael Jimoh ,

• I don't believe it's possible to not have a default security level.
• There is a conditional in the post functions to create an issue -but it doesn't work.
• I know it was once possible to have the security level set to none by people without permission to set a security level to anything else. I've done it many times (over a year ago cloud version) but now a default is being set that the creator doesn't have permission to set. Which is how I always believed it was set to none.

Regardless, with the combination of what appears to be changed behaviour and a bug, this behaviour is no longer possible. And more than a little bit awkward for clients.

[Brendan Andrews]

@Ismael Jimoh can you please explain how Atlassian suggests to allow for issues to be confidential using security levels (or any other way)? Given that in the last 14 months or so the behaviour has changed.