Admin portal visible defects: what to review

Field	Value
Branch	feat/admin-and-merchant-portals, draft PR #976: feat(admin): portal navigation, financials and monitoring, plus the agent-process work behind them, not merged
Project	README.md
Issue	#882: bug(admin): false 'Set Up Separate Admin Password' banner for every admin once the #875 credential migration runs
Servers you need	Nothing renders this. See the honest answer below
Local origins	Not applicable. The fix is in auth-api, and auth-api already proxies to whichever origin AUTH_API_ORIGIN names
Test plan	docs/engineering/testing/runs/admin-portal-visible-defects/README.md

What changed here?

Only one thing landed on this branch: the profile-completion count in auth-api.

• services/api/auth/src/routes/adminUsers.js's /stats handler now counts a profile complete off encryptedInterests and encryptedMood, which is what profileService.js actually writes.
• It used to read the plaintext interests and mood fields, which that same save path deletes on every write. So the count was structurally zero and always had been.
• Committed as 312b2694.

The other defect in this project was already fixed on dev before the project started.

• The false "Set Up Separate Admin Password" banner. AdminMigrationBanner.jsx already reads hasAdminPassword from GET /auth/admin/status, not from a client Firestore read.
• Verified, not re-fixed. The deployed admin.dev.ourlantern.app bundle contains zero occurrences of adminPasswordHash and does contain the admin/status call.

Where do I look, and what am I looking for?

There is no screen for the profile-completion fix, and that is a finding rather than an oversight.

• usersProfilesComplete and usersProfilesIncomplete come back on the /auth/admin/users/stats payload and nothing in apps/admin/src renders either of them. Checked against origin/dev as well: no surface rendered them there either.
• So the fix is real and correct, and it has no visual surface to review. If you want to see it, the honest route is the response body, not a page.
• The one screen that reads that endpoint is http://localhost:3001/admin/users, and it renders totals, roles, activity and banned counts. It does not render profile completeness.

What "verified" means for this one, since you cannot click it

• The Firestore emulator: a new test in adminUsersRead.integration.test.js, 21 of 21 passing.
• A hand count against real lantern-app-dev data.
• The strongest one: the actual unmodified adminUsers.js route mounted on a local Express app and hit against real dev Firestore. Old logic finds 1 complete profile among 22 role=user docs; new logic finds 2, recovering a real user the old logic missed.

The banner http://localhost:3001/admin, signed in as an admin who already has a portal password

• You should see no "Set Up Separate Admin Password" prompt. This is the one thing here you can actually look at.
• It was never re-verified in a live browser during this project, because the local test credentials did not exist on the VM at the time. They exist now, via npm run env:bootstrap, so this check is finally runnable.

What is deliberately NOT done?

The credential migration was not run, and must not be run before the banner fix is live.

• migrate-credentials.mjs must not be run with --apply against any environment until the banner fix is in, or every admin sees the false prompt.
• That constraint is already satisfied on dev, and the migration itself is out of scope for this project.

The post-deploy check on the profile-completion count is the standing item.

• Once this branch merges and auth-api redeploys, the count reads from deployed dev for the first time. It is scenario 5 in the test plan and it is not filled.
• Given there is no surface rendering it, that check is a request against the deployed endpoint rather than a page load.

No surface was built to display the count.

• Whether the profile-completion number deserves a card anywhere is a product question nobody has asked. It is named here so you are not surprised that a fixed number is invisible.

What open findings touch this project?

• Nothing from ../merchant-and-venue-dashboards/branch-review-0828.md lands here. The reviewer checked adminUsers.js's profile-completeness switch explicitly and listed it under what was found clean.
• One adjacent open bug in the same file's territory: #995: bug(auth): the admin Banned stat counts expired bans, because it reads the raw flag instead of isActivelyBanned. That number does render, on /admin/users, so if the Banned card looks high, that is why. Located, not fixed.

What issue does each piece close?

Piece	Issue	State
The structurally-zero profile-completion count	#881: bug(admin): dashboard profile-completion counts are structurally always zero (plaintext fields were encrypted away)	Fixed on branch, no visual surface
The false admin-password banner	#882: bug(admin): false 'Set Up Separate Admin Password' banner for every admin once the #875 credential migration runs	Already fixed on dev, verified not re-fixed
The migration whose run triggers the banner	#875: security: sensitive fields colocated with readable data, so admin clients pull credentials and sealed-identity material into the browser	Out of scope, not run
The Banned stat counting expired bans	#995: bug(auth): the admin Banned stat counts expired bans, because it reads the raw flag instead of isActivelyBanned	Open, not fixed