Atlassian... Could you please reply the quesitons?

looks to be linked to https://jira.atlassian.com/browse/CLOUD-6999 for the custom domain names.

Either way round, is there any update that could relate to this update?
https://blog.developer.atlassian.com/ecosystem-support-for-custom-domains/

Dont get it... embarassing for Atlassian

Very Disappointing, and very easy to implement.

Sad to see Atlassian not addressing such as basic need.

This is the highest voted non-closed issue, and the status is 'gathering interest'?!

https://jira.atlassian.com/browse/JSDSERVER-513?jql=project%20%3D%20JSDSERVER%20and%20status%20!%3D%20Closed%20ORDER%20BY%20votes%20DESC%2C%20updated%20DESC

It is a very basic requirement that would be expected from the beginning, a simple cname support link.

It is needed to fill a glaring feature gap between competitors like zendesk which of course does it.

It is a trivial feature to implement for atlassian, provide a subdomain to the support portal.

For those who are looking for a solution: UseResponse did pretty well in the last few years. Their solution is a public forum, a helpdesk panel, a knowledge base and also a live chat solution all-in-one and they developed some quite nice features here – and multilingual / multi-domain is basic standard there. Actually we're checking out if a migration from Jira ServiceDesk to UseResponse could solve our problem here. And, of course, it includes a plugin for Jira / Confluence integration, so backend developement could stay in Jira, while User-Frontend is handled by UseResponse.

Come on Atlassian team. This feature is not just about what customers are voting. It is about Atlassian prestige. I think that not all of your customers have the knowledge and skills to even implement a solution on masking servide desk url, but for those of us who really care about the best way and best practices to do things this is a very very important matter. Here at my company we have been customers for about 10 years now, we like your software, we like your solutions. They are great solutions, please, please solve this issue.

This should be an easy change to Jira to enable this and can't believe it's not included in the product.

Currently I'm having to get around this by using IIS on another webserver and using URL Rewriting to perform this, but I shouldn't really have to use a second web server to overcome such a simple task......

This is a big issue. Jira you need to figure out a way to allow this process so that we can redirect our old easy to remember support URL to your URL. 

Any updates?

One year futher (after many!)  and  what have the Jira (service desk) customers learned? Go to another software solution if need a proper subdmain for your helpdesk(s).

Still no update after May 9th 2018 where Atlassian said it wasn't on a their long term roadmap?

any solution to this issue? friendly url or rewrite? so i can use customer.domain.com for Jira service desk on cloud

Hi,

Any updates on this? 

Please help us connect a domain!

Yes indeed, did not manage to do it with a rewrite or proxy because of the internal requests..

Basic need.

would be great with the release of Jira 8 and JSD 4 to hear more about the timeline for this basic functionality...    

@3qml-sanc 

Does your solution address the jira-side issue of generated links back to the support portal?  Sure we can set up a reverse proxy to point foo.bar.com to our Jira ServiceDesk Project 27... but when links are send out to respond to the issue, all the links point back to the main Jira Site, and our aforementioned Service Desk Project 27, which in reality doesn't solve anything at all.

The goal is a complete and independent subdomain that's specifically for the particular service desk in question 

Hi @Michael: +1 Could you please share how you resolved the base url issue ?

Hello, we are still in evaluation phase, however this feature is as many say - must have. Our current work-around is using Refined Theme for Jira Service Desk. But only helps with parts of our needs.

Hi @Francis, hi @Michael:  +1 from our side. Michael – what have you done? Would be great if you could share a/your solution with us.

Hi @michael,

Can you share your approach of this setup?  I'm curious how you resolve the base url issue

Francis

Atlassian seems to ignore many important requests, delaying them for years, which is immensely frustrating.

But we've stayed with JSD, moving all company departments to it, in spite of the limitations.  On server, we've also managed to implement support.ourdomain.com and kb.ourdomain.com without too much trouble.

Any product you select will have it's pros and cons, we have decided that the pros outweigh the cons.

We rolled out JSD to 2 of our customers then found out about all outstanding critical unresolved for years issues hence decided to give up on it / looking for alternatives.

I assume at this point that most people have just given up on JSD. I know we have.

I don't think Atlassian "get it" that information security is an issue for many of it's customers (actually all of it's customers but the rest don't yet realise it). I suspect this is because they live in an Agile bubble where everyone trusts each other. We will either have to use a different product that does include sub-domains and get a Jira connector, or hack something ugly ourselves.

Yep, I got a reply to my rant about how bad it is stating Atlassian is taking every feedback very seriously etc. but facts are the opposite. It's a great system but we're simply being ignored and marketing profit making ideas are prioritised AKA "sell and ignore/forget".

Is this seriously a ticket from 2014, without any followup?

please make this possible  support.mydomain.com why is this not implemented already? this is 2019 almost all helpdesk software allows for subdomain without redirect, should be able to install on sub.domain.com and it should display sub.domain.com as our customer area to submit bugs to for support

Was shocked to find this is not implemented after 4 years for all the reasons many people have already mentioned.

It's crazy that self hosting organisations:

1. can not use a friendly URL for public facing customer support portals and emails like support.domain.com (without ugly redirect workarounds)
2. are forced to expose and use the same domain for their internal development (software + portfolio) as their external public facing customer support (increasing both customer confusion and attack surface)

This is the first product we have evaluated NOT to offer such basic features as custom domains, customer portal customisation, etc.

Yes, same here.

If there are actual technical reasons why this is not available please articulate that to your customers. If this is not available because some sales droid does not think it is important then it would be nice to know we should investigate other options. Without this option I am going to do that anyway. Maybe if this costs enough sales someone will find it important.

I agree with this 100%. Please re-assess the situation. We are currently investigating alternatives only because of the custom URLs and the shameless self-branding. 

Just to add yet another comment for this. Not being able to use our own URL and NOT advertise the Jira service desk to my customer is just plain STUPID.

If there are actual technical reasons why this is not available please articulate that to your customers. If this is not available because some sales droid does not think it is important then it would be nice to know we should investigate other options. Without this option I am going to do that anyway. Maybe if this costs enough sales someone will find it important.

Same on our side - we have only rolled out JSD to two customers and until this feature is available are not going to use it for others. After so many votes and today's response from Atlassian we're now considering alternative software/solutions instead.

Thank you Atlassian for the update today!

I hope you escalate this futher within your organization as soon as possible.

From a sales perspective for you it is an important future because companies want their own branding and professional dashboard and don't want external customers to get strangled with the internal customers/employees service desk. 

We have not yet started to use Jira Service Desk because of it external which is a pitty!

bureaumoeilijkedingen you could use a something like Apache HTTPD to strip those headers –

Header unset 'Content-Security-Policy'
Header unset 'X-Frame-Options'

+1, we used to have the workaround to load an iFrame loading the servicedesk (yes, not very pretty). However, with the latest update this is blocked due to security reasons ("frame-ancestors 'self'"). 

It makes ServiceDesk so much more appealing for external servicedesks, don't understand why this isn't on their priority (sales) list!?

It's insane. Takes 15 min to do this in IIS or other web servers.

They're way too busy with conferences to drive more revenue from new customers than us here who already paid... am fed up with lack of response for such a basic but a MUST feature that is making us look unprofessional to cusotmer not to mention causing extra nuisance for both sides...

2018 and we're still not there.. Come on, I think the need for this has been expressed loudly enough!

Okay. What about fundraising an amount of money to get somebody to code it as a plugin for everybody?

Yes, we use JSD a little internally for IT support, but we need a tool that can offer an external portal to our customers to actually do what we want to do. This remains our #1 blocker to really using JSD and is about the only reason we haven't gone up from the 3 agent license!

It's not even hard.  It's honestly hard to understand why this isn't available yet. It's a huge pain point for our organization.

It boggles my mind that this is still unsolved after more than 3 years without any comment from Atlassian, even though it's literally the #1 most basic feature for any service desk…

Might as well use some random open source stuff, looks like the level of support you receive is about the same.

full ack. We testet JSD, but we're on the way to stop and not use it if project/domain specific URLs are not possible.

full ack 

+1

This is really frustrating and unsecure - our customers will face our internal JIRA url which they should not know about

Looking at the dates Atlassian don't give a **** about their customers' needs... I'm going to start looking for alternatives otherwie we'll be forced to write our own service desk which means moving away from JIRA and their steep pricing model completely.

+1

Base URL for JIRA Service Desk should be separate from JIRA Software/Core. So that it could be proxied differently using untrusted networks. And all emails should use SD base URL so that internal JIRA instance is not divulged to untrusted public. 

This would be the only truly enterprise-grade solution with the security in mind. But today using Service Desk is so dangerous that we won't adopt it. 

 +1

 +1

The workaround may be feasible for the customer portal channel, but all emails send from JIRA service desk will still use URLs created from the JIRA base URL - which in our case is only accessible from our intranet. 

This is a blocker for us to adapt JIRA service desk -

• we want to host the JIRA server internally,
• we want to link development tickets and service requests tightly
• we want to use the same user accounts for developers and service agents
• we want to use the email channel and the web frontent channel for service requests
  • --> the web channel needs to be available under a public URL - we can manage this using a reverse proxy and a secured tunnel connection between the proxy and our internal jira

What we do not want is to set our base url to something like service.company.com, so that our internal users would have to use this to access our internal JIRA server for all development tasks.

We also do not want that service desk emails sent to our customers include links build from our internal JIRA URL.

==> Please separate the base url for service desk & outgoing service desk emails from the internal base URL used for JIRA software projects

Split this into a separate issue if need be: We need friendly linking to Service Desk articles. Trimming off the query arguments yields something reasonable, but it doesn't work:

https://acme.atlassian.net/servicedesk/customer/kb/view/37153980?q=Health&q_time=1497471844550&portalId=1&applicationId=83221f6d-4c7c-33c0-987a-7835fed37235

https://acme.atlassian.net/servicedesk/customer/kb/view/37153980

The cleanest link I can manage is search by label, but we need direct linking to pages:

https://acme.atlassian.net/servicedesk/customer/portal/1?q=azure

Is this possible for JIRA Service Desk Cloud? I would like to have a custom url (subdomain) for my service desk portal. 

We'd really like this feature. Have been using service desk internally for some IT support, but now we want a customer portal for external support.

Our JIRA server is not accessible from the general internet, and we'd prefer not to make the DNS entry public (it's an internal corporate subdomain), so this will need to go through a separate reverse proxy server. So we have a problem where I can make pages available (rewriting the URL) but all the links don't work because Jira's base URL is pointing to an inaccessible location.

All we need is to be able to set a particular portal to have its own base URL and for it to pop out on a different port (separate tomcat servelet? I'm not sure how that works, done plenty of web dev but never with Java). Then the reverse proxy in the DMZ can proxy it through like our internal reverse proxy already does for our internal Jira.

I would really expect this to be a standard feature...

Yeah, that's crazy that this has been open more than two years.  I'm sure there's a lot of internal code that references the single base-url.  But there's no reason it can't be done as a piecewise rollout that one component at a time can use an alternative base-url.

It's a shame to see Atlassian is so slow addressing basic feature. In IMHO this feature should be part of v1.0  and yet 2+ years since was requested nothing changed. 

Is there a process to submit bounties for features?  I'm sure we could crowd fund a decent bounty to expedite this majorly needed feature.

We definitely need the ability to have a subdomain on a per service desk basis.  We're growing and supporting several franchises and we absolutely must be able to brand each service desk individually.

We have already decided to go with another provider – or build our own tool – due to the lack of this essential feature. 

We tried many of the proposed solutions sent to us by JSD support – spent a lot of time trying them out – and none of them worked.  And honestly, a lot of the support we received was half-hearted.

We like JIRA but need to move on if they can't meet the important needs of customers.

Echo this all around.  When providing Customer facing service – through individual customer accessible portals - this feature is an extreme must have.

The opportunity to provide service to a customer via "https://{customername}.{mydomainname}.com — and then have the rest of the Service Desk cloud URL metadata suppressed/hidden from the customer would be huge.   

On a security/information sensitivity concern - the ability for some to "hack at" the URL and discover various customers (providing we have placed a customer brand/logo) on the entry page – is highly detrimental to continuing service with the Atlassian Service Desk (Cloud) offering.

Atlassian – please make a comment – give us some perspective on roadmap.  We believe in the service, but elements like this will eventually sink your business as we move to another provider with better features (regardless of their pricing).......

Cheers.

Totally agree! This is an important feature!

Definitely need this feature as our support portal is customer facing.  Please make it a priority to allow a friendly URL such as support.mydomain.com.

We would like to see this feature as well. We want to have Servicedesk at support.ourdomain.com instead of the current unfriendly URL.

Hi,

It will be better if we have different base URL for JIRA Software & serviceDesk . as we are using JIRA software for internal users & JIRA Service Desk for our clients / Customers . having same URL for both making difficult in email password rest link & notifications email

In case it's not clear, this is also a bit of a security problem, since in order to accept e-mails from all customers you have to turn the ability on for anyone to create requests.

Then all of your customers can just URL hack your different portals to see who all your customers are.. which is not desirable.

If we keep commenting will this come to fruition? I am 100% considering not licensing Service Desk because I can't easily set up a friendly URL. I am using nginx, which doesn't even have a work around.

In Aug/2016 it's still a problem? I would expect Atlassian solve it. How should i tell my customers they are the second, sixth ? We need custom URLs ASAP

Would love to see this issue moving forward! Customers hate lengthy URL's. I'll work on using rewrite as a temporary solution, but would rather not for every single service desk.

It really is hard to believe this problem still persists.

If you are rolling out a help desk, branding and ease-of-use should be paramount towards accomplishing user adoption.

The JIRA team must be so focused on the trees that they are missing the forest that their customers-- IT professionals that must get buy-in are facing, prior to any internal functionality in the program.

The urlrewrite.xml solution above is not ideal. Your friendly subdomain has to differ from the actual subdomain it redirects to, to prevent infinite redirects, which creates branding confusion between your two urls.

Agreed. The workaround is fine for people navigating to it, but emails, etc, all likely have the fully awkward link?

@Ryan
I'll try. If it would work for me, I'll give a hint how.
Thanks!

@Vladimir

I don't believe you have the ability to edit those config files in Atlassian Cloud, but you might want to put in a support ticket with them to see if they could possibly do it for you. I'm not sure what options you have on the Cloud platform.

@Ryan Pesta
Do you know, it is possible that you suggest in Atlassian cloud (Atlassian on-Demand)?

I see the workaround above for Apache, but does anyone have a workaround for Tomcat on a Windows Server? I've tried playing around with the urlewrite.xml file but I think I'm missing something. Our Service Desk URL is "https://jira.company.org/servicedesk/customer/portal/5" and I want it to redirect from "https://help.company.org"

This is an annoying issue. If someone asks me, "How can I get to the helpdesk website?", I shouldn't have to provide them this absurdly long URL.

Update: Playing around with the rewrite rules, I was able to get this working for my Tomcat Jira instance.

Append the urlrewrite.xml file in (Atlassian\JIRA\atlassian-jira\WEB-INF) with the following entry and add a DNS entry pointing from the friendly subdomain to your Jira server.

<rule>
<condition name="host" operator="equal">friendlysubdomain.company.org</condition>
<from>^(.*)$</from>
<to type="redirect">https://jiraserver.org/servicedesk/customer/portal/1</to>
</rule>

Not sure if this is the most efficient code, but it works.

We very much need this too. We would also need it to use the project-specific URL in the email notifications that it sends (so that service desk email links point to the subdomain and not the main jira.company.com subdomain).

Voted too, this is very important to us for our client facing work.

Ah, mine is an interim solution until that is able to happen.

You misunderstood what this feature request is about. Or maybe I did

I thought this feature request was about using subdomain/domain as service desk portal and not ugly https://jira.company.com/path/to/servicedesk/portal address. Full separation from JIRA not just redirect.

It has been working just fine in my situation. We access jira via https://jira.company.com. ServiceDesk customers access Jira either via Jira itself or helpdesk.company.com or servicedesk.company.com or support.company.com and get redirected to https://jira.company.com/path/to/servicedesk/portal

Phil: can you confirm your ServiceDesk works using your RewriteRule? In our case, in the browser console the following error shows up:

"AJS.contextPath() is not here. Please use require("servicedesk/util/context-path")"

I built the following Apache redirect which is a "decent" work around if anyone was interested. You will need to have all of the potential subdomains you want to use in DNS as well.

RewriteEngine On

# Vanity URL redirect to ugly URI for Jira ServiceDesk plugin
RewriteCond %{HTTP_HOST} ^(helpdesk|servicedesk|support)\.company\.com$ [NC]
RewriteRule ^(.*)$ https://jira.company.com/servicedesk/customer/portal/3 [R=301,L]

The result should function like this

phil@PhilsLaptop :~$ curl -ILk helpdesk.company.com
HTTP/1.1 301 Moved Permanently
Date: Wed, 11 Feb 2015 14:28:50 GMT
Server: Apache
Location: https://jira.company.com/servicedesk/customer/portal/3
Content-Type: text/html; charset=iso-8859-1

HTTP/1.1 303 See Other
Date: Wed, 11 Feb 2015 14:28:50 GMT
X-AREQUESTID: <>
X-ASEN: <>
Set-Cookie: <>
X-AUSERNAME: anonymous
Location: https://jira.company.com/servicedesk/customer/portal/3/user/login?destination=portal%2F3
Cache-Control: no-cache, no-store, no-transform
X-Content-Type-Options: nosniff
Content-Type: text/html;charset=UTF-8
Strict-Transport-Security: max-age=31536000; includeSubDomains

HTTP/1.1 200 OK
Date: Wed, 11 Feb 2015 14:28:50 GMT
X-AREQUESTID: <>
X-ASEN: <>
Set-Cookie: <>
X-AUSERNAME: anonymous
Cache-Control: no-cache, no-store, no-transform
X-Content-Type-Options: nosniff
Content-Type: text/html;charset=UTF-8
Strict-Transport-Security: max-age=31536000; includeSubDomains

Upvote! Really Basic need.

I vote for this too. thanks it would help our implementation.

Any idea when this can be implemented. For us it's really important.