Issue Summary

Sharing any object (Dashboard or Filters) with a direct user will add a new row with PARAM1 set to the external_id instead of the user_key. This causes problems when migrating to Data Center as Jira DC doesn't understand this value as a valid user and will throw an error saying the user does not exist:

Reproducible on Data Center:

No, Datacenter uses user_key.app_user

Steps to Reproduce

• Create a new user;
• Create a new Dashboard or Filter;
• Share the dashboard or filter with this user;
• Query the table sharedpermissions looking for this shared record
• the param1 column will store the external_id from the cwd_user record of this user.

Expected Results

Jira should use user_key for all user associations.
During the export, the external_id's should be replaced with user_keys, so that admins can use the Manage Shared Objects section to adjust any shares to the Dashboards or Filters as expected once migrated to Data Center.

Actual Results

external_id is used.
While the Cloud instance is able to understand the external_id as the user profile, DC is unable to create such an association. User references are made to the user_key which is then tied to the cwd_user table to retrieve the user profile.

This is a problem during migrations from Cloud to Data Center. This means once the data is migrated to DC, most objects that have a direct share with a user profile will lose their association, and whenever an admin tries to edit the share it will throw an error as that specific user external_id does not exist as a valid user. There is no easy way to identify the users without database manipulation.

This happens because the external_id is not used for user profile associations in DC, it uses the user_key instead. That being said the "sharedpermissions" will show anonymous users after the migration:

This will impact any Cloud to DC migration.