RFCs are a way for Atlassian to share what we’re working on with our valued developer community.
It’s a document for building shared understanding of a topic. It expresses a technical solution, but can also communicate how it should be built or even document standards. The most important aspect of an RFC is that a written specification facilitates feedback and drives consensus. It is not a tool for approving or committing to ideas, but more so a collaborative practice to shape an idea and to find serious flaws early.
Please respect our community guidelines: keep it welcoming and safe by commenting on the idea not the people (especially the author); keep it tidy by keeping on topic; empower the community by keeping comments constructive. Thanks!
- Publish : 25th March 2024
- Discuss : 29th Match 2024
- Resolve : 7th April 2024
Summary of Project:
Atlassian is looking at how we can reduce app migration friction for our customers. Sometimes it is not a great experience due to manual steps and stuck or slow app migrations. Below we will look at a solution for migrating app custom fields by type to improve the current state.
Problem
We’ve noticed low usage of our existing Connect Custom Field migration feature. We’re interested in understanding why this is and how we can better assist you in migrating your specific app custom fields n.b. Atlassian custom field types are automatically migrated by the Jira Cloud Migration Assistant (JCMA).
The current solution is limited to migrating a specific instance of a custom field in server by name and type and expects it to already exist in cloud i.e. no new custom field will be created during migration. This works for locked custom fields but not for unlocked custom fields where the custom field name could be defined by the customer.
Proposed Solution
Add getSupportedCustomFieldTypeMappings to retrieve custom field type mappings in JiraAppCloudMigrationListenerV1:
public interface JiraAppCloudMigrationListenerV1 {
Map<ServerAppCustomField, String> getSupportedCustomFieldMappings();
// New
Map<String, String> getSupportedCustomFieldTypeMappings()
}
public class ServerAppCustomField
{
String fieldName;
String fieldTypeKey;
}
An example where we migrate all custom fields of type custom-field-server-type:
public Map<String, String> getSupportedCustomFieldTypeMappings() {
return Map.of(
"custom-field-server-type",
"custom-field-cloud-type"
)
}
The custom field type in this context is the suffix of the type key after the : e.g. for com.vendor.app:calculated-dateonly-field you would use calculated-date-only-field corresponding to the key field when you define your custom field type.
You can continue to use getSupportedCustomFieldMappings with getSupportedCustomFieldTypeMappings we will migrate all custom fields that fit into either map.
We hope by making JiraAppCloudMigrationListenerV1 API more flexible to migrate more app data in JCMA we can reduce the manual effort to migrate your app.
Asks
- If we add the feature to migrate custom fields by type i.e. don’t specify the custom field name will this be useful?
- Are there any other gaps to consider?
Thank you for helping improve app migrations.