A retired product can return only to the exact row that delivered it, so each new way of writing grant rows needs its own exception #155

New Issue

2026-09-28T21:03:06Z

cgalo5758 commented

2026-09-28 21:03:06 +00:00

How product retirement is enforced needs a proper look. Each new mechanism that writes grant rows has had to bend the rule.

What exists

A product's lifecycle_status is draft, published or retired. core.confer refuses to confer a retired product unless it counts as continuity rather than a new sale, and it answers that question in two different ways:

Default grants: any default grant that ever delivered the product in this pool counts. The default floor issues a new grant row each time it restores the default, so a test tied to one row would refuse every restoration.
Every other source (subscription, purchase, grant): only a provision from the same source row counts.

Where it bends

An operator can extend a grant that is on hold. The extension writes a successor grant row that has never delivered anything. If the product is retired after that, the successor cannot resume it, although it continues the same decree. To handle that, the test follows the extension chain, which is a third way of answering the same question.

Default grants, extended grants and resumed grants all hit the same problem: the rule is keyed to the row that delivered the product, while continuity belongs to something larger. That something might be the decree across its extensions, the organization's holding of the product, or the pool.

Questions to examine

What retirement is for: stopping new sales, stopping new grants, or also moving existing holders on, and on what schedule.
What the unit of continuity is, and whether one test could replace the per-source ones.
How retirement meets the default floor, the default being a retired product, and #154's idea of a default that resumes.
How it meets taking other things out of service: ladders (#62), entitlement sets (#41), and the product flags (#145).
Operators cannot retire a product from the console yet (#97), so the behaviour is reached only through the database or seeds today.

This is for later. Nothing here blocks extending or resuming grants.

How product retirement is enforced needs a proper look. Each new mechanism that writes grant rows has had to bend the rule. ## What exists A product's `lifecycle_status` is `draft`, `published` or `retired`. `core.confer` refuses to confer a retired product unless it counts as continuity rather than a new sale, and it answers that question in two different ways: - **Default grants:** any default grant that ever delivered the product in this pool counts. The default floor issues a new grant row each time it restores the default, so a test tied to one row would refuse every restoration. - **Every other source** (subscription, purchase, grant): only a provision from the same source row counts. ## Where it bends An operator can extend a grant that is on hold. The extension writes a successor grant row that has never delivered anything. If the product is retired after that, the successor cannot resume it, although it continues the same decree. To handle that, the test follows the extension chain, which is a third way of answering the same question. Default grants, extended grants and resumed grants all hit the same problem: the rule is keyed to the row that delivered the product, while continuity belongs to something larger. That something might be the decree across its extensions, the organization's holding of the product, or the pool. ## Questions to examine - What retirement is for: stopping new sales, stopping new grants, or also moving existing holders on, and on what schedule. - What the unit of continuity is, and whether one test could replace the per-source ones. - How retirement meets the default floor, the default being a retired product, and #154's idea of a default that resumes. - How it meets taking other things out of service: ladders (#62), entitlement sets (#41), and the product flags (#145). - Operators cannot retire a product from the console yet (#97), so the behaviour is reached only through the database or seeds today. This is for later. Nothing here blocks extending or resuming grants.

cgalo5758 added the

kind

design

area/entitlements area/catalog labels 2026-09-28 21:03:06 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: wiki-cafe/member-console#155