• Symptom Severity:
    • Support reference count:
    • Sprint:
      Enterprise is heavy, Galaxy - zsh, Imps Sprint 20
    • Occurrence Factor:


      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
        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>
      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


      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.


          Issue Links



              • Votes:
                28 Vote for this issue
                38 Start watching this issue


                • Created:
                  Last commented:
                  6 weeks, 2 days ago