Jira Service Desk 4.0 EAP 7 is out. The finish line is just ahead!

JSM Development JSM Data Center Announcements
, ,
1

The team’s been delicately packaging EAP 7, and improving the ServiceDeskCustomerRequestService in our Java API. Before, we had only one API for retrieving customer requests, which meant that a laundry list of requests would be returned even when searching for a single issue. We’ve now split that into two APIs, so you get the most relevant result.

I want to test this EAP

We were hoping you’d say that. First, check out Preparing for Jira 8.0 so you know what breaking changes to expect, then download this EAP.

If you use the maven.atlassian.com site to download your milestones, make sure you get milestone 4.0.0-m0022.

You can also find the Java API documentation here, and the REST API documentation here.

What’s next?

EAP 8 is up next, and will contain a breaking change to our public API. Similar to our previous changes, fugue will be removed – directly impacting how you write automation extensions.

If internal or vendor feedback highlights that more changes are needed (including breaking changes), they’ll also be packaged up.

I have feedback

That’s great! We’re counting on your feedback to tell us if things are working (or not). You can post a comment here, and we’ll get back to you as quick as we can.

Regards,
Lachlan Goodhew-Cook
Senior Developer, Jira Service Desk Team

2

Hi @lgoodhewcook ,

With the latest Service Desk EAPs we’ve been experiencing H2’s JdbsSQLExceptions being thrown upon creating Request Types, like the one below.

com.querydsl.core.QueryException: Caught JdbcSQLException for select count(*) from dual where "AO_54307E_VIEWPORTFORM"."VIEWPORT_ID" = ? and "AO_54307E_VIEWPORTFORM"."KEY" = ?
    at com.querydsl.sql.DefaultSQLExceptionTranslator.translate(DefaultSQLExceptionTranslator.java:50)
    at com.querydsl.sql.Configuration.translate(Configuration.java:459)
    at com.querydsl.sql.AbstractSQLQuery.unsafeCount(AbstractSQLQuery.java:627)
    at com.querydsl.sql.AbstractSQLQuery.fetchCount(AbstractSQLQuery.java:132)
    at com.atlassian.servicedesk.internal.feature.customer.request.requesttype.RequestTypeQStoreImpl.lambda$requestTypeKeyExists$12(RequestTypeQStoreImpl.java:328)
    at com.atlassian.pocketknife.internal.querydsl.DatabaseAccessorImpl.lambda$execute$0(DatabaseAccessorImpl.java:69)
    at com.atlassian.sal.core.rdbms.DefaultTransactionalExecutor.executeInternal(DefaultTransactionalExecutor.java:87)
...
    at io.atlassian.fugue.Either.flatMap(Either.java:231)
    at com.atlassian.pocketknife.step.EitherStep3.then(EitherStep3.java:24)
    at com.atlassian.servicedesk.internal.feature.customer.request.requesttype.RequestTypeServiceOldImpl.createRequestType(RequestTypeServiceOldImpl.java:386)
    at com.atlassian.servicedesk.internal.feature.customer.request.requesttype.RequestTypeServiceImpl.createRequestType(RequestTypeServiceImpl.java:55)
...

Here’s the calling code:

RequestTypeService requestTypeService = ComponentAccessor.getOSGiComponentInstanceOfType(RequestTypeService.class);

RequestTypeCreateParameters.Builder cb = requestTypeService.newCreateBuilder();
        RequestTypeCreateParameters createParameters = cb
                .serviceDesk(serviceDesk)
                .issueType(issueType)
                .description("")
                .helpText("")
                .name("ExampleName")
                .build();
RequestType requestType = requestTypeService.createRequestType(user, createParameters);

It was working fine in EAP05 (m0010) and before.

Thanks,
Vasiliy

2 Likes
3

Thanks for raising this @vasiliy.kizhaev I’ll raise a ticket internally for us to look into this and get back to you.

2 Likes