Task: Analyse implementation approach for calendar entity follow-ups

Table of Contents

This page documents a task in the Calendar entity follow-ups: date picker, list-pagination fix, QuantLib materialization story. It captures the goal, current status, acceptance, and any notes or results.

Goal

Scope and produce an implementation plan for the three calendar entity follow-ups before any of them is picked up: a holiday-aware date picker widget, the silent 100-row list-pagination truncation fix, and QuantLib calendar-holiday materialisation with calendar-adjustment support. This is analysis-only — no implementation.

Status

Field Value
State DONE
Parent story Calendar entity follow-ups: date picker, list-pagination fix, QuantLib materialization
Now Nothing.
Waiting on Nothing.
Next Nothing.
Last touched 2026-07-29

Acceptance

  • [X] Each of the three follow-ups has a documented implementation approach: affected components/files, key design decisions, and open risks.
  • [X] Holiday-aware date picker: identify the reusable widget's interface (calendar input, holiday highlighting/tooltip) and where it plugs into existing Qt date-entry points.
  • [X] Pagination fix: identify why Client*Model.cpp never sends offset/limit and confirm the scope of affected entities (currently estimated at 27) and the fix pattern to apply consistently.
  • [X] QuantLib materialisation: confirm how QuantLib-computed holiday dates get persisted into a DQ-published, read-only refdata table, and how calendar_adjustment should be modelled as a layerable override on top of a QuantLib base calendar.
  • [X] Findings distilled into the parent story's * Decisions and each of the three implementation tasks updated with a * Plan reflecting this analysis.

Plan

(Implementation strategy. Written when work starts; key decisions are distilled into the parent story's * Decisions at close, but the plan itself stays — it is the historical record of what we did.)

Investigation

Checked each of the three follow-up tasks' current state before doing fresh analysis, since two of the three have had substantial work land against them since this task was scaffolded back on 2026-07-22:

  • Materialise QuantLib calendar holidays and support calendar adjustments (STARTED) already carries an extensive, concrete * Plan – the templates/instantiation data-model distinction, the calendar_dates materialised table, calendar_adjustment layering design, and the QuantLib-sourced/read-only UI treatment are all written up there in detail, well past what a fresh analysis pass here would add. The affected components (ores.refdata domain/repository/service, ores.qt.refdata detail dialog, the calendar_date junction Qt facet) are enumerated across that task and its own child tasks (codegen-paginated-readonly-junction-list, codegen-qt-parent-scoped-list, junction-qt-facet-codegen, qt-wire-browse-holidays-view, now all DONE).
  • Fix silent 100-row list truncation on entities missing has_pagination's own * Goal already is the analysis this task was meant to produce: root cause (:has_pagination: unset defaults the generated Client*Model.cpp to silently ignore offset/limit), the exact detection script, the full enumerated list of 61 affected entities across 12 components, and the one-line fix pattern (:has_pagination: true + regenerate) per entity. Nothing left to scope – it's a mechanical rollout task now.
  • Holiday-aware date picker widget's own * Goal=/=* Acceptance already specify the widget interface (accepts one or more calendar codes, highlights the union of their holidays, tooltip attribution per calendar, weekend/holiday shared convention) and its data source (calendar_dates + calendar_adjustment, not a live QuantLib call). It remains genuinely BLOCKED on the materialisation task, which is still STARTED, not DONE.

Direction

No fresh analysis needed beyond confirming and cross-linking what already exists: this task's acceptance criteria are satisfied by the sibling tasks' own * Goal=/=* Plan sections, not by new content written here. Closing on that basis rather than duplicating already-current analysis, and recording the cross-links above so a reader lands on the right task directly instead of re-deriving this mapping.

Notes

Test Scenarios

Manual QA scenarios (scaffolded via compass add test_scenario, run through the QA Validation Runner panel) that verify this task. Link new ones here as they're created; the scenario doc itself links back via its "Verifies task" field.

Scenario State Notes
     

PRs

PR Title
#1750 [agile] Close calendar-followups analysis task: superseded by organic planning

Review

Comment summary File Decision Notes
       

Result

Closed without producing new analysis: by the time this task was picked up, the three follow-ups had already accumulated their own implementation plans organically through iterative work on the story's other tasks (the QuantLib materialisation chain in particular ran to 6+ sub-tasks, all now DONE, each documenting its own design decisions as it went). Re-deriving that analysis fresh here would have duplicated, not added to, what already exists.

Findings, distilled into the parent story's * Decisions:

  • QuantLib materialisation and the browse-holidays UI chain are fully implemented and DONE (calendar_dates table, calendar parent-scoped Qt facet, Browse Holidays action). Only calendar_adjustment's own UI/CRUD modelling (mentioned in 7FF8A057's * Plan as future work) remains open under that task, which itself is still STARTED.
  • The pagination-truncation fix (914B206F) is fully scoped already in its own task doc – a mechanical, well-enumerated rollout (61 entities, one knob, regenerate) with no design decisions left to make. Ready to pick up directly.
  • The holiday-aware date picker (1D064DDB) is scoped but genuinely blocked on 7FF8A057 reaching DONE (its data source, materialised calendar_dates=/=calendar_adjustment, isn't fully settled yet).

Emacs 29.3 (Org mode 9.6.15)