Skip to content

feat(auth-ui): read-only Bundles page MAPCO-11712 - #156

Open
CptSchnitz wants to merge 8 commits into
masterfrom
feat/bundles-page
Open

CptSchnitz wants to merge 8 commits into
masterfrom
feat/bundles-page

Conversation

@CptSchnitz

Copy link
Copy Markdown
Contributor

Summary

  • Adds a new read-only "Bundles" page to auth-ui, listing GET /bundle records with an Environment and creation-date-range filter bar synced to the url, and a details modal for fields not shown in the table (hash, keyVersion, assets, connections, metadata).
  • Reachable from the sidebar nav, positioned after "Assets"; no backend/API changes.
  • Fixes found via manual Playwright testing against a bundle with 350 connections: the details modal now keeps its header/close button fixed while only the entry lists scroll, each entry list is independently bounded so a long list doesn't bury the Metadata section, and rows are keyed defensively rather than by content.
  • Bundles are listed newest-first, sorted client-side since GET /bundle has no sort parameter.

Implements .scratch/bundles-page/spec.md and tickets 01–03.

Test plan

  • pnpm test (auth-ui): 190/190 passing
  • pnpm exec tsc -b tsconfig.app.json: no new errors (pre-existing, unrelated errors in calendar.tsx/EditClientModal.tsx/EditConnectionModal.tsx only)
  • pnpm exec eslint on all changed files: clean
  • Manually verified in-browser via Playwright against a seeded bundle with 350 connections: list, filters, and modal (including scroll containment) all behave correctly

CptSchnitz and others added 6 commits September 22, 2026 10:40
Add a read-only Bundles page listing GET /bundle records, reachable
from the sidebar nav. No filtering yet.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Add an Environment dropdown and createdAfter/createdBefore date
inputs to the Bundles page, synced to the url like the existing
Connections/Clients/Domains/Assets pages.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Clicking a bundle row opens a read-only modal showing the hash,
keyVersion, assets, connections and metadata, using the row data
already fetched by the list request.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
GET /bundle's createdAfter/createdBefore are date-time, not bare
dates. Widen the picked day to its first and last instant (UTC)
before sending, so the day stays inclusive on both ends and the
request matches the endpoint's actual contract.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Playwright testing against a bundle with 350 connections found two
bugs: the whole modal, including its header and close button,
scrolled as one block, so scrolling into the list scrolled the close
button out of the viewport with no way back to the top short of
scrolling back up; and duplicate name+version pairs across entries
produced a React duplicate-key warning.

Give the header a fixed position and let only the body scroll, cap
each entries list to its own bounded, independently scrollable box
so a long list doesn't bury the Metadata section, and key rows by
index rather than by content, which isn't guaranteed unique at this
layer even though the API schema marks it so.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
GET /bundle has no sort parameter, so ordering is whatever the
database returns. Sort client-side by createdAt descending so the
most recently built bundle is always the first row.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@CptSchnitz CptSchnitz changed the title feat(auth-ui): read-only Bundles page feat(auth-ui): read-only Bundles page MAPCO-11712 Sep 22, 2026
@github-actions

github-actions Bot commented Sep 22, 2026 •

Copy link
Copy Markdown

🎫 Related Jira Issue: MAPCO-11712


// The date inputs pick a day; the endpoint filters on a full timestamp. Widening to the
// day's first and last instant keeps the picked day inclusive on both ends.
const startOfDay = (date: string): string => `${date}T00:00:00.000Z`;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Current state: it is UTC
. Should it be local?
Wondering what's better

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch, and it's more than a preference — it's a correctness bug. startOfDay/endOfDay were string-concatenating the date input's value with a hardcoded UTC offset, so "the day picked" was actually being read as UTC. Anyone outside UTC would get the filter shifted by their local offset from midnight: a bundle built just after local midnight on the picked day could land on the wrong side of the boundary and get silently excluded.

Fixed in f9057fd: the boundary is now built from the local calendar day (new Date(year, month - 1, day, ...), which JS reads as local time) and converted to the equivalent UTC instant via .toISOString() for the request — matching the local-day/UTC-on-the-wire pattern ClientsPage already uses via its Calendar picker. Verified the fix (and the tests, which now assert the round-tripped local time rather than a hardcoded UTC string) under TZ=UTC, TZ=America/New_York and TZ=Pacific/Kiritimati.

CptSchnitz and others added 2 commits September 24, 2026 14:13
createdAfter/createdBefore were built by string-concatenating the
date input's value with a hardcoded UTC offset, so "the day the user
picked" was actually being read as UTC. Anyone outside UTC would get
a filter shifted by their offset from local midnight — a bundle
built just after local midnight on the picked day could fall on the
wrong side of the boundary and get excluded.

Construct the boundary from the local calendar day instead (matching
the local-day, UTC-on-the-wire pattern ClientsPage already uses via
its Calendar picker) and convert to the equivalent UTC instant for
the request.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Cut comments down to the non-obvious point, dropping restatements of
what the surrounding code already shows.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants