Jira Service Desk 4.0 EAP 4 is now available. This time we’ve fixed an oversight which impacted the use of the new exception types in our Java API. We’ve also been busy ensuring that we’re compatible with the good stuff that Jira have been implementing. For all the information, read Preparing for Jira 8.0.
Where to download this EAP
You can download this EAP from the Early Access Program downloads page. If you’re using the maven.atlassian.com site, download milestone 4.0.0-m0017.
You can also find the Java API documentation here, and the REST API documentation here.
The timeline
We want to ensure that Jira Service Desk 4.0 is a roaring success, so we’ll be releasing another milestone before the beta, and looking to release Jira Service Desk 4.0 towards the end of 2018. However, that might change based on feedback, so keep reading our announcements.
Tell us what you think
Your feedback is always welcome. We are doing our best to address it as soon as we receive it. If you’ve got a comment, feel free to post it below.
Regards,
Lachlan Goodhew-Cook
Senior Developer, Jira Service Desk Team
Hi @lgoodhewcook ,
Good job on the EAP! We now have our plugin compiling with the new API and everything appears to work as expected.
On a slightly unrelated note, is there any method available in the Java API to determine if a specific user is a customer of a specific service desk?
I see that there is the ServiceDeskPermissionService but this comes with a very clear warning that it is not for consumption for plugin developers. Why is this still part of the API if its not safe for use?
Basically I need to be able to determine if an ApplicationUser is a customer of a specific service desk project, is there any way for me to achieve that currently? I know I can check for the absence of application access but this isn’t quite enough, I believe its possible for a user to lack application access but not be a customer of private service desks.
I need to be able to make this check in the context of a project, not an issue, I want to know if a user is a customer before issue creation happens. This probably isn’t the place to ask but I don’t know of any other way to contact the JSD team directly 
Cheers!
Reece
It looks like I can indirectly work this out by requesting a list of service desks as a given user, and if the service desk is not present, they cannot see it.
Would that be the best approach here?
That’s great @anon19873023 glad to hear it’s all working.
The warinings on com.atlassian.servicedesk.api.ServiceDeskService are a leftover from when they were Experimental APIs. I’m of the opinion if we haven’t changed them in years and are going over a major version bump nothing should still be experimental so I’ll be removing that warning before release.
It looks like I can indirectly work this out by requesting a list of service desks as a given user, and if the service desk is not present, they cannot see it.
That would be one way of doing it sure but it could fall over with loading a large number of serivce desks into memory.
That feels like a pretty glaring oversight on our part. I’ll raise an issue for us to add something to make this easier. But in the meantime I’ve put this together that uses all public API components and the jira permissions (which are all cached so it’s nice and fast).
com.atlassian.jira.security.PermissionManager jiraPermissionManager;
com.atlassian.servicedesk.api.customer.CustomerContextService customerContextService;
// If you need a service desk specifically you can get a project from it through com.atlassian.jira.bc.project.ProjectService#getProjectById(com.atlassian.jira.user.ApplicationUser, java.lang.Long) where the Long is servicedesk.getProjectId()
public boolean isCustomerForProject(CheckedUser customer, Project project) {
// running in the customer context to make sure that we get the proper permissions and don't block users who don't have Jira access.
return customerContextService.runInCustomerContext(() -> canCreateRequest(customer, project));
}
public boolean canCreateRequest(CheckedUser user, Project project) {
return jiraPermissionManager.hasPermission(ProjectPermissions.CREATE_ISSUES, project, user.forJIRA()) && jiraPermissionManager.hasPermission(ProjectPermissions.BROWSE_PROJECTS, project, user.forJIRA());
}
Let me know how that works out for you.
Lachlan Goodhew-Cook,
Jira Service Desk Server
1 Like
Thanks for taking the time to reply @lgoodhewcook
I was unsure about interacting with non-JSD API’s directly when dealing with customers, but it does appear that the standard Jira PermissionManager returns the correct result for me when run in the customer context, brilliant!
Thanks for the information regarding the experimental APIs and for logging an improvement for checking customer permissions. We try to be good plugin developers and avoid experimental API’s when we can, so having those cleaned up would be lovely.
The customer context is something that still causes confusion to plugin developers, this probably affects us more than most because we do a lot of interaction with JSD. To my knowledge, the behaviour of the customer context is not publicly documented anywhere, it took us months to even realise that this was a thing, I know that it is an internal implementation detail of JSD but it is rather confusing to plugin developers if you do not know that this special context exists. Is there any possibility of getting some better documentation for this?
To my knowledge, all portal interaction gets routed through the customer context, meaning that all Jira users are treated as customers when using the portal. Is that a correct assumption?
I have a very specific question relating to mail handlers which you might be able to get me an answer for. What context should a mail handler be executed in? JSD does not currently have its source code available which means that this is impossible for me to find out myself.
We develop a custom mail handler for Jira, this mail handler creates/comments/updates issues in JSD projects. Currently it runs outside of the customer context, meaning that customer permissions don’t quite work correctly in our product at the moment.
Should all mail handlers be executed in the customer context if the project is a JSD project? Is that safe and the correct thing to do? It would make my life a lot easier if I can just switch contexts and then trust Jira to handle all the permissions for customers after that.
Hey @anon19873023,
The customer context is something that still causes confusion to plugin developers, this probably affects us more than most because we do a lot of interaction with JSD. To my knowledge, the behaviour of the customer context is not publicly documented anywhere, it took us months to even realise that this was a thing, I know that it is an internal implementation detail of JSD but it is rather confusing to plugin developers if you do not know that this special context exists. Is there any possibility of getting some better documentation for this?
Absolutely, there is a ticket https://jira.atlassian.com/browse/JSDSERVER-3962 here to improve the docs around it that I’ve raised with our documentation team to have a look at.
It is an implementation detail that has leaked into the API. Ideally you’d never have to do something like that just to know if someone is a customer or to perform some action we should take care of it for you.
To my knowledge, all portal interaction gets routed through the customer context, meaning that all Jira users are treated as customers when using the portal. Is that a correct assumption?
Yep, that’s correct. Any user (that is also a valid customer) passed to the customer context service gets special permissions for that request.
I have a very specific question relating to mail handlers which you might be able to get me an answer for. What context should a mail handler be executed in? JSD does not currently have its source code available which means that this is impossible for me to find out myself.
We develop a custom mail handler for Jira, this mail handler creates/comments/updates issues in JSD projects. Currently it runs outside of the customer context, meaning that customer permissions don’t quite work correctly in our product at the moment.
Should all mail handlers be executed in the customer context if the project is a JSD project? Is that safe and the correct thing to do? It would make my life a lot easier if I can just switch contexts and then trust Jira to handle all the permissions for customers after that.
Sounds good to me that’s how the JSD mail handler works.
// When processing an email, we want to run as the person who sent us the email, and we want to be in the portal context
private <T> T inEmailContext(CheckedUser user, Supplier<T> callback) {
// a function that is run in customer context, which in turn runs the passed in callback
Callable<T> inCustomerContextCall = () -> inCustomerContext(callback);
// now run this as a specified user
return authenticationContextUtil.runAs(user.forJIRA(), inCustomerContextCall);
}
Lachlan Goodhew-Cook
Jira Service Desk Server
1 Like
Brilliant! This is the information I was looking for, thanks Lachlan.