gitea_admin/zurich_kotak
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
23 Commits 2 Branches 0 Tags 2.3 MiB
JavaScript 74.1%
CSS 25.5%
HTML 0.4%
dbbd34f7bf
Go to file
Yashas dbbd34f7bf form: apply the prefill the server already sends 
"Sourced By", "Submitted By" and "Source Channel" rendered empty on the
new-lead form. The prefill pipeline was working the whole time — the
form-screen response carries

  partner_code    "Shetty Insurance Services (POSP-77341)"
  rm_or_agent_id  "arjun.posp@zurichkotak.example"
  source_channel  "agency"

and the form ignored all three.

The two sides key the same field differently and nothing reconciles it.
A form field is the ACTIVITY key, suffixed because one global may be
used on several activities in a version — partner_code_3,
rm_or_agent_id_3, source_channel_4. A fieldMapping node names the
GLOBAL — partner_code, rm_or_agent_id, source_channel. Neither is
wrong. The seeding loop matched on f.id exactly, found nothing, and
seeded nothing, with no error anywhere.

Now it tries the exact id, then the field uid, then the global name with
the numeric suffix stripped. Taking all three means this survives a
pipeline authored in either convention rather than breaking again the
next time one is written the other way. Empty and null are skipped so a
mapping that resolved to nothing does not overwrite a real default.

Worth noting the failure mode rather than just the fix: a prefill that
matches nothing looks exactly like a prefill that was never configured.
It is why the pipeline read as "empty" from the config tables — the
authoritative store is tbl_wf_activity_prefill_nodes, not the
pipeline_config JSONB, and the quickest honest check is neither: POST
/view/form-screens and read prefill_data.
2026-09-07 16:45:45 +05:30
public/brand Wire the console to the platform and make it deployable 2026-08-24 15:20:13 +05:30
src form: apply the prefill the server already sends 2026-09-07 16:45:45 +05:30
.env.example Wire the console to the platform and make it deployable 2026-08-24 15:20:13 +05:30
.gitignore Updated to new frontend specifications 2026-09-04 13:26:20 +05:30
CLAUDE.md Updated to new frontend specifications 2026-09-04 13:26:20 +05:30
eslint.config.js Empty vite-react project 2026-08-24 12:27:21 +05:30
index.html fix(build): add BASE_HREF placeholder + config.js tag to index.html 2026-08-24 15:47:26 +05:30
package-lock.json Wire the console to the platform and make it deployable 2026-08-24 15:20:13 +05:30
package.json Wire the console to the platform and make it deployable 2026-08-24 15:20:13 +05:30
README.md Wire the console to the platform and make it deployable 2026-08-24 15:20:13 +05:30
vite.config.js Wire the console to the platform and make it deployable 2026-08-24 15:20:13 +05:30

README.md

Zurich Kotak — Lead Desk

Operator console for the Zurich Kotak "Lead to Policy" demo. Leads arrive through three channels — direct, bancassurance and agency — and run one state machine to policy issuance. The agents do the work; a person appears at one queue.

Workflow config is seeded from sm2/custom-apps/zurich-kotak/ (org 84, app 536, workflow zk_wf_lead). Design doc: sm2/app-designs/zurich-kotak/design.html. Workflow spec PDF: sm2/custom-apps/zurich-kotak/zurich-kotak-workflow.pdf.

Run it

npm install
npm run dev          # http://localhost:5175
npm run build        # → dist/

.env carries the API host for local dev only:

VITE_ZINO_API_URL=https://dev.getzino.in

Logins (all password ZurichKotak@2026, org 84):

Email Role Can do
sanjay.uw@zurichkotak.example SME Underwriter Clear / Decline Referral — the only human decision
meera.rm@zurichkotak.example Bancassurance RM Submit a Partner Bank Lead
arjun.posp@zurichkotak.example POSP / Broker Submit a Partner Agent Lead
kavya.csr@zurichkotak.example Direct / Call centre Submit a Self-Serve Lead
deepa.ops@zurichkotak.example Operations Cross-channel visibility

Sign in as Sanjay to land in Referred to Underwriting, which is where the demo happens.

How it talks to the platform

Everything goes through src/api/client.js:

  • POST /usr/login — auth. org_id must be a string; a number returns cannot unmarshal number into Go struct field LoginRequest.org_id.
  • POST /app/536/view/recordview — every queue is one record view (zk-rv-leads) filtered server-side on current_state_name.
  • POST /app/536/view/form-screens then POST /app/536/activity — forms are read from the live activity schema and submitted straight back.

Forms are not defined in this repo

Whatever /view/form-screens returns is what renders — labels, types, select options, which fields are mandatory. Add a field to an activity in Studio, redeploy, and it appears here with no frontend change. That is deliberate: the workflow is the source of truth, and a hardcoded form would quietly diverge from it.

Permissions are never enforced here

The console does not hide a button to stop someone using it. Every permission decision is the workflow's, made server-side on each submission — the platform refuses and this app reports what it said. Two refusals worth knowing: /activity answers 403, /start answers 400, and both carry permission denied.

The runtime-config contract

VITE_ZINO_API_URL is read at runtime from a config.js the server writes when it places the build — never compiled in. One artifact is promoted between environments unchanged, so a build-time URL would point every environment at whichever backend happened to build it. requireConfigValue throws if it is missing, so a production build with no config.js fails loudly rather than calling the wrong backend.

vite.config.js uses base: './' and the router takes its basename from the <base href> the server writes, so one build serves any mount path. Do not reintroduce a build-time base.

This is also why the fonts and logo live under src/assets/ and not public/. Vite rewrites bundled asset URLs to be relative; a public/ file referenced as /fonts/… stays absolute and 404s under the /zurich-kotak/ mount path. The favicon is the one exception — it stays in public/brand/ and is referenced relatively from index.html.

Deployment

Registered with frontgen by sm2/custom-apps/zurich-kotak/05_frontgen_project.sql (slug zurich-kotak, repo_name zurich_kotak, org 84). A push to main builds and serves at https://preview-dev.getzino.in/zurich-kotak/.

The webhook only fires on a new push — a push made before the frontgen project row existed matched no project and did nothing.

State of the build

Piece Status
Brand — Zurich Sans, palette, logo done (kept from the original scaffold)
Sign-in against the real gateway done
Runtime config, relative base, router done
Pipeline sidebar (mirrors tbl_wf_states) done
Queue lists waiting on the zk-rv-leads record view
Lead file, activity forms, attribution panel waiting on zk-dv-lead + form screens