Make badges a first-class entity with a colour-editing UI
Table of Contents
This page is a capture in the discarded bucket of the product backlog.
Resolved (deep backlog refinement, 2026-07-11): Confirmed ores.dq.badge_definition/badge_severity already have generated Qt UI: BadgeDefinitionController and BadgeSeverityController exist (projects/ores.qt/admin/src/) and are wired into AdminPlugin.cpp (lines 149-153). Also confirmed BadgeCache (projects/ores.qt/api/src/BadgeCache.cpp) fetches badge definitions/mappings from the server via get_badge_definitions_request and is consumed broadly across the app (CurrencyMdiWindow, BookMdiWindow, PartyMdiWindow, PortfolioMdiWindow, TenantMdiWindow, OreBadgeComboBox, etc.) — indicating badge_definition already is the live source of truth for rendered badges, not a hardcoded catalogue, and an editing UI already exists.
What
Badges (the coloured pills used throughout the Qt UI for status/severity
indicators — currency market tier, party status, book status, etc.)
should be user-editable reference data, not a fixed catalogue baked
into the app. ores.dq.badge_definition (colours, label, severity) and
ores.dq.badge_severity already exist as real codegen entities with a
generated Qt UI (BadgeDefinitionController=/=BadgeSeverityController,
wired into AdminPlugin.cpp) — worth checking, before scoping any
work, whether that existing UI already covers "users can change their
colours", or whether the badges actually rendered elsewhere in the app
(currency, party, book, etc.) are hardcoded (e.g. via BadgeCache=/
=IconUtils convention) rather than actually reading their colour from
badge_definition rows — in which case the entity/UI exists but isn't
the real source of truth for what users see, and that's the actual gap
to close.
Why
Hardcoded badge colours mean any branding/accessibility/preference
change requires a code change and a release, instead of an admin
simply editing a reference-data row like they already can for rounding
types or market tiers. If badge_definition already exists precisely
for this and just isn't wired end-to-end as the actual colour source,
that's a comparatively small integration gap rather than new entity
work — worth confirming which case this is before estimating.
References
- Badge system wiring (knowledge doc)
- Badge catalogue (knowledge doc)
- ores.dq.badge_definition (existing codegen entity model)
- ores.dq.badge_severity (existing codegen entity model)
See also
- Persist tag colour and tag dialog — related capture on user-editable colour for a different UI concept (tags, not badges).