-
Bug
-
Resolution: Fixed
-
Medium
-
None
Cases for dates, ISBNs and hyphen separated phone numbers have been fixed. Issue still persists for patterns matching strings in the form of JIRA issue keys i.e. XX-9.
Steps to reproduce:
- Create a new blank page on Confluence OnDemand and type a string with at least two alphabetical characters, and at least one number separated by a dash - E.G. "UTF-8".
- During the edition, the text is normal.
- Hit the preview or direct save the page and the text separated by hyphens will become a hyperlink, see this screenshot
.
- The hyperlink in this page will point to https://<base_url>/browse/UTF-8 which is not a valid URL
Fix notes
- Issue is caused in instances with JIRA app link. JIRA App link URL patterns are matched using regex alone which is insufficient.
- The same behavior doesn't occur on the same version of Confluence Standalone.
- One difference that was observed between OnDemand and Standalone is that on OnDemand there is by default a plugin called Application Links, see this screenshot.
- On Confluence Standalone this plugin doesn't exist by default, see this screenshot
- is duplicated by
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
- is related to
-
CONFSERVER-29899 Make possible to unlink automatic ondemand links in Wiki pages
- Closed
- relates to
-
-
- Closed
-
- mentioned in
-
Page Loading...
-
-
-
-
-
-
-
[CONFCLOUD-54251] Dashed word in Confluence OnDemand automatically creates a link to a non-existent JIRA issue
With the current fix, only issue like text that matches the key for projects that are actually linked to the space will be converted to an issue link. There can still be links created to issues that don't exist in those projects, cause verifying if every issue exists would have performance implications.
If you were seeing a link and after this fix is not there anymore and you want it back, either link the JIRA project to the Confluence space (in Space Tools -> Integrations) or use the JIRA Issues Macro.
Just chiming in .... Same issue with AES-128. I'd be happy with something as simple as \AES-128. Anything would help.
Jaes W Overley
added a comment - I encountered a similar issue with regard to ICD-10 medical coding where we have a JIRA queue that happens to be ICD. Any comments that include ICD-10 automatically link to this ICD-10 JIRA issue. I searched the web for a solution and stumbled across this post. After much trial and error, I found that if I enter a \ in front of the - it removes the incorrect link to the ICD-10 issue. I find this is a satisfactory solution as there are other formatting items which require the \ to appear correctly. I realize this does not solve the issue of JIRA linking dashed words to non-existent JIRA queues, but thought I would share my solution with anyone else that encounters the same issue.
Jaes W Overley
added a comment - I encountered a similar issue with regard to ICD-10 medical coding where we have a JIRA queue that happens to be ICD . Any comments that include ICD-10 automatically link to this ICD-10 JIRA issue. I searched the web for a solution and stumbled across this post. After much trial and error, I found that if I enter a \ in front of the - it removes the incorrect link to the ICD-10 issue. I find this is a satisfactory solution as there are other formatting items which require the \ to appear correctly. I realize this does not solve the issue of JIRA linking dashed words to non-existent JIRA queues, but thought I would share my solution with anyone else that encounters the same issue. 
Jesse Jones
added a comment - It's sorta ridiculous that this bug still exists, two years after it's been submitted.
Isn't it possible to determine whether a JIRA project exists? For example, if someone types "UTF-8", and there is no project "UTF", then assume it shouldn't be a link; on the other hand, if someone types WEB-67 and there's a project labeled "WEB", then create the link?
I did find a workaround that is less intrusive than {noformat} – if you italicize the hyphen, it's barely noticeable, but stops the auto-linking.
Jesse Jones
added a comment - It's sorta ridiculous that this bug still exists, two years after it's been submitted.
Isn't it possible to determine whether a JIRA project exists? For example, if someone types "UTF-8", and there is no project "UTF", then assume it shouldn't be a link; on the other hand, if someone types WEB-67 and there's a project labeled "WEB", then create the link?
I did find a workaround that is less intrusive than {noformat} – if you italicize the hyphen, it's barely noticeable, but stops the auto-linking. Hi Mikhail, we have updated this issue (please see description) to reflect the current state of this issue. The cases where phone numbers, dates and other hyphen separated numbers have been fixed (in version 5.3.1 and OnDemand), however a related issue still exists for patterns which could potentially resemble JIRA issue keys (such as the example you tried).
Thanks.
The bug is still there as of today in Confluence On Demand. Entering something like XYZ-103 will create a link which points to a non-existing issue.
Mikhail Shtyrev
added a comment - - edited The bug is still there as of today in Confluence On Demand. Entering something like XYZ-103 will create a link which points to a non-existing issue. I just checked my OnDemand instance and the bug is fixed there.
Thanks!
Re-opening as it turns out this issue has not been fixed yet. It's still present in Confluence 5.2-OD-14.
CONF-27814