Problem: Storage service package objects do not keep knowledge of prior states, (state-before-last)

[ross-spencer]

Please describe the problem you'd like to be solved.

Storage service can set packages back to a prior 'concrete' state and not intermediary states. E.g. if a package deletion request is rejected, the DEL_REQ flag should be removed and the previous state of the package reinstated.

Describe the solution you'd like to see implemented.

There are two possibilities I see for this:

• Enable the storage service to keep knowledge of a package's state at more than two different points in time, i.e. the DEL_REQ and the state prior to that that wasn't a DEL_REQ.
• Create developer documentation that enables the developer (and user) to understand what is possible to do with a package at different states in a workflow. E.g. these are all the statuses we can have for a package. What are the capabilities of the user/user-interface given any particular state and how should states be set backwards if an action isn't followed through. This would make it easier to make changes and perform code-review.
• Determine that there is a difference between status and flag: flags for potential actions, states for concrete actions (and thus implement).

NB. if the deletion, as an example, is possible at multiple stages (which I am reasonably convinced would be as there are no controls in the UI against that) we would still need to implement the first point, i.e. ask the storage service to keep knowledge of the state before last.

Additional context

An example might be package deletion. Because a state constant is used to record as the package being set as requested for deletion DEL_REQ the storage service might maintain memory of that state until the user opts to do something different, e.g. reject that package deletion.

But, what was the state of the package before deletion?

Because the storage service doesn't maintain this logic, all we can currently do is set the flag back to DEL_REQ.

EDIT: This is only partially accurate. This is perhaps a more unusual scenario than discussed here and came up during testing. To recreate this issue the following needs to happen:

1. Deletion fails. Package sent back to DEL_REQ.
2. Package deletion request is then REJECTED: package cannot be set back to a state other than DEL_REQ.

Under normal conditions, the variable here will be used to set status back one.

Partially related to artefactual/archivematica-storage-service#390

---

For Artefactual use:
Please make sure these steps are taken before moving this issue from Review to Verified in Waffle:

• All PRs related to this issue are properly linked 👍
• All PRs related to this issue have been merged 👍
• Test plan for this issue has been implemented and passed 👍
• Documentation regarding this issue has been written and it has been added to the release notes, if needed 👍

[sromkey]

Somewhat related also to #716 (in the sense that it would be nice to tackle both things at once).

[ross-spencer]

Closing as this is a (self-inflicted) non-issue (as far as I understand) if this comment from @replaceafill is resolved here. It looks like the behavior is as expected and status is updated for a deletion requested, and then either removed from this page once deleted, or set back to stored if the request is rejected. We should consider additional testing around #1014 given the opportunity.