feat(template): personal document layout + owner-name on the My surface#6271
Merged
Conversation
…y surface
A MANAGE_DOCUMENT entity with a personal owner now renders on the personal (My) surface as a
DOCUMENT - header form + inline line-items table (add/edit dialog) + status pill + totals footer -
instead of the plain my-form, scoped to the <Entity>MyController (header) and <Item>MyController
(items, the personal one-hop). Item metadata is reused from detail-register (App.detailsFor); item
DATA goes through the personal controller so ownership + sensitive-field stripping are enforced.
- generateUtils: new personalDocumentModels collection (MANAGE_DOCUMENT + personal); document roots
excluded from the plain personalModels form.
- my.js: my-document-page.js + my-document-view.html for personalDocumentModels.
- index.html routing/scripts: /my/<Doc>/create|edit -> the document editor for document roots.
- Owner name ("New/Edit <Doc> for <owner>"): EdmIntentGenerator emits the identity target's label
field (relationshipIdentityLabel); parameterUtils propagates personalIdentityLabel; the personal
controller gains GET /me returning only the display name; the document page shows it in the title.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…ersonalFormModels for the UI form The first cut excluded document roots from personalModels, but rest-java generates the personal <Entity>MyController from personalModels too - so a personal document lost its REST controller (404). Restore personalModels (roots keep their MyController + list + perspective); add a separate personalFormModels (personal minus document roots) that only the plain my-form UI uses. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…t detail-column fields The my-document page read the item metadata with the wrong field names and resolved it too early: detail-register publishes editColumns with col.name (not col.key) and lookup.text (not .value), and its registration script runs AFTER the page's init - so App.detailsFor returned nothing and the items table rendered empty (though the header aggregates were correct). Resolve itemsDef lazily (def()) and use col.name / col.lookup.text throughout. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
… param The child items MyController.getAll requires ?<masterEntityId>=<id> (and enforces ownership); without it it returns an empty list. loadItems now passes it instead of fetching the whole list and filtering client-side. Verified live: the ExpenseClaim document shows its item rows + totals. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…pre-load options) Load the item lookup options in loadItems (not only on dialog open) so the items table shows the Category/Supplier/TaxRate labels on first render instead of raw FK ids. Verified live. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Gives the personal (My) surface a document layout for
function: Documententities with a personal owner — the third item from the personal-surface review, plus the "for<owner>" title (item 2).What
A
MANAGE_DOCUMENTentity that also has a personal owner now renders on the My surface as a document — header form + inline line-items table (add/edit dialog, per-row delete) + status pill + totals footer — instead of the plain my-form. It is scoped to the<Entity>MyController(header) and<Item>MyController(items, the personal one-hop), so ownership + sensitive-field stripping are enforced server-side. Item column metadata is reused fromdetail-register(App.detailsFor); item data goes through the personal controller.personalDocumentModels(MANAGE_DOCUMENT ∧ personal) +personalFormModels(personal minus document roots).personalModelsis unchanged, so rest-java still generates theMyController; only the UI form is swapped for the document layout.my-document-page.js+my-document-view.htmlforpersonalDocumentModels./my/<Doc>/create|edit→ the document editor for document roots.EdmIntentGeneratoremits the identity target's label field (relationshipIdentityLabel);parameterUtilspropagatespersonalIdentityLabel; the personal controller gainsGET /mereturning only the display name; the document/for <owner>title renders it.Verified live
Regenerated
kf-mod-expenses(its remodeledExpenseClaimis a personal document) and drove the My shell: the document renders with title "Edit Expense Claim EXP0000001 for Administrator", a DRAFT pill, header form, an items table (Hotel 200/40/240 + Taxi 40/8/48 with add/delete), and a totals footer (240/48/288)./mereturns{"name":"Administrator"}.Known limitation
Lookup columns in the items table show the raw FK id until the dialog first loads the options (the table doesn't pre-load lookup options) — a small polish follow-up. The dialog resolves them correctly.
🤖 Generated with Claude Code