A couple of tweaks to the child file table in the notification emails:
- Name - if the file was uploaded to S3, the name could be a direct download link to the file;
- Checks passed - rename to just "Checks", and give more info in the values, rather than just True/False: "N/A" if no checks applied (or just non-empty), e.g. "FAIL (cf)" if any checks failed, "PASS" if all passed.
- Published - rename to "Status", with values:
- PUBLISHED if file was successfully harvested and/or stored to S3;
- ARCHIVED if file was only archived (and not harvested or stored to S3);
- IGNORED if publish_type was NO_ACTION (though we'd also need to consider if the file was used to generate another file which was then published)
- DELETED if the file was a delete request and was successfully deleted;
- ERROR if anything went wrong.
It may also be helpful to indicate if a file was an overwrites of a previously published version (e.g. with an asterisk in the Status column, explained below the table).
It would also be helpful to identify files that were not part of the original incoming collection, but generated during the handling process. Again, could be indicated with a special symbol in the table + a footnote, or better still, these files could be listed in a separate table.
A couple of tweaks to the child file table in the notification emails:
It may also be helpful to indicate if a file was an overwrites of a previously published version (e.g. with an asterisk in the Status column, explained below the table).
It would also be helpful to identify files that were not part of the original incoming collection, but generated during the handling process. Again, could be indicated with a special symbol in the table + a footnote, or better still, these files could be listed in a separate table.