Location API

Summary

Implement the ConnectRPC service for location CRUD. Locations are reusable physical places (ranges, facilities, personal addresses) referenced by events and personal range days. Supports org-scoped, user-scoped, and public visibility.

Requirements

• Location CRUD (create, read, update, delete) with ownership enforcement
• Visibility model: private org-scoped, private user-scoped, public (well-known ranges)
• List locations filtered by org, user, visibility, and proximity (lat/lng)
• Authorization checks: org members manage org locations, users manage personal locations, anyone reads public
• Search/autocomplete for public locations to reduce duplicates
• Ownership validation via check constraint (see db-schema)

Implemented (v1)

5 RPCs matching proto contract (CreateLocation, UpdateLocation, GetLocation, ListLocations, DeleteLocation). 19 integration tests.

MVP Design Decisions

• Visibility-gated listing: ListLocations enforces caller-readable visibility as a baseline gate (own user locations, org member locations, public when flagged). Filters (org_id, user_id) narrow within that visible set — they cannot widen it.
• Public locations are immutable: UpdateLocation and DeleteLocation reject public locations with FailedPrecondition. No creator tracking for public locations in v1.
• Name normalization: names are trimmed before length validation; whitespace-only names are rejected.
• Deletion guard: DeleteLocation checks events.location_id foreign key references before allowing deletion.
• Input structs: CreateLocationInput / UpdateLocationInput used to satisfy clippy’s too-many-arguments lint.

Deferred to future passes

• Proximity/geo search: proto supports lat/lng fields but filtering by proximity is deferred.
• Search/autocomplete: deduplication of public locations via search is deferred.
• Public location editing: may need creator tracking or admin-only edits in the future.
• Notification side effects: deferred pending push notification infrastructure.