# Clients can no longer change venue records or read other clients’ records

This is the second of two security releases. The first one, live since earlier
today, moved every staff screen that reached these records onto the server's own
authority with an explicit permission check. This one closes the door behind it.

## What we found

A signed-in client could, with technical know-how and without going through any
screen, change some of a venue's records directly — an invoice, a point-of-sale
sale, an email template, a member tag — and read other clients' invoices,
receipts, message history, member tags and scores, patch tests and health
clearances. Both are now closed at the database, on 72 tables for changes and 16
for lookups.

## What staff need to know

**Nothing changes on the screens you use.** Each change still needs the same
permission it needs in the app today — **Manage invoices** for invoices and
payments, **Access point of sale** for sales, **Edit email templates** for
templates and suppressions, **Edit member profiles** for member tags, **Manage
private events** for private events, **Manage migration** for imports. Owners and
managers hold these by default; the front desk keeps what it has today
(point-of-sale sales, member tags, booking add-ons, service availability,
contraindication clearances, buddy invites and private events).

Looking these records up now needs a permission too. This is the full list of the
sixteen kinds of record whose lookup changed, and the permission each one needs:

| To look up | You need |
|---|---|
| Client invoices, invoice payments and credit notes | **View client invoices** |
| Point-of-sale sales and their receipt lines | **Open point of sale** |
| Client scores | **View client insights** |
| Member tags | **View client profiles** |
| Message and notification history | **View admin reports** |
| Patch tests | **View all treatment records** |
| Health clearances | **View health information**, or **Book on a client's behalf**, which the front desk holds |
| Migration import rows | **Run data migration** |
| Website and lead events | **Manage integrations** |
| Email suppressions, SMS suppressions and the SMS consent log | **Edit email templates** |
| Undo tickets | see below — this one is not a permission |

Two of these are worth flagging before someone reports them as a fault.

- **Undo tickets** are now visible only to the staff member who performed the
  action that created them. No permission restores a venue-wide view of them.
  This is deliberate: an undo ticket holds a copy of the record it can restore,
  and only the person who made the change ever needs to see it. Everything the
  product itself does with undo tickets is unaffected.
- **Point-of-sale sales** are now read through **Open point of sale** rather than
  a separate reporting permission. A finance or auditor role that used to read
  receipts directly, without that permission, will no longer see them. Give them
  **Open point of sale** if they need it.

For every other row in the table above: if a staff member tells you a list looks
empty after this release, it is a permission they do not hold rather than a fault
— give them the permission named above and it returns.

## What clients see

Nothing changes for a client's own records. They keep their own invoices, credit
notes, point-of-sale receipts, scores, tags, notification history, patch tests
and health clearances, and they can still start a chat, be counted in analytics
and make a private-event enquiry exactly as before.

## What this release does not close yet

This release narrowed lookups on the sixteen kinds of record above. It did not
narrow them on the rest, because doing so would have emptied screens that are not
yet ready for it — so some venue settings remain readable by anyone signed in to
that venue, exactly as they are today. That includes the analytics integration
keys, the bank details on your invoice settings, the one-time links on buddy
invites and private-event participants, and internal notes on recurring invoice
schedules, card migration requests and private-event series.

**Nothing here got worse in this release** — every one of those lookups works the
same way it did yesterday. We are naming them so the remaining work is visible
rather than assumed done. Closing the two that matter most, the analytics keys
and the bank details, is queued as a separate change.

## Compatibility

| Combination | Result |
|---|---|
| The release serving production today + this database change | Safe. Security release A is already live, and it is what moved every affected staff screen onto the server's own authority. A full source audit of the current release finds no screen left reading or writing these tables through a signed-in session, apart from five own-row paths this release deliberately preserves. |
| This release's code + the database as it is today | Safe. This release ships no application code — only database policies — so there is nothing to deploy ahead of it. |
| Rollback | Each file lists the exact policies it dropped and where to recreate them from, and no table, column or grant other than client TRUNCATE is touched. |