I posted a patch for this in CONF-34994 for those with access to the source code.

Performed a work around that replaces the keys on import using regex replacements on xml the exported entities.xml file and repackaging prior to import to production environments. Much safer than modifying a large production database. Script also provides a safe rollback method in if the import fails only that space is impacted.

Workaround (this is vague and requires database, Excel, and Confluence CLI skills):

1. Run a database query against the old system (from which you exported) to get all user_key and lower_username from user_mapping table. Dump this into Excel.
2. Run a database query against the new system (to which you imported) to get all user_key and lower_username from user_mapping table. Dump this into another Excel sheet in the same document.
3. Use a vlookup function in Excel to map the two datasets to each other based on lower_username.
4. Use Bob Swift's Confluence CLI tool to search the storage format for the mention tag. I may have done this directly in the database, but seems like CLI might be easier. If performance too slow, then use database. It will be pretty easy to identify those which are incorrect... as the first N digits of the user_key fields are probably the same. Narrow your search down.
5. At this point you will know every page which needs to be fixed. If it is small enough, then you can do it manually. Otherwise, figure out the CLI command to run to fix every page.

Anyhow, hope that helps. If someone goes through it, then posting the more specific steps here would be helpful to others. Sorry I didn't think of that when I was doing it.

Hi glen.whitaker

Thanks for getting in touch. Currently there is no update on this issue. We have a number of higher priority issues to address before looking into this. As soon as we have more information we'll update this ticket with details.

Regards
Steve Haffenden
Confluence Bugmaster

Is there any update on this bug? This is a common problem in restoration and having to backup and restore a few hundred spaces this is the number one cause of issues being raised against the confluence instance.

There are some occasions where the mentions works fine for userA within a row on a table and a secondary mention of the same user in the same table but separate row is showing as a broken link.

Hi Rp

Thanks for the update on this.

Regards
Steve Haffenden
Confluence Bugmaster
Atlassian

The broken link that you are seeing here is because the user (user1) no longer exists in the new version of Confluence that you have created.

Please see step #7 in the description. Even if user1 exists the link is broken.

If you have user mention on a page without code block it's OK after import. It says "Unknown user (user1)" (instead of broken link) if user1 doesn't exist.

So code block interferes somehow with user mentions on space import. It prevents correct mapping of user keys to user names on the page. We end up with non-existing user keys. Without code block user keys are correctly remapped (if user exists) or created (if user doesn't exist).

To sum up:

Hi Rp

Thanks for raising this issue. The broken link that you are seeing here is because the user (user1) no longer exists in the new version of Confluence that you have created. As a result the link to the user is no longer valid.

Unfortunately simply recreating the user will not resolve this issue as that user will have a different userID to the original user.

Regards
Steve Haffenden
Confluence Bugmaster
Atlassian