Uploaded image for project: 'Confluence Data Center'
  1. Confluence Data Center
  2. CONFSERVER-34994

Mentions broken after space xml Import

XMLWordPrintable

      NOTE: This bug report is for Confluence Server. Using Confluence Cloud? See the corresponding bug report.

      If try to import a xml backup from a Confluence A to a Confluence B with a user that exist in both instances your mentions macros will get broken due a non existing user_key.

      Steps to Reproduce:

      1. Set up Confluence and create a user (eg Jessie Jones: jjones)
      2. Create a page under a dummy space
        • Add a {noformat} macro to the page - this step is required because the issue only occurs if there is CDATA elsewhere on the page.
        • Mention jjones.
      3. Generate an xml export of the space
      4. Delete the space from the instance
      5. Open entities.xml and find the userkey for jjones, and modify it so it is different to the userkey in the system. Make sure you modify every occurrance.
      6. Import the space back into Confluence
      7. You will see that the mentions will be broken:

      Workaround prior to import

      1. Open the zip file and edit entities.xml
      2. Find all occurrences of ]] > (note the space)
      3. Replace with ]]]]><![CDATA[>
      4. Import the space

      Workaround after import

      For a full update of your instance, see User mentions appear as Broken link after XML import

      For update of individual entries, read on.

      1. Shutdown Confluence B.
      2. Run below query against Confluence A database: 
        select * from user_mapping
where username = 'jjones';

        Above example is jjones but you will need to use the user name of the user that got the broken mention.

      3. Copy the user_key.
      4. Now run below query against Confluence B 
        select * from user_mapping
where username = 'jjones';

        Above example is jjones but you will need to use the user name of the user that got the broken mention.

      5. Copy the user key.
      6. At this point we will have two user keys for user jjones, one from Confluence A and the other for Confluence B.
      7. Now Run the following query against Confluence B database:
        Backup Confluence B before doing the update query 
        UPDATE BODYCONTENT 
SET BODY = CAST(replace (cast(BODY as nvarchar(max)), 'user key from step 3' , 'user key from step 5') as ntext)
where BODY like '%user key from step 3%';

        The above query was designed to MS SQL Server, if you are using other databases like Oracle/Postegres/MySQL as your DBA to adapt the query.

      8. Start Confluence B, check for the broken macros again (it should be resolved).
      9. If you notice any otehr problems or the macros did not got resolved then shutdown Confluence and rollback your database using the backup taken before the update procedure.

      Workaround after import if the original system is not accessible

      NB: This workaround requires the original export file for reference.

      1. As an administrator, go to the page and click '...' and View Storage Format.
      2. Grab the value of ri:userkey, eg ri:userkey="40288ac6444668f70144466ab1e70003"
      3. Open entities.xml from the export file
      4. Search for the userkey. You will find a ConfluenceUserImpl object that looks like this: 
         <object class="ConfluenceUserImpl" package="com.atlassian.confluence.user">
<id name="key"><![CDATA[8a81818556b603360156b603fad80002]]></id>
<property name="name"><![CDATA[admin]]></property>
<property name="lowerName"><![CDATA[admin]]></property>
</object>
      5. Inside the name property you will find the username, in this case it is 'admin': <property name="name"><![CDATA[admin]]></property>
      6. Edit the page and change the mention to that username

      Notes:

      The reason why this happens it's because the mention macro uses the user_key to make the reference to the target user instead of the username.

      <ri:user ri:userkey="40288ac6444668f70144466ab1e70003"/>

      During the import Confluence will not identify that jjones exist in both instances and that the source user_key needs to be updated with the target user_key.

      This will only happen with Confluence instances on version 5.2.3 and latest since previous versions relies on the username instead of the user_key.

        1. broken_link.png
          broken_link.png
          149 kB

            [CONFSERVER-34994] Mentions broken after space xml Import

            Steve Rhodes added a comment -

            This really should be backported for 5.10 at least.

            Steve Rhodes added a comment - This really should be backported for 5.10 at least.

            Feng Xu (Inactive) added a comment -

            A fix for this issue is now available for Confluence Server customers.

            Upgrade now or check out the Release Notes to see what other issues are resolved.

            Feng Xu (Inactive) added a comment - A fix for this issue is now available for Confluence Server customers. Upgrade now or check out the Release Notes to see what other issues are resolved.

            Denise Unterwurzacher [Atlassian] (Inactive) added a comment -

            Hi garen_parham1471499919. In terms of fixing existing systems with broken mentions, unfortunately there isn't a way to do that, because the mentions are rewritten during the import process. Once the import is done, if the mentions are broken, they will stay that way, because only the userkey is stored in the page - there is no associated username.

            There won't be any backport of this fix, because backports are risky and can be problematic. In this case the fix only works on import, it can't fix an instance post-import, and the 'Workaround prior to import' detailed in the issue description above can be performed pre-import to achieve the same result.

            I will add another workaround to the description to detail the case where you don't have access to the original system anymore. It is however very manual, and requires the export file for reference.

            Denise Unterwurzacher [Atlassian] (Inactive) added a comment - Hi garen_parham1471499919 . In terms of fixing existing systems with broken mentions, unfortunately there isn't a way to do that, because the mentions are rewritten during the import process. Once the import is done, if the mentions are broken, they will stay that way, because only the userkey is stored in the page - there is no associated username. There won't be any backport of this fix, because backports are risky and can be problematic. In this case the fix only works on import, it can't fix an instance post-import, and the 'Workaround prior to import' detailed in the issue description above can be performed pre-import to achieve the same result. I will add another workaround to the description to detail the case where you don't have access to the original system anymore. It is however very manual, and requires the export file for reference.

            Garen Parham added a comment - - edited

            Any hope of the fix for this being backported for 5.10.x versions?  Also, any hope for an "automatic" fix (or anything really) for existing systems that have these broken mentions?  We currently have quite a few pages that are affected and have been unable to locate the original systems where the old user_key data came from – so we aren't able to try the fix suggested in the confkb article ("User mentions appear as Broken link after XML import").

            Garen Parham added a comment - - edited Any hope of the fix for this being backported for 5.10.x versions?  Also, any hope for an "automatic" fix (or anything really) for existing systems that have these broken mentions?  We currently have quite a few pages that are affected and have been unable to locate the original systems where the old user_key data came from – so we aren't able to try the fix suggested in the confkb article ("User mentions appear as Broken link after XML import").

            Denise Unterwurzacher [Atlassian] (Inactive) added a comment -

            Thank you so much r.rallison! The extra level of CDATA was the missing link, and I've now managed to reproduce the issue, so I'll update the steps to reproduce above. I appreciate it!

            Denise Unterwurzacher [Atlassian] (Inactive) added a comment - Thank you so much  r.rallison ! The extra level of CDATA was the missing link, and I've now managed to reproduce the issue, so I'll update the steps to reproduce above. I appreciate it!

            Ray R. added a comment -

            I'm no longer in the department which runs our instance of Confluence, but here are some tips on getting a repro.

            If you're importing to a target instance of Confluence which is a clone of the source instance, then the userkeys won't be different and the mentions won't break. You will probably still see translateBodyContentXhtmlProperty errors in your logs, but the page content will appear correct.

            Also, the error doesn't affect all pages with mentions. As noted in my first comment, only pages that have CDATA in them will fail to translate. Try adding a noformat macro to a page with mentions.

            If you're able to read customer service requests, there are some additional details in CSP-130962.

            Ray R. added a comment - I'm no longer in the department which runs our instance of Confluence, but here are some tips on getting a repro. If you're importing to a target instance of Confluence which is a clone of the source instance, then the userkeys won't be different and the mentions won't break. You will probably still see translateBodyContentXhtmlProperty errors in your logs, but the page content will appear correct. Also, the error doesn't affect all pages with mentions. As noted in my first comment, only pages that have CDATA in them will fail to translate. Try adding a noformat macro to a page with mentions. If you're able to read customer service requests, there are some additional details in CSP-130962.

            Denise Unterwurzacher [Atlassian] (Inactive) added a comment - - edited

            Hi all. I am trying to reproduce this bug in order to fix it, but I have followed the steps above (and various other steps) in Confluence 5.8, 5.9 and 5.10, and I cannot reproduce the issue.

            If anyone is experiencing this issue on Confluence 5.10 or 6.0, who would be willing to help us out with some more information, could you please contact Support? I would like to gather the following:

            1. The affected space export
            2. A full site export so I can analyse the user data, and reproduce with a new export
            3. A support zip

            Denise Unterwurzacher [Atlassian] (Inactive) added a comment - - edited Hi all. I am trying to reproduce this bug in order to fix it, but I have followed the steps above (and various other steps) in Confluence 5.8, 5.9 and 5.10, and I cannot reproduce the issue. If anyone is experiencing this issue on Confluence 5.10 or 6.0, who would be willing to help us out with some more information, could you please contact Support ? I would like to gather the following: The affected space export A full site export so I can analyse the user data, and reproduce with a new export A support zip

            Doug added a comment -

            We experienced this problem too. Thanks Florian Hassanen for the workaround. Worked well for us on Confluence 5.9.7.

            Doug added a comment - We experienced this problem too. Thanks Florian Hassanen for the workaround. Worked well for us on Confluence 5.9.7.

            Deleted Account (Inactive) added a comment -

            Observed on Confluence 5.10.1, too. Workaround provided by @Florian Hassanen "solved" the problem.

            Deleted Account (Inactive) added a comment - Observed on Confluence 5.10.1, too. Workaround provided by @Florian Hassanen "solved" the problem.

            Florian Hassanen added a comment - - edited

            we observed the same problem under similar conditions like r.rallison

            in the affected instance (Confluence 5.8.4) the error message logged reads:

            WARN [Long running task: Importing data] [importexport.xmlimport.persister.XHtmlBodyContentPropertyUserRewriter] translateBodyContentXhtmlProperty Unable to parse text of BodyContent 11111111 as XHTML storage format: The XML content could not be parsed. There is a problem at line 1, column 7777. Parser message: Unexpected EOF in CDATA section at [row,col {unknown-source}]: [1,7777]

            We can confirm that again CDATA inside CDATA with an escaped end marker "]] >" (do note the space in between!) seems to be cause of this problem.

            We found another work around, that does not involve modifying java code (use at your own risk):

            1. extract the export zip file
            2. in entities.xml replace all instances of "]] >" with "]]]]><![CDATA[>" (kudos to http://stackoverflow.com/a/12860902 )
            3. pack the modified entities.xml into the export zip again

            when importing this modified export zip file, none of the above error messages appear and the mentions are imported correctly.

            Florian Hassanen added a comment - - edited we observed the same problem under similar conditions like r.rallison in the affected instance (Confluence 5.8.4) the error message logged reads: WARN [Long running task: Importing data] [importexport.xmlimport.persister.XHtmlBodyContentPropertyUserRewriter] translateBodyContentXhtmlProperty Unable to parse text of BodyContent 11111111 as XHTML storage format: The XML content could not be parsed. There is a problem at line 1, column 7777. Parser message: Unexpected EOF in CDATA section at [row,col {unknown-source}]: [1,7777] We can confirm that again CDATA inside CDATA with an escaped end marker " ]] > " (do note the space in between !) seems to be cause of this problem. We found another work around, that does not involve modifying java code (use at your own risk): extract the export zip file in entities.xml replace all instances of " ]] > " with " ]]]]><![CDATA[> " (kudos to http://stackoverflow.com/a/12860902 ) pack the modified entities.xml into the export zip again when importing this modified export zip file, none of the above error messages appear and the mentions are imported correctly.

              dunterwurzacher Denise Unterwurzacher [Atlassian] (Inactive)
              dluvison Deividi Luvison (Inactive)
              Affected customers:
              28 This affects my team
              Watchers:
              36 Start watching this issue

                Created:
                Updated:
                Resolved: