Admin inventory needs to filter Published / Unpublished, so give it the status dimension directly #132

New Issue

2026-08-22T17:07:11-05:00

bermudalamb commented

2026-08-22 17:07:11 -05:00

There is no way to find unpublished items in the admin. Since #90 every new item arrives pending and has to be published, so "what is waiting for me to publish" is a routine question, and the inventory cannot answer it.

#105 replaced the four-way status dropdown with a Sold / Not sold / All preset, and recorded at the time that this gave up isolating a single status, that the pending workflow was the likeliest thing to miss it, and that the fix would be to restore that ability rather than to remove the preset. This is that follow-up, arriving sooner than expected.

Decision, taken 2026-08-22

The admin gets a multi-select of the four statuses - Pending, Available, Reserved, Sold - in place of the preset. The storefront keeps its three-way control unchanged.

The API already accepts several statuses since #105, so this exposes the dimension itself rather than adding more presets over it. Everything is then expressible in one control: Published is available + reserved + sold, Unpublished is pending, Sold and Not sold are the sets they always were, and Reserved on its own becomes reachable again.

Two alternatives were considered and rejected.

Growing the preset list to five - All, Not sold, Sold, Published, Unpublished - keeps one click per answer, but Reserved stays unreachable and the list grows again the next time somebody has a new question.

A second control beside the first, Publication alongside Availability, reads naturally and reintroduces exactly what #105 was designed to avoid. Sold and Unpublished is an impossible combination, since a sold item is necessarily published, and any two-dimensional control has to either give that a meaning or block it.

Scope

Admin only. The storefront has no use for this: pending items are excluded from every public read unconditionally, so Published and Unpublished are not distinctions a customer can draw.

ADMIN_SALE_STATUSES and the admin's use of saleStateFromStatuses go away with the preset. Both stay for the storefront.

Verification

The admin filter test from #105 is rewritten for the new control rather than deleted, and gains what it could not previously assert: selecting Pending alone shows a staged item and hides published ones, which is the question that prompted this. Selecting Available and Reserved together excludes both Pending and Sold, which is the Published-minus-Sold case and the one a preset would have had to be invented for.

An empty selection must mean "no filter" rather than "no statuses", since a multi-select cleared back to nothing should show everything rather than an empty table.

There is no way to find unpublished items in the admin. Since #90 every new item arrives pending and has to be published, so "what is waiting for me to publish" is a routine question, and the inventory cannot answer it. #105 replaced the four-way status dropdown with a Sold / Not sold / All preset, and recorded at the time that this gave up isolating a single status, that the pending workflow was the likeliest thing to miss it, and that the fix would be to restore that ability rather than to remove the preset. This is that follow-up, arriving sooner than expected. ## Decision, taken 2026-08-22 The admin gets a multi-select of the four statuses - Pending, Available, Reserved, Sold - in place of the preset. The storefront keeps its three-way control unchanged. The API already accepts several statuses since #105, so this exposes the dimension itself rather than adding more presets over it. Everything is then expressible in one control: Published is available + reserved + sold, Unpublished is pending, Sold and Not sold are the sets they always were, and Reserved on its own becomes reachable again. Two alternatives were considered and rejected. Growing the preset list to five - All, Not sold, Sold, Published, Unpublished - keeps one click per answer, but Reserved stays unreachable and the list grows again the next time somebody has a new question. A second control beside the first, Publication alongside Availability, reads naturally and reintroduces exactly what #105 was designed to avoid. Sold and Unpublished is an impossible combination, since a sold item is necessarily published, and any two-dimensional control has to either give that a meaning or block it. ## Scope Admin only. The storefront has no use for this: pending items are excluded from every public read unconditionally, so Published and Unpublished are not distinctions a customer can draw. `ADMIN_SALE_STATUSES` and the admin's use of `saleStateFromStatuses` go away with the preset. Both stay for the storefront. ## Verification The admin filter test from #105 is rewritten for the new control rather than deleted, and gains what it could not previously assert: selecting Pending alone shows a staged item and hides published ones, which is the question that prompted this. Selecting Available and Reserved together excludes both Pending and Sold, which is the Published-minus-Sold case and the one a preset would have had to be invented for. An empty selection must mean "no filter" rather than "no statuses", since a multi-select cleared back to nothing should show everything rather than an empty table.

bermudalamb added this to the Make the password-reset email editable from Admin project 2026-08-23 07:17:44 -05:00

bermudalamb self-assigned this 2026-08-23 07:17:53 -05:00

bermudalamb referenced this issue from a commit

2026-08-23 07:18:52 -05:00

feat(admin): filter inventory by status directly, so Published and Unpublished are reachable (#132)

bermudalamb moved this to In Progress in Make the password-reset email editable from Admin on 2026-08-23 07:19:54 -05:00

bermudalamb referenced a pull request that will close this issue

2026-08-23 07:20:48 -05:00

feat(admin): filter inventory by status directly, so Published and Unpublished are reachable (#132) #134

bermudalamb added reference feature/132-admin-status-multiselect

2026-08-23 07:21:07 -05:00

bermudalamb closed this issue