[GFI] Generate Individual Entity Labels #182

Activity

1. roncodes

   added

   enhancementNew feature or requestNew feature or request

   good first issueGood for newcomersGood for newcomers

   help wantedExtra attention is neededExtra attention is needed

   on Oct 30, 2025
2. janni1288 commented on Aug 2, 2026

   

   janni1288

   on Aug 2, 2026

   Contributor

   More actions

   Hi @roncodes, I've been working on this issue. As a first step I found and fixed a bug in the existing entity label template - merged in #280.

   For the remaining frontend piece ("Update UI to allow selecting 'View Label for Entity'"), my plan is to add a "View Label" button directly on the Entity card ('entity/card.hbs'), next to the existing Edit/Delete actions, calling the exisiting 'labels/{id}?type=entity' endpoint (which already renders a single entity without pulling it siblings at the same destiations).

   Before I open a PR - is that a placement you had in mind, or would you prefer it somewhere else (e.g. a dedicated action menu, or inside the order tracking view)?
3. roncodes commented on Aug 3, 2026

   

   roncodes

   on Aug 3, 2026

   MemberAuthor

   More actions

   @janni1288 sorry for the slow reply here — answering your placement question properly.

   Entity card next to edit/delete is the right spot. That's what you went with in #283, so no change needed. It mirrors how the waypoint label button sits inline in the payload list rather than behind a separate menu, and it keeps the action next to the resource it acts on.

   On the acceptance criteria, so the remaining scope is clear:

   • "Labels show only the selected entity and its destination" — done. The type=entity path resolves a single Entity and renders fleetops::labels/entity-label from that record alone, so siblings at the same destination aren't pulled in.
   • "Works consistently across multiple entity types" — you can consider this covered. Entity::label() renders one view for every entity type with no per-type branching, so there's a single render path, and your fix in fix(labels): correct entity label to use entity data instead of stale waypoint/order fallbacks #280 is what made it correct.
   • "Generated labels render correctly as PDF or print views" — the endpoint already serves stream, pdf, text and base64, and LabelPdfRenderingTest pins Entity to the shared UTF-8 renderer. That's the wiring, not the visual output, so this is the one criterion still resting on your manual check rather than on a test.

   Review notes are on #283. Two things needed changing — the new labels route wasn't needed since orders/label/{id} already handles type=entity internally, and reviewing it surfaced an unrelated cross-tenant leak in the label lookups that I've fixed in the same PR. Details there.

   Thanks for picking this one up and for splitting the template fix out into #280 first — that was the right call.
4. roncodes

   closed this as completedon Aug 3, 2026