BE: Migrate system-defined statuses to custom statuses
When the user tries to edit any attribute of a system-defined status or add/remove a status from a system-defined lifecycle, we need to invoke copying the system-defined lifecycle with statuses to custom lifecycle and custom statuses.
This should happen behind the scenes and should not be visible for the user.
The proposal is to add the lifecycle and status entities (with the requested change) and then enqueue the migration using a background job.
We also need to take into account legacy issue board lists, since we're introducing system_defined_status_id and custom_status_id columns to the lists table.
The background job should work like this:
- In the best case, only ever walk the
work_item_current_statusestable. So collect all namespace IDs under the root level namespace and traverse that table. - (Optional) Handle the full migration for all
openitems first. Then walk through allcloseditems afterwards. - Save a mapping in the database so we know what status needs to be migrated to which status.
- Make the system so it also handles regular status migrations (for example if the user deletes a status they should map items to another status which will trigger the background migration)
Further breakdown required or POC.
Edited by Agnes Slota