Separate trade and instrument detail dialogs
Table of Contents
This page is a capture in the next bucket of the product backlog — a pre-sprint idea, not yet pulled into a sprint as a story.
1. What
Split the current combined trade-plus-instrument details dialog into two separate detail dialogs — one for the trade, one for the instrument — and work out how a user navigates from one to the other. The navigation mechanism is the open design question and deserves a brainstorm session on idiomatic patterns in trading systems before committing to a design. Candidate patterns to seed the brainstorm:
- A button/link in trade details that opens the linked instrument details (the simplest option).
- Hyperlinked entity references: any field that is a soft FK (instrument_id, book_id, portfolio_id, party_id) renders as a navigable link — the pattern generalises beyond trade/instrument.
- Master-detail drill-down: instrument opens as a nested tab or panel inside the trade window rather than a separate top-level window.
- Blotter-style navigation: trade blotter row → trade details → "View Instrument" action, with breadcrumbs to step back.
- A shared "related entities" sidebar listing all linked entities of the focused record (what OMS/EMS front-ends often do).
2. Why
The combined dialog tries to display two distinct aggregates in one
window, which crowds the UI and couples the dialogs' lifecycles.
Now that instruments are first-class (own tables, own NATS
messages, own forms per type — see the C1202 nested-structs work),
a dedicated instrument details dialog is natural, and the
trade dialog gets simpler. The trade→instrument soft FK
(classification.instrument_id / identity.trade_id) already
provides the navigation key in both directions.
3. References
- Story: Fix rfl complexity failure (Windows + macOS CI) — instrument decomposition that makes instruments first-class.
4. See also
- Story: Consolidate history dialogs onto HistoryDialogBase — parallel effort to rationalise dialog architecture.