Import/Export confluence space: Why do some @mentions fail gracefully and others break?

[Michael Podvinec]

We're in the process of exporting a confluence space from one instance to another. 

In this context, we've discovered that mentions break upon import into another instance, as they reference the user by some unique user identifier from the database. For some mentions, however, the link breaks but the name of the referenced user is displayed (i.e. it fails gracefully). In this case, the storage format in the SOURCE wiki looks like this:  

<ac:link>

  <ri:user ri:userkey="<32hexdigits>" />

  <ac:plain-text-link-body>

    <![CDATA[Lastname Firstname]]>

  </ac:plain-text-link-body>

</ac:link>

For other mentions, the link breaks and a "broken image" icon is shown instead, with no easy way of discerning the user that was mentioned originally. In this way, the storage format in the SOURCE wiki looks like this: 

<ac:link><ri:user ri:userkey="<32hexdigits>" /></ac:link>

I realize this is a long shot, but does anyone know what makes a mention use the former (more gracefully failing) format, rather than the latter?

Also, if anyone has experience with fixing up mentions after an export/import to another system, I'd be interested in your solution. 

Thanks, 

Michael 

[Boris Georgiev _Appfire_]

Hi Michael,

The "32hexdigits" is the user key of the user in Confluence. The user key is mapped to a username and a user with this username is looked up in the user directories registered in Confluence. If a user is not found the macro breaks.

When doing imports from another instance you need to make sure that all the users from the source instance are available inside the target instance - and the usernames should match. The importer looks the users by name and fixes the references inside pages (fixes the userkey), but if the user is not found then the importer leaves the old user key (the one from the source instance).

To fix this you have a few options:

• Ensure the users from source are available on target and then do the import again
• Run a SQL script to fix the user keys inside the ri:userkey=" attribute - THIS IS DANGEROUS AND YOU NEED TO BE SURE YOU KNOW WHAT YOU'RE DOING before taking this approach
• Write a groovy script with script runner to fix all the pages with broken user mentions macro - might be slow if you have large set of pages to scan but much safer than the SQL approach