Skip to content

JNY-MBR-STR-001Prepare the association’s structure and local dues

Markdown

JNY-MBR-STR-001

Prepare the association’s structure and local dues

Markdown
  • DocumentDraft
  • Product intentProposed
  • ImplementationObserved

KindJourneyProduct areaMembershipModuleOrganizational Structure, Membership Configuration and TermsRevision1End-to-endOptional

Read atservices-membership 5994c270react-console baf6dae3

The Formal Contract

The narrative above explains; the sections below are authoritative — the rules, scenarios and tests this document binds.

Goal
Establish the national and local units with the information needed to operate chapters.

Steps

#SurfaceActionCapabilityExpectedProvenance
1createOrganizationalUnitTypeSave the association’s unit categories and allowed parent choices.CAP-MBR-STR-001The categories retain the submitted placement choices.test
services-membership:tests/e2e/structure-api.e2e.spec.ts#the structure API, end to end in process › creates unit types with their allowed parents
2createOrganizationalUnitBuild the national, regional, zone and chapter records beneath their selected parents.CAP-MBR-STR-002The returned units have valid placements and computed depths.test
services-membership:tests/e2e/structure-api.e2e.spec.ts#the structure API, end to end in process › creates units in the tree
3replaceOrganizationalUnitSave Atlanta’s mailing, contact, geographic, visibility and custom information.CAP-MBR-STR-006A single-unit read returns Atlanta’s saved details.test
services-membership:tests/acceptance/structure/MBR-ACC-0006.acceptance.ts#MBR-ACC-0006 a complete chapter, recorded and read back
4linkOrganizationalUnitOrganizationAssociate Atlanta Chapter Inc. as the chapter’s legal organization.CAP-MBR-STR-007The legal relationship begins on its specified date.test
services-membership:tests/e2e/structure-api.e2e.spec.ts#the structure API, end to end in process › links an organization as the unit’s legal entity
5setOrganizationalUnitFinancialSettingsSave Atlanta’s local Commerce ordering-profile choice.CAP-MBR-STR-008The initial finance record returns its first version.test
6createOrganizationalUnitDuesProductCreate Atlanta’s catch-all dues extension from its existing Accounting product.CAP-MBR-STR-008The extension returns the product’s shared name and status.test
services-membership:tests/e2e/packages-as-products.e2e.spec.ts#packages as products, through the API › extends a product of type chapter_dues as a unit’s dues product, under the product’s id, with the product’s name

Alternate and Failure Paths

PathFrom stepConditionPath takenOutcomeProvenance
alternate2The selected regional parent is not allowed for chapters.The placement attempt fails.Staff select a permitted zone parent before retrying.test
services-membership:tests/e2e/structure-api.e2e.spec.ts#the structure API, end to end in process › refuses a parent of a type not allowed, 409 parent_type_not_allowed
failure4Atlanta already has an overlapping open legal relationship.The new relationship is rejected.The existing legal organization remains the sole open legal relationship.test
services-membership:tests/e2e/structure-api.e2e.spec.ts#the structure API, end to end in process › refuses a second open legal entity, 409 legal_entity_already_open

Assertions

IdStatementProvenance
01Created example units occupy eligible root or parent placements.test
services-membership:tests/e2e/structure-api.e2e.spec.ts#the structure API, end to end in process › creates units in the tree
02The example chapter rejects a second open legal organization.test
services-membership:tests/e2e/structure-api.e2e.spec.ts#the structure API, end to end in process › refuses a second open legal entity, 409 legal_entity_already_open
03The example dues extension returns shared information from its Accounting product.test
services-membership:tests/e2e/packages-as-products.e2e.spec.ts#packages as products, through the API › extends a product of type chapter_dues as a unit’s dues product, under the product’s id, with the product’s name

End-to-end policy: optional: Existing evidence exercises service operations without an administration screen. The product should require browser coverage when that screen supports this workflow.

The Markdown files under specs/ in rhythmsoftware/rhythm-v2-docs are the canonical source of truth. This reader is a generated, read-only projection of them.