Task #7888
Add PREMIS event for deletion of package after extraction when it's selected in the Extraction micro-service
| Status: | Verified | Start date: | 05/11/2015 | |
|---|---|---|---|---|
| Priority: | High | Due date: | ||
| Assignee: | - | % Done: | 100% | |
| Category: | PREMIS | |||
| Target version: | Release 1.7.0 | |||
| Google Code Legacy ID: | Requires documentation: | |||
| Sponsored: | No |
Description
The deletion event should be recorded in the AIP METS file as a PREMIS event.
--this came up in the chat room as a result of the creation of an additional structMap for the transfer post-extraction ('unpackaging' PREMIS event)
Subtasks
History
#1 Updated by Evelyn McLellan over 7 years ago
You know, this could be complicated. How do you create a PREMIS event for an object that no longer exists? What do you link the event to? I'm thinking this may be the reason why we don't already have this event.
#2 Updated by Courtney Mumma over 7 years ago
Evelyn McLellan wrote:
You know, this could be complicated. How do you create a PREMIS event for an object that no longer exists? What do you link the event to? I'm thinking this may be the reason why we don't already have this event.
Perhaps it should be a log of the deletion? Any tracking would do.
#4 Updated by Justin Simpson about 7 years ago
- Status changed from New to In progress
I think this is addressed in 7690 work. The deletion of the original zip file will be recorded in the logs directory, not in the mets file. We don't currently have anything in the archivematica METS file to handle intellectual entities (i.e. non-existent physical objects, directories, etc).
When we implement premis 3.0, I think that is when we will add this kind of support, for now, we just have to verify in 1.4.0 release that there is adequate data in the logs directory.
#5 Updated by Sarah Romkey about 7 years ago
- Status changed from In progress to Feedback
This was perhaps not ready for QA/review, but I was just testing #7690 and there is no logs directory in the AIP.
#6 Updated by Sarah Romkey about 7 years ago
- File issue_7690-38e0595a-df2e-4b40-aa72-0a605fea3b0d.7z added
- File 7690_again-0e05086e-ae55-409f-8edc-946fdcb1eec4.7z added
I have run two tests and can't find the logs directory in either- please see attached AIPs.
#7 Updated by Evelyn McLellan about 7 years ago
- Status changed from Feedback to QA/Review
#8 Updated by Sarah Romkey about 7 years ago
- Status changed from QA/Review to Feedback
There isn't a log being created by the extract packages micro-service, or at least the log is not landing in the transfer logs. Again, this was tested in conjunction with #7690 .
#9 Updated by Misty De Meo about 7 years ago
Looking at the contents of StandardTasksConfigs, I don't think we added anything to cause this to be logged to disk.
#10 Updated by Justin Simpson about 7 years ago
- Status changed from Feedback to In progress
This issue is waiting completion of the subtask, we didn't define the requirement for a log file from the extract packages microservice, now we have.
#11 Updated by Justin Simpson about 7 years ago
- Status changed from In progress to Deploy
#12 Updated by Sarah Romkey almost 6 years ago
- Status changed from Deploy to Feedback
- Target version changed from Release 1.4.0 to Release 1.6
As of 1.5, there isn't anything in the logs to indicate that a package was deleted.
I can't find a PR for this feature- let's take a look again in preparation for 1.6.
#13 Updated by Justin Simpson over 5 years ago
- Assignee deleted (
Justin Simpson)
#14 Updated by Sarah Romkey over 5 years ago
- Status changed from Feedback to New
#15 Updated by Sarah Romkey over 5 years ago
- Target version changed from Release 1.6 to Release 1.7.0
#16 Updated by Sarah Romkey about 5 years ago
- Status changed from New to Verified
The subtask took care of the main feature behind this ticket, so verifying.