Feat/labelmaker optional location assetid - #1620
Conversation
Adds HBOX_LABEL_MAKER_HIDE_LOCATION and HBOX_LABEL_MAKER_HIDE_ASSET_ID so operators who don't find those fields useful can free up label space without needing a GUI settings page. When the asset ID is hidden, the item name is promoted to the bold headline instead of being left blank. Suggested and specced by Cosmo. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XoM8uYDeQmNxy11vj4TZts
HideAssetID can leave a label's description empty (no location, no
asset ID line). If the promoted item-name title then wraps to enough
lines to exceed the QR code's height, wrapText("") hit a slice bounds
panic: byte-offset bookkeeping used to compute the "leftover text"
return value could walk past len(text), producing text[i:] with
i > len(text). Reported and reproduced live by Cosmo running the
HideAssetID build on real hardware.
Clamp the offset before slicing, and add regression tests at both the
wrapText and GenerateLabel level covering the exact crash.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XoM8uYDeQmNxy11vj4TZts
Summary by CodeRabbit
WalkthroughLabel generation now supports hiding locations and asset IDs through configuration. Text wrapping clamps offsets to prevent panics, with regression tests covering empty descriptions and asset label generation. Environment variable documentation describes the new options. ChangesLabelmaker behavior
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant Client
participant HandleGetAssetLabel
participant LabelMakerConf
participant GenerateLabel
Client->>HandleGetAssetLabel: request asset label
HandleGetAssetLabel->>LabelMakerConf: read HideAssetID and HideLocation
HandleGetAssetLabel->>GenerateLabel: pass computed title and description
GenerateLabel-->>Client: return generated label
Possibly related PRs
Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches✨ Simplify code
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
🧹 Nitpick comments (1)
backend/app/api/handlers/v1/v1_ctrl_labelmaker.go (1)
141-142: 🔒 Security & Privacy | 🔵 Trivial | ⚡ Quick winSecurity Recommendation: Mitigate potential Denial of Service (DoS) via large inputs.
Since label generation involves intensive text measurement (glyph-by-glyph) and string allocations in
wrapText, processing exceptionally largetitleordescriptionstrings could consume excessive CPU and memory.Ensure that the underlying
asset.Nameandasset.Parent.Namefields are strictly length-bounded at the database/validation layer. If they are not, consider truncating the text within the label-generation handlers before passing it togenerateOrPrintto prevent resource exhaustion from maliciously large inputs.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@backend/app/api/handlers/v1/v1_ctrl_labelmaker.go` around lines 141 - 142, Ensure asset.Name and asset.Parent.Name are strictly length-bounded through existing database or validation mechanisms before label generation. If no such bounds exist, truncate the title and description in the handler flow before calling generateOrPrint, preserving normal inputs while preventing excessively large text from reaching wrapText.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@backend/app/api/handlers/v1/v1_ctrl_labelmaker.go`:
- Around line 141-142: Ensure asset.Name and asset.Parent.Name are strictly
length-bounded through existing database or validation mechanisms before label
generation. If no such bounds exist, truncate the title and description in the
handler flow before calling generateOrPrint, preserving normal inputs while
preventing excessively large text from reaching wrapText.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 67f15e02-b54c-4a54-8fd8-5520a27d87de
📒 Files selected for processing (5)
backend/app/api/handlers/v1/v1_ctrl_labelmaker.gobackend/internal/sys/config/conf.gobackend/pkgs/labelmaker/labelmaker.gobackend/pkgs/labelmaker/labelmaker_test.godocs/src/content/docs/en/quick-start/configure/index.mdx
Suggested and specced by Cosmo.
Claude-Session: https://claude.ai/code/session_01XoM8uYDeQmNxy11vj4TZts
What type of PR is this?
What this PR does / why we need it:
Adds HBOX_LABEL_MAKER_HIDE_LOCATION and HBOX_LABEL_MAKER_HIDE_ASSET_ID so users who don't find those fields useful can free up label space without needing a GUI settings page. When the asset ID is hidden, the item name is promoted to the bold headline instead of being left blank.
Which issue(s) this PR fixes:
While implementing this feature, a pre-existing bug was encountered and also fixed.
wrapText in backend/pkgs/labelmaker/labelmaker.go had a latent off-by-one bug in its overflow handling: when
word-wrapping determined that a line wouldn't fit in the remaining vertical space, it returned the "leftover" text
via text[processedChars:], where processedChars is a running byte count built up while walking the string. That count
could exceed len(text) whenever the overflow was detected on the string's final line — most easily triggered by an
empty string, where processedChars becomes 1 on the very first iteration while len(text) is 0, producing a slice
bounds out of range [1:0] panic. This was always theoretically reachable (e.g. an item with no location and a long
enough name), but was rare in practice because the description text was almost never empty. The new HideAssetID
option changes that: it promotes the item name to the bold title slot and can leave the description as "" when
there's also no location, so a sufficiently long item name (long enough that its wrapped title lines consume the QR
code's full height) reliably triggers the panic on every request for that asset's label. Fixed by clamping the
computed offset to [0, len(text)] before slicing, with regression tests covering both wrapText directly and the full
GenerateLabel path.
Special notes for your reviewer:
Testing
Pulled this branch to my homebox machine and ran
docker compose buildStood up my existing homebox deployment setting these variables, and verified that the labels print the way I want.