Member Associations
Feature Detail
Description
Member Associations manages the relationship between individual users and the organizational units they belong to. It handles users who are active members of multiple local associations simultaneously - an NHF-documented scenario where a single peer mentor may belong to up to five local chapters. Admin tooling covers viewing, assigning, transferring, and auditing organizational memberships, ensuring correct data scoping and access boundary enforcement across the hierarchy.
Sources & reasoning
Multi-membership is explicitly documented as an NHF-specific challenge requiring platform support, with up to 5 local chapters per member and a direct link to double-reporting risk. Member Associations is the admin surface that resolves ambiguous membership before it causes downstream data integrity failures. Blueprint confirms MVP classification.
No source references — this artifact was included based on reasoning alone (see above).
Analysis
Multi-membership is a documented operational reality for NHF's volunteer base. Without explicit membership management, the platform cannot correctly scope activity reports, run duplicate-detection checks, or enforce access boundaries between chapters. A peer mentor in five chapters who logs an activity must have it attributed to the correct chapter - and coordinators from each chapter must only see their relevant scope. Incorrect membership data directly corrupts Bufdir reports and creates privacy risks by exposing one chapter's data to coordinators of another. Resolving ambiguous membership at the admin level prevents cascading data integrity failures in every downstream system.
Member associations are stored in user_organization_roles with a composite key on (user_id, organization_id, role). The admin UI provides a user-centric view showing all org memberships for a given user, and an org-centric view showing all members of a given hierarchy node. Bulk reassignment supports organizational restructuring. Membership changes are emitted to the audit log. When a user has multiple active memberships, the mobile app presents a context-switcher so the user selects the active chapter for a session - this depends on the profile-switching feature on mobile. Removing a user from all nodes effectively deactivates platform access without a hard delete.
Components (45)
Shared Components
These components are reused across multiple features
Service Layer (11)
Data Layer (23)
Infrastructure (7)
User Stories
No user stories have been generated for this feature yet.