Is it possible to restrict issue access based on a value in a custom field?

[James Porter]

Hi,

I've created a custom field called Company, which is populated with our client company name's. Basically I am looking to give some form of read only access to my clients, but they should only be able to see issues that relate to their company only. So i am wondering if I can restrict access to issues in a project based on the value in the company custom field?

Thanks

[Nic Brough -Adaptavist- · Accepted solution]

Sort of, but not really.

There are a few ways to approach restricting individual issues (e.g. using "only the person who raised this issue can see it") but what you really need here is "issue security"

This enables a "security level" that you can set on an issue. If it's blank, then just the project "who can browse" determines visibility, but if you set it to another level, you get to define rules. The more simple rules might be "Top Secret can only be seen by group X", or "Confidential can only be seen by people in the role of Y, and people in group X"

At that level, you'd have some pain, because you'd have to set up a security level for each value in the company custom field.

But... Security levels include rules like "is in custom field", which could solve this for you - you'd only need two security levels - "public (empty value)" and "private (determined by your field)".

That only works for select lists though, and if your company field is text, you'll need a different approach - set up the security levels, then write logic to read the company field and set the security level in a listener.

[James Porter]

Thanks for the response Nic. Sounds like I can'tr really achieve what I'm looking for, so it is probably best I extract info out and build some form of webpage to display semi-static data. It doesn't need to be real-time and will probably suffice in most cases. Cheers.

[Nic Brough -Adaptavist-]

Not without a bit of code or thought (using the right type of field and/or maintaining groups)

[Ivaylo Stoukanyov]

Hello Nic,

I have exactly the same issue here and even following your guide,  I cannot resolve it. Probably I'm doing something wrong, so please help.

The issue:

Just like in the question above, I have a field called "Customer" with values: CUSTOMER1, CUSTOMER2 and CUSTOMER3 (all capitals)

1. I created a group called customer1
2. I'm assigning "John Doe" who is registered JIRA user to the group customer1
3. I navigate to JIRA Administration -> Issue security schemes -> "My security scheme" and I'm creating Security Level CUSTOMER1.
4. I add to the Security Level CUSTOMER1 "Group custom field value" Customer (the name of my custom field)
5. I navigate to my project -> Settings -> Issue Security and I can see the Security Level I created e.g. CUSTOMER1
6. I login with the accoutnt John Doe, which has a restricted access to only browse the project, but I can still see the issues with value in "Customer" field CUSTOMER2, CUSTOMER3 and the goal is John Doe to be able to see only issues with the value in the field "Customer" = CUSTOMER1

What the hell I'm doing wrong? =(

I will highly appreciate your help!

Thank you in advance!

Iv

[Marlene Cote]

We have to solve this same problem.  Can someone comment on this if you have been successful setting this up, please?

[Vin]

[I know this is a old thread and many would have found their solutions already. I am answering so that the new person at least gets a hint of how this can be resolved.]

I had a similar situation.

the way I resolved is by using Issue level security. (I am not sure if that existed when Nic replied back in 2014).

Create different Issue level security levels for each company and user groups for each company. 

Add the users from a particular company in the associated user group.  Assign correct user groups to their respective security level. 

When an issue is created, ensure that the issue level is updated for right company. You are good to go! 

hope this helps!

[Nic Brough -Adaptavist-]

This is what I said back in 2014 (issue security has been there since 2005, and possibly earlier)

[Dean B]

Hi @Nic Brough -Adaptavist- , I need some help with the same. Are you still around?

[Nic Brough -Adaptavist-]

Yes, still here, but a bit slow, due to being on a holiday in Las Vegas before going to Summit.

Where are you stuck?  The answer above still applies, although the admin UI has moved around a bit.

[Dean B]

 Hi @Nic Brough -Adaptavist- , sorry for the late reply. I have managed to resolve it following the instructions again. Thanks for getting back to me.

Now, trying to figure out the JEHM email handler to map few custom fields in next gen project. Hopefully, will be able to sort it out soon.