Set up Individual Issue unique security/permission

[Masashi.Igosaki@tcichemicals.com]

I'd like to implement prototype of performance management using jira work management.

I selected the existing template for the project and embed forms for performance management in details.

Main concern is about security, visibility for the user.

Each user's performance management contents such as objective or rating etc. should be highly confidential., therefore I'd like to set up 3 types of securities.

One is surely Admin Role, this is easy., so no problem.

another 2 are for Evaluator and Evaluee.

Evaluator can only view subordinates issue contents as well as approval function.

Evaluee can view her/his own performance management contents (cannot view other's contents)

Is there anyway to set up those security/access?

I'm beginner of Jira.

[Nic Brough -Adaptavist- · Accepted solution]

I am sorry that the answer you got before was misleading - it was generated by an AI that has no understanding of your question or Atlassian software.

Company-managed projects can have a "security scheme" applied to them. 

When one of these schemes are in use, then issues can have a field called "level" or "security level" set on them, and when a security level is set, the issue is only visible to people named in that level.

An example is easier to explain how levels work, so let's say you set up a security scheme that has three levels, with some example rules.  It will look like it is offering you four:

• None/blank:  No security level set, anyone who can see the project can see the issue
• Secret: People with the role of developer, the group called project-watchers, and Charlie can see the issue
• Top Secret:  People with the role of developer and Charlie can see the issue
• Super Squirrel Secret: Only Charlie can see the issue

For your case, I am not sure I have all the information to define it, but I do think you are looking at the right thing, except for the "evaluator can use approval function" - that sounds like it should be something in the workflow (where you can create conditions like "only evaluators can move the issue to the next status"), not something to do with issue visibility.

You mention "subordinate", which makes me think of sub-tasks.  Sub-tasks inherit their security from their parent issue because they are a part of it.