Persona Follow-ups — Done Report (2026-07-12)
Scope (Efran, 4 items): ① Proses Dokumen out of the notaris view · ② support future per-notaris accounts with their own transactions · ③ audit "Daftar Permohonan" in the Verifikator Apostille view (vs the real Apostille + SABH) · ④ filters + search on every transaction list.
Status: ALL DONE & DEPLOYED — staging ahu-ai-ocr:6aecc76c live on 192.168.83.20:3520. Both suites green (backend 2525 / 0 fail, frontend 970 / 0 fail); verified live with API checks + persona screenshots.
① Proses Dokumen out of notaris
Removed from the notaris sidebar and the home CTA cards (the friendly home now leads with the two real filing actions). The /process* and /verification/:id routes moved under the admin guard, and the admin nav gained "Proses Dokumen" (Pemantauan group) — it is the OCR ops/QA surface, and the admin work-queue table already deep-links into it. Nothing in the notaris filing flows ever linked there (verified by sweep), so no notaris journey breaks.
② Per-notaris accounts — the ownership seam
The schema has carried a dormant Submission.ownerId ("Phase-1 object-level authz anchor") that nothing ever populated. It is now live end-to-end:
- Stamped at creation, everywhere: PT klasifikasi (
POST /api/submissions), perbaikan (upload + the Surat Keterangan service), apostille (/start+/submit-form), all PP flows, and peralihan PP→PT all writeownerIdfrom the authenticated principal (security/owner.ts → requestOwnerId). Anonymous requests stampnull— today's shadow-mode behavior is byte-identical. - Scoped reads when it matters:
GET /api/submissionsandGET /api/apostille/listfilter to the caller's own rows whenSECURITY_ENFORCE=onand the caller holds a non-staff role (notaris/perseroan/umum). Staff (both verifikator teams, admin) always see their full surface. In shadow mode lists stay unscoped, so nothing changes for the PoC until real per-user tokens (SABH SSO) arrive — exactly the platform's dormant-until-env-flip convention. - Covered by
ownership-and-names.test.ts: stamping (authed vs anonymous), scoping under enforcement (own rows only, pre-accountnullrows hidden from scoped callers, staff see all), and shadow-mode neutrality.
So when accounts land, flipping enforcement on gives each notaris their own transaction space with zero further schema or endpoint work — the remaining task is only the token issuer (SSO) and, if desired, extending the same one-line scope to more per-family list endpoints.
③ "Daftar Permohonan" for Verifikator Apostille — removed (here's the analysis)
What it was: a leftover from before the P2 unified inbox. Originally the apostille verifikator's only queue was the shared /apostille/daftar list; after P2 merged apostille into the domain-scoped /verifikator queue (with status mapping, SLA chips, status=all covering already-decided rows), the nav entry became a second door to the same rows.
Does the real Apostille have it? Not for the verifikator. In the AHU Apostille system the applicant tracks their permohonan list; the verifikator works a verification queue of submitted requests. Our split now mirrors that: umum keeps "Daftar Permohonan" (/apostille/daftar), the verifikator keeps only "Daftar Verifikasi". Route guards were split accordingly (list = umum+admin; review page still shared, since the queue links into it).
Does SABH give the PT notaris a transaction list? Yes — SABH's notaris dashboard is essentially a Daftar Transaksi. Our equivalent already exists: "Permohonan Saya" on the notaris home (PT-family scoped, and per-account once enforcement is on). So nothing was missing on the PT side; the only action was removing the redundant verifikator entry.
④ Filters + search on every transaction list
| Surface | Search | Filters | Status |
|---|---|---|---|
| Admin — Semua Transaksi | new (ID / nama / jenis) | family tabs PT/PP/Apostille + status + awaiting-verifikasi toggle (existing) | done |
| Notaris — Permohonan Saya | new (nama PT / jenis / ID) | new status dropdown (matches the row chips) | done |
| Verifikator PT & Apostille queues | already had (P2) | already had (status, AI rec, jenis, flow, sort) | no change |
| Umum — Daftar Permohonan | n/a (short personal list, paginated) | — | unchanged |
To make search useful, the submissions list payload now carries namaPerseroan: registry snapshot (oldData.nama) → apostille applicant → fallback to the extracted nama_perseroan field (one extra query for the still-unnamed rows). The admin table and notaris rows display it too — live on staging, 16/20 rows resolve a name (the 4 without are failed-extraction rows with no data at all).
Verification
- Backend 2525 / frontend 970, all green; new
ownership-and-names.test.ts(4 tests). - Live:
?family=notarisrows carry names;ownerIdcolumn present (49 rows, all null — correct for shadow mode); screenshots confirm the trimmed notaris nav + 2-card home + search bar, and the verifikator-apostille nav with only "Daftar Verifikasi".