Please describe the problem you'd like to be solved
Enabling package deletion to be completed via the API would improve automation of processes around Archivematica. Thinking in this context around assertions we might like to make around the efficacy of various features in our automated processing workflows, though it is conceivable there will be use for folk outside of AMAUAT where parts of Archivematica are suitably decoupled.
We also allow a deletion request to be submitted via the API but do not follow this to its logical conclusion by enabling a deletion request to be approved or rejected.
Equally, preservation and maintenance of AIPs might be supported by original design aspects of Archivematica, notably, system independence, and diverse integration and described in the (currently draft) 'original ADR'.
Describe the solution you'd like to see implemented
Take deletion to its logical conclusion and enable its approval via the API. One approach might be:
API endpoint to list packages for deletion.
API endpoint to approve or reject an API with suitable response for the caller.
Follow up and consider creating some alignment with the regression testing checklist (24.4 and 24.5 (at time of writing) around package deletion approval and rejection, with AMAUAT, and measuring appropriate responses and package status via other calls that can be made via the API.
Describe alternatives you've considered
One could imagine streamlining deletion to a single-step but with great power comes great responsibility. This might not align well with what is anticipated of the administration component a preservation system. Users might still seek some level of independence and air-gap between deletion calls.
There may be other alternatives, including doing nothing.
The storage service does not have graduated levels of access, so there is one flavor of API access for all purposes. If deletion was eventually provided to the storage service then everyone with API access would be able to completely delete packages. As such, levels of access and authentication for specific purposes (read-only/write-only) as examples needs to be considered.
For Artefactual use:
Before you close this issue, you must check off the following:
[ ] All pull requests related to this issue are properly linked
[ ] All pull requests related to this issue have been merged
[ ] A testing plan for this issue has been implemented and passed (testing plan information should be included in the issue body or comments)
[ ] Documentation regarding this issue has been written and merged
[ ] Details about this issue have been added to the release notes
Please describe the problem you'd like to be solved
Enabling package deletion to be completed via the API would improve automation of processes around Archivematica. Thinking in this context around assertions we might like to make around the efficacy of various features in our automated processing workflows, though it is conceivable there will be use for folk outside of AMAUAT where parts of Archivematica are suitably decoupled.
E.g. https://github.com/artefactual/archivematica-storage-service/issues/250
We also allow a deletion request to be submitted via the API but do not follow this to its logical conclusion by enabling a deletion request to be approved or rejected.
Equally, preservation and maintenance of AIPs might be supported by original design aspects of Archivematica, notably, system independence, and diverse integration and described in the (currently draft) 'original ADR'.
Describe the solution you'd like to see implemented
Take deletion to its logical conclusion and enable its approval via the API. One approach might be:
Describe alternatives you've considered
One could imagine streamlining deletion to a single-step but with great power comes great responsibility. This might not align well with what is anticipated of the administration component a preservation system. Users might still seek some level of independence and air-gap between deletion calls.
There may be other alternatives, including doing nothing.
Additional context
Original related issue where part of the solution seems to have been implemented in the API and Storage Service UI: https://github.com/artefactual/archivematica-storage-service/issues/250
Levels of access in the Storage Service
The storage service does not have graduated levels of access, so there is one flavor of API access for all purposes. If deletion was eventually provided to the storage service then everyone with API access would be able to completely delete packages. As such, levels of access and authentication for specific purposes (read-only/write-only) as examples needs to be considered.
For Artefactual use:
Before you close this issue, you must check off the following: