Handling reports¶
This page answers a single question: somebody complains about a publicly visible entry — what happens next, and what do you have to do?
You will find the queue in the governance hub under Reports (/governance/reports).
Roles: who can do this?
The report queue is fully open to hub admins and instance moderators: the list, decisions, and removing/restoring reported entries.
Why this route exists¶
Citizen content in spaces is never public on locali. What is publicly visible is exactly what verified organisations publish. Those entries are precisely the ones an operator needs a reporting route for — and the ability to act on one without switching off a whole organisation.
The route is addressed to you as the operator, not to the organisation that published the entry. That is the decisive difference from the existing "Report info" function, which reports incorrect master data and is handled by the organisation itself. A complaint about content must not land with the very people it is about.
Besides published entries, organisation profiles can be reported ("Report profile" on the profile page — it lands in this same queue, labelled with the organisation) and so can places (their own review path in place management; also works without an account).
Who can report¶
Anyone — including people without an account. This is the only place in locali where something can be written without signing in, and it is built that way deliberately: the person who needs the route most is often somebody who finds something about themselves on a hub they never signed up to. Requiring registration there would put a hurdle in front of an objection.
Abuse is bounded technically instead:
| Limit | Default |
|---|---|
| Reports per IP address per hour | 5 |
| Reports per IP address per day | 20 |
| Reports per signed-in account per day | 10 |
| Length of the free-text description | 1000 characters |
What you see in the queue¶
One row per reported subject (an entry or an organisation profile) — not per report. If ten people complain about the same entry, that is one decision, so it is one row with the number 10.
Each row shows the entry, the publishing organisation, every reason given, the text of the most recent report, and how long the first still-open complaint has been waiting.
The list is sorted by waiting time: whatever has waited longest is at the top. Anything past the response target (default 48 hours, adjustable between 24 and 336 hours in the Hub settings under "Operator policies") is flagged in red.
A reported entry that the organisation has since deleted itself stays in the queue, marked "no longer public". The people who reported it are still waiting for an answer — the entry disappearing does not settle the complaint.
How you decide¶
There are exactly three outcomes, and each one requires a reason of at least ten characters:
| Decision | Meaning |
|---|---|
| No action | You reviewed it and the entry stays. |
| Remove entry | The entry is taken off every public surface. |
| Pass on | You hand the matter on outside the platform, e.g. to an authority. The entry itself is untouched. |
The reason is mandatory because it does two jobs at once: it is sent verbatim to everyone who reported the entry, and it is your record if the same matter comes up again months later. A removal whose reason nobody wrote down is worthless as evidence.
One decision closes all open reports on that subject at once, with the same reason.
Recurring dates: one date or the whole series¶
A recurring event is stored as one entry per date. When the complaint is about the series rather than a single date, the confirm dialog asks — and names the number: "Only this date" or "All 12 dates of this series". The single date is preselected; removing more than was asked for is the mistake here that cannot be taken back quietly.
The restore asks the same question, with the count of removed dates: "All 12 removed dates of this series". That matters more than it sounds — no list and no search leads to a removed entry, so a series that could only be brought back one date at a time would in practice not be brought back at all. Dates the organisation withdrew itself are left alone: that was their decision, not yours.
For a reported organisation profile there is deliberately no "Remove entry" — a profile cannot be "deleted" on its own. The proportionate lever is archiving the organisation in governance organisation management; the queue explains this on the row.
After a removal: further steps¶
Once you have chosen "Remove entry", locali asks once whether that is the end of it. The follow-up dialog names the publishing organisation and offers two further steps:
| Step | Effect |
|---|---|
| Disable direct publishing | The organisation can no longer publish new entries without review — and cannot switch that back on itself; only you can grant it again. Entries already published stay up. |
| Suspend organisation | The organisation disappears from the public directory and its sources are paused. Content and owners are kept; you can reactivate at any time. |
None of this happens by itself. The dialog sits on "Nothing further", and the button that carries a step out stays disabled until you deliberately pick one. Close it and this one entry simply stays removed.
The dialog only appears when there is an organisation behind the entry and you are allowed to operate organisation governance. Both steps remain available at any later time through organisation management in the governance hub — the dialog is a shortcut at the right moment, not a separate route.
What the reporter is told¶
- Signed in: an in-app notification with the outcome and the reason. It cannot be switched off — somebody who took the trouble to complain has earned an answer.
- Anonymous with an e-mail address: an e-mail with the same content.
- Anonymous without an address: nothing. The form says so beforehand.
Signed-in reporters can see their own reports at any time under My reports (/me/reports).
What is stored, and for how long¶
| Data | Retention |
|---|---|
| Reported entry, reason, free text, your decision | permanently (your record) |
| The reporter's e-mail address | until they have been answered, then deleted |
| IP address | never stored — only a salted hash of it, solely for the volume limit, deleted after 30 days |
The report itself survives; the trail to the person does not.
Legal review
The retention periods are defaults, not legal advice. Have them confirmed by your data protection adviser before going live.
What the route does not do¶
- No auto-hiding. An entry never disappears automatically, however many reports it gets. An automatic removal would be a removal without a decider — and a decider is the whole point here.
- No advance warning to the organisation. The publishing organisation learns of a report only once you have decided.
- No reports from spaces. Entries in spaces are not public; for those, moderation by that space's moderators still applies.
Related pages¶
- Record — every one of your decisions is written there
- Hub settings — where "Operator policies" also holds the response target
- Users — suspending and disabling accounts
- Sources — pausing and decommissioning whole sources