Document checklists
This page describes what the module makes of an upload: a case file item, with a state and a review. It is meant for whoever configures an application, registration or request form, and for whoever reviews the files that come in.
The idea
An ordinary form receives files. A form with a checklist receives a case file: expected items, each of which is uploaded, reviewed, accepted or refused.
A requirement designates a file field on the form and adds to it what the case file needs besides:
| Setting | Effect |
|---|---|
| File field | The item this requirement governs. |
| Item name | What the reviewer reads in the table. |
| Required item | Holds the case file incomplete until it is accepted. |
| Accepted formats | Extensions, for example pdf, jpg. Empty: whatever the plugin already accepts. |
| Maximum size | In kilobytes. Zero: the plugin’s own ceiling. |
Constraints can only narrow. The plugin accepts nine types and five megabytes; a requirement may accept nothing but a two-hundred-kilobyte PDF. The reverse is not possible: a format absent from the plugin’s list never gets past the upload, and no setting here will rescue it.
The four states
| State | Meaning |
|---|---|
| Missing | No file has arrived. |
| To review | A file is there, nobody has looked at it yet. |
| Accepted | Reviewed and kept. |
| Refused | Reviewed and refused, with an internal reason. |
A case file is complete only when every required item is accepted — not merely uploaded. That distinction is the whole point of the module: a file whose items have all arrived but which nobody has looked at is not a complete case file, it is a case file to review.
Optional items never hold the case file back, whatever their state.
The internal reason stays internal
The reviewer’s note is for whoever picks the case file up again in six months. It is never sent to the applicant: the message they receive tells them which item is refused, and nothing else. A note written for a colleague is terse, passes judgement and assumes a context; read by the person it concerns, it does not say the same thing.
Replacing an item
It is done from the submission detail, by the reviewer. The refused item comes back through the usual channel — email, counter — and is uploaded there.
Self-service replacement assumes the applicant returns to their case file through a signed link: that is a portal, and it is the subject of a separate plan. This is an accepted limit of this first version.
The old file is not deleted. A replacement can be a mistake, and the original item is sometimes the only trace of what had been submitted. It goes with the case file’s purge, along with everything else.
Where the files live
In the plugin’s private upload folder, the one the core already protects with an
.htaccess and an index.php — never in the media library, never behind a
public URL. The module creates no other: that would have meant securing and
purging two locations instead of one.
A file’s real type is read from its contents, never from its extension nor
from the header it announces. An executable renamed report.pdf is refused at
upload; and if its name ends in something other than the expected format —
report.pdf.exe — the item’s constraint refuses it a second time.
Deletion takes everything
Deleting a submission erases its items, including those a replacement had set aside. The submission designates only the current file; the review table is the only thing that knows where the others went.
Without this, a document would have stayed on disk after a GDPR deletion — which is exactly what the purge exists to prevent.
Exporting the states
The Export case file states button, in the submissions list, produces a CSV: one row per case file, one column per item, and completeness in plain words.
It contains no file path and no internal note. An export gets forwarded, opened on a workstation, dropped in a shared folder: writing the location of the items on the server into it, or what a reviewer noted for a colleague, would take out of the case file what must stay in it.
What the module does not do
No text recognition, no off-site virus scanning, no data extraction, no public sharing, no external storage. Each one would send off the site documents that are uploaded there precisely so that they do not leave it.
Rights
Reviewing and exporting follow the submissions’ rights: you need the capability to view them, and the form must be accessible to the user. A reviewer who cannot see a form does not export the state of its case files.