Spike: Validation

Data integrity validations

Use database constraints to ensure database integrity. e.g. ensuring that foreign keys are not NULL
Use rails validations to enforce validations that cannot be enforced as db constraints but are essential to the integrity of data. E.g. ensure that a previously decided decision is not changed
These validations (both database constraints and rails validations) will result in a failure to save the inconsistent data to the database.
Validation failures should result in:
1. a bugsnag error, because either the client requested something it should not have requested (e.g. a change to a previous reviewer report)
2. an error report to the user frontend (to make them aware that a data save has done awry)

Workflow validations (“readyness”)

Background

We want to ensure that our data is complete and appropriate (ready) as a paper progresses though its lifecycle:
- These readyness checks will ensure, e.g., that each author of a paper has an affiliation, and that only one author is marked as the “corresponding” author, and that the corresponding author cannot be marked as “deceased”
The general user experience model of the Aperta application is that user data is saved on the fly, e.g., when the user ticks the box “corresponding”, that change is immediately saved to the database. This is how the application behaves, generally, and is how we have always presented it.
This means that we must not ever prevent the saving of data because it is not ready
We can, however, prevent certain discrete state changes from happening
Validations are “enforced” when attempting to proceed through a “gate”, e.g. marking a card complete or submitting a paper

Principles

NB: All of the following applies only to papers, tasks, and their associated data models, e.g. authors, attachments, etc.

If a field is otherwise editable, readyness should not prevent saving of data
Readyness checks are enforced at gates:
- submitting a paper
- marking a card as complete
- submitting a review
- registering a decision
These validations, when performed, should not prevent saving data in the database, except insofar as they prevent a state change for the gate, e.g. a change from completed: false to completed: true in the database
In other words, we need to allow the user to save “unready” data but be prevented from marking a card complete
After a card/review/decision is marked completed/submitted/registered, readyness checks should be performed on the “child” data of that card
- For each field, the user should be alerted to future readyness problems, if possible
  - This check should occur upon loss of focus, in the case of text entry
  - This check should occur upon data change, in the case of a selection, radio buttons or tick box
Hierarchical
- Use the template hierarchy for validations
- e.g. each thing is ready if it passes readyness checks and its children pass
- e.g. a validation could include “one of” the child tick boxes
Readyness checks are enforced on the backend by guard
- Card completion is prevented until the card is “ready”
- Paper submission is prevented until the paper is ready (i.e., the submission cards are all completed)
- Decision registration is prevented until the decision is ready
Depending on UX decisions, this could mean that a button is hidden or dimmed when a card is not ready