ObjectPermission Data Migration Strategy

[HanlinMiao]

Proposed Changes

For any models that are being removed or collapsed into models (Site and Region -> Location, Aggregate -> Prefix),
we need to keep some sort of records to trace back the old model instances that are removed along with the old model classes specifically for ObjectPermission constraints constructed by the UUIDs of old model instances:

{
    "id": "d266c50f-fdcc-4bb1-b768-2492034e1b86",
    "id__in": ["d266c50f-fdcc-4bb1-b768-2492034e1b86", "5318f8c3-c0dc-4534-9b92-458a378a0fdc"],
}

Justification

Since we decided to let admin users themselves resolve and change the constraints of ObjectPermission instances to use the new model filters after the old model classes are removed, we need to assist the user in any way possible in referencing the old model instances.

[lampwins]

As discussed, I think we should migrate the UUIDs to the new objects, i.e. a record keeps its same UUID through the migration. This would help not only in this case, but also external/3rd party references to records via the UUID.

Additionally, I would like to see us produce log files are part of these migrations to assist administrators if they need to trace an object.

[bryanculver]

As discussed, I think we should migrate the UUIDs to the new objects, i.e. a record keeps its same UUID through the migration. This would help not only in this case, but also external/3rd party references to records via the UUID.

Additionally, I would like to see us produce log files are part of these migrations to assist administrators if they need to trace an object.

This is being done for Location, but isn't for Role, Aggregate, and potentially others. @lampwins would it be preferred to go back and do that for all models which are being collapsed into others?