mirror of
https://github.com/maziggy/bambuddy.git
synced 2026-05-09 08:25:54 +02:00
[GH-ISSUE #676] [Bug Report] When logging into Bambuddy with any account not in the "Viewer" group, the AMS d #446
Labels
No labels
A1
automated
automated
bug
bug
Closed due to inactivity
contrib
dependencies
dependencies
duplicate
enhancement
feedback
hold
invalid
Notes
P1S
pull-request
security
ThumbsUp
user-report
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/bambuddy-maziggy-1#446
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @maziggy on GitHub (Mar 12, 2026).
Original GitHub issue: https://github.com/maziggy/bambuddy/issues/676
Originally assigned to: @maziggy on GitHub.
When logging into Bambuddy with any account not in the "Viewer" group, the AMS displays 0% quantity for most filaments. When logging in as a "Viewer", the qty displays correctly.
System Information
Logs (sanitized): bambuddy.log
Submitted via BamBuddy Bug Report
@cadtoolbox commented on GitHub (Mar 12, 2026):
@maziggy commented on GitHub (Mar 12, 2026):
Cannot reproduce the problem.
I investigated the code and there's no permission-based filtering of AMS fill level data — all user groups receive the same remain values from the printer via both REST and WebSocket.
Since I wasn't able to reproduce this on my end, so I suspect this might be a browser cache issue. Could you try the following:
If the issue persists after that, I'll need some more details to track it down:
/api/v1/printers/*/status)?
@cadtoolbox commented on GitHub (Mar 12, 2026):
Hard refresh didn't fix the issue or browser cache. Multiple computers show same issue. Only "Viewers" are correct. What's interesting is the Bambuddy instance I use on my laptop for testing new versions works fine. The version installed on the Windows PC is the issue, but only for some accounts. Maybe a communication issue? But I also loaded it from the browser of the machine it's running from and had the same issue.
Here's a few clues. From the Bambuddy logs:
[2398AA591200559] H2D tray_now: multiple AMS [1, 129, 130, 2] on extruder 0, no snow field, using slot 2 (may be incorrect)
From Browser debug:
/api/v1/printers/5/cover?v=%2Fdata%2FMetadata%2Fplate_1.gcode:1 GET http://wl3dprintfarm/api/v1/printers/5/cover?v=%2Fdata%2FMetadata%2Fplate_1.gcode 404 (Not Found)
index-uY-HUfhG.js:7619 WARNING: Multiple instances of Three.js being imported.
(anonymous) @ index-uY-HUfhG.js:7619
/api/v1/settings/:1 Failed to load resource: the server responded with a status of 401 (Unauthorized)
index-uY-HUfhG.js:8715 [WebSocket] Connected
cover:1 Failed to load resource: the server responded with a status of 404 (Not Found)
@maziggy commented on GitHub (Mar 13, 2026):
Not sure if this is the main problem, but I've found an issue...
Inventory fill level overriding AMS remain via nullish coalescing
The fill level display uses a fallback chain: Inventory → AMS remain. The inventory spool assignments query is gated by the inventory:view_assignments permission. The Viewer group likely doesn't have this permission, so the query is skipped entirely and the correct AMS remain values from the printer are shown directly.
For other groups (that do have the permission), the query fires and returns spool assignments. If any of those spools have stale weight_used values (where weight_used >= label_weight), the inventory fill calculates to 0%. The problem is the nullish coalescing operator (??):
const effectiveFill = inventoryFill ?? tray.remain;
// 0 ?? 85 → 0 (not 85, because 0 is not null/undefined)
So a stale inventory fill of 0% permanently shadows the correct real-time AMS remain value from the printer. This also explains why HT units showed correctly — they likely didn't have matching spool assignments.
Fix: When inventory says 0% but the AMS hardware reports a positive remain, the inventory value is now bypassed in favor of the live AMS data. When both agree on 0%, behavior is unchanged.
To verify on your end before the fix ships: check Settings → Inventory for spool assignments on the affected AMS slots — look for spools where the remaining weight is at or near zero while the physical spool still has filament.
Please try with branch dev.
@cadtoolbox commented on GitHub (Mar 13, 2026):
@maziggy That was what I saw. The inventory spool was set to 0 remaining weight even with full spools in the AMS. Working on re-testing soon.
@maziggy commented on GitHub (Mar 23, 2026):
Any news here?
@cadtoolbox commented on GitHub (Mar 23, 2026):
@maziggy All looks good in the last updates. Thanks again!