Issue Summary

During Cloud to Cloud migrations, sometimes importing the Cloud site to Data Center (DC) instance is required as a stepping stone for operations like merging two Cloud instances into one or making some adjustments in the user properties (emails, etc.) before moving to the destination Cloud instance.

Cloud support two AAID formats as mentioned here: https://hello.atlassian.net/wiki/spaces/I/pages/1124693006/AAID+Format

• 5a97df6a3724239813d0f607a
• 342058:d6c19455-ae10-4a41-bad9-33d8d2d3c500

The latter is causing issues in the DC as this is not a valid/expected format for DC to digest. Because of this, after importing the backup from the source Cloud into DC, users can't access contents that have relations with the userkey formatted with the latter format.

This is reproducible on Data Center: yes

Steps to Reproduce

1. Create a Cloud site export containing user objects with the unexpected format and content related (created by, mentioned, etc.) to this type of user.
2. Import it to the DC instance.
3. Navigate to the content related to the user with unexpected userkey formatting

Expected Results

The content should be displayed without any issues.

Actual Results

The below exception is thrown in the atlassian-confluence.log file:

2023-XX-XX XX:XX:XX,XXX ERROR [http-nio-8090-exec-4] [rest.api.model.ExceptionConverter] convertServiceException No status code found for exception, converting to internal server error : 
 -- url: /confluence/rest/experimental/search | userName: XXXXXX | referer: <confluence_baseURL>/index.action | traceId: 82fc7374bc3066e0
java.lang.IllegalArgumentException: hexBinary needs to be even-length: 342058:d6c19455-ae10-4a41-bad9-33d8d2d3c500
     at javax.xml.bind.DatatypeConverterImpl.parseHexBinary(DatatypeConverterImpl.java:427)
    at javax.xml.bind.DatatypeConverter.parseHexBinary(DatatypeConverter.java:342)
    at com.atlassian.confluence.impl.search.v2.lucene.ContentPermissionSearchUtils.compressKey(ContentPermissionSearchUtils.java:138)
    at com.atlassian.confluence.impl.search.v2.lucene.ContentPermissionSearchUtils.getEncodedUserKey(ContentPermissionSearchUtils.java:126)
    at com.atlassian.confluence.impl.search.v2.lucene.filter.ContentPermissionsFilter.<init>(ContentPermissionsFilter.java:75)

OR
Enabling debug logs for the class com.atlassian.confluence.content.render.xhtml will show messages like:

The ri:user tag contained an attribute that we could not process. The ri:userkey attribute had a value of "557057:07161c8c-61af-4a7c-bc37-7f46acca364e". This value could not be accepted for security reasons. We have chosen to remove this attribute from the tag and leave everything else in place so that we could process the input.

Diagnostic

To find out whether if your XML Backup from Confluence Cloud is impacted by this, you can:

1. First find out if any user is exported with the impacted AAID Format in the extracted XML Backup:
   grep command for Unix Environment

   grep -A5 "<object class=\"ConfluenceUserImpl\" package=\"com.atlassian.confluence.user\">" entities.xml | grep key
   
   <id name="key"><![CDATA[5d668ffbc63b940e18c24375]]></id>
   <id name="key"><![CDATA[63fs0a7d6c30bbd7a33e35b1]]></id>
   <id name="key"><![CDATA[712120:879c7303-7ad0-4311-adb0-45573a2181ea]]></id>
   <id name="key"><![CDATA[712120:a7b4415d-f3d5-3cac-ac60-6eab1b5e291c]]></id>
   

   the last 2 AAID formats are impacted

2. Then verify if there is any user-associated content to the impacted AAID Format in the extracted XML Backup:
   grep command for Unix Environment

   grep "ri:user ri:userkey" entities.xml
   
   <ri:user ri:userkey="5d668ffbc63b940e18c24375" />
   <ri:user ri:userkey="712120:a7b4415d-f3d5-3cac-ac60-6eab1b5e291c" />
   

   the second AAID format is impacted, and will be stripped away during XML Import

Workaround

Currently, there is no known workaround for this behavior. A workaround will be added here when available.