Better support for migrating plans to a new mission model version

parkerabercrombie commented 3 months ago

Checked for duplicates

No - I haven't checked

Alternatives considered

Yes - and alternatives don't suffice

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 commented 2 weeks ago

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 commented 1 week ago

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

When a plan is selected on the plans page, show a button to change the mission model
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.
After confirming, the mission model for the plan changes, and any errors are flagged in the row item
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.

NASA-AMMOS / aerie