fix(intent): a view is an additional page, not a replacement — and a document's calendar line items render (#6547, #6482)

[delchev]

Closes #6547. Closes #6482.

Three ways a view: declaration silently cost the author something. All are the same failure class — the attribute parses, the generation is green, and the promise is simply absent from the running app.

#6547 — the calendar replaced the entity's layout

view: calendar|range was emitted as layoutType: MANAGE_CALENDAR, which overrode whatever layout the entity had resolved. For a function: Document master that meant losing the document surface entirely: line items, Print, inline process tasks (approvals fell back to the Inbox). Authors had to choose between the calendar and the document.

The calendar is now an additional page. EdmIntentGenerator emits the entity attribute calendarView and leaves layoutType at the natural MANAGE / MANAGE_MASTER / MANAGE_DOCUMENT, so every page that layout brings still exists. The landing route stays where it always was — no behaviour change for existing calendar apps — and the layout's own browse page moves down one segment:

Route	Page
/<Entity>	the calendar
/<Entity>/list	the layout's list / master / document list
/<Entity>/create, /<Entity>/:id/edit, /:id/preview	the layout's own editor — the document page for a document master

Both browse pages carry a switch to the other (goCalendar() / goList()); the personal surface mirrors it (/my/<Entity> calendar, /my/<Entity>/list list, so personalListModels no longer excludes calendar roots). calendar.js no longer emits the shared manage form — the layout owns it.

view: slots gets the same treatment (second commit). It was initially left replacing the layout on the argument that a picker is an authoring surface rather than a second way to browse — which does not survive contact with a booking document: the picker is how a booking is created, the document page is how it is worked with afterwards, and an author needs both. So slotsView replaces layoutType: MANAGE_SLOTS, slots.js stops emitting the shared form, and slot-click on a document master now lands on the document create page prefilled with the chosen datetime. /<Entity> is the picker, /<Entity>/list the layout's browse page, with a Slots⇄List toggle pair. Nothing about a view replaces a layout any more.

MANAGE_CALENDAR (and MANAGE_SLOTS) is gone from every consumer (uiCalendarModels / personalCalendarModels now key on calendarView; the shell template, calendar.js and the AppTest manifest's layout token follow). It was intent-only and never offered by the entity editor, so no hand-authored .edm can still carry it.

#6482 — a document's calendar line items rendered nothing

The line-items child declaring view: calendar emitted its panel markup and was then filtered out of secondaryDetails by name — correct on its own terms (the items have their own section), but it meant the calendar could only ever apply to a secondary child, and the declaration produced nothing at all.

The issue's option 1: the items pane honours it. The master now carries documentItemsLayout: calendar, derived from the child (the calendar: config belongs to the child, so it is never authored on the master), and the pane renders as an x-h-calendar on all three document surfaces (power, personal, partner): the same rows and the same line dialog — event-click edits that line, empty-day click adds one with the date preset, and Delete moves into the dialog since a calendar has no per-row menu. Mutually exclusive with documentItemsLayout: chat (both claim that pane), parser-rejected with a message naming both.

The row→event mapping is now one shared implementation — application-core/shell/js/services/calendarEvents.js (window.HarmoniaCalendar) — rather than a third, fourth and fifth copy of the Jackson java.time normalization. The calendar's own configuration is read at runtime from the child's detail registration, so the document page still never enumerates the child at generation time.

Verification

• Unit: 343 green in engine-intent, including the rewritten documentMasterWithACalendarViewKeepsTheDocumentLayoutAndAddsTheCalendar, a new documentWhoseItemsChildIsACalendarRendersTheItemsPaneAsACalendar, and chatDocumentRejectsAnItemsChildThatIsAlsoACalendar.
• IntentEngineIT: 39 green.
• IntentEmissionCoverageIT (the emission oracle) green with new assertions: the /Leave calendar landing route, /Leave/list, /Leave/create, /my/Leave/list, both toggles, and the items calendar on the power and personal document surfaces (x-h-calendar="itemsCalCfg", HarmoniaCalendar.events, itemsDef.calendar, the dialog Delete, and the items table gone). The fixture gained a Roster / RosterItem document pair for it.
• Live instance: generated + published a fixture app (a Document + view: calendar, and a document whose items child is a calendar) — 0 problems for the project, health Ready, and the generated shell carries /Booking → calendar, /Booking/list → the document list, /Booking/:id/edit → the document editor, plus Roster-document.html with the items calendar.
• mvn formatter:validate clean; the release-profile javadoc build clean.

A defect this surfaced, worth calling out

Extending the rule to slots made a mistake in the first commit obvious: navigation.js's PERSPECTIVE_COLLECTIONS listed uiCalendarModels / uiSlotsModels alongside the layout collections. Once a view entity keeps its layout it is a member of both, so its perspective was generated twice — the same rename path written twice and a duplicate application-perspectives contribution. Harmless on disk (identical content overwriting itself) but wrong; both view collections are dropped from that list, since a view entity is always in exactly one layout collection. Verified after the fix: exactly one perspectives/<Entity>/ per entity in the generated app.

Verified in a browser

Both views were driven end to end on a local instance against a generated + published fixture app (0 problems, health Ready), with no console errors:

• items calendar — the pane paints the day-events with FK-resolved titles; event-click opens Edit line on that row with the dialog Delete, empty-day click opens Add line with the date preset. Header, totals and Print untouched.
• calendar — /<Entity> lands on the calendar with a List toggle, /<Entity>/list shows the document list with a Calendar toggle, and the event-click opens the document editor.
• slots — /<Entity> lands on the 3-day picker (honouring open/close/step) with a List toggle; a free slot opens /<Entity>/create?<Start>=… on the document editor, and the saved record's edit page carries Visit Items + Add, the totals footer and Print — exactly what a slots entity used to lose.

The partner document surface is a mechanical mirror of the personal one and is not separately asserted (the fixture has no partner-owned document).

[delchev]

Verified in a browser as well (the layer the emission oracle cannot reach), against a local instance with a generated + published fixture app — a function: Document master declaring view: calendar, and a second document whose line-items child declares it:

#6482 — the items pane (#/Roster/1/edit): the pane renders as the calendar with the three day-events placed on their dates, each titled through the FK lookup ("Ada Lovelace", not a raw id); the document header, the totals footer (Hours 24.00) and Print are untouched. Clicking an event opens Edit line on that row (Day 12/08/2026, Hours 8, Person) with the dialog Delete; clicking an empty day opens Add line with Day preset to that day (19/08/2026) and no Delete.

#6547 — the additional page (#/Booking): the nav entry still lands on the calendar, now with a List toggle; #/Booking/list shows the document list (a page that did not exist for a calendar entity before) with a Calendar toggle back; and clicking the calendar event opens the document editor — header form, Booking Items table with Add, totals footer, Print — where it previously opened the plain manage form.

No console errors or exceptions on either page.