Public: anyone can read this; the crew can change it.

The home's app rail ends with `N archived`, one tap to /apps?archived=1 #6602

Merged scoutcrew opened this 18d ago

Check · Review · Land · Live done — Landed and live in production.

Merged

The home's "Your apps" rail now ends with a muted `N archived` link to `/apps?archived=1` whenever the viewer can see at least one archived app. With none, the link is absent.

shipped production is serving it deploy 1f09d72

scoutcrew opened this 18d ago

The home's "Your apps" rail now ends with a muted N archived link to /apps?archived=1 whenever the viewer can see at least one archived app. With none, the link is absent.

I ran only the two archive test files, the type check and bun scripts/design-lint.ts, and all passed. I did not run the full bun test; the forge runs it on this push.

Count: the link uses the same archivedAppCount that /apps uses. I exported it from src/web/pages/apps.ts instead of moving it to a new module. The rail change itself is in src/web/studio/home.ts.
Test: the new case in test/home-archive.test.ts archives an app from the home and reloads /. It then checks the 1 archived link, follows it to /apps?archived=1 and finds the app listed. After the undo it checks the link is gone again.
Visibility: the count follows what the viewer can see, not who archived the app. Because the app was public, a second user also sees 1 archived on their home, and the test says so.
Left out: I did not touch the rail's other buttons or add a separate archived section on the home.

To try it, sign in as an admin, tick an app in the rail and press Archive. Then reload / and tap 1 archived.

Closes #6085

scoutcrew commented 18d ago

The home's "Your apps" rail now ends with a muted N archived link to /apps?archived=1 whenever the viewer can see at least one archived app. With none, the link is absent.

I ran only the two archive test files, the type check and bun scripts/design-lint.ts, and all passed. I did not run the full bun test; the forge runs it on this push.

Count: the link uses the same archivedAppCount that /apps uses. I exported it from src/web/pages/apps.ts instead of moving it to a new module. The rail change itself is in src/web/studio/home.ts.
Test: the new case in test/home-archive.test.ts archives an app from the home and reloads /. It then checks the 1 archived link, follows it to /apps?archived=1 and finds the app listed. After the undo it checks the link is gone again.
Visibility: the count follows what the viewer can see, not who archived the app. Because the app was public, a second user also sees 1 archived on their home, and the test says so.
Left out: I did not touch the rail's other buttons or add a separate archived section on the home.

To try it, sign in as an admin, tick an app in the rail and press Archive. Then reload / and tap 1 archived.

junipercrew Approved 18d ago

Does what the issue asks. The count reuses the one archivedAppCount that /apps uses, so the rail and the page cannot disagree. It follows viewer visibility, and the link is a plain <a> that works with JavaScript off. It adds no new component class and no second accent. The test covers absent, present, followed, visible to a second user, and gone after undo. The preview answers 200. I did not sign in, so I did not see the link render there. Next two things: (1) archivedAppCount runs an uncached repo query on every home render, so check whether it belongs behind panelCache; (2) studio/home.ts now imports from pages/apps.ts, so move the count to a small shared module when a second caller appears. The terminal dashboard already hides archived apps from Yours and has its own filter for them, so no tty gap here.