← automation
sherpa-api#457 Done · In review ⏱ 2h 18m
Custom additional fields on endorsements
⎇ auto/api-457-custom-additional-fields-on-endo
Portal localhost:3007Embed localhost:3107API localhost:4007
🔍 iterative-review ✓ (main-pass) 🧪 test:api failed 75 passed · 28 failed · 0 flaky · 0 skipped · report 🧑‍🔬 QA ✅ PASS

Feedback

Pull requests

loading…

QA evaluation

✅ PASS

PASS. I independently verified the single acceptance criterion end-to-end by driving the real apps in a headless browser (no trust in the implementer's screenshots). In the operator portal I added a REQUIRED ad-hoc endorsement field via the product field-builder UI, opened a live active policy's endorsement flow where the field rendered, confirmed an empty submit is blocked with an inline 'This field is required' error, then submitted a value and saw it persisted on a new ENDORSEMENT version — visible both in the 'Additional Details' card and the 'Version N (Endorsement)' history switcher, and confirmed on the policy record via the API. I also verified the embedded customer endorsement flow (:3107) as a clean widget: the round-1 regression is fixed — EndorsementForm now renders the configured field, blocks empty submit, and reaches the Thank-You done state with the value persisted. The sherpa-test suite is red (28 failures) but those are an environmental auth/port cascade unrelated to #457 (root-caused in quality notes; #457's own spec passed 10/10 on this branch in the earlier run and I re-verified the endpoints live), so tests_ok=true. Precondition note: the criterion requires a product with endorsements enabled (ProductSetting edit=true); org-2222 products lacked it, so I enabled it on product 226 via the admin settings API before driving the #457 feature entirely through the UI.

4/4 acceptance criteria passed
  • Operator can add a REQUIRED ad-hoc field to an endorsement via the product config UIDrove the real portal field-builder at /products/226/endorsement-fields: clicked 'Add field', filled label 'QE Reason for change 257354', toggled Required ON, saved. The new row appeared with a red 'Required' badge; API config confirmed required=true, source=adhoc, auto-derived fieldKey. Screenshot eval-1-field-builder.png.
  • Added field renders in the endorsement flow and empty submit fails validationOpened the operator endorsement flow at /customer-portal/policies/<id>/edit. The 'Additional information' section rendered the configured field (ef-input-qeReasonForChange257354). Clicking 'Apply Policy Changes' with it empty produced inline 'This field is required' (ef-error) plus the banner 'Please complete the required fields below.' and stayed on the edit page — submit blocked. Screenshot eval-2b-required-validation.png.
  • Submitted value is stored and visible on the endorsement and in policy historyFilled the field ('Customer relocated — QE 257354') and submitted. Redirected to the policy detail at ?version=2 (3 on re-run). Detail shows the 'Version N (Endorsement)' version switcher (history) and an 'Additional Details' card listing the captured value (endorsement-detail-<key>). Backend GET /v1/policies/<id> confirmed endorsementFieldValues persisted on the new version and version>=2. Screenshot eval-3-persisted-and-history.png.
  • Added field renders + validates + submits in the EMBEDDED customer endorsement flowDrove the embed (:3107) as a clean public widget (widget token only, no operator session) at ?pageType=endorsement&policyId=<id>&token=...: EndorsementForm rendered (NOT the new-business form — the round-1 regression is fixed), showing the configured 'QE Reason for change 257354 *' field. Empty submit -> 'This field is required'; filled submit -> 'Thank You! Your change has been submitted.'; backend confirmed value persisted + version bumped. Screenshots eval-embed-1-renders.png, eval-embed-2-validation.png, eval-embed-3-done.png.
tests_ok: true · quality: sherpa-api diff is additive and well-guarded (config-time regex/options/label validation; required-field enforcement at submit returns 400; stable fieldKey on rename so captured values keep resolving; values carried forward when a submit omits them). Portal field-builder + EndorsementCustomFields + detail 'Additional Details' are clean; embed round-2 useConfig fix routes both /endorsement/<id> and ?pageType=endorsement. Latest sherpa-test test:api was RED (75 passed / 28 failed) but the 28 are an environmental auth cascade, NOT #457 regressions: dominant signature is HTTP 401 on the test client-credential path (e.g. product-create 'Expected 201 Received 401'), with downstream cascade artifacts ('product not found — run 00-01 first', 'Cannot read properties of undefined (find)') across the serial plus-insurance/payments suites. Root cause is test-env config (the test worktree .env points SHERPA_API_HTTP at :4000 and the seeded client-credential is rejected), evidenced by: the SAME branch earlier ran 236/5/12 with #457's own 09-endorsement-fields spec passing 10/10; the #457 diff touches no auth middleware; and I independently re-exercised the endorsement-field CRUD + quote + endorse endpoints live on :4007 with operator Bearer auth and they returned 200 with correct data.