Activity Type Repository
Component Detail
Description
Data access layer that wraps all Supabase queries for the activity_types table. Enforces row-level security by always including org_id in queries. Handles serialisation of the JSON metadata column and surfaces typed errors for constraint violations.
activity-type-repository
Summaries
The Activity Type Repository is the authoritative gateway through which the platform reads and modifies activity configurations for every organization using the system. By enforcing that every database query is automatically scoped to the correct organization, this component eliminates an entire category of data-leakage risk — one organization's activity types can never be exposed to another. This directly protects the business from compliance violations and the reputational damage of a data breach. Additionally, by translating raw database errors into meaningful business-level error messages, the component accelerates issue resolution and reduces support overhead when configuration problems arise.
The Activity Type Repository is a medium-complexity data component with a single critical external dependency on the Supabase client. This dependency must be provisioned and configured before development begins, and any Supabase schema changes to the activity_types table will require coordinated updates here — flag this as an integration risk in the project schedule. Because this component runs on both backend and mobile execution contexts, testing must cover both environments, including offline and low-connectivity scenarios on mobile. Row-level security enforcement via org_id scoping must be validated with multi-tenant test fixtures, which should be prepared as part of the QA setup.
Soft-delete behavior also requires explicit test coverage to avoid accidental data loss in production.
The Activity Type Repository implements the data access layer (repository pattern) for the activity_types Supabase table, running in both backend and mobile contexts. All queries are mandatorily scoped with org_id to enforce row-level security at the application layer in addition to any Supabase RLS policies. The JSON metadata column is serialized on write and deserialized on read, with the raw JSON output typically passed to the Activity Type Metadata Resolver for typed access — these two components form a natural pair and should be used together. The interface covers full CRUD plus soft deletion and display-order batch updates (updateDisplayOrder accepts an ordered array of IDs for drag-and-drop reordering use cases).
Database constraint violations (unique names per org, foreign key errors) are surfaced as typed domain errors rather than raw Supabase exceptions, keeping error handling clean in calling services.
Responsibilities
- Execute Supabase CRUD queries against the activity_types table with mandatory org_id scoping
- Serialise and deserialise the JSON metadata column
- Surface database constraint violations as typed domain errors
Interfaces
fetchByOrgId(orgId)
fetchById(id)
insert(orgId, data)
update(id, data)
softDelete(id)
updateDisplayOrder(orgId, orderedIds)
Relationships
Dependents (2)
Components that depend on this component
Related Data Entities (1)
Data entities managed by this component
Used Integrations (1)
External integrations and APIs this component relies on