How to get Product bugs addressed in a timely manner

I totally agree and it has become harder to raise issues since we don’t (or at least I don’t) have create permissions on JAC. Raising support requests for bugs is sub-optimal on Ecosystem.

When we Atlassian ships bugs that affect us in the cloud we have to shout as loud as we can and rattle as many people directly as possible to get things fixed. It is better in cloud than on server because it appears that there is more focus from Atlassian there.

1 Like

In the Google Groups topic referred to by @yvesriel I introduced the concept of some sort of vendor representation. In my view, that small subgroup of vendors has a regular meeting with product managers from the Atlassian products and the Atlassian Marketplace team. They can serve as a filter for our requests and make sure that Atlassian only has to deal with the really important stuff. I still think we should consider this!


@remie, Thank you for “being the change you seek” in proposing a solution. I would ask that others who comment on this thread to follow this example. I think @andy raises a legitimate question. Let’s find a legitimate solution together.

If you feel it’s important to help us to understand the problem, please provide more details. Which products need our attention? Is it Cloud or Server/DC that needs attention? What features have gone under-served?

Also, while the anecdotes are useful examples, the proposed problem is an aggregate. So help us understand more about the aggregation of the problem. How many bugs do you have open? How is the aggregate affecting your business? Is it measured in support cases for you, or missed sales opportunities?

Please don’t interpret my questions as denial of your problems. When you ask, “Who is supposed to care about Atlassian product bugs?” then the answer is, “We, as Atlassian Developer Relations, care.” But caring isn’t sufficient to know what to do about your problem. So I need your help to understand the scope and scale.

This will help me to better represent your needs inside Atlassian.

1 Like

It’s not necessarily a single bug. It’s also the visuals - our common customer believes that when there is an issue with a marketplace vendor’s product that they can fix everything. When we as a vendor has to turn around and go “sorry we’re waiting on Atlassian” - it doesn’t look good for either one. We can file bugs through but it’s not necessarily the appropriate place since they’re just doing the same work we’ve already done…

I agree with @remie that a representative group from the community would be good. But I think it goes beyond that. With Cloud we’re somewhat good - we can report issues somewhere and while the issues might just sit there (which isn’t good) we can at least tell our customers “we’ve reported the issue - look over here” (this btw is a cop-out but it’s what we have to live with). There’s still the case of that there are umpteen projects and it’s hard to know what’s already reported etc.

It would be awesome to have a single ecosystem project where we could report an issue for all products (Cloud, Server etc). Lock it down to single people within each vendor etc if you need to. If Atlassian would go through that project once or twice a week and triage the bugs reported and move it into the appropriate place it would be awesome. Make it public so other vendors can also go “hey we’ve run into the same issue”.

Just my $0.02.


Would something like a “Known issues” section on the Atlassian Marketplace work? Which will allow vendors to also list their add-on as being affected by the issue?

1 Like

@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 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.


@andy that is an impressive list. It was mentioned before that some of the issues vendors encounter can actually be fixed relatively easy. Would you say that having the ability to submit PRs would be something you would have actively done (or will still do) if that would be an option?

@pvandevoorde, I must admit that I was a little bit taken aback by your answer. We have raised issues and been trying to get them acknowledged. Atlassian never bothered asking for more details and when they did, we didn’t get any follow up. Just like @andy and probably many more did. I’m not condemning, just stating what I experienced. I know that you try to do your best just like we are.

My point with all this is that I believe that Vendors and Atlassian have a symbiotic relationship. When I log in a bug, I know that it’s only one (or a few) complaints and I don’t expect Atlassian running to solve the issue right now. I do my own due diligence by at least logging the issue. I know how software works and that you need to prioritize your efforts to maximize them. And I will live with the fact that they aren’t solved if we have a good process in place. A process that I can call upon if I feel that the issue is actually hurting my business.

While the idea of having a sub group of Vendor sitting on a board may sound appealing, I’m not convinced that it will change something for the majority of vendors. I think that Atlassian should allocate a certain number of hours per release to fix vendor issues. There should be a special Kanban board (or something else) where you can find these issues. Then a product manager (which we can exchange with) can, based on the level of effort required for the task, the number of votes and the number of installations take a decision to prioritize the work. At the end, I simply want to be heard, have some type of follow up and make sure that not only the biggest vendors have a say in the order in which the issues are solved. That’s why a realistic selection algorithm needs to be put in place to give every vendor a chance.

Asking me for hard numbers about the impact of the issue is not realistic. I often get people uninstalling the add-on with no meaningful feedback except the pre-filled ones. And when I reach out to them, I often get no answers. You will also have to rely on the Vendor’s intuition to prioritize the issues.


Thank you for doing this @andy.

This is the kind of list I can use to start some conversations.

Everybody: feel free to add to this list, the more data we have the better.

I cannot guarantee anything but know that we acknowledge these problems and the challenges they present to you as vendors.

Thanks for your honest and productive feedback @yvesriel.

I do agree that we need to keep improving our processes.
Open conversations like this one play a keep part in achieving that goal.

We cannot change things overnight but we do need to keep improving wherever and whenever we can.

I assume “Pull Request”

FWIW - the two items that would substantially improve our life as a vendor (BigBrassBand) are:

Add-ons break after customer data imports

Grant “Browse Users” permission to add-ons requesting READ scope

Thank you @andy, @yvesriel, and @daniel for representing the vendors well here.


Might as well state the ones that hurt my business :slight_smile:

A Multiple CustomField Type should not enforce entering Options (48 votes)
I get many complaints about this one, especially with the “Confusing Interface” reason.

As a developer, I want the Issue Detail View in the plan and work mode to support the different JIRA custom field abstract classes so that my own custom field can be displayed (156 votes)

Service Desk Add-on changes behavior of Checklist add-on


I get the same feedback from users of my plugin Project Specific Select Field because of enforcing admins to enter option values when add Custom Field.

1 Like

I worked at Atlassian from 2008-2013 as a senior developer on Confluence. I am a marketplace developer now. This has always been a problem and honestly I don’t see it changing. My practical advice is to find workarounds to problems and accept that anything you report will not be fixed right away (or possibly ever)

It’s not that Atlassian isn’t working hard trying to fix all bugs, it’s just that they provide so many open communication channels to report problems that there is a very large volume of bugs. Most bugs found by an individual developer or customer matter a lot to that individual but mean very little to the aggregated user/developer base. People may find this upsetting but in my opinion this is the cold hard reality of the situation and it’s not new. Keep in mind, this is my personal opinion and since I no longer work at Atlassian it’s in no way affiliated with them.

What I find a little disturbing is that Atlassian’s response to this problem is to close communication channels to limit bug reports. Maybe I’m a little OCD but it bothers me a little to find a bug and not being able to report it somewhere. This is the current situation with routing everything through the support system. I don’t have a support entitlement number so I can’t use the support system. Therefore, I can’t report bugs.


Ok guys, what about a round 3 :slight_smile: Just in time for Christmas!

Last night my heart stopped for a few minutes. Too bad there wasn’t any defibrillators around as I probably would have needed one. I opened a ticket after receiving from customers two complaints, back to back, that the cloud add-on has an issue which makes it very confusing for customers to use it. The problem: In the “Search Issues” view, when you navigate from one issue to the other, the add-on is inserted twice: one correctly and a broken one linked to the previously visited issue. Yeah yeah, you read that right :slight_smile:

So, I create the ticket and at the end of the day I receive a reply telling me that problem has already been reported by other vendors and to remember to watch and vote for the issue. Wait what (disc scratch sound effect)! To VOTE for i!? You mean that it will be in the same pile of issues that haven’t been addressed for years even when hundreds of people are voting for it? I simply can’t fathom how this not be a “critical” problem. Of course, it’s not “stop the production line” critical but surely it’s critical enough to get assigned to an upcoming sprint and be part of the next cloud releases (or so my naive mind is thinking). Turns out that the issue has been raised two weeks ago by another vendor and so far no one from Atlassian even commented on it (beside the usual linking to helpdesk issues).

I’m not complaining about the work of the service desk agent. She did what was required and she was polite and helpful. The real issue here is that this thread as been going on for over a year without actual real helpful actions. It started from a thread I opened on Sep 2016 and was raised again by @andy this past March. Everytime these threads get a lot of heat, discussions and promises. Every time it falls into oblivion or at least it looks like it from the perspective of the vendors.

This thread mentioned the need of some type of escalation system where these type of issues could be properly addressed. Atlassian said

… we need to keep improving our processes. Open conversations like this one play a keep part in achieving that goal. We cannot change things overnight but we do need to keep improving wherever and whenever we can.

That was nine months ago. If something was done in the mean time it sure would be nice to hear about it. I get it that Atlassian opened a “Marketplace vendor” page on the ecosystem site but that’s just a portal. It’s not a process that we can call upon in time of needs. I’m not a big vendor but I’m not an insignificant one either. Atlassian is making good money with the Marketplace add-ons. While these type of things are not critical to them, it is for us and it’s hurting our businesses.

I would have gladly patched it like @ryanackley mentioned but this is for the cloud, not the server. So nothing can be done from our side.

Sorry for “being an ass” once again but we need to keep the ball rolling :slight_smile:

1 Like

Yves, can you send over issue link? @iragudo is currently tracking a similar issue that’s occurring on Confluence Cloud (double-loading of app / two iframes).

Hi Neil,

Sure thing! It’s JRACLOUD-68222. Good to know that you’re on it :slight_smile: I see that Ian should already be aware as he linked the issue to another helpdesk ticket a few hours ago.

We boiled this down to a free standing example to demonstrate the problem.

The Confluence version of the bug is at .

Since this seems to be affecting both JIRA and Confluence at the same time - it would be awesome to have something we can tell customers since “vote and watch this Atlassian bug” isn’t really that great customer service…

1 Like