Better support for migrating plans to a new mission model version
Opened this issue · 5 comments
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.
Met with @lklyne and developers to start gathering requirements on this, Lyle took some notes in this Figma document:
Lyle will be working on UI design for this next sprint, and we'll kick off dev/implementation discussions in earnest next week.
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
- 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.
Plan details error messaging for extraneous activities:
Potential model for fixing activities that were renamed:
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
A potential approach here:
https://www.figma.com/design/dNrdkpcAobXVqj97JaSm1l/AERIE-Mission-Model-Migration?node-id=21-1909&t=0yTN3oNEfhv7psvm-4
For extraneous activity types
- Extraneous activity types are resolved one by one.
- User clicks rename by one of the extraneous activity types
- User selects a replacement activity type from the AD
- (idea to validate) can we hint at parameter mismatch, or even suggest activities with matching params
- Renaming changes all activity types
For extraneous parameters
- Similar workflow to activity types above
- List all extraneous parameters for an activity
- User can fix none, some, or all
