@pvandevoorde After several drafts and my entire afternoon collating, here are some simplistic issues V impact that you asked for for reference (trying not to appear like a rant!), I can’t quite keep this clear of improvements vs bugs, sorry. Its definitely a bit on the long side (sorry), but you did ask. I also hope not to offend anyone on any related issue, am just trying to convey required info:
ACJIRA-1151 (User with no group should not show up when searching for BROWSE and COMMENT_ISSUE permissions) Users with no application access or with just restricted to portal are found in the permission/search rest method even though they don’t have access and If I try to run a rest operation (like add a comment or get the issue) on their behalf i get forbidden or a portal redirection. UI login also fails with the portal redirection
AC-1014 (Grant “Browse Users” permission to add-ons requesting READ scope), created 18 MAR 2014
We have had to implement a whole addon section in our Cloud addon dedicated to a management and use of user/password which is used in dedicated REST calls outside Atlassian Connect due to this deficiency (among others). this impacts us architecturally, and customers as they have to allocate a seat just for this purpose. Anyone needing to lookup users has to do similar things.
Given the lack of progress with this issue, any time we hit an AC issue that needed something that wasn’t white-listed we had no choice buy to bypass AC and use REST with this account, ie. there are many more things I can’t remember now covered by this approach, became the platform couldn’t seem to react.
ACJIRA-411 (New REST API CloudHealthCheck method needed)
Over time we have had quite a few cloud customers who had installation problems, root cause always ended up being one plugin or another not started. I logged this issue to get some API access that did not depend on AC or Webhooks to determine the ‘health’ of an instance - as JIRA doesn’t (AFAICT) monitor itself, it would reduce support load to be able to know if all our Requirements in terms of cloud JIRA modules were fully functional. This issue was marked obsolete in Feb 2016, still applies today.
AMKT-12613 (Prevent repeat evaluations of cloud add-ons)
When an implementation doesn’t match documentation, that is a bug. The documentation for cloud licenses says that evaluations cannot be extended, but they can. I logged this issue as a Bug, but it was later rebadged an Improvement…
We implemented enforcement that Atlassian should have done in the first place, we are now no longer impacted, however, every other cloud Vendor will be.
JRA-42133 (Renamed Username to be Reflected in all DB tables) created FEB 2015
You though renamed users was all done? Try editing a component lead to a user who has been renamed, unless you know the user key you are up the creek. This is a core product bug, it could easily be fixed at the UI level as users should not need to see userkeys ever. Its just broken, why is it still broken! for the love of pete!
Forget “create-a-thing” competitions at Atlassian, Run a “fix-a-thing” competition, there is a lot of scope!
JRA-63575 (Provide a relationship at the data level that an attachment was uploaded via the commenting UI or not)
We’re probably the major/only impacted vendor of this issue. On the one hand yes, Comments and Attachments are not related. On the other, you create attachments through the Comment popup, and embed them (images) within comments, yet there is no ‘real’ way to track a file that was uploaded via a Comment to be associated with that comment (customer want this, we are attempting workarounds, its all quite message).
JRA-42609 (Assignee permission check during IssueService validateUpdate uses the JIRA authentication context user not the supplied user)
Just silly, requiring workarounds.
JRA-60200 (IMAP and handling of FolderClosedExceptions)
Inadequacies of Mail Handler API’s mean that real world problems cannot be neatly handled. We get support traffic about this quite a lot, but customers probably hit the problem more often, key looser here is the customer. #punted to unassigned longgrass
JRA-43589 (Make Mentions use the IssueEvent pattern)
The black sheep of the IssueEvent world, mentions. We have customers asking us to be able to customize this, which we cannot because the standard IssueEvent pattern of listeners was not followed. The looser here is the customer who can’t use your product as they want to.
JRA-64947 (Update Velocity Engine to 2.0+)
JIRA 7.3 only ships with Velocity Engine 1.6.4, whereas 2.0.x was released in JUL 2016 and resolves https://issues.apache.org/jira/browse/VELOCITY-776 which directly impacts us, other than making a suggestion, how would this problem ever get any visibility/consideration?
JSD-3471 (Ability to get Custom Request Type ‘values’)
This seems to be a difference of opinion in whether or not its appropriate to set a field or not. I thought this was oversight, but turns out its a wont/fix. Using a system in the ‘only’ way it was envisaged seems counter intuitive to what JIRA ‘the swiss army knife of all issue trackers’ seems famed for.
JSD-3533 (Comment entities not set before COMMENT_CREATED fired, causes Race Condition for addons and event listeners) created MAR 2016
Oh man. So in order to worka round the buggy nature of the Event notification happening before the Private nature is ‘certain’, we’ve had to implement a JSDCommentEvent listener as a workaround. Great? Well no, by implementing this workaround, we have had to ‘guess’ that a Comment was being executed - its a good guess, but no, in this case, ANY comment, including issue workflow transitions and closures (with a comment present) result in JIRA ISSUE_COMMENT notifications. We have customers who (a) don’t want Private comments to be notified to the public (b) to retain the event nature (which we don’t have anymore). A rock and a JSD hard place.
I brought up the state of the SDK’s at last years Atlascamp in Barcelona, that it was unable to build example addons for all core products with Atlassian Marketplace licensing support that deployed correctly (haven’t checked of late). Yes it can be done but its tricky! If Atlassian wants to get more developers into the ecosystem, having the SDK’s actually work without osgi head scratching would be a start. Who is the looser there?!
Raising awareness via a ‘metaproject’ would be fine, but without cross-product clout to go fix them or to raise their priority within teams already very happily churning away through their own backlog? Its a cross product turf war for resources!
I like the idea of known issues, a bit like an application link perhaps so our JIRA can refer to a ‘core’ JIRA system somehwere? Somehow be able to surface issues tagged in that way? I’m just a little depressed that we have to start listing things we are waiting on rather than things we have fixed.