-
Bug
-
Resolution: Fixed
-
Highest
-
7
-
Severity 1 - Critical
-
47
-
Summary
JIRA Issue Macro Repair feature delete some of the content
How to replicate
- Space or Site import to the Confluence Cloud instance
- If Confluence detects there is any broken link, there will be a button off Next Step there.
- If we click on What's Next button, Confluence will redirect us automatically to JIRA Macro Repair feature.
- If user didn't perform any import, Confluence still can detect any broken link and can still perform JIRA Macro Repair, by accessing this page https://(instance_name)/wiki/admin/jim-validator/view.action
Actual Result
Performing JIRA Macro Repair will remove some of the content insides the page. We see that the content inside View File Macro, Panel, Anchor and several of macros will be removed after we perform the JIRA Macro Repair
Expected Result
The content should not be removed
Workaround
Revert the page that gets affected by JIRA Macro Repair to the previous version.
[CONFCLOUD-53014] JIRA Macro Repair remove some of the content in Confluence page
Hi pradeep.tathineni477149333, as this is a different issue, could you please create a ticket on https://support.atlassian.com/help/confluence/? Thanks.
Pradeep Tathineni
added a comment - Hello,
I am really hoping to find some help on a similar jiraissues problem.
I post a xhtml storage payload to confluence to create a page, in which I also have a jiraissues macro in the following form:
<ac:layout>
{...othercode...}
<ac:layout-section ac:type="single"><ac:layout-cell>
<h2><strong style="line-height: 1.5;">JIRA issues</strong></h2>
<ac:structured-macro ac:name="jira">
<ac:parameter ac:name="columns">key,summary,reporter,created,updated,status</ac:parameter>
<ac:parameter ac:name="rendermode">dynamic</ac:parameter>
<ac:parameter ac:name="jqlQuery">{$keysForJql}</ac:parameter>
</ac:structured-macro>
</ac:layout-cell></ac:layout-section>
{...othercode...}
</ac:layout>
The confluence page is created fine with all correct features of the macro, but the email sends out with the jiraissues macro table only showing the fields boldened and side-by-side, and underneath is a link that says "No issues found".
The odd thing is that when this link is clicked, I am taken to JIRA search where the issues ARE found (which means $keysForJql is not the problem).
Let's say the $keysForJql var is set to "key in (DEV-XXXX,DEV-YYYY) on the payload post.
The "No issues found" link found in the email sent out copy-pastes as:
https://jira.ourjiradomainname.com/secure/IssueNavigator.jspa?reset=true&jqlQuery=key+in+%28DEV-XXXX%2CDEV-YYYY%29&src=confmacro
and will redirect to https://jira.ourjiradomainname.com/issues/?jql=key%20in%20(DEV-XXXX%2CDEV-YYYY), having found the issues.
Super frustrating, please help!
Pradeep Tathineni
added a comment - Hello,
I am really hoping to find some help on a similar jiraissues problem.
I post a xhtml storage payload to confluence to create a page, in which I also have a jiraissues macro in the following form:
<ac:layout>
{...othercode...}
<ac:layout-section ac:type="single"><ac:layout-cell>
<h2><strong style="line-height: 1.5;">JIRA issues</strong></h2>
<ac:structured-macro ac:name="jira">
<ac:parameter ac:name="columns">key,summary,reporter,created,updated,status</ac:parameter>
<ac:parameter ac:name="rendermode">dynamic</ac:parameter>
<ac:parameter ac:name="jqlQuery">{$keysForJql}</ac:parameter>
</ac:structured-macro>
</ac:layout-cell></ac:layout-section>
{...othercode...}
</ac:layout>
The confluence page is created fine with all correct features of the macro, but the email sends out with the jiraissues macro table only showing the fields boldened and side-by-side, and underneath is a link that says "No issues found".
The odd thing is that when this link is clicked, I am taken to JIRA search where the issues ARE found (which means $keysForJql is not the problem).
Let's say the $keysForJql var is set to "key in (DEV-XXXX,DEV-YYYY) on the payload post.
The "No issues found" link found in the email sent out copy-pastes as:
https://jira.ourjiradomainname.com/secure/IssueNavigator.jspa?reset=true&jqlQuery=key+in+%28DEV-XXXX%2CDEV-YYYY%29&src=confmacro
and will redirect to https://jira.ourjiradomainname.com/issues/?jql=key%20in%20(DEV-XXXX%2CDEV-YYYY ), having found the issues.
Super frustrating, please help! Hi Atlassian,
is there any progress? After my warning the Workaround is still the same and status Technical Review is there for five days!?
I want to sure this bad scenario won't be there anymore!
Martin
@martin.trneny2126826849 I can confirm the "easy" workaround of Atlassian is not working in all cases and I can confirm we have the exact same problem as you do, at least in regards to the "merged" edits you describe in 5.
Thank you for sharing also your worries.
Sorry I was confused before about your role . 
Best regards, Rafael.
Hi Rafael,
I hope it is only related to this bug CONF-31026 which was released around 21/Sep/2016 based on history log from that issue. So may be instead of correct the issue the new one was created. The status is saying "An issue has been implemented.." so I really hope all information has been taken on their mind during fixing this bug.
I posted at CONF-31026 info for other users to be careful because this bug could be devastating for Confluence instance.
We were really shocked because it affected also pages for our customers!
Regards.
Martin
Hi Martin,
Yes that is right, thank you for investigating.
Actually I reported the issue like this, at the beginning.
Also looks like is not just Macro issue, it seems that information is like manually deleted and/or changed.
Attached an example, Status of a comment is automatically resolved.
Comment was added 4 months ago, and the date of resolution was the same as the day that changes happened, by the user moritzmenzel.
Just for your information.
Hopefully you can help us to find out what was wrong with our confluence.
Thank very much again.
Best regards, Rafael.
Hi Atlassian,
based on our ticket JST-225398 this bug was raised and I can say your workaround isn't correct.
Based on our investigation during reverting affected pages back to consistent state we noticed that you cannot simple revert page to previous version. The most of pages were affected in this style:
Your macro (or whatever it was):
- edited a CURRENT version of a page
- deleted some content
- somehow deleted also record from the page history about CURRENT version (from the first step)
- stored the page version as a new CURRENT
- so at the page history you have CURRENT (with icons of two users) and then CURRENT-2 (as the previous version) and surprisingly the CURRENT-1 is completely lost
- as a result - you CANNOT revert to the CURRENT-2 (obviously you thing it is your last change before incident but amazingly it isn't) because then you lost your changes from version the CURRENT-1 which is unfortunately not visible (available)
Try to replicate on your side.
So PLEASE at least read carefully your SD ticket where I described this behavior at 05/Oct/16 2:14 PM !!! So correct your "easy to repair" workaround.
What testing you are performing guys?!! This bug affected more than 120 our pages!!
@Phong Nguyen or whoever,
that's cool the status is changed to RELEASED TO CLOUD but what about the _Fix version/s _field??! I want to be sure our instance has correct version.