Skip to main content

School Membership

Purpose​

A School Membership represents a User's relationship with a School.

School Membership is the primary authorization and access-control construct within Chilarai.

A User gains access to a School through a School Membership.

Roles, permissions, approvals, and administrative access are derived from School Memberships.

Business Context​

A User may belong to multiple Schools.

Examples:

  • Parent in multiple Schools
  • Teacher in multiple Schools
  • Parent in one School and Teacher in another
  • Principal and Teacher in the same School

A School Membership captures the relationship between a User and a School together with the roles and access rights associated with that relationship.

Relationships​

School Membership to User​

  • Each School Membership belongs to exactly one User.
  • A User may have multiple School Memberships.

School Membership to School​

  • Each School Membership belongs to exactly one School.
  • A School may contain multiple School Memberships.

School Membership to Roles​

  • A School Membership may contain one or more Roles.
  • Roles are assigned to Memberships, not directly to Users.

Key Design Decisions​

Membership-Based Authorization​

Authorization is driven by School Memberships.

A User's permissions are determined by:

  • School Membership
  • Assigned Roles
  • Membership Status

Permissions must never be derived directly from the User entity.

Multi-School Participation​

Users may belong to multiple Schools.

Examples:

  • Parent in School A
  • Parent in School B
  • Teacher in School C

Each relationship is represented by a separate School Membership.

Multiple Roles per Membership​

A School Membership may contain multiple Roles.

Examples:

  • Parent + Teacher
  • Teacher + Principal
  • Parent + School Admin
  • School Admin + Principal

The Membership model must support multiple role assignments.

Membership Approval​

Membership approval requirements depend on the onboarding source.

Parent Memberships​

Approval is required.

Flow:

  1. Parent registers
  2. Parent requests School access
  3. Membership created in PendingApproval state
  4. School Administrator reviews request
  5. Membership activated

Staff Memberships​

Staff memberships are created by School Administrators.

Examples:

  • Teacher
  • Accountant
  • Receptionist
  • Principal

Staff memberships are automatically activated.

School Administrator Memberships​

School Administrator memberships are automatically activated when assigned by an authorized administrator.

School Context​

A User may have multiple active School Memberships.

After authentication:

Single Membership​

The User enters the associated School directly.

Multiple Memberships​

The User selects the active School context.

The selected School Membership determines:

  • Available Roles
  • Accessible Features
  • Visible Data
  • Administrative Actions

Roles​

Examples of supported roles include:

  • School Admin
  • Teacher
  • Parent
  • Principal
  • Accountant
  • Receptionist

Additional roles may be added in the future without requiring redesign of the Membership model.

Attributes​

Identity​

  • MembershipId
  • UserId
  • SchoolId

Roles​

  • Roles

Notes:

  • Multiple roles are supported.
  • Roles are membership-scoped.

Status​

Possible values include:

  • PendingApproval
  • Active
  • Suspended
  • Archived

Approval​

  • ApprovedAt
  • ApprovedBy

Membership Information​

  • JoinedAt
  • Notes

Audit​

  • CreatedAt
  • CreatedBy
  • UpdatedAt
  • UpdatedBy

Status Lifecycle​

PendingApproval​

Membership exists but access has not yet been approved.

Typical examples:

  • Parent registration requests

Active​

Membership is approved and operational.

The User may access School resources according to assigned Roles.

Suspended​

Membership access is temporarily blocked.

Historical information remains available.

Archived​

Membership is no longer active but is retained for historical and audit purposes.

Constraints​

User Membership Uniqueness​

A User may have only one Membership per School.

Valid:

  • User A → School A → Membership A
  • User A → School B → Membership B

Invalid:

  • User A → School A → Membership A
  • User A → School A → Membership B

Role Assignment​

Roles must be assigned through School Memberships.

Roles must never be assigned directly to Users.

Access Control​

Users may access School resources only when the Membership status is Active.

Suspended, Archived, or PendingApproval memberships must not grant access.

Administrative Ownership​

Platform Administrators​

May:

  • Create Schools
  • Create initial School Administrators
  • Manage platform-wide access

School Administrators​

May:

  • Create Staff Memberships
  • Assign Roles
  • Approve Parent Memberships
  • Suspend Memberships
  • Reactivate Memberships

Administrative actions are always scoped to the School associated with the Membership.

Exclusions​

The following information does not belong to School Membership:

  • Authentication Credentials
  • Passwords
  • Student Academic Records
  • Attendance Data
  • Fee Information

These belong to other domain entities.

Future Considerations​

The following capabilities may be introduced later:

  • Role inheritance
  • Delegated administration
  • Temporary role assignments
  • Membership expiration rules
  • Fine-grained permission overrides

These capabilities should not require redesign of the Membership model.

Summary​

Core decisions:

  • School Membership is the primary authorization model.
  • Users may belong to multiple Schools.
  • Roles are assigned to Memberships, not Users.
  • Multiple roles per Membership are supported.
  • Parent memberships require approval.
  • Staff memberships are automatically activated.
  • Administrative access is membership-scoped.
  • A User may have only one Membership per School.
  • Authorization is determined by Membership, Roles, and Status.