Edit Organizational Hierarchy Nodes and Structure
Organizational structures are not static — local chapters form, disband, or reorganize regularly. The org admin must be able to edit hierarchy nodes through a dedicated editor interface. Changes must propagate correctly through the hierarchy (e.g., deactivating a region must flag all child chapters as needing reassignment). All edits must be validated to prevent orphaned units or circular dependencies, and a hierarchy validator must run before committing changes to the database.
User Story
Acceptance Criteria
- Given I am viewing a hierarchy node, when I tap the edit action, then I can rename the unit, change its parent unit, or deactivate it
- Given I attempt to deactivate a node that has active child units, when I confirm the action, then I receive a warning listing all child units that will be affected before proceeding
- Given I add a new local chapter, when I save it, then it appears as a child of the selected parent region and is immediately visible in the hierarchy tree
- Given I move a unit to a new parent, when the change is saved, then all associated peer mentors, coordinators, and activity records retain their association with the moved unit
- Given I make a structural edit, when the hierarchy validator detects an inconsistency (e.g., circular reference, orphaned unit), then the save is blocked and a specific error message is shown
Business Value
Accurate organizational structure is the foundation of all reporting and access control. Stale or incorrect hierarchy data causes incorrect Bufdir aggregations, misdirected coordinator access, and reporting gaps. Enabling admins to maintain the structure in real time eliminates the need for manual database corrections and keeps all downstream reporting reliable.
Components
- Hierarchy Node Editor Screen ui
- Hierarchy Admin Portal Screen ui
- Hierarchy Service service
- Hierarchy Structure Validator infrastructure
- Organization Unit Repository data
- Hierarchy Cache data
- RLS Policy Manager infrastructure