Privacy and authorization

One rule (Support\EventVisibility) feeds both Event::scopeVisibleTo($viewer) — and with it Events::visibleTo() and Events::browse() — and EventPolicy::view, so a list and a detail page never disagree:

Unlisted events are link-only: found by uuid, never by slug for strangers, never listed.

What each surface hides

The policy

Policies\EventPolicy and Policies\VenuePolicy are registered unless events.authorization.register_policy is off. Events::for($event)->by($user) checks the policy before every call — the writes and the reads that reveal people; without by() the call is trusted code:

An undefined ability denies — with events.admin undefined, nobody is an admin. Swap the policy with events.authorization.policy, extending the package’s class. With registration off and no policy of yours, by() still never silently allows: the configured class is asked directly.

Venues

Anyone views a venue, and any organizer may hold an event at any venue. Creating needs an authenticated user, plus abilities.venues when set. An owned venue is managed by its owner’s approved users and admins and created only by someone the owner allows, so nobody plants a venue into another team’s list. A shared venue sits under other organizers’ events, so only admins and holders of abilities.shared_venues create, edit, geocode or delete one.

Visitor IPs

Geolocation::locateRequest($request), the usual near-me starting point, sends the visitor’s IP address to geolocation-for-laravel’s IP providers. Mention it in your privacy notice, or ask for the location instead.