Are the watchers if this issue still experiencing this bug? We have not had any recent reports. Thank you!

@Chris - Don't let the fact that this has been open for over a year give you the hope that it will be a higher priority item for Atlassian. Recently, they have made it clear that they are re-focusing on their "business model" and not working on things they don't find value in. Simple things like combining notification e-mails have been open for nearly 14 years (https://jira.atlassian.com/browse/JRA-1369) and are still getting the "Not in our roadmap" response.

Apparently a country with 1.3 billion people isn't worth the time.

For your case, you could either move to JIRA Server, or find another product to use.

I agree with Bo. It has been over a year since this was reported. We need to get this fixed. I have a team in China that can't use Jira because of this issue. VPN is not an option because of company security.
Jira is a fantastic tool that connects people globally, unless you live in China. Let's get it together folks.

Just as an FYI - even if you guys get past this, when you go to add user accounts they won't be able to create them without a VPN as well. The same CDN also hosts the Captcha, which it requires on initial account set up. You really need to consider how much effort using JIRA is worth to you.

In general, I can't recommend the cloud version for anything more than basic issue tracking. At which point, there are plenty of other platforms out there for this (which probably support China)

It is unacceptable for you to leave such a ticket unsolved for such a long time.
I've also created a ticket where the support engineer told me he can do nothing about this.
You should set up CDN server in China or at least use a CDN which can be accessed from China, and stop assuming google CDN's availability - it's blocked from China. We can't deal with the blocking, but you can, just change your CDN strategy will solve this.

I agree with DJX.

I want to setup JIRA Cloud for a company in China but I am not sure if they are willing to use a VPN each time they want to do User Management.
This may be a major issue for them.

I must say, this ticket has a general feel of "It's China's fault, not ours." Using a CDN is an optimization that works great in many cases, but when it doesn't I don't think it's appropriate to blame the reasons the CDN is blocked.

Also, this is not a "minor" bug. With this bug, I cannot administer my JIRA users without connecting to a VPN other than my company's VPN. This would break the company's policy.

As you mentioned, it is possible to get the "blessing" of the government - have you considered doing so? Are you really interested in serving the China market?

Is there already a ticket to make this move? This still doesn't cover areas like signup though that use the Google reCaptcha

jkoke we now have the option of uploading these resources to the common-admin-cdn where all the UM resources go. This would mostly address this issue as our own CDN is not blocked.

If our own CDN does get blocked then all of User Management will not work.

You heard me talking about it with Jason ... some things from Google are mirrored internally within China by companies that have the blessing of the government, e.g. http://libs.useso.com/

But generally we are stuffed. The only option (that I can think of) is we have to drop back to a locally sourced resource if we can work out that a request is coming from China Remember that for periods of time https://jira.atlassian.com has also been blocked by the GFWoC ...

ajax.googleapis.com like all Google services is blocked by China.

Your web pages assume you can load jQuery from ajax.googleapis.com

Your web pages assume jQuery is loaded and fail when it is not.

So, all your cloud services fail in China (without a VPN)

It's a simple one line fix. Just load from a different CDN.

http://jquery.com/download/

If we move to RequireJS over Almond we can take advantage of fallback paths: https://github.com/jrburke/requirejs/wiki/Upgrading-to-RequireJS-2.0#pathsfallbacks

We could keep using the CDNs and fall back to a local copy if blocked.