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.

1. 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.

2. 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

3. 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.

4. 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.)

4.1. 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.

4.2. 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.

5. Notes

6. 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
     

7. PRs

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

8. Review

Comment summary File Decision Notes
       

9. 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)