The tricky business of migrating app custom fields

Cloud Migrations
1

I’m confused by the section under Step 3: Add the values of migrated app custom fields in the tutorial on migrating app custom fields. It says we can use the bulk API to populate the app custom field values, but it doesn’t say where we get those values from. Does the core migration bring those values across somehow, or do we need to do the whole binary blob thing for those custom fields?

In our server app, we have two custom fields that are derivatives of single-select fields. I’m hoping that the JCMA will populate the corresponding custom fields on the Cloud side if I implement the getSupportedCustomFieldMappings method of the JiraAppCloudMigrationListenerV1 interface. Am I on the right track there?

2

Hello @david.pinn ,
When the getSupportedCustomFieldMappings method from JiraAppCloudMigrationListenerV1 is implemented, it only enables to map the custom field references in respective entities at the cloud side. You can review this ticket with some details

App custom field values are not migrated as part of core data migration. You can use app data export endpoints to retrieve the custom field values that will be accessible at cloud app. You can review the documentation here:

And then use the respective values in the bulk API to populate the custom field values at cloud side.
Hope this helps. Feel free to reach out for any further questions.

3

Thanks, @PoojaJangid.

I have these follow-up questions:

a) Does the core migration add contexts on the cloud side for all of the fields returned by the getSupportedCustomFieldMappings method? For example, I might have a global (all issues) context and a specific-to-project-ABC context on the server-side; will the core migration create those two contexts on the cloud-side?

b) What about the options for my app custom field? Can I find those using the jira/classic:customFieldOption namespace?

With thanks for your help,
David

4

Does the bulk API to populate the custom field values endpoint have to be called in the context of an impersonated user? i.e with an Authorization: Bearer access token header?

The required scope ACT_AS_USER suggests to me that the answer should be Yes, but then why would the Atlassian-Account-Id be required in the header?

5

How would you suggest that we choose a site administrator account to reference in the bulk update API? The migration runs in the background - without any user interaction - so there’s no user context unless we create one.

6

Hello @david.pinn ,
There is a Jira cloud REST API to get the users from site-admins group. You can call this API to get the Atlassian account id of the user that is site admin.
Details: https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-groups/#api-rest-api-3-group-member-get

Just so you know, we have an open MIG ticket to improve the usability of this bulk API. You can vote this ticket to express your interest.
Details: [MIG-812] Remove admin user impersonation from bulk APIs requirements - Create and track feature requests for Atlassian products.

Thanks.

With regards,
Pooja

1 Like
7

Hello @david.pinn ,
Yes, that’s right. This bulk API requires a user impersonation.
Atlassian-Account-Id is required in header because the permissions of user who was site admin when triggering the migration could change, when this bulk API is invoked in migration journey. So the user had to be passed explicitly.

Just so you know, we have an open MIG ticket to improve the usability of this bulk API. You can vote this ticket to express your interest.
Details: [MIG-812] Remove admin user impersonation from bulk APIs requirements - Create and track feature requests for Atlassian products.

Thanks.

With regards,
Pooja

1 Like
8

Hello @david.pinn ,

a. Yes, if getSupportedCustomFieldMappings is implemented, the context will be added at cloud site for respective projects as part of core data migration.

b. To migrate the references of app custom fields as part of core migration, an app has to be installed at cloud site. With this, I understand you already have custom field options id accessible. So you may not have to use jira/classic:customFieldOption as the reference of app custom field option do not change. Do let us know, if this is not the case for your app custom field.

Thanks.

With regards,
Pooja

1 Like
9

The documentation of the Bulk update custom field value endpoint says, “The values of up to 200 custom fields can be updated.”

The documentation of the Bulk update entity properties endpoint does not mention a limit, but is there one?

10

Hello @david.pinn ,
Yes, there is a limit of up to 50 values in single request to entity properties bulk update API.
Thank you for highlighting. We will update the documentation.

With regards,
Pooja

1 Like