Story: Migrate ores.qt.refdata onto the generic HistoryDialog

Table of Contents

This page documents a story in Sprint 23. It captures the goal, current status, acceptance criteria, and the tasks that compose it.

Goal

Every ores.qt.refdata entity's history view is the single generic HistoryDialog widget (built in Consolidate history dialogs onto HistoryDialogBase's task 7D8659AB, currently wired for currency only) constructed with (entity_type, entity_id), with no remaining hand-rolled per-entity *HistoryDialog class anywhere in ores.qt.refdata. Each entity's migration retires its own dialog (class + .ui) and adapts its controller's Open/Revert handling to the (entity_type, entity_id, version) generic signal shape, following exactly the pattern task 7D8659AB established for currency (CurrencyController, PR #1553): resolve the generic signal back to a typed domain object via that entity's own existing typed history/get request, preserving full version-nav.

This story was originally scoped to every ores.qt component; it has been narrowed to ores.qt.refdata only — too open-ended otherwise. Every other component's migration now has its own backlog capture (see Out of scope) so each can be sized, prioritised, and scheduled independently.

Once every ores.qt.refdata entity has migrated, this story contributes (alongside every other component's own migration, once commissioned) to unblocking Retire HistoryDialogBase, per-entity dialogs, and their templates (in the sibling story above) — that task deletes HistoryDialogBase itself and the per-entity codegen templates once nothing depends on them anymore, which requires every component, not just refdata, to have migrated.

Status

Field Value
State DONE
Parent sprint Sprint 23
Now Nothing.
Waiting on Nothing.
Next Nothing.
Last touched 2026-07-18

Acceptance

  • Every entity in ores.qt.refdata listed in * Tasks below has migrated from its hand-rolled per-entity *HistoryDialog to the generic HistoryDialog widget.
  • Every migrated entity's controller resolves Open/Revert via the entity's own typed history request, matching the currency pattern from PR #1553 — no typed domain payload crosses HistoryDialog's signals.
  • Zero remaining *HistoryDialog.{hpp,cpp,ui} files anywhere in projects/ores.qt/refdata once every task below is DONE.

Tasks

Task State Start End Description
Migrate ores.qt.refdata's history dialogs to the generic HistoryDialog DONE 2026-07-15 2026-07-16 Retire the 43 hand-rolled *HistoryDialog classes in projects/ores.qt/refdata, wiring each entity onto the generic HistoryDialog and adapting its controller's Open/Revert to the (entity_type, entity_id, version) signal shape, following the currency pattern from PR #1553.
Update ores.cpp.qt codegen templates for the generic HistoryDialog DONE 2026-07-14 2026-07-14 Update the cpp_qt_controller and cpp_qt_history_dialog mustache templates so regenerating any entity emits the generic HistoryDialog wiring instead of a per-entity *HistoryDialog class, with currency regenerating to zero-diff as the proof.
Fix Windows link error: HistoryDialog missing ORES_QT_API export DONE 2026-07-14 2026-07-14 ores.qt.refdata.dll fails to link on MSVC because HistoryDialog never got the ORES_QT_API export macro every other ores.qt.api class carries.
Delete per-entity history-dialog codegen archetypes and reconcile dynamic_combo drift DONE 2026-07-14 2026-07-15 Delete outright (not just disable) the deprecated per-entity history-dialog codegen archetypes, and resolve the dynamic_combo detail-dialog codegen drift found while regenerating currency for task 257F85B2.
Migrate remaining ores.qt.refdata entities without a codegen model onto the generic HistoryDialog DONE 2026-07-17 2026-07-18 Re-scoped on pickup from 17 to 2 entities (floating_index_type, leg_type) – the other 15 turned out to already be out of ores.qt.refdata (payment_frequency_type was a naming error for an already-migrated entity; the 14 DQ-owned entities had already moved to ores.qt.data_management, now tracked under the DQ commissioning story instead). Both have an existing ores.trading codegen model and migrate via the same full-regeneration process as every other entity in this story.
Move ores.dq-owned entities from RefdataPlugin into a new ores.qt.data_management plugin DONE 2026-07-16 2026-07-16 14 entities owned by ores.dq (catalog, change_reason, change_reason_category, code_domain, coding_scheme, coding_scheme_authority_type, data_domain, dataset, dataset_bundle, methodology, nature_dimension, origin_dimension, subject_area, treatment_dimension) currently live in RefdataPlugin's Qt UI despite having no ores.refdata backend at all. Repurpose the existing empty ores.qt.data_transfer plugin stub into ores.qt.data_management (matching the 'Data Management' menu label already used in RefdataPlugin's code) and move these entities' controllers, menus, and the Data Librarian window there, correcting the component-ownership mismatch before any HistoryDialog migration work on them.

Decisions

  • Migration happens by updating the shared ores.cpp.qt codegen templates once (task 257F85B2), not by hand-migrating each entity's controller individually — hand-migrating currency first (PR #1553/#1563) was the right initial proof, but repeating that by hand across 60+ entities would just recreate the same manual, uncodegen'd divergence 60+ more times. Discovered when starting the migrate-refdata-history-dialogs task: compass codegen entity generate currency --diff showed currency's own controller as a manual divergence from what the templates still produced.
  • No template-level gating on whether an entity has a server-side history field mapper yet: the template always emits the generic- HistoryDialog wiring. An entity without a mapper gets a graceful "no history" response at runtime (the dispatch registry's existing unknown-entity_type handling) until its own commission story adds the mapper — simpler than threading a new model flag through every entity, and no entity is worse off than before (it had no working history dialog either way, since the per-entity dialog's compile path for has_version_navigation was itself dead code — see the template task's Notes).
  • Per-component migration tasks proceed one entity at a time, reviewing each regeneration's diff before committing — if an entity's diff is unexpectedly large (structural incompatibility, not just cosmetic), skip it and record it as drifted rather than forcing it through.

Out of scope

Emacs 29.3 (Org mode 9.6.15)