We’d love to take the opportunity and gather everyone’s feedback and current successes/pain-points with the new 3LO integration that already landed in Jira, and will soon be available in Jira Service Desk as well as other products.
There’s a list of things that we’re still actively working through, to list a few:
Better guidance in terms of documentation, app management and things like helpfulness of error messages you might get.
@haskovec Thanks for reaching out! I just replied on your thread, there was an extra colon in the payload. We’ll take this as great feedback for providing better error messages. Let us know how you go from here!
OAuth2 seemed to be a compelling alternative to our legacy integration via HTTP Basic, so we went down this path, but it turned out to be a frustrating waste of time for us since Jira Software APIs are not (“yet”) supported. The beginning of this thread indicated that support was being “actively worked” as of almost a year ago now – can you give an update on when/whether we should expect this capability?
We have several suggestions for areas where the current implementation can be improved for better DX and app management:
First things first, you’ve already mentioned this but the fact there is not streamlined procedure to publish the app has to be addressed. We currently have filed a review request which has gone unanswered during the last two weeks so at least acknowledging and giving some kind of timescale for the review process would improve this ordeal greatly.
Allow apps to be shared before being submitted for review. Currently apps which are not published can’t be used by users even within the same org. Allow apps to be shared with some warning in the consent string to allow faster G2M times and development ease.
Apps are managed by an individual account. This goes against business continuity measures everywhere. Apps should be possible to collaborate on with a shared ownership model so that having the owner of the app leave your org won’t be of any issue.
Apps should have account level flavor. Currently apps are associated on a user level access, some use cases require “Account level” access which isn’t associated with a specific user and shouldn’t be revoked if a certain user changed their password. These apps could only be authed by users with administrative permissions in the account and from then on should be handled as service accounts.
If you would like to dive deeper into any one of those items, I’d be happy to.