Migrate project config to global config. Remove option to create Project-level configs
Description
All configuration should be stored on global level. First, we have to migrate project config to global level following these rules:
Migrate to global level if different from default.
If global level already exists for project. Merge it.
If global level already exists for project but it is related with many projects. Extract it to new global config. Merge it.Ideas how to do that:
- Liquibase migration - it would be best to perform it as a single SQL migration runned immediately when new app version is started. However, due to convoluted nature of operations that need to be performed, this may be hard to achieve.
- If the former is not possible, we will need a code that will handle both new and old configuration + migration job. After running the migration job, we can safely remove parts of the code refering to the old config.
Finally, we should remove button to create Project level config. In both cases we should do this as soon as possible.
Linked issues
is blocked by
ESFJ-780
Add “Default shared fields (shared issue)”, “Default filter columns (shared filter)” to global config
ESFJ-780
Add “Default shared fields (shared issue)”, “Default filter columns (shared filter)” to global config
Released
Activity
Show:
Details
Priority
MediumAssignee
Mariusz Szymański
Reporter
Mariusz Szymański
Fix versions
Roadmap
Created
7 December 2023, 15:19
Updated
20 February 2024, 08:52
More fields
Created: 7 December 2023, 15:19
Updated:
20 February 2024, 08:52
Hello @Mariusz Szymański,
Please merge code to dev branch.
This is the best moment to add more information that can be helpful to prepare release notes.
@Parsa Shiva I don’t know why, but there was some older (pre-migration) code version deployed on QA… So, not the issue with my code.
@Mariusz Szymański Following issue occurs - QA environment.
The project configuration is still available regardless of migration.
@Parsa Shiva As we checked, this functionality works fine; however, global default config and default project config are not created equal. The difference here are smart checklist and issue checklist fields that are less restrictive on default global config level (set to true by default). I assume we can’t risk accidentaly turning this on on shares, so it should stay as is. If the configs are in fact equal, the migration will be skipped.
@Mariusz Szymański Currently we need to address the scenario when a project has identical configuration with the default global configuration. In which case no new configuration with association of that project should be created. It should fall under the default global configuration.
@Mariusz Szymański Ready for QA environment push.
The setup is ready for the next and last test. 🤞
Global and project configs are double checked and recorded by screenshots.
We should be able to finalise it.
@Mariusz Szymański Please push to QA, projects set for migration test.
Possible combinations
Hello @Mariusz Szymański ]
This is the best moment to add more information that can be helpful for tester.
Please attach - Before / After screenshot if possible.
@Mariusz Szymański I will assign you here because this task have no PR
This is done together with
Hello @Krzysztof Bogdan,
Task is ready for review.
@Mariusz Szymański please make sure reviewer
have easy access to contend to be reviewed.
If this is code change. Please make sure PR is created.
If this is new documentation, blogpost, etc. Please provide link to page.