updates lacks osc-qam's field selection (-F) and repeatable -G review groups

[plusky]

Reported by a user comparing mtui's updates with osc qam list:

MTUI (which directly uses the OBS request API) and osc-plugin-qam are not equivalent in functionality. MTUI's updates command lacks field functionality. For example, the command

osc qam list -G qam-sle -G qam-emergency -G qam-teradata \
  -F ReviewRequestID -F SRCRPMs -F Rating -F Products -F "Incident Priority" \
  -F Bugs -F "Unassigned Roles" -F "Assigned Roles" -F Package-Streams \
  -F Creator -F Issues -F Comments

Can we complete these fields in mtui -> updates?

The gap is real. Two separate gaps, in fact — field selection and repeatable -G — plus one correction to the premise that changes how expensive the fix is.

Current behaviour

crates/mtui-core/src/commands/updates.rs renders a fixed-width row with six hardcoded fields (render_row, :203-219):

let mut row = format!(
    "  prio={:<5} {:<10} {:<12} {:<11} {}",
    field("priority"),
    field("status"),
    field("kind"),
    deadline,
    field("id"),
);
if want_assignment {
    ... row.push_str(&format!(" assignee={assignee}"));
}

There is no -F/--field equivalent, no way to add a column, and no machine-readable output.

--review-group is also single-valued — no ArgAction::Append — so the reporter's -G qam-sle -G qam-emergency -G qam-teradata has no equivalent either. That one is small and independent of the field question.

Correction to the premise, because it drives the design

updates does not use the OBS request API. It queries TeReGen: teregen.updates(&query) (crates/mtui-datasources/src/teregen.rs:235-259), which returns the response's updates key as an opaque serde_json::Value array.

mtui does use OBS directly elsewhere, but crates/mtui-datasources/src/obs/qam.rs exposes only mutating QAM operations — comment, assign, unassign, approve, reject. There is no per-request field reader on the OBS side. So mtui has no existing path to fetch request-level attributes for a queue listing the way osc-plugin-qam does.

This matters: the two possible implementations differ by an order of magnitude in cost.

The first thing to determine

updates passes the TeReGen array through untouched and render_row reads only those six keys. Every other field in the response is silently discarded. So the cheapest possible outcome is that TeReGen already returns most of what the reporter wants and this is purely a rendering feature.

Someone with live TeReGen access should dump one /updates row verbatim and compare against the twelve requested fields. That single data point decides the shape of the work.

Field-by-field, best current guess

requested field	likely source	notes
ReviewRequestID	already present	rendered as id
Incident Priority	already present	rendered as priority
Rating	TeReGen / report metadata	rating exists in report metadata ("rating": "recommended"-style)
Products	TeReGen / report metadata	products exists in metadata
Bugs	TeReGen / report metadata	parsed today by ReducedMetadataParser
SRCRPMs	metadata packages or OBS	the metadata package map is a candidate; needs checking against what osc-qam means by SRCRPMs
Creator	OBS request	not a metadata field; the OBS request's creator
Issues	OBS request
Assigned Roles	OBS review state	osc-plugin-qam computes these from the request's per-group review list — genuinely OBS-side. mtui's assignee is a single string, not a role set
Unassigned Roles	OBS review state	same
Comments	OBS comments API	mtui can write a comment but has no read path
Package-Streams	TeReGen (SLFO)

So roughly: a few are free, several are plausibly already in the TeReGen payload, and four (roles ×2, Comments, Creator/Issues) need capability mtui does not have today.

Suggested shape

1. Determine what TeReGen already returns (above). Everything already in the payload is a rendering change and should land first — it is the bulk of the reporter's list for a fraction of the cost.
2. Add -F/--field as a repeatable arg plus --json for the machine-readable case. A fixed-width row does not scale to twelve columns anyway, and anyone passing twelve -F flags is almost certainly scripting. Accept the osc-qam field names as aliases so existing muscle memory and scripts transfer.
3. Make --review-group repeatable (ArgAction::Append), OR-ing the groups — independent of the rest and worth doing regardless.
4. For the genuinely OBS-side fields, decide between extending TeReGen to carry them (one query, server-side) versus per-row OBS fetches from mtui (N requests per listing, slow on a large queue, and needs a new read path in obs/qam.rs). The TeReGen route looks strongly preferable for a listing command; the OBS route may still be right for a single-RRID detail view.

Worth noting for scoping: full parity is not obviously the goal — osc qam list and mtui updates have different default views (mtui defaults to the unassigned in-testing pickup queue). The reporter's ask is field availability, which does not require adopting osc-qam's output format.

[plusky]

Investigated against live TeReGen (2026-08-02, 144 queue rows) — the split the issue suspected is confirmed, and stage 1 is now PR #420.

What /updates already carries (was pure rendering work): id, priority, rating, category, status, kind, deadline, assignee, assignees ({group: [{state, user}]}), review_groups (Maintenance rows only), title (SLFO only), url. So ReviewRequestID, Incident Priority, Rating, plus derivable Assigned Roles/Unassigned Roles — five of the twelve requested fields, landed in #420 as -F with osc-qam names, along with repeatable -G and --json.

Two server behaviors that shaped the implementation, verified live:

• A repeated review_group param is not OR-ed — the last one wins (qam-sle&qam-teradata → 8 rows, reversed → 120). So -G a -G b fans out as one query per group, merged.
• The server-side group filter matches SLFO rows (47 under qam-sle) even though SLFO rows never serialise review_groups — client-side filtering cannot replicate it, and Unassigned Roles on SLFO rows is unknowable to a client. Rendered as n/a.

Also: without with_assignment=1 TeReGen omits assignee/assignees on SLFO rows specifically, so -F Assignee under --status all would print a false "unassigned" for an assigned row. #420 refuses that combination rather than printing blanks that read as facts.

The remaining seven fields (Products, SRCRPMs, Bugs, Package-Streams, Creator, Issues, Comments) are genuinely absent from the payload. Two routes:

1. TeReGen enrichment — filed as qa-maintenance/teregen#1, together with the SLFO review_groups serialisation gap above. One server-side query, backed by data SMELT largely has; the right shape for a listing.
2. An OBS read path in mtui — obs/qam.rs is write-only today; reading per-request data means N+1 OBS round-trips per listing (144 rows → 144+ requests), which is exactly why osc qam list is slow. If it ever lands, it belongs behind a single-RRID detail view, not the queue listing. (Comments and Creator are only reachable this way.)

Keeping this issue open for the stage-2 decision; -F names for the missing fields already error with a pointer here, so the surface is forward-compatible with either route.