# Commission records can only be written by staff of that venue

This is an internal security fix. No screen changes, no commission amount
changes, and nothing you need to do.

## What was wrong

Nine server functions behind commissions — calculating a commission, creating
one, the automatic commissions for pass, product, gift card, service and private
event sales, looking up the original seller of a pass, and the refund clawback
that reverses commissions — each took the venue id as an argument and acted on it
directly. They did not check that the caller was signed in, that the caller was
staff, that the caller held the commissions permission, or that the venue they
named was their own venue.

Functions of this kind are reachable by a direct request, not only through the
screens that use them. So the venue id in the argument is something the caller
chooses, and it was being trusted.

## What changed

Those nine now, before they read or write anything:

1. require a signed-in venue administrator or manager;
2. require the **Create and edit commission rules + templates** permission — the
   same permission your commission rules, templates, approvals, payroll marking
   and settings screens already require;
3. refuse outright when the venue in the argument is not the venue the signed-in
   staff member is working in;
4. refuse a platform operator who is not in an active support session for that
   venue.

The two functions that carry no venue in their arguments — the original-seller
lookup and the refund clawback — are now confined to the signed-in staff member's
own venue, so they can never read or reverse another venue's commissions, and the
refund clawback can never send another venue's webhooks.

Creating a commission by hand, running an automatic commission and requesting a
clawback now also write an entry to the venue's audit log, naming the staff
member. A refused cross-venue attempt is recorded too.

## What did not change

Every automatic commission still runs exactly as before and is unaffected by this
change: online checkout, subscription renewals, point-of-sale product and gift
card sales, completed appointments, private event payments, and the clawback that
runs when a payment is refunded. Those paths run on the server without a signed-in
person — a webhook from the payment provider has no session — so they continue to
call the same calculation code directly, with the same deduplication, the same
rounding, the same proportional-refund behaviour and the same webhooks.

Commission rules, templates, approvals, payroll marking, statements and settings
are untouched; they already required this permission.

## Compatibility

| Combination | Result |
|---|---|
| The release serving production today + this release | Safe. This release adds no database object and changes no table, so there is nothing for an older release to be incompatible with. |
| This release's code + the database as it is today | The intended state. There is no migration in this release. |
| Business app currently in the stores + this release | Unaffected. The app does not call these functions; it reaches commissions through the venue workspace screens, which are unchanged. |