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

cgalo5758 referenced this issue

2026-10-26 20:58:23 +00:00

After a product's entitlement set is cleared, extending a grant of it fails with "Failed to save the grant" and no reason #273

cgalo5758 referenced this issue

2026-10-27 00:03:20 +00:00

An org type's default ladder can start on a product that confers nothing, and then restoring the default fails #153

cgalo5758 commented

2026-10-27 00:03:20 +00:00

A note from fixing #153. Restoring an organization type's default confers the bottom tier of its default ladder, and that conferral refuses a draft product always, and a retired product for any organization that has never held it through its default. So a default ladder whose bottom tier is draft breaks the same paths #153 lists for a product with no entitlement set (a new person's first sign-in, a revoke, a grant's expiry, a subscription's end, and the moves after a default change), and one whose bottom tier is retired breaks them for every organization that never held that product as its default, every new sign-up included. Nothing in the console changes a product's lifecycle today (#97), so only the database or a seed reaches this. Whatever adds a retire action should refuse retiring the bottom tier of a ladder an organization type uses as its default, unless this issue first settles how retirement meets the default.

cgalo5758 referenced this issue from a commit

2026-10-27 00:03:58 +00:00

Tick #153's landing items

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