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.
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?
Can someone explain this to me??
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.
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.
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...
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.
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.
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.
I have multiple projects that use variations of the same base workflow. The variations depend on the requirements of the project or issue type. The variations mostly come in the form of new statuses ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs