Qt to web reference data matrix

The Qt side is read from ores.qt/refdata. An entity exists where a <Entity>MdiWindow, a <Entity>DetailDialog or a Client<Entity>Model exists. The fields of a dialog are the members of the entity struct that the dialog source reads into widgets or writes back from them. The widget names are not read, because they differ from the wire names and because some dialogs build their combo boxes in code. The columns of a list are the struct members its model returns for the display role. The actions are the toolbar actions the window adds.

The web side is read from the registries: REFDATA_RECORDS and CLASSIFICATION_LISTS in the wire protocol package, the convention kinds in conventionKinds.ts, and the FieldSpec[] table beside each record screen. A Qt entity is matched to a web surface by its entity type, such as ores.refdata.currency. An entity the registries do not name is matched by hand in the script, with the surface that covers it.

Three kinds of field are not counted as a gap. The provenance fields (version, modified_by, performed_by, recorded_at, the change reason and commentary) are read by every web screen and asked of no one, per the Record screen standard. A parent key such as calendar_code is implied by the address of a part. A party_id is the party scope the web lists under. The script names each such field and the standard section that explains it.

Qt fields and web fields are the counts after the provenance fields are removed. A field only in Qt is a candidate gap. A field only in the web is something the web added. A blank web count means the web surface has no field table to compare, because the entity is reached from another area, exists in the registry only, or is not there.

Every Qt list window had the same toolbar: Reload, Add, Edit, Delete and History. Every dialog had the same shape: a tab widget with a General tab and a Provenance tab, a Save, a Delete and a Close button. Currency alone split its fields over four tabs: General, Formatting, Rounding and Provenance. The table lists the windows that added to that standard or lacked part of it.

The shared history dialog showed a timeline of versions on the left and, on the right, two combo boxes to choose the versions to compare, a toggle between all fields and only the changes, and the difference as text.

• Children on the record page. The currency page has countries, calendars and groups tabs. The party page has identifiers, contacts, memberships, centres and counterparties tabs. The Qt currency window had no children at all.
• Every classification carries a display_order, and the two lists that Qt kept as code and description only carry a name.
• The party carries transliterated_name, codename, party_category and is_registration_default. The contact carries is_primary.
• The currency carries ore_currency_type, spot_days, day_basis and base_precedence. The calendar carries an image_id.
• The convention screen knows 26 kinds, and Qt had dialogs for 9. Tenor basis swap, which is one of the three kinds with editable terms, had no Qt dialog at all; nor did the FX, inflation, commodity and bond kinds.
• Workflows on the list header, and the change notification that turns Refresh gold, which Qt did not have.

A gap is a Qt field or part that a person could use and the web does not offer. Each row says what the pipeline must decide.

These Qt parts are absent from the web because a standard section replaces them, and the pipeline does not bring them back.