Privara Manual, as shipped in the download
Privara — User Manual
A register for data-subject requests, and the clock that runs on each one. Version 3.1.5 [src: app/controllers/api.php:18].
About this manual
Every statement here was written by reading Privara's own source, and each one carries the file it came from in a bracketed src marker. Paths are relative to the folder this docs directory sits in. If a sentence disagrees with the application, the application is right and this manual has a bug — the markers exist so you can check rather than take our word for it.
Nothing is described that the code does not do. Where something is deliberately limited, that is said plainly rather than left out.
One framing point before anything else. Privara records requests and computes dates from them. It does not decide whether you have complied with anything, and nothing in this manual is legal advice. What follows describes what the software calculates and where in the code it does so.
What Privara handles
Six kinds of request: access, deletion, rectification, portability, objection and restriction of processing [src: app/src/Dsar.php:31]. Request text is accepted up to 100,000 characters [src: app/src/Dsar.php:42].
A request can arrive through a public form on your own site [src: app/index.php:66], or be logged by a handler when it came in some other way — by post, by e-mail, or across a counter.
A subject who has submitted one can check its progress themselves, by reference [src: app/index.php:69], and a verification link confirms the request came from the address given [src: app/index.php:68].
The deadline, and how it is counted
This is the part of the product that does real work, and it is worth reading properly.
The statutory period is one calendar month [src: app/src/Dsar.php:89]. The counting is not, however, "add one month to today" — it follows the European Union's own rules for counting periods, which the source names and implements [src: app/src/Dsar.php:5].
The day of receipt does not count. The period begins the following day [src: app/src/Dsar.php:76].
A month-period ends on the same-numbered day of the last month, clamped to the month end where that day does not exist [src: app/src/Dsar.php:45]. A request received on 31 January produces a deadline in February that lands on the 28th or 29th, not in March.
A deadline falling on a Saturday, Sunday or public holiday runs to the end of the next working day [src: app/src/Dsar.php:59].
There is one further guard worth knowing about, because it protects against a subtle case. Clamping a month-end date can pull the computed end back onto or behind the date the request arrived; the code refuses to let the period end before the day after receipt [src: app/src/Dsar.php:76].
Why the counting rules matter rather than being pedantry
The source states the consequence of getting this wrong, and it is the reason the rules are implemented rather than approximated: counting from the received date without those provisions marks requests overdue up to three days early [src: app/src/Dsar.php:13].
Three days early is conservative, and it is still wrong in a register a controller might have to show a regulator. A deadline that is wrong in your own favour is still a deadline you cannot defend.
The extension
A complex request may be extended, once, to three months in total [src: app/src/Dsar.php:96].
The application enforces the "once" and refuses a second attempt with a plain explanation [src: app/controllers/app.php:236]. Every extension is written to the request's log with the new deadline [src: app/controllers/app.php:236].
That rule lives in exactly one place, deliberately. The source notes that the screen and the REST interface each used to carry their own copy, and that two copies of a statutory rule is one copy too many [src: app/controllers/app.php:229].
The verification email
When a request arrives through the public form, the requester is sent a link to confirm their address [src: app/src/helpers.php:100]. It goes through your own SMTP server whenever an SMTP host is set in Settings, and through the server's own mail() only when none is [src: app/src/helpers.php:69]. The sender is the SMTP "From" address, or the DPO address when that is empty, or the SMTP username when that is an address [src: app/src/helpers.php:55].
Whether it was sent or not is written to the request's own log. When it was not — no mail server, or the server refused it — the log says so and why, and the requester's confirmation page tells them the email could not be sent and gives the DPO address to write to instead [src: app/src/helpers.php:100].
Correspondence and evidence
Files can be attached to a request: a PDF, Word, OpenDocument or Excel file, a PNG or JPEG scan, a TXT, CSV, JSON or EML file, or a ZIP, up to 10 MB each [src: app/controllers/v3.php:605]. The file's own bytes decide its type, not its name; HTML and SVG are refused whatever they are called [src: app/controllers/v3.php:607]. If your server's PHP upload limit is lower than 10 MB, the page states the lower figure and a larger file is refused with that reason [src: app/controllers/v3.php:661]. Attachments are served only to a signed-in user, and every type except an image downloads rather than opening in the browser [src: app/controllers/v3.php:707].
Erasing a closed request's subject details also deletes its attached files from disk and blanks their names [src: app/controllers/v3.php:730].
The deadline digest
The daily digest of what is overdue and what falls due soon is sent with the first dashboard visit of the day once it is switched on and SMTP is set — no cron job is needed [src: app/controllers/v3.php:471]. A daily cron call to the digest URL still works for days nobody signs in. A mail server that refuses is retried at most once an hour, and the failure is written to the audit trail [src: app/controllers/v3.php:471].
Status: what is stored and what is worked out
Privara keeps five stored statuses — new, verifying, in progress, completed and refused [src: app/src/Dsar.php:33] — and displays six [src: app/src/Dsar.php:35].
The sixth is overdue, and it is never stored. It is derived whenever status is asked for, by comparing today against the request's effective deadline [src: app/src/Dsar.php:107].
The precedence is deliberate: refused and completed win first, because a closed request cannot become overdue afterwards; then overdue; then whatever the stored status was [src: app/src/Dsar.php:104].
"Effective deadline" means the extended one where an extension was granted, and the original otherwise [src: app/src/Dsar.php:112].
Because overdue is derived rather than written, a register cannot drift into claiming a request is on time after its date has passed.
References and verification links
Each request gets a short reference for humans and a long token for machines, and they are built differently on purpose.
The reference is eight characters from an alphabet that omits the look-alikes — no zero, O, one or I [src: app/src/Dsar.php:39]. It is meant to be read down a telephone.
The verification token is thirty-two random bytes in hexadecimal [src: app/src/Dsar.php:134]. It is meant to be unguessable.
Both are checked for uniqueness as they are issued and both throw rather than return a duplicate if a free value cannot be found [src: app/src/Dsar.php:122].
Users, roles and what each may do
Three roles [src: app/controllers/v3.php:49].
| Permission | viewer | member | admin |
|---|---|---|---|
request.view | yes | yes | yes |
audit.view | yes | yes | yes |
request.handle | — | yes | yes |
request.attach | — | yes | yes |
view.save | — | yes | yes |
| everything else | — | — | yes |
The source names the intent: a viewer holds an auditor's seat and changes nothing, a member is the person who actually handles requests, and settings, templates, erasure and the team are the data protection officer's own [src: app/controllers/v3.php:49].
Exporting the register
The register exports as CSV or JSON [src: app/src/Dsar.php:217].
The API and agent access
Machine access uses a key [src: app/index.php:91]. Requests can be listed and fetched, a status advanced, and an extension applied [src: app/index.php:92].
Five tools are exposed to an agent, of which two write [src: app/controllers/v3.php:49]:
| Tool | Writes? | What it does |
|---|---|---|
list_requests | no | Requests, filterable by derived status including overdue |
request_detail | no | One request with its clocks and its full action log |
deadlines_report | no | What is overdue and what falls due within N days |
create_request | yes | Logs a request that arrived by another channel |
advance_status | yes | Moves a request through the workflow |
advance_status accepts only the stored statuses, so an agent cannot invent one [src: app/controllers/v3.php:49].
What Privara does not do
It does not tell you whether you have complied. It records what arrived, computes the dates the regulation's counting rules produce, and shows you what is overdue. Whether a response was adequate, whether a refusal was lawful, and whether an extension was justified are all judgements it does not make and does not store an opinion about.
Public holidays are supported but not supplied. The working-day roll accepts a list of holidays, in either a recurring MM-DD form or a specific YYYY-MM-DD one [src: app/src/Dsar.php:56]. Neither the request creation path nor the extension path passes one [src: app/src/Dsar.php:76], and the source records that as deliberate [src: app/controllers/app.php:229]. In practice that means weekends are rolled off and national holidays are not — so a deadline landing on a public holiday will be shown as falling that day. If your jurisdiction's holidays matter to your register, that is a gap to close before relying on the dates.
It is not legal advice, and the wording of your notices, your lawful bases and your retention rules are yours. Privara counts days and keeps a trail.