Upload and Download Plans

Mythicaeda commented 5 months ago

Checked for duplicates

Yes - I've already checked

Alternatives considered

Yes - and alternatives don't suffice

Describe the feature request

Allow users to download and upload plans in a similar manner to what is provided in the aerie-cli. Specifically:

Allow users to download a json representation of a plan, its activities with arguments, and tags. This download functionality should be exposed within the plan page and in the table of plans.
Allow users to upload a plan json file. This will involve adding an upload button to the plans page and allowing a user to specify a model and give the plan an alternative name if the plan name is already taken. Note: most of the upload can be performed in a single query but extra work is required to associate the old activity ids with the new activity ids so that subsequently the UI can set the appropriate anchor_ids on the newly uploaded activities, where appropriate.

See slack thread for more context and details: https://jpl.slack.com/archives/CJ07FGRPH/p1718137212295689

dandelany commented 1 month ago

@duranb demo'ed progress on this in today's Sprint Demos meeting and we had some discussion/ideas come out of that:

Per @cartermak - we should consider it a requirement to be able to export from one host and import to another, handling any cases with mismatched IDs
We should drop the sim_id field from the JSON format since it's not really being used
Should drop model_id from format and force the user to associate a model at import time - rather than matching to the same model ID and potentially using the wront model
Should include Sim arguments to the JSON format so they are preserved in the imported plan
Should include activity directive tags in the format (currently it only has plan tags)
- and include color for the tags, which will be used to recreate the tag with the same color if it doesn't exist in the target environment. If the tag already exists, its color will be left alone.
Should add a "version" field to the JSON which specifies the format version. Hardcoded to "1", incremented anytime we change the format in the future.
Need to handle cases where the imported plan's activity args or sim args don't match expected args - warning or error
Will plan to meet next week sometime to discuss these details

bradNASA commented 1 month ago

@dandelany , I'm not sure I'm adding this comment in the right place. I heard talk of switching from using durations instead of end times. I vote to support both. One activity could have a start time and duration. Another could have a start time and end time. Another could have all three, but they need to agree.

In addition, I would like to have the option to specify times as timestamps or offsets from the plan start and be able to mix them. I'd also like timestamps supported for DOY and MM-DD, again allowing a mix. I'd also like fractions of seconds to be optional (with any number of digits up to some limit, which I expect is 6 for aerie) along with time zone specifiers like "Z," "PST," "+7:00," and "-07:00." I guess I could live with restrictions on time zones, but I expect it wouldn't be much harder to support.

dandelany commented 1 month ago

A few notes based on discussing ^these points with Brad yesterday:

While we are making some changes the export format noted above, we expect to maintain backwards-compatibility for importing older files. In particular, we do not currently plan to switch to specifying durations instead of end times, which would break compatibility if it was the only option.
We don't plan to implement any of the suggestions for optionally specifying things in different ways for V1 plan import - but will discuss and consider these for a later version.
One more format improvement we discussed in the meeting that should be included is a "version" field which would specify the format version. This would be hardcoded to "1" for now (or "2" if we want to consider the existing files version 1) and incremented in the future anytime we change the format going forward. I'll edit my last comment to add this to the list

NASA-AMMOS / aerie-ui