Better support for migrating plans to a new mission model version

[parkerabercrombie]

Checked for duplicates

No - I haven't checked

Alternatives considered

Yes - and alternatives don't suffice

Related problems

No response

Describe the feature request

When a new version of a mission model is available, we will need to migrate existing plans to the new model. Right now we download the plan from the API, run an ad-hoc upgrade script, and then upload to the new model. Aerie should provide a standard workflow for this since this is a very common need.

[dandelany]

Met with @lklyne and developers to start gathering requirements on this, Lyle took some notes in this Figma document:

https://www.figma.com/board/PykIfZW7SNdGoySgQjC81O/AERIE-Plan-Migration-Explorations?node-id=0-1&node-type=canvas&t=MAkhPE1CMmFN1Xxm-0

Lyle will be working on UI design for this next sprint, and we'll kick off dev/implementation discussions in earnest next week.

[lklyne]

Notes and working direction from UIWG 2024-11-20

We have a working direction and a few open questions. General approach is to have a less structured mission model migration process that relies on our built in error handling to identify and resolve errors that come up. Notes here: https://www.figma.com/board/PykIfZW7SNdGoySgQjC81O/AERIE-Plan-Migration-Explorations?node-id=100-1459&t=akjfG5N3Eng6Ed22-4

Workflow plans

1. When a plan is selected on the plans page, show a button to change the mission model
2. Button opens a dialog where user can select a mission model. List of mission models is sorted reversed chronologically, and should display the date a model was uploaded. On this page, we should also show a list of potential errors and a note that a snapshot will be created.
3. After confirming, the mission model for the plan changes, and any errors are flagged in the row item
4. When a plan model migration errors is opened, we show those errors in the activity validation section of the error console.

Updates to activity validation errors console:

• Add "Extraneous activity types" section to the top of the list. This shows all the activity types that are not present in the new mission model. Option to "rename" these, which will associate the missing activity type with a new type. Clicking replace presents a new TBD dialog which lists activity types, and prompts the user to rename a single one, or rename all associated types.
• We should provide similar replace functionality for extraneous parameters.
• Lyle to sync with @dandelany about details for the rename dialog.

Limitations with this approach

• This pattern disallows the ability to do combined swaps. Eg no a -> b and b -> c. The workaround would be a two step migration process.

View model migration questions

• This could introduce view migration issues. There could be conflicts with resource names as well.

Simulation history questions

• Can we show simulations from previous mission models? We should probably record what model is used for each simulation in the database.

[lklyne]

Plan details error messaging for extraneous activities:

Potential model for fixing activities that were renamed:

[lklyne]

Open questions to work through

• "Rename" vs "Replace"
• Do we address anything for parameter renames? "parameter a1" -> "parameter a2"
• Are activities renamed in bulk or one by 1? (1 replace button vs 1 per row item)
• Do we need to support rename for the first go?

Notes

• Would be nice to be able to resolve some errors then come back to more