Change plan start and end bounds

[parkerabercrombie]

Checked for duplicates

Yes - I've already checked

Alternatives considered

Yes - and alternatives don't suffice

Related problems

No response

Describe the feature request

I want to be able to change the plan start and end a plan after the plan has been created. This use case has come up for extending a plan, but I can imagine cases where you might want to change the plan start as well.

[ewferg]

I second this! It should be fairly straightforward for a user to edit plan bounds. Extending does seem like the easiest use case though. If you want to make a smaller plan, what do you do with activities outside the plan bounds?

[joswig]

I think activities outside of the plan bounds should persist, but they won't be simulated. Maybe we add iconography to the table view to indicate that they fall outside the normal time range

[mattdailis]

@AaronPlave let's chat when you get around to working on this. I want to make sure we iron out the behavior w.r.t plan branch/merge.

Simplest (but least user-friendly) option: Disallow editing plan start/end when branches exist

Requires thought but may be okay: keep all activities even if they're outside the plan bounds. Keep the plan bounds of the parent plan after merge. I think the combination of those two facts keeps plan branch/merge simple

Rabbit hole (almost certainly out of scope): allow "temporal subset branching" where activities outside the child plan bounds are omitted from the child plan

[AaronPlave]

Agreed, should think through which solution we want here once I start on this. My initial thought is that we're already accepting that by changing the plan bounds (outside of a merge) you may end up with activities outside of the plan so it doesn't seem unreasonable that this is just a consequence of plan bound changing that affects all related plans.

[dandelany]

Picking up this task again... The UI portion is (mostly) done in NASA-AMMOS/plandev-ui#1834 - @AaronPlave will finish this, fix tests, & remove draft status when ready for review.

We originally hoped this could be a UI-only feature, but Aaron's branch raised a number of questions around backend behavior. I've discussed these with @Mythicaeda and decided on our backend requirements, which she is working on now:

1. Activity directive offsets are relative to the plan start/end time. When plan start time changes, all activity directives that are anchored to plan start should get their start offset updated such that they keep the same absolute time. Likewise, activity directives anchored to plan end should be updated the same way to maintain absolute time if the plan end boundary changes.
2. When plan start time changes, any simulation_dataset and plan_dataset rows associated with the plan should have their "offset from plan start" updated, so that the dataset maintains the same absolute time.
3. Plan snapshots currently do not save plan bounds. The plan_snapshot table should be updated to have start time and duration columns, and these should be set to the plan's boundaries at the time the snapshot is taken. When restoring a from a snapshot, the plan bounds should be restored from the snapshot's bounds. We should add a DB migration for all existing snapshots, which should get their bounds set to the existing plan bounds (since they cannot change today).
4. We should automatically take a new plan snapshot when the user changes the time bounds, as it is a good natural restore point.
5. Plan branch/merge - @Mythicaeda will investigate to determine the changes necessary needed to support merging plan branches with different bounds and update this issue. Main concerns are how we handle activities outside bounds and how we compare the start time of activities from a branched plan in a diff.
   1. If there are significant changes needed, we plan to defer this - we should allow boundaries to be changed on plan branches, but disallow merging two branches with different time boundaries, to avoid this case.
   2. If this basically works already with minimal changes needed, we will support it.