Search Contact Notes and Activity Summaries
Contact records accumulate notes and post-session report summaries over time. When a coordinator needs to find, for example, all contacts for whom a peer mentor wrote about a specific challenge or course interest, text search across notes surfaces that information instantly. The search service queries notes and report summaries stored in Supabase, filtered by the coordinator's RLS scope, and returns results grouped by contact with relevant excerpts highlighted. This feature directly supports the formalized report structure required by Blindeforbundet (health status, course interest, way-forward items) and the general notes functionality requested by all organizations.
User Story
Audience Summaries
Full-text search across contact notes and post-session report summaries transforms a passive record-keeping system into a proactive coordination intelligence tool. For Blindeforbundet, whose formalized visit reports capture structured health status, course interest, and way-forward items, this capability allows coordinators to surface patterns across hundreds of contacts in seconds rather than hours. The business impact is threefold: reduced administrative overhead during Bufdir audit preparation, improved care quality through faster identification of at-risk contacts or unmet course interests, and a measurable competitive differentiator that positions the platform as essential infrastructure for Norwegian disability organizations. This story directly supports client retention by solving a pain point that currently requires manual review of individual records—a process that does not scale as membership grows.
Organizations that adopt this platform gain audit-readiness and the ability to demonstrate outcome patterns to funders, strengthening grant renewals and stakeholder confidence.
This high-priority story carries moderate-to-high implementation complexity due to its dependency on the foundational contact search story (story-contact-and-notes-search-coordinator-001), which must be fully delivered and stable before this work begins. Delivery planning must account for two parallel workstreams: backend full-text search query construction against Supabase with RLS scope filtering, and frontend result rendering with excerpt highlighting and visual distinction between name-matched and note-matched results. Acceptance criteria include five discrete testable conditions, each requiring dedicated QA scenarios covering RLS boundary enforcement, excerpt display accuracy, deduplication of contacts appearing in both match types, and deep-link navigation to the specific note or report section. Stakeholder sign-off from Blindeforbundet is recommended before UAT, as the formalized report structure (health status, course interest, way-forward) must be correctly represented in search results.
Rollout risk is low if the dependency story is stable, but regression testing on RLS scope enforcement is mandatory given data privacy obligations.
Implementation requires extending the existing search repository layer to construct full-text queries against both the notes table and post-session report summaries stored in Supabase. The query must apply the coordinator's RLS policy at the database level—not as a client-side filter—to prevent unauthorized data exposure. Results must be grouped by contact ID server-side, with each result carrying metadata indicating match source (name, note, or report field) and a character-offset excerpt for frontend highlighting. The frontend must render visually distinct match-type indicators and handle the deduplication case where a contact matches on both name and note content, displaying a single card with both match types flagged.
Deep navigation on tap must resolve the specific note or report section ID and pass it as a scroll target or highlight anchor to the contact detail screen. Edge cases include contacts with large note volumes (excerpt truncation strategy), RLS returning zero results (empty state UX), and overlapping excerpt boundaries. Full integration tests against a seeded Supabase instance with multiple RLS scopes are required before merge.
Acceptance Criteria
- Given the coordinator enters a search query, when results include contacts with matching note content, then note-matched results are visually distinguished from name-matched results
- Given a note result is returned, when displayed in the results list, then a short excerpt of the matching note text is shown beneath the contact name
- Given the coordinator's RLS scope covers only their chapter's contacts, when search results are returned, then only contacts within their permitted scope appear
- Given the coordinator taps a note-matched result, when navigating, then the contact detail screen opens and scrolls to or highlights the relevant note or report section
- Given a search returns both name matches and note matches for the same contact, when displayed, then the contact appears once with both match types indicated
Business Value
The ability to search note content transforms passive record-keeping into an active coordination tool. For Blindeforbundet, formalized post-visit reports contain structured data (course interest, health situation, way-forward) that coordinators must act on. Full-text search across this data enables coordinators to identify patterns, prioritize follow-ups, and respond to Bufdir audit requests without manually reviewing hundreds of records — reducing administrative overhead and improving care quality.
Components
- Contact Search Screen ui
- Accessible Search Input Field ui
- Search Results List ui
- Contact Search Service service
- Supabase Contact Search Repository data
- Contact RLS Query Builder infrastructure
- Search Debounce Utility infrastructure
- Contact Detail Screen ui
- Contact Detail Service service