add another company waiting for a fix on this

Dear All,

Thanks for raising your concerns and feedbacks for the bug. This bug sounds to appear from the JIRA side
I just want to update you that we are tracking the reported problem of JIRA here https://jira.atlassian.com/browse/JRA-31977

Thanks,
Minh Tran
Confluence BugMaster

This exists in Confluence 5.10.7 (with Integrated JIRA 7.1.9).

This is affecting to custom fields that deals with *project pickers *as well.

Following ticket for ETA on this fix

This does not work for version 5.9.1. Would really appreciate if this issue can get fix soon. Do you have an ETA on when this would get fix for confluence?

Please update affects version/s to have 5.8.8 of confluence as well

Could you please provide us a rough timeline on when this fix will be implemented?

This really stinks that we can't have continuity between 2 atlassian applications when it comes to the way that fields are displayed.
It's really difficult and confusing when both applications share the same user base (directory server), but we can't resolve a User's name from a UserID field for display in the confluence page?

the xmlutil escape didn't work to me, it shown it as a string on confluence macro,
but this version of the same file worked fine for both the custom field version and the original version fields

#disable_html_escaping()
#if ($value)
    #foreach ($singleValue in $value)
#if ($singleValue.name)
<customfieldvalue>$singleValue.name</customfieldvalue>
#else
<customfieldvalue>$!singleValue.id</customfieldvalue>
#end
    #end
#end

restart of both Jira and Confluence required

We think that there is the following method if you only solve this problem.

Workaround:

1. Editing a xml-version.vm file
   (jira-application-dir)/atlassian-jira/WEB-INF/classes/templates/plugins/fields/xml/xml-version.vm

   #disable_html_escaping()
   #if ($value)
     #foreach ($singleValue in $value)
   <customfieldvalue>$xmlutils.escape($!singleValue.name)</customfieldvalue>
     #end
   #end
   

2. JIRA Service Resart
3. Confluence Service Restart (Optional)

We do not know about adverse effects of workaround.
We really need to resolve this issue.

Any update on this?

Hi Everyone

Thanks for your continued interest in this issue. Unfortunately this is still not on our backlog and it is likely to be some time before we can commit to addressing this. As soon as we have any further updates we'll let you all know.

Regards
Steve Haffenden
Confluence Bugmaster

We really need to resolve this issue.

Even we want to know milestone when this issue will be resolved.

Any update on this one? About time after a year!

Hi Steven
I totally understand your situation and being in product company deal with very similar issues in terms of priortization.
I know you have other high priority issues but this issue is impacting us and ( other customers) as mentioned in the issues.
I would like to get some type of statement of direction from company so that i can share with our internal customers.
Please help.

Hi vikas.mahajan

Thanks for getting in touch. There is no set timeframe for this issue as yet as there are a number of other issues that we need to address before this.

Regards
Steve Haffenden
Confluence Bugmaster

This is impacting us a lot as well. Do you have any time frame on when can this be fixed ?

Vikas

Hi guye

Thanks for your update, we'll definitely take this into consideration.

Regards
Steve Haffenden
Confluence Bugmaster

Thanks Guys. I feel it's important for your prioritisation to re-iterate one of the use cases here.

There are many users - particularly large companies that use the downloaded edition - who use the Jira issues macro to create reports in Confluence, and often export these to PDF. This is vital for sending information out to other employees who don't use Jira (including e.g. executive reports), and external parties. See CONF-30116 for a slightly heated discussion of this.

We rely on this macro to help us fully automate such reports, so that we write the information once in the Jira issue, and then can always generate an up to date report in Confluence. As soon as anything in this macro breaks (or is deliberately broken, as per the discussion in CONF-30116), this totally breaks this use case and massively reduces the value of a combined Jira/Confluence installation. Either we produce the reports manually, which is a lot of work, error prone, and more subject to variations if different people are producing it, or we have to leave off vital information.

This macro is absolutely crucial for this use case, so please give it appropriate priority.

A workaround suggested by guye for a version field.

Workaround for those who need it:

1. You need the Jira Misc Custom Fields plugin
2. This provides you with a new custom field of type Calculated Text Field
3. Set this to be a copy of the required field using the formula <!-- @@Formula: issue.get("customfield_10700") --> (obviously edit the field reference appropriately)
4. Use the new custom field in your Confluence report

Not elegant, but does the job until this is fixed.

Hi Venkat

Thanks for getting in touch. This issue is currently on our backlog but unfortunately there are a number of higher priority issues that we to address before tackling issues such as this. As soon as we have any updates we'll add the details to this issue.

Regards
Steve Haffenden
Confluence Bugmaster
Atlassian

Dear Atlassian,

Has there been any consideration to this issue. It'd be really beneficial to our organisation to fix this.

Thank You,
Venkat

Verified on Confluence 5.1.4, 5.4.2 and 5.4.3, connecting to JIRA 6.1.7.

Hei, It would be perfect to get this thing fixed as quickest as possible. Our users are complaining quite a lot because of that. Thanks!