Bundle grants and package-specific unit requirements

Purpose

Administrators describe the additional memberships and affiliation requirements accompanying an offering.

How It Works

An administrator configures the additional memberships associated with a package. A grant identifies another program and one of its classifications. Its dates can match the primary term or use a separate term rule. Staff also specify package-level affiliation counts and whether local dues accompany the offering. These choices specialize the program’s defaults for this package. The service validates submitted categories, counts and grant date rules. Each submitted list replaces its previous rows. Omitting a list retains it. Newly saved grants receive new identities, so consumers cannot treat a grant row as a permanent reference across replacements. Several target-program compatibility checks are absent. The product should define those checks and the handling of retained grants when a package’s program changes.

Relationships

The package owns the grant and unit-rule lists.
Program affiliation settings continue to supply primary and portal choices.
The term engine validates independently dated grants.

Show evidence (sources, provenance, origins, pinned commits)

The Formal Contract

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

Outcomes: One offering can describe grants in other membership programs.Package requirements can specialize program-level affiliation counts.
Surfaces: apijob

Controls

32 controls apply, from the corpus control catalogue.

TC-AVL-002 TC-AVL-003 TC-AZ-001 TC-AZ-002 TC-AZ-003 TC-AZ-004 TC-AZ-005 TC-AZ-006 TC-CHG-001 TC-CHG-002 TC-CHG-003 TC-CHG-004 TC-CRY-001 TC-CRY-002 TC-CRY-003 TC-DAT-001 TC-DAT-007 TC-IAM-001 TC-IAM-002 TC-IAM-004 TC-IAM-005 TC-LOG-001 TC-LOG-002 TC-LOG-003 TC-LOG-004 TC-PI-001 TC-PI-003 TC-SEC-001 TC-SEC-004 TC-TEN-001 TC-TEN-002 TC-TEN-003

Permissions

Key	Checked at	Scope
`membership.configuration.manage`	api	tenant
`membership.application.access`	api	tenant

Business Rules

8 rules, 7 to be proved before approval. A rule's product intent is derived from its origin: 0 confirmed by a product decision, the rest inheriting this capability's proposed.

Id	Rule	Kind	Enforced at	Provenance
`01`must prove Proposed	A package accepts at most ten submitted grants, and rejects a submitted grant naming its own program. no proof recorded yet	validation	api, service	observed services-membership:modules/configuration/services/configuration/configuration-records.ts:packageResource
`02`must prove Proposed	Each grant must pair a membership type with its own program. no proof recorded yet	validation	database	test services-membership:tests/e2e/database-refusals.e2e.spec.ts#mistakes only the database catches, through the API › DEF-MBR-0086: a configuration write a check, a foreign key or an integer column refuses › refuses a grant whose type is not of the granted program 400 naming grants: membership_type_id, and writes no package
`03`must prove Proposed	A grant uses the primary term’s dates or a separately validated rule that the term engine can compute. no proof recorded yet	validation	service, database	observed services-membership:modules/configuration/services/configuration/configuration-records.ts:packageResource
`04`must prove Proposed	Submitted grants replace the whole grant list and receive newly allocated identities on each replacement. no proof recorded yet	policy	service	observed services-membership:modules/configuration/services/persistence/membership-packages.ts:replacePackageChildren
`05`must prove Proposed	A package accepts at most twenty unit rules, each naming one existing affiliation-enabled kind with a maximum no lower than its minimum. no proof recorded yet	validation	service	observed services-membership:modules/configuration/services/configuration/configuration-records.ts:unitRuleProblems
`06`must prove Proposed	Package counts and dues choices override the corresponding program counts, while program primary, portal and suggestion choices remain; package-only kinds are allowed. no proof recorded yet	calculation	service	observed services-membership:modules/memberships/services/affiliations/unit-rules.ts
`07`must prove Proposed	Fixed ends, grants and unit requirements change only when their lists are submitted, with an empty list removing their rows. no proof recorded yet	policy	service	observed services-membership:modules/configuration/services/configuration/configuration-records.ts:packageResource
`08` Proposed	Grant configuration does not verify the target program’s activity, admitted owner kind or compatibility with the owner’s other holdings.	policy	service	documented react-console:acceptance/membership/inventory/business-rules.json#RUL-MBR-CFG-019

Scenarios

Id	Given	When	Then	Provenance
`01`	A student offering includes membership in the Section program.	The student completes the purchase.	The resulting holdings include both the primary program and Section.	test services-membership:tests/acceptance/configuration/MBR-ACC-0111.acceptance.ts#MBR-ACC-0111: The well-known FAA configuration every developer and integration run starts from reads back exactly as the seed describes it, its packages' products exist with the right audiences, and a second seed run changes nothing

Edge Cases

Id	Given	When	Then	Provenance
`02`	A package adds a category absent from its program requirements.	A term is established under that package.	The category is permitted using its package counts and default program-specific choices.	test services-membership:tests/acceptance/configuration/MBR-ACC-0104.acceptance.ts#MBR-ACC-0104: A package's unit rules override the program's counts: the Regular package demands a chapter the program leaves optional, a Section-only package names a type the program does not list, a region is refused, and clearing the rules hands control back to the program

Planning

Bundle grants and package-specific unit requirements ​

Purpose ​

How It Works ​

Relationships ​