Summary
#7151 (#7202) made the shared apiErrors helper safe (a field is named only by a 400/409 refusal), #7152 (#7209) routed the personal/partner LINE DIALOGS through it, #7062 did the power form and dialog. The personal and partner pages' MAIN save paths were left out: the form save and the document HEADER save still assign the raw e.message to the page banner, and their header controls bind no aria-invalid at all.
Evidence (origin/master, template-application-ui-harmonia-java/.../ui/)
my/my-form-page.js.template:182 this.error = (e && e.message) || 'Could not save.';
partner/partner-form-page.js.template:182 this.error = (e && e.message) || 'Could not save.';
my/my-document-page.js.template:233 this.error = (e && e.message) || 'Could not save.'; (header save)
partner/partner-document-page.js.template:223 same
plus the delete/load paths in the same files (my-form-page 94/195, partner-form-page 94/195, my-document-page 148/254/524/550/592, partner-document-page 138/244/439/478) and admin/admin-index.html.template:246, 313, 329 (this.error = String(e.message || e)).
ApiError.message IS the developer-facing text (api.js:25 super(errorMessage || String(httpStatus || '')), :30 this.errorMessage = errorMessage || ''; // dev-facing). So on a 500 the Hibernate/JDBC sentence lands verbatim in <div x-show="error" ... x-text="error"> (my-form-view.html.template:41) - the #7151 leak - and on a 400 naming a field (The 'Name' property is required) the message is prose with no field marked: grep -c aria-invalid my-form-view.html.template = 0, same for partner-form-view, and the document-view HEADER controls (my-document-view.html.template:60-127, partner likewise) carry none either - only the item dialog does since #7209.
The power form goes through baseFormPage.applyApiError (baseFormPage.js:67-75); the self-service pages never adopted it. This is the surface-parity pattern (#7136/#7137/#7153/#7152) one more time, on the page #7209 itself edited ten lines below.
Fix
Give the my/partner form and document pages an applyApiError that mirrors baseFormPage (namedProperty -> fieldError, messageWithLabels, else the refusal text, else the neutral fallback), bind :aria-invalid="fieldError === '<prop>'" on the header controls, and route the load/delete paths through apiErrors.refusalMessageFor. Adjacent nit: the power document dialog's Fill-Month input (perspective/document/document-view.html.template:738) lacks the :aria-invalid its siblings at 730/745 have, while the my-side copy #7209 made has it.
Found reviewing #7202 and #7209.
Summary
#7151 (#7202) made the shared
apiErrorshelper safe (a field is named only by a 400/409 refusal), #7152 (#7209) routed the personal/partner LINE DIALOGS through it, #7062 did the power form and dialog. The personal and partner pages' MAIN save paths were left out: the form save and the document HEADER save still assign the rawe.messageto the page banner, and their header controls bind noaria-invalidat all.Evidence (origin/master,
template-application-ui-harmonia-java/.../ui/)plus the delete/load paths in the same files (
my-form-page94/195,partner-form-page94/195,my-document-page148/254/524/550/592,partner-document-page138/244/439/478) andadmin/admin-index.html.template:246, 313, 329(this.error = String(e.message || e)).ApiError.messageIS the developer-facing text (api.js:25super(errorMessage || String(httpStatus || '')),:30this.errorMessage = errorMessage || ''; // dev-facing). So on a 500 the Hibernate/JDBC sentence lands verbatim in<div x-show="error" ... x-text="error">(my-form-view.html.template:41) - the #7151 leak - and on a 400 naming a field (The 'Name' property is required) the message is prose with no field marked:grep -c aria-invalid my-form-view.html.template= 0, same forpartner-form-view, and the document-view HEADER controls (my-document-view.html.template:60-127, partner likewise) carry none either - only the item dialog does since #7209.The power form goes through
baseFormPage.applyApiError(baseFormPage.js:67-75); the self-service pages never adopted it. This is the surface-parity pattern (#7136/#7137/#7153/#7152) one more time, on the page #7209 itself edited ten lines below.Fix
Give the my/partner form and document pages an
applyApiErrorthat mirrorsbaseFormPage(namedProperty ->fieldError,messageWithLabels, else the refusal text, else the neutral fallback), bind:aria-invalid="fieldError === '<prop>'"on the header controls, and route the load/delete paths throughapiErrors.refusalMessageFor. Adjacent nit: the power document dialog's Fill-Month input (perspective/document/document-view.html.template:738) lacks the:aria-invalidits siblings at 730/745 have, while the my-side copy #7209 made has it.Found reviewing #7202 and #7209.