Invitations grant access to a site. They grant nothing else, and the gap shows up the moment a team actually uses the product.
app/Jobs/SendAnalyticsDigest.ts:84:
FROM sites s JOIN users u ON u.id = s.owner_idThe weekly and monthly digest goes to the site owner and nobody else. A viewer or admin invited onto a site receives no digest, ever. Site alerts are configured with their own recipient list (app/Analytics/alerts.ts), so a member is not on those either unless someone types their address in by hand.
That was a coherent design when a site had exactly one person on it. It is now the common case that it does not.
Why this undercuts the feature we just shipped
The digest is the thing that brings people back. An agency invites a client as a viewer precisely so the client stops asking for screenshots — and the client then hears nothing, and asks for screenshots. The invitation delivered access without delivering the habit.
It also means the value of a seat is invisible to the person occupying it, which is exactly backwards for a plan that sells seats.
Suggested
- Send the digest to everyone who can reach the site, not just the owner.
listSiteMembers()inapp/Analytics/access.tsalready returns exactly that list, owner first, and is the same function the members API and the dashboard panel use. - Let each member opt out for themselves. A per-membership preference is the honest unit — one person on five sites should not have to choose all or nothing, and one site's owner should not be able to unsubscribe someone else.
- Decide deliberately whether alerts follow. There is an argument they should not: an alert is operational and its recipient list is chosen for a reason. A digest is informational and defaults to everyone. Worth stating either way rather than leaving it as an accident of which query got written first.
Note
site_members has no columns for preferences today — (site_id, user_id, role, created_at). An opt-out needs either a column here or a small preferences table.