Jira service desk agent permissions

[Robert Cuellari]

In Jira core it's possible to have user permissions access restricted to specific projects and other features.

I'm hoping to understand the possibility with Jira Service Desk.

If I wanted to create a user (so they can obtain an API key) and restrict them to only have access to a subset of tickets (based on a custom field value), would this be possible? (in Jira Service Desk, not Jira Core)

[Dirk Ronsmans]

Hi @Robert Cuellari ,

If you want them to have access to only specific issues within a project (you can of course restrict their access to only specific projects just like in Core) you can use a feature called issue level security.

Based on a security level (available on all cloud plans except Free) they will be blocked to see issues if they don't belong to that specific security level.

You could use that custom field value if you want to run some automations and set the correct level but that depends on the whole use case.

https://support.atlassian.com/jira-cloud-administration/docs/configure-issue-security-schemes/

[Robert Cuellari]

Thanks @Dirk Ronsmans for the quick feedback. 

This doesn't feel very intuitive for me.  There's a few follow up questions I have.

1. In the issue security scheme I can select a custom field, but not an explicit value for a given custom field.
2. When I go into set security issue in the edit permissions schemes I can add something like "Group Custom Field Value", but what does this actually do?  I am not able to select a value for the custom field.

This doesn't make much sense to me.

I'm hoping to achieve the following.

In Jira service desk there is an Organizations field.  I would like to create a Jira user who only has access to the tickets where Organizations field value = (and their value here).

Is it possible to do this?  It doesn't look like issue security scheme and permission schemes can meet this requirement, unless if I'm horribly misunderstanding the user interfaces.

-Rob

[Dirk Ronsmans]

Hey @Robert Cuellari ,

With a permissions scheme you cannot achieve this that's just a high level permission.

With the issue level security you can do this but you'll have to do some more action than just saying "organization = value"

What you would do is:

1. create a security scheme
2. Assign one or more levels to it. This level basically defines "if I set this security level on the issue, this person/group can see it"
3. Build an automation that based on the organization field will set the correct issue security level.

You can make it more dynamic by linking the security level (in your scheme) to a custom group field so you only need one level and base "who" can see it based on custom field.

Setting the level on the issue itself can be a manual action or through an automation.

It's not as straight forward as you had hoped but I'm afraid (at least what I can think of) is the only solution to really restrict visibility

[Robert Cuellari]

Thank you.  I'll have to dig into this more, but it feels overly complicated. I also want to make sure that none of these issue level securities will impact all other service desk tickets from other customers. Intuitively, it doesn't feel like I can ensure this without some automation (outside of what can be configured).  Am I correct in this assumption?

[Robert Cuellari]

Wanted to add to this.

If I set a security level it will restrict that particular issue to whatever the security level is.  (assuming I can figure this part out).

For all remaining issues, I will need to set up other security levels.

It looks like the security level is more of an "Allow List" and not a "Block List".  Even though I could set some Allow security settings for a subset of tickets, what happens to that user for all the remaining tickets?

I would need to set up a security level for all tickets where organization != X, and then assign those tickets a particular security level to restrict to internal usage only.

This sounds overly complicated and I'm not sure it won't have additional caveats.

[Dirk Ronsmans]

Well there shouldn't be any impact to other customers.

You basically start with a security level of "None", meaning no security level assigned = everyone can see who has access to the project.

So you start wide and then start limiting issues. Impact to other customers should be little to none.

[Robert Cuellari]

Thanks, my concern is that the user that we create in Jira Service Desk has access to read and write to the tickets via API only for a subset of given tickets within one project. I don't see how to set any kind of restrictions to a single user (that could have an API key associated with that user.)

-Rob

[Dirk Ronsmans]

I would like to point out here that I'm talking about Agents. (so the people handling the tickets).

If you are talking about customers who can create tickets through the portal or the API well then things are different of course. So maybe that's a nuance we need to look at.

Just want to make sure that you are aware of of the difference between customers and agents.

[Robert Cuellari]

Understood, I wasn't sure if a customer can actually have an API key generated for them.

Under that assumption I felt like I might have had to create a service desk agent user for this specific use-case. Is there a way to set up a customer and generate an API key for them?

Thanks again for the quick responses.

[Dirk Ronsmans]

A security level is indeed a Allow list but you can opt to not set a security level on most tickets so that just means "no security applied".

If we look for a customer then they can only see what they created or what their organization has created (if shared) so then it becomes a none issue right?

It all depends on what side of the tool you are looking. Are you trying to restrict the Agent's view or the customer's view. A customer is by default limited in what they can see due to the share option/customer permission and the organization(s) that they belong to.

For an Agent then we need to look at security levels.

[Robert Cuellari]

Our goal is to allow this customer to have programmatic access to the tickets via an API key and then have the ability to update these tickets? 

Is there a way for customers to do this?

[Dirk Ronsmans]

Then I feel like we can ditch the issue security.

If we really are talking customers then they are already limited out of the box to see what they created (or what is shared with them/their organization).

To create those issues programmatic they can use the REST API which has specific parts for Servicedesk/Service Management

And example would be the creation: 

https://developer.atlassian.com/cloud/jira/service-desk/rest/api-group-request/#api-rest-servicedeskapi-request-post

As to the fact if you need an agent license and then "raise on behalf", that's something we'll/you'll have to investigate. I feel like if you have access as a customer this should work..

As I haven't created this specific use case myself yet I cannot guarantee all the steps tho without building it.

[Robert Cuellari]

Thanks, I hadn't realized that they can do these without using an API key. I'll see if this is a workable path.

Much appreciated for your time.

-Rob

[Robert Cuellari]

@Dirk Ronsmans 

Sorry to reopen, but I checked the documentation and it doesn't look like it's possible to create any credentials as a customer to make API requests.

It looks like a token is required and it doesn't appear like there is a way to generate a token as a customer.

Am I overlooking something?

[Dirk Ronsmans]

Hey @Robert Cuellari ,

Let's see if I can find something. From the documentation I feel like it should be possible with a customer only user too as this part:

• raiseOnBehalfOf is not available to Users who have the customer permission only

states that the options is not available if you have a customer permission only (so a customer should be able to do it).

I'll try and investigate it a bit further to see how a customer only can authenticate through the api.

[Robert Cuellari]

Thanks @Dirk Ronsmans

It does look strange. I found some other threads looking to get client authentication but they were never resolved and were still at the conclusion that it wasn't possible.

-Rob

[Robert Cuellari]

Hi @Dirk Ronsmans

Any luck with this?  I haven't been able to find a solution with Jira service desk and will likely have to look into alternatives.

Hopefully you found something I haven't!

Thanks,

-Rob