feat: filter by Sold / Not sold / All on the storefront and the admin (#105)

Three decisions were taken before any code, and are recorded on the issue. The status filter is generalised to accept several values rather than gaining a second `sold` dimension beside it. "Not sold" is not a status: it is available-or-reserved on the storefront and includes pending in the admin, neither of which is one value. `?status=available,reserved` and `i.status = ANY($n::text[])` express that with one concept, so there is no way to write a contradiction like `?status=sold&sold=no`. A single status still parses to a list of one, which is how the admin's existing `?status=sold` keeps working untouched. The storefront now defaults to Not sold. That is a change in what every customer sees, not just a new control: the black SOLD ribbons leave the default view on a catalogue where they were evidence the shop sells things, and every storefront link shared so far quietly changes meaning. Accepted deliberately, with the default named in STOREFRONT_DEFAULT_STATUSES rather than implied by the absence of a parameter. The admin's four-way status dropdown is replaced rather than joined. That gives up isolating a single status: there is no longer a way to view only Reserved, or only Pending, and Not sold folds pending in with the rest. The pending workflow from #90 is the likeliest thing to miss it, and if it does, the fix is to put isolation back beside the preset rather than to remove the preset. The e2e test that covered "which is how Reserved is reached" is renamed and narrowed to what survives, rather than deleted. One thing the issue did not anticipate, found by a test rather than by reading. The favorites view deliberately showed sold favorites - "a favorite that has just sold is often exactly what the customer came to look at", and they have just been emailed to say so. Defaulting the storefront to Not sold reversed that silently and broke the test asserting it. Favorites therefore keep their own default of everything, on the server and in the control's displayed position, while an explicit ?status= still wins. That interaction is the kind a single-feature change quietly breaks, and it was caught only because the previous decision had been written down as an assertion. "All" still means different things in the two places, as the issue set out: available + reserved + sold on the storefront, all four in the admin. Pending remains unreachable from every public read - the storefront's unconditional exclusion clause is untouched - and the pending guard now checks every requested status rather than a single one, so `?status=available,pending` is refused for naming pending at all rather than accepted because the first name happened to be allowed. The control sits in the filter bar rather than in the drawer, since the default now hides sold pieces and a customer who never opens the drawer would otherwise have no way to know they exist. It is consequently excluded from the "Filters (N)" count, which describes the drawer, while still counting toward hasActiveFilters so that an empty result reads as "no items match these filters" with a way out rather than as an empty shop. Verification: 13 integration tests covering the default, each preset, the favorites exception and its override, and pending's unreachability under every accepted combination; 38 parser unit tests including multi-value parsing, an unknown name in a list being refused rather than dropped, and a list that names nothing; 6 new end-to-end tests for the storefront control, its URL round-trip, and the default staying out of the URL. 204 backend unit tests and 76 integration tests across the four affected suites pass. Two full end-to-end runs: 110 and 111 passing against the same 3 pre-existing failures, one run also showing a pending-publish failure that passes in isolation and did not recur - the cross-suite database contention filed as #116. tsc, ESLint and the production build are clean. Closes #105 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-22 12:58:33 -05:00
parent e5ff980eae
commit 32b3f616d9
9 changed files with 618 additions and 42 deletions
@@ -0,0 +1,196 @@
+import request from 'supertest';
+import app from '../../src/app';
+import { pool } from '../../src/db';
+import { resetDb, closeDb } from './setup/testDb';
+
+beforeEach(async () => {
+  await resetDb();
+});
+
+afterAll(async () => {
+  await pool.end();
+  await closeDb();
+});
+
+// Direct insert so a test can put an item in a specific state without going
+// through the transitions that put it there.
+async function insertItem(name: string, status: string): Promise<number> {
+  const { rows } = await pool.query(
+    `INSERT INTO items (name, price_cents, status) VALUES ($1, $2, $3) RETURNING id`,
+    [name, 10000, status]
+  );
+  return rows[0].id;
+}
+
+async function seedOneOfEach() {
+  await insertItem('Pending piece', 'pending');
+  await insertItem('Available piece', 'available');
+  await insertItem('Reserved piece', 'reserved');
+  await insertItem('Sold piece', 'sold');
+}
+
+const namesFrom = (body: { name: string }[]) => body.map((i) => i.name).sort();
+
+describe('the storefront status filter', () => {
+  // The product decision this change carries: with no filter the storefront no
+  // longer lists sold items. Asserted on the default rather than on the
+  // parameter, because the default is the part that changed for everyone.
+  it('lists neither sold nor pending items by default', async () => {
+    await seedOneOfEach();
+
+    const res = await request(app).get('/api/items');
+
+    expect(res.status).toBe(200);
+    expect(namesFrom(res.body)).toEqual(['Available piece', 'Reserved piece']);
+  });
+
+  it('lists only sold items when asked for them', async () => {
+    await seedOneOfEach();
+
+    const res = await request(app).get('/api/items?status=sold');
+
+    expect(namesFrom(res.body)).toEqual(['Sold piece']);
+  });
+
+  it('brings sold items back for an explicit All', async () => {
+    await seedOneOfEach();
+
+    const res = await request(app).get('/api/items?status=available,reserved,sold');
+
+    expect(namesFrom(res.body)).toEqual(['Available piece', 'Reserved piece', 'Sold piece']);
+  });
+
+  it('lists not-sold items for an explicit Not Sold, matching the default', async () => {
+    await seedOneOfEach();
+
+    const explicit = await request(app).get('/api/items?status=available,reserved');
+    const implied = await request(app).get('/api/items');
+
+    expect(namesFrom(explicit.body)).toEqual(namesFrom(implied.body));
+  });
+
+  // The guarantee that must survive the filter being generalised. Pending is
+  // excluded from every public read by a clause the caller cannot opt out of,
+  // and these assert it directly rather than trusting the parser to go on
+  // refusing the name.
+  describe('pending stays unreachable from the storefront', () => {
+    it('refuses a request naming pending on its own', async () => {
+      await seedOneOfEach();
+
+      const res = await request(app).get('/api/items?status=pending');
+
+      expect(res.status).toBe(400);
+      expect(res.body.error).toBe('invalid status');
+    });
+
+    // The case a single-value check would have let through: the list is refused
+    // for naming pending at all, not accepted because the first name is fine.
+    it('refuses a request naming pending among allowed statuses', async () => {
+      await seedOneOfEach();
+
+      const res = await request(app).get('/api/items?status=available,pending');
+
+      expect(res.status).toBe(400);
+      expect(res.body.error).toBe('invalid status');
+    });
+
+    it('never returns a pending item under any accepted combination', async () => {
+      await seedOneOfEach();
+
+      for (const query of ['', '?status=sold', '?status=available,reserved,sold', '?status=reserved']) {
+        const res = await request(app).get(`/api/items${query}`);
+        expect(res.status).toBe(200);
+        expect(res.body.map((i: { name: string }) => i.name)).not.toContain('Pending piece');
+      }
+    });
+  });
+
+  it('refuses an unknown status rather than ignoring it', async () => {
+    const res = await request(app).get('/api/items?status=available,sold_out');
+
+    expect(res.status).toBe(400);
+    expect(res.body.error).toBe('invalid status');
+  });
+});
+
+describe('the admin inventory status filter', () => {
+  // All means all four here, unlike the storefront. Same word, two meanings,
+  // which is why each is asserted where it applies rather than assumed shared.
+  it('lists every status including pending when none is named', async () => {
+    await seedOneOfEach();
+
+    const res = await request(app).get('/api/admin/items');
+
+    expect(namesFrom(res.body)).toEqual([
+      'Available piece',
+      'Pending piece',
+      'Reserved piece',
+      'Sold piece'
+    ]);
+  });
+
+  it('still accepts a single status, which is what the old dropdown sent', async () => {
+    await seedOneOfEach();
+
+    const res = await request(app).get('/api/admin/items?status=pending');
+
+    expect(namesFrom(res.body)).toEqual(['Pending piece']);
+  });
+
+  // Not Sold in the admin includes pending, which it does not on the storefront.
+  it('accepts a multi-status Not Sold that includes pending', async () => {
+    await seedOneOfEach();
+
+    const res = await request(app).get('/api/admin/items?status=available,reserved,pending');
+
+    expect(namesFrom(res.body)).toEqual(['Available piece', 'Pending piece', 'Reserved piece']);
+  });
+});
+
+describe('the favorites view keeps its own default', () => {
+  // Favorites defaulted to showing sold items before this filter existed, on
+  // the reasoning that a favorite which has just sold is often exactly what the
+  // customer came to look at — they were emailed to say so. Defaulting them to
+  // Not Sold alongside everything else would have quietly reversed that.
+  it('shows a sold favorite with no status named', async () => {
+    const agent = request.agent(app);
+    expect(
+      (await agent.post('/api/customers/register').send({
+        email: 'favdefault@example.com',
+        password: 'supersecret123',
+        firstName: 'Thom',
+        lastName: 'Lamb'
+      })).status
+    ).toBe(200);
+
+    const soldId = await insertItem('Sold favorite', 'sold');
+    const availableId = await insertItem('Available favorite', 'available');
+    expect((await agent.post(`/api/customers/me/favorites/${soldId}`)).status).toBeLessThan(300);
+    expect((await agent.post(`/api/customers/me/favorites/${availableId}`)).status).toBeLessThan(300);
+
+    const res = await agent.get('/api/items?favorites=1');
+
+    expect(res.status).toBe(200);
+    expect(namesFrom(res.body)).toEqual(['Available favorite', 'Sold favorite']);
+  });
+
+  // The default is a default, not an override: naming a status still wins.
+  it('honours an explicit Not Sold within the favorites view', async () => {
+    const agent = request.agent(app);
+    await agent.post('/api/customers/register').send({
+      email: 'favexplicit@example.com',
+      password: 'supersecret123',
+      firstName: 'Thom',
+      lastName: 'Lamb'
+    });
+
+    const soldId = await insertItem('Sold favorite', 'sold');
+    const availableId = await insertItem('Available favorite', 'available');
+    await agent.post(`/api/customers/me/favorites/${soldId}`);
+    await agent.post(`/api/customers/me/favorites/${availableId}`);
+
+    const res = await agent.get('/api/items?favorites=1&status=available,reserved');
+
+    expect(namesFrom(res.body)).toEqual(['Available favorite']);
+  });
+});