nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Can someone explain this to me?

John Dunlap2

For the last 6 years the following ticket for adding CNAME support to JIRA OnDemand has been open with Atlassian employees periodically reassuring everyone that there was no hidden agenda and that the only reason they have not added the feature is because of "priorities". Again, the ticket has been open for 6 years. NO ONE is too busy to implement a feature like this in a 6 year time frame. Clearly, they are lying to their customers. There is no other logical conclusion.

https://jira.atlassian.com/browse/CLOUD-6999

Further, I have recently discovered that Atlassian deliberately removed the exact same feature from BitBucket. What is going on here? Never mind that Atlassians competitors have supported this feature for years. Why can't Atlassian at least be honest with people that they have no intention of ever implementing this feature in OnDemand. Why keep lying to everyone?

https://confluence.atlassian.com/bitbucket/associate-an-existing-domain-with-an-account-221449746.html

Can someone explain this to me??

Accepted answers

All comments

Nic Brough -Adaptavist-

"Lie" is probably a bit strong. Have a look at https://jira.atlassian.com/browse/JRA-9 if you want a better feel for "we have higher priorities at the moment".

John Dunlap2

"Lie" seems to be the appropriate word to me. Atlassian very clearly does not intend to implement this feature and, despite having higher priorities, they have been actively removing it from their other cloud products. What other conclusion can be drawn from this but that they do not want to support this feature?

Further, you provided JRA-9 as evidence that Atlassian has higher priorities than CNAME support. However, you neglected to point out that the ticket you linked to(JRA-9) has 454 votes and 211 watchers. The ticket I linked to(CLOUD-6999) has 1752 votes and 607 watchers...

Nic Brough -Adaptavist-

It's from a time when JIRA's ecosystem was a lot smaller than it is now. I am pointing out that they said they wanted to fix it and they did, despite taking 9 years about it. If you wanted to compare numbers usefully, you'd do it by "proportion of user base", which at the time would have given it 10 times as many votes. And, bear in mind that votes are only part of the prioritisation process. If they were everything, then that request would be second on the list. The highest one is still 100,000 requests older than that.

They have higher priorities. In the spirit of at least two of their five principles, they close things they aren't going to do, they don't lie about them. And insulting people by accusing them of lying probably is not a good way to engage with them.

John Dunlap_vmbeua

Then why remove that feature from BitBucket?

John Dunlap_vmbeua

If I seem a little confrontational it is because I I have literally been trying to "engage" with people from Atlassian on this issue for 4 or 5 years. They very rarely reply and, with all due respect, when they do reply, what they say doesn't square with the facts that I see in front of me.

John Dunlap_vmbeua

The explanation which makes considerably more sense to me is that Atlassian deliberately doesn't support this feature both because that would hurt their partner network who host Atlassian products as a workaround for the absence of this feature and because it would hurt their standalone server sales.

Jeremy Largman

At the risk of being another Atlassian who's reassuring everyone that there is no hidden agenda, I feel inclined to comment on your post. I know I'm not moving the feature request along but I can try to address our process and whether or not it's honest.

Nick referenced JRA-9, which was one we took 9 years to implement. Another somewhat infamous one is JRA-1330, which we did finally close as "won't fix." For some features, we want to build them, and they are in a prioritization conversation. For others, we can actually make an assessment that "no" is the more honest answer. In this case, with CLOUD-6999, it's still in the prioritization bucket. "Coming Later" is actually what we think this is!

We do have a partner network that we want to keep healthy, that's true. When there is an established vendor in the marketplace, we won't intentionally make a competing feature. But that doesn't hold us back from implementing things that are core parts of the platform.

As for Bitbucket, we removed CName in part because it was not a highly adopted feature. Of course that'd be different for JIRA and Confluence; having your own intranet for example and wanting a custom url makes much more sense. We had a handful of security gaps (passwords were sent to Bitbucket in clear text when custom domains were used and spam score was raised by services due to matching reverse DNS lookups), plus high support costs for that feature. So we deprecated it.

I've worked here a long time because I really like this company. My personal opinion: we're really not in the deception game. Disappointing maybe, but not deceptive.

MattS

Jeremy, with 1752 votes I think another response on the issue at https://jira.atlassian.com/browse/CLOUD-6999 could be helpful.

John Dunlap_vmbeua

I'm sorry it's taken me so long to get back to this. I have spent a fair amount of time thinking about what you said since my last post. When I saw that CNAME support had been removed from BitBucket, I assumed that it had been correctly implemented. As you explained above, that does not appear to have been the case.

As far as passwords being sent in clear text, I presume you mean that login's were transpiring over HTTP instead of HTTPS because the SSL certificate for the Atlassian domain did not match the domain of the CNAME. As you'd need to either have your own trusted certificate authority(easier said than done) or allow the customer to upload their own SSL cert(which feels very wrong) to get around this... I can understand why it would be a little tricky to resolve.

As for for email spam scores, I can understand that as well especially if you're sending email directly from the web server instead of indirectly sending it through a vendor.
So, with all of that said, if that was indeed the lay of the land, then I can understand your decision to remove that feature(disappointing though it is).

In hindsight, it would appear that the use of the word "lie" was a bit strong after all.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

bitbucket-server

jira-cloud

jira-core