Implement 2nd eye checks and log the results in the curation log

[rija]

User story

As a curator performing 2nd eye check I want to the results of my check recored in my curation log So that we can detect quality and consistency issues more easily

Acceptance criteria

Given I have a dataset with status "Private (2nd eyes)" When I click the link in the email notification Then I am presented with the checklist of items to complete for that dataset

Given a 2nd curator has completed the checklist for a dataset When they click submit on the form Then the form is saved to GigaDB and the handling curator is notified

Additional Info

This is the first step toward implementing what's described in #701

Suggested schema for Curation Log

UX

I suggest two screens were log entries can be entered as part of this story:

• Checklist screen for Quality control: see #705 (so not implemented as part of this story)
• Generic Curation Log controls at the bottom of the Dataset Update Form

Non functional requirements

I suggest curation log entries of compliance type:

• cannot be edited
• cannot be deleted

all below is for compliance type:

They are logs, they are meant for auditing, so they are write only. I also suspect that, in a future not too far, some government will want to have a look at this table's record and would frown upon it being modifiable.

For that reason, I have added the Action Type "6. Correction to previous entry" to support the case were there is a mistake made in an entry that need correcting in a new entry (that's how it's done in accounting journals, where new entries are added to compensate for the error instead of editing the erroneous entry).

Product Backlog Item Ready Checklist

• [ ] Business value is clearly articulated
• [ ] Item is understood enough by the IT team so it can make an informed decision as to whether it can complete this item
• [ ] Dependencies are identified and no external dependencies would block this item from being completed
• [ ] At the time of the scheduled sprint, the IT team has the appropriate composition to complete this item
• [ ] This item is estimated and small enough to comfortably be completed in one sprint
• [ ] Acceptance criteria are clear and testable
• [ ] Performance criteria, if any, are defined and testable
• [ ] The Scrum team understands how to demonstrate this item at the sprint review

Product Backlog Item Done Checklist

• [ ] Code is complete
• [ ] Automated tests related to the changes are implemented and passing
• [ ] All automated test suites are passing locally
• [ ] Code is refactored to best practices and coding standards
• [ ] Documentation is updated as needed
• [ ] A Pull Request has been created and review requested
• [ ] Pull Request is reviewed and approved
• [ ] The item has been merged to the develop branch
• [ ] All automated test suites are passing on continuous Integration pipeline and item is ready to release

[rija]

This story looks like it's a good opportunity to move away from the legacy stack and use the new stack as described in the systems architecture diagram (Yii2 API endpoints)

[only1chunts]

One point of note - "Curation logs" are and should be different to audit logs, I agree an audit log should be un-editable and permanent, but a curation log entry should be both editable and deletable. The prupose of a curation log is maintain the notes, comments and thought of the curators to aid in consistent curation and passing over of datasets to different curators during the curation process, so perhaps these should be renamed to "Curation Notes" instead. There is a type of audit log already in place called "History" on the public datasets, this should automatically log any changes made to published datasets. It should NOT include any changes made to datasets whilst they are not published, i.e. the dataset "History" only starts when a dataset is published, the first entry for a dataset will always be the "dataset was set to public" entry.

[tuli]

One point of note - "Curation logs" are and should be different to audit logs, I agree an audit log should be un-editable and permanent, but a curation log entry should be both editable and deletable. The prupose of a curation log is maintain the notes, comments and thought of the curators to aid in consistent curation and passing over of datasets to different curators during the curation process, so perhaps these should be renamed to "Curation Notes" instead. There is a type of audit log already in place called "History" on the public datasets, this should automatically log any changes made to published datasets. It should NOT include any changes made to datasets whilst they are not published, i.e. the dataset "History" only starts when a dataset is published, the first entry for a dataset will always be the "dataset was set to public" entry.

Thank you for clarifying this important difference between curation and audit logs.