Skip to main content

Collections and schemas

All Atlas data is stored in MongoDB via Mongoose schemas and is model-bound per request through getModels(req, ...).

Core collections (Atlas)

FinanceConfig holds one document per tenant with budgetTemplates[] and workflowPresets[]. OrgBudget stores per-org budget drafts, line items, linear multi-stage workflow state, revisions, and comments.

User linkage

The user schema has:
This is used in the frontend to gate access to /club-dashboard/:id.

Org (organization) schema

File: Meridian/backend/schemas/org.js

Identity

Membership config

If requireApprovalForJoin is true, join requests create OrgMemberApplication instead of immediate membership.

Roles (positions[])

Roles are stored on the org document in positions[]:
Invariant: Role names are referenced by OrgMember.role. If you rename role names, you must migrate members.

Operational lifecycle & governance (CMS Phase 1)

Distinct from verificationStatus and new-org approvalStatus:
  • lifecycleStatus — string (defaults to active; allowed values and transitions come from OrgManagementConfig.atlasPolicy.lifecycle).
  • orgTypeKey — ties the org to an entry in atlasPolicy.orgTypes for required governance document keys.
  • lifecycleChangedAt / lifecycleChangedBy — audit fields when status changes.
  • adminNotes — staff notes (replaces non-persisted status/notes on older admin update handlers).
  • governanceDocuments[] — per-key versioned PDF metadata (draft | approved | superseded), with S3 URLs under orgs/governance/.
Defaults and merge logic for atlasPolicy live in Meridian/backend/services/atlasPolicyService.js (including directory hiding for non-active orgs on GET /get-orgs when enabled, and blocking new org-hosted events from template creation when configured).

Verification fields

Atlas “verification” is stored directly on the org:
verificationType is validated via config in OrgManagementConfig for requests; on Org it is an enum.

Messaging settings (messageSettings)

Per-org constraints:

Org-level helper methods

Org defines helpers used by permission checks and role management:

OrgMember schema

File: Meridian/backend/schemas/orgMember.js

Fields

Hard-deletes of OrgMember append a row to OrgMembershipAudit (orgMembershipAudits) for accountability.

Indexes

Permission evaluation

1

Check denied permissions

If deniedPermissions.includes(permission)deny
2

Check custom permissions

Else if customPermissions.includes(permission)allow
3

Check org role

Else → org.hasPermission(this.role, permission)

OrgMemberApplication schema

File: Meridian/backend/schemas/orgMemberApplication.js Represents a join application when Org.requireApprovalForJoin === true.

Fields

OrgManagementConfig (global system config)

File: Meridian/backend/schemas/orgManagementConfig.js
This is a singleton document (read via findOne()).

Key sections

OrgVerification (verification request)

File: Meridian/backend/schemas/orgVerification.js

Fields

OrgMessage (announcements/messages)

File: Meridian/backend/schemas/orgMessage.js

Fields

Indexes are tuned for timeline queries (orgId + createdAt).

OrgFollower (followers)

File: Meridian/backend/schemas/orgFollower.js

Fields

Important: This schema currently defines org_id: ref 'Club', but the model is named OrgFollower and used as “org followers” throughout routes. Treat this as a likely ref mismatch (it should probably be ref: 'Org'). If you rely on population behavior here, verify the reference is correct.