Admin inventory filtering should use the same flyout and controls as the storefront #169

New Issue

2026-08-24T16:28:02-05:00

bermudalamb commented

2026-08-24 16:28:02 -05:00

#139 gave the storefront filter panel searchable multi-selects for categories and tags, inside the flyout drawer it already had. The admin's inventory filters did not move: they are still an always-visible row of controls above the table, and the category control there is single-select, holding a list of at most one so that the two screens could share a filter type without the admin changing shape.

The two screens now ask the same questions through different UI. This makes the admin match the customer-facing panel: the same flyout, the same searchable multi-select for category and for tag, the same Filters (N) button, and the same removable active-filter chips beside it.

The decision this reverses

InventoryFilters.tsx carries a comment arguing for the row it has: "An always-visible row rather than the storefront's drawer: this sits above a data table, where hiding the controls behind a click costs more than the space it saves, and a drawer would overlay the very rows being filtered."

That reasoning is not wrong, and it is being traded away deliberately for consistency between the two panels. The active-filter chips are what keeps the cost bearable — with them beside the button, the current filter is still readable without opening anything, which is the part the always-visible row was really protecting.

Scope

The drawer becomes shared rather than copied, with the sections that differ driven by props rather than by a second component:

Favorites is storefront-only.
Status is admin-only. The storefront keeps its three-way preset outside the drawer, since pending is excluded from every public read and Published / Unpublished are not distinctions a customer can draw.
Price on the storefront is a slider bounded by the catalogue's real range, which comes from /api/filters. The admin has no such bound and keeps the two number inputs it has now.

Categories become multi-select in the admin too, which removes the list-of-at-most-one special case #139 introduced there.

The admin e2e page object and specs move with it — the category, tag and status controls are behind a button now, and Clear filters moves into the drawer footer alongside the storefront's Clear all.

Depends on #139, which is what makes the filter shape multi-valued in the first place.

#139 gave the storefront filter panel searchable multi-selects for categories and tags, inside the flyout drawer it already had. The admin's inventory filters did not move: they are still an always-visible row of controls above the table, and the category control there is single-select, holding a list of at most one so that the two screens could share a filter type without the admin changing shape. The two screens now ask the same questions through different UI. This makes the admin match the customer-facing panel: the same flyout, the same searchable multi-select for category and for tag, the same `Filters (N)` button, and the same removable active-filter chips beside it. ### The decision this reverses `InventoryFilters.tsx` carries a comment arguing for the row it has: *"An always-visible row rather than the storefront's drawer: this sits above a data table, where hiding the controls behind a click costs more than the space it saves, and a drawer would overlay the very rows being filtered."* That reasoning is not wrong, and it is being traded away deliberately for consistency between the two panels. The active-filter chips are what keeps the cost bearable — with them beside the button, the current filter is still readable without opening anything, which is the part the always-visible row was really protecting. ### Scope The drawer becomes shared rather than copied, with the sections that differ driven by props rather than by a second component: - Favorites is storefront-only. - Status is admin-only. The storefront keeps its three-way preset outside the drawer, since pending is excluded from every public read and Published / Unpublished are not distinctions a customer can draw. - Price on the storefront is a slider bounded by the catalogue's real range, which comes from `/api/filters`. The admin has no such bound and keeps the two number inputs it has now. Categories become multi-select in the admin too, which removes the list-of-at-most-one special case #139 introduced there. The admin e2e page object and specs move with it — the category, tag and status controls are behind a button now, and `Clear filters` moves into the drawer footer alongside the storefront's `Clear all`. Depends on #139, which is what makes the filter shape multi-valued in the first place.

bermudalamb added this to the Customer and Admin UI review findings project 2026-08-24 16:40:45 -05:00

bermudalamb self-assigned this 2026-08-24 16:40:53 -05:00

bermudalamb referenced this issue from a commit

2026-08-24 16:42:24 -05:00

feat(admin): filter inventory through the same flyout the storefront uses (#169)

bermudalamb referenced this issue

2026-08-24 16:42:53 -05:00

The storefront filter panel needs searchable multi-select for categories and tags #139

bermudalamb closed this issue

2026-08-24 16:47:00 -05:00

bermudalamb moved this to Review in Customer and Admin UI review findings on 2026-08-24 16:48:14 -05:00

bermudalamb referenced this issue