Bitbucket has this nice feature of opening issue details in a modal when you click on issue key in PR:
The idea is to add
openIssueView(key, params) to
AP.jira, so that in connect apps it would be possible to have similar experience.
Currently we are using two workarounds:
- re-creating editable issue view in our frontend
- opening issues in new tab
Both workarounds have some obvious downsides, this is either suboptimal user experience, or a tech debt.
ps. I was trying to hack and make use of
/rest/bitbucket/1.0/issue-details/fragment endpoint, but unfortunately it does not work with JWT of my connect app.
+1 on the edit view being available to apps…
This seems like a good idea, so I’ve created ACJIRA-2134 for this.
@dmorrow - since you created ACJIRA-2134, i figured i would point out that the request is probably largely the same or at least related to ACJIRA-495 - a way to trigger the edit issue dialog. (Which has been lingering for ~5 years by the way).
Thanks for letting me know. I’ve marked ACJIRA-2134 as a duplicate of ACJIRA-495. I also asked the relevant Jira team if it is likely they will be able to implement this in the foreseeable future. I’ll let you know if there is any info to share.
It’s great to hear that I’m not the only one with such need:)
Speaking about editing issues, please don’t forget about:
- comment dialog
- workflow transition dialogs (currently those can be used in a hacky way (get ID from REST endpoint, manually concatenate transition dialog URL, display in iframe using decorator=dialog), but I would prefer a first class citizien JS API )
@dmorrow would you be able to describe what’s the possible timeline for such feature request? Suggested resolution of the answer:
- Soon (within few weeks)
- Mid term (< 1 year)
- Long term plans / might not happen
The reason for my question is that I’m upon a decision whether we should invest into our own “issue view” experience, or we should postpone this work, because issue view will be provided by Connect.
When I reached out about this, the response I received was as follows:
At this stage we don’t have this in our FY21 plan. My advice would be to create a ticket…
So whilst I have ensured issues are lodged in the appropriate backlogs, so far there has been no commitment provided so it seems it may not be implemented even in the next year.
I realise this is frustrating.
Thanks @dmorrow - really appreciate you following through on that.
Can you ask them - since the ACJIRA tickets already exists - where else should we create issues?
Thanks for the update, and as Daniel pointed out the ticket exists already for 5 years.
It’s not that frustrating, it’s just an additional cost. What’s more important, many vendors will need to pay this cost, as all of them who have this need, would have to implement their own issue view. The need to display issues in a Jira app is rather common
In the end everyone loses here: Atlassian, vendors, customers, and users.
There’s no better place for you to create issues. I received advice to create a ticket in a Jira Service Desk that is only visible to Atlassian staff. In the past, a few projects such as AC, ACJS and ACJIRA were used to track most issues relevant to the developer community, but we’ve grown a lot and now there are numerous Jira and platform teams that use different Jira projects and tenants, most of which are not publicly visible.
Yes, I agree that implementing this would prevent numerous duplicate implementations by the developer community. In the internal issue I created, I emphasised that there is significant interest from the developer community in the hope that this would help prioritise the issue.
For the ones looking at recreating an edit dialog - the old server url seems to still work in Cloud(for now):
[host url here]/secure/EditIssue!default.jspa?key=SAM-5099
I’m actually using it, but there are challenges:
- it works, for now, and it’s not hard to imagine that Atlassian eventually would like to remove the old issue view and related dialogs/pages. Since everyone is forcibly switched to the new issue view, it will not be difficult to justify this removal with data(low usage of old issue view)
- it does not give feedback, on when the window should be closed. I need to use bizarre hacks/workarounds(for example with webhooks)
- wiki markup in comment/description fields, and bugged wiki markup <-> ADF conversion
- this is a legacy page, not actively maintained by Atlassian, only a fraction of users know how to get to this page actually (middle click on “Edit” button ;))
So this is something, but the experience for end users in Cloud is not great.
Oh I agree that is fraught with danger and concern. But it’s the only crumb that Atlassian will give to us…