The product flags mix up who can see a product, who can buy it and who can be given it #145

New Issue

2026-09-27T15:15:41Z

cgalo5758 commented

2026-09-27 15:15:41 +00:00

The question

What states can an operator put a product in, and a product in its place on a plan ladder, and which surface reads which state? Today the answers are spread over separate flags that each got a second job as the catalog grew, and every new surface reads them a little differently.

What goes wrong now

One flag, two meanings. "Listed" (is_public, "Shown in the member catalog") is also the only way to make a grant-only product: an unlisted product is how a set is given without being sold. So an operator cannot say "members see this, but it is not for sale", or "given only, but shown to the members who hold it".
Four inputs, one verdict. A product's state comes from its lifecycle (draft, published, archived), Active, Listed, and a readiness check (price, provider mapping, capability set). The products list folds them into purchasable, ready to grant, incomplete or inactive; the readiness section measures a product never meant for sale against selling (#102); the category changes nothing (#95); a product cannot be retired (#97).
A ladder's lowest tier is an organization type's starting plan and its fallback, and nothing ties the two. When the default ladder's lowest tier is unlisted, members never see the plan they start on or the plan a cancellation returns them to. Once "Cancel plan" sits on the current plan's card (a separate change), hiding the tier no longer removes cancellation.
The operator pages do not show what members see. The plan overview marks draft and archived tiers but not unlisted or inactive ones, so a ladder reads the same to the operator whether members can see its tiers or not. The page states that rank 0 is "the base tier new organizations start on", which holds only for a ladder that is some organization type's default.
The plan pages accrete. Overview grid, off-ladder products, shared products, what new organizations get and the ladder list sit on one page in no considered order (#89), a second page covers the same ground (#90), the two disagree on tier order (#103), and the grid's orientation is open (#135).

What depends on the answer

The product columns and their meaning; the member catalog's filter (ListPublicPlanProducts: active, listed, published); the readiness verdict and the list's status column; the grant form and the private-product presentation (#123); the operator plan pages; what a cancellation lands on and how the member learns it.

Options known so far

Separate the states by what they govern: in service (lifecycle), sold (a sellable price), given (grantable), shown to members. Each gets its own name and its own readiness verdict (#102's second option).
Replace the flags with one availability value (for sale, given only, hidden, retired), accepting that some combinations need a value of their own.
Make "shown on this ladder" a property of the tier's place on the ladder rather than of the product, so a ladder's floor can be shown to its members while the product stays out of the standalone catalog.

Stop-gap

Until this is decided: the operator plan pages mark tiers members cannot see (unlisted or inactive), and the organization type's default-plan preview warns when the candidate ladder's lowest tier is one of them. Both come out when the model is settled.

Decided when

The model names every state a product and a ladder tier can be in; the member catalog, the operator plan pages, the readiness section and the grant form all read that one model; and the stop-gap is removed.

## The question What states can an operator put a product in, and a product in its place on a plan ladder, and which surface reads which state? Today the answers are spread over separate flags that each got a second job as the catalog grew, and every new surface reads them a little differently. ## What goes wrong now - **One flag, two meanings.** "Listed" (`is_public`, "Shown in the member catalog") is also the only way to make a grant-only product: an unlisted product is how a set is given without being sold. So an operator cannot say "members see this, but it is not for sale", or "given only, but shown to the members who hold it". - **Four inputs, one verdict.** A product's state comes from its lifecycle (draft, published, archived), Active, Listed, and a readiness check (price, provider mapping, capability set). The products list folds them into purchasable, ready to grant, incomplete or inactive; the readiness section measures a product never meant for sale against selling (#102); the category changes nothing (#95); a product cannot be retired (#97). - **A ladder's lowest tier is an organization type's starting plan and its fallback, and nothing ties the two.** When the default ladder's lowest tier is unlisted, members never see the plan they start on or the plan a cancellation returns them to. Once "Cancel plan" sits on the current plan's card (a separate change), hiding the tier no longer removes cancellation. - **The operator pages do not show what members see.** The plan overview marks draft and archived tiers but not unlisted or inactive ones, so a ladder reads the same to the operator whether members can see its tiers or not. The page states that rank 0 is "the base tier new organizations start on", which holds only for a ladder that is some organization type's default. - **The plan pages accrete.** Overview grid, off-ladder products, shared products, what new organizations get and the ladder list sit on one page in no considered order (#89), a second page covers the same ground (#90), the two disagree on tier order (#103), and the grid's orientation is open (#135). ## What depends on the answer The product columns and their meaning; the member catalog's filter (`ListPublicPlanProducts`: active, listed, published); the readiness verdict and the list's status column; the grant form and the private-product presentation (#123); the operator plan pages; what a cancellation lands on and how the member learns it. ## Options known so far - Separate the states by what they govern: in service (lifecycle), sold (a sellable price), given (grantable), shown to members. Each gets its own name and its own readiness verdict (#102's second option). - Replace the flags with one availability value (for sale, given only, hidden, retired), accepting that some combinations need a value of their own. - Make "shown on this ladder" a property of the tier's place on the ladder rather than of the product, so a ladder's floor can be shown to its members while the product stays out of the standalone catalog. ## Stop-gap Until this is decided: the operator plan pages mark tiers members cannot see (unlisted or inactive), and the organization type's default-plan preview warns when the candidate ladder's lowest tier is one of them. Both come out when the model is settled. ## Decided when The model names every state a product and a ladder tier can be in; the member catalog, the operator plan pages, the readiness section and the grant form all read that one model; and the stop-gap is removed.

cgalo5758 added the

kind

design

area/catalog area/operator-ui area/member-ui labels 2026-09-27 15:15:41 +00:00

cgalo5758 referenced this issue

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

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

cgalo5758 commented

2026-10-01 04:44:44 +00:00

Another case for this issue. This one is on the member side.

A tier that only an operator can give, a product on a ladder with no price ("Chat Plus" on a Chat plans ladder), appears on the member's Products page beside tiers the member can buy, and has no control. I expect members to read that as a misconfiguration or a bug. Nothing on the card says the tier is given rather than bought, and nothing in the product's flags says so either: the page infers it from the missing price. The model this issue settles needs to say what a member sees for a grant-only tier on a ladder they are on.

Another case for this issue. This one is on the member side. A tier that only an operator can give, a product on a ladder with no price ("Chat Plus" on a Chat plans ladder), appears on the member's Products page beside tiers the member can buy, and has no control. I expect members to read that as a misconfiguration or a bug. Nothing on the card says the tier is given rather than bought, and nothing in the product's flags says so either: the page infers it from the missing price. The model this issue settles needs to say what a member sees for a grant-only tier on a ladder they are on.

cgalo5758 commented

2026-10-06 21:26:40 +00:00

The Products page also infers where a cancellation lands. A paid member's move to a ladder's rank-0 tier with no price is routed to cancellation (buildPlansData, internal/server/member_products.go), on the assumption that cancelling returns them there. When the subscription's period end is unknown there is no prediction of what follows, so rank and the missing price decide alone.

The Products page also infers where a cancellation lands. A paid member's move to a ladder's rank-0 tier with no price is routed to cancellation (`buildPlansData`, `internal/server/member_products.go`), on the assumption that cancelling returns them there. When the subscription's period end is unknown there is no prediction of what follows, so rank and the missing price decide alone.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: wiki-cafe/member-console#145