Default Screen Schemes are messed up with recent project imports in Jira
Platform Notice: Data Center Only - This article only applies to Atlassian products on the Data Center platform.
Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Summary
After using a third-party plugin to import multiple project areas, users start complaining about different issues (permissions, notifications, screens, etc) because multiple default schemes were replaced during the import.
Cause
The Projects imported were also using default schemes but they were with a different configuration. Once imported, they replaced the Production default schemes in multiple areas (permission, notifications, screens, etc).
Please Read
⚠️ As with all recommendations made by Atlassian Support, please follow best practices for Change Management and make sure to test and validate these steps in a lower environment (staging, development, testing, etc) prior to rolling any changes into a Production environment. This is to validate these changes and ensure that they will function well within your infrastructure prior to placing these changes in production.
Solution
Jira Production was messed up. And now?
Jira does not have a "rollback" option, to revert the latest updates, so the only possible way is to restore a backup and manually re-do the latest changes.
Recommendation
Prepare a Stage Test Environment using Production Data "STAGE". This Environment will be used to preserve the messed Production data;
Restore the Production environment to the last known good backup prior to the import;
Perform a full lock reindex on Production;
Restore tickets created by end-users since the import incident from "STAGE" to Production;
environment:
Use a JQL search to find issues that were created/modified since the incident;
Export them to CSV;
Import the CSV into PROD Jira.
The restoration of issues from STAGE to Production has limitations. Non-issue items will not be restored. These can include some third-party plugin data (as an example, Xporter for Jira templates), or even first-party data such as Advanced Roadmaps for Jira plans.
Justification of this recommendation
We cannot accurately find the impact of the import done.
Challenge 1 - third party plugin
The item used to perform the import was a third-party plugin, and we do not have access to its source code or how it works. Therefore, Atlassian Support cannot determine accurately what this plugin did, and therefore what the scope of change was.
Challenge 2 - complexity of comparison
There is no accurate, expedient way to compare two Jira instances that are in production use. Items modified or added are stored across many different tables in the database, and these tables have relational links (not always enforced) to each other. To add to this, end-users have been using Production for a few days now, so we don't have an accurate way to compare table to table since Production will have data deleted, updated, and created intentionally by users.
Challenge 3 - relational nature of Jira data structure
Some tables in Jira are very easy to compare. Take for example the jiraissue table, which stores basic data for an issue. We can see the Jira issue ID, its summary, description, issue type, and so on. This table could be easily compared from instance to instance.
Let's however look into how a project gets its Field Configuration. The master table is nodeassociation.
The nodeassociation is related to FieldLayoutScheme table. To understand what this scheme is, we need to visit another table, fieldlayout. We can check on the actual fields mapped to this by looking up the fieldlayoutitem table
To perform some kind of comparison, we would need to look up at least more 3 tables, not including the project ID lookup. To add to the complexity, these IDs may have been changed or added during the import.
Jira's database structure is relational and complex. It is not practicable to compare one instance to another to ascertain the configuration delta.
Conclusion
If the import only changed one thing (for example, a custom field name) and we knew what the scope of that change was, then we would have a good shot at manually remediating this data.
However, if we do not understand the full scope of what was changed, and many different product areas might have been affected - notification schemes, field schemes, issue type schemes, and so forth, thus the restoration to a previous database backup is recommended.
Atlassian Support does not have an accurate way to describe the full scope due to the technical reasons above.
While rolling back the instance is not something to be taken lightly, it is the only way we can reliably say that the instance is brought back into a consistent, expected state.
Was this helpful?