فهرست منبع

Add #2944 to the CHANGELOG

maziggy 2 روز پیش
والد
کامیت
0426833050
1فایلهای تغییر یافته به همراه1 افزوده شده و 0 حذف شده
  1. 1 0
      CHANGELOG.md

+ 1 - 0
CHANGELOG.md

@@ -52,6 +52,7 @@ All notable changes to Bambuddy will be documented in this file.
 - **The frontend build no longer warns about `path` and `crypto` being externalized for the STEP previewer (#2976)** — `occt-import-js`, the Emscripten build behind STEP previews, requires both modules, but only inside its `ENVIRONMENT_IS_NODE` branches; in the browser it loads its `.wasm` from the URL the preview worker passes and draws randomness from `crypto.getRandomValues`. Vite still externalized both and printed two warnings on every build. `vite.config.ts` now drops exactly those two warnings for that one package through `build.rolldownOptions.onLog`, so an externalization anywhere else, or of any other module, still shows.
 - **The frontend build no longer warns about `path` and `crypto` being externalized for the STEP previewer (#2976)** — `occt-import-js`, the Emscripten build behind STEP previews, requires both modules, but only inside its `ENVIRONMENT_IS_NODE` branches; in the browser it loads its `.wasm` from the URL the preview worker passes and draws randomness from `crypto.getRandomValues`. Vite still externalized both and printed two warnings on every build. `vite.config.ts` now drops exactly those two warnings for that one package through `build.rolldownOptions.onLog`, so an externalization anywhere else, or of any other module, still shows.
 
 
 ### Fixed
 ### Fixed
+- **In Spoolman mode, a new Bambu Lab roll links to a filament of its own product line (#2907, reported and contributed by @ojimpo in #2944)** — Bambuddy matched a new roll to a Spoolman filament by material and colour alone. Several product lines share a colour, so a PLA Matte Charcoal roll was linked to the PLA Basic "Black" filament, took its name and density, and showed up as Black. The same happened to other lines: PLA Tough took PLA Basic's library entry, PLA Silk White took "Aero White", and PETG HF took plain PETG's. The match now also checks the product line the AMS reports, both among your existing filaments and in the Spoolman filament library, and each roll takes its own library entry and density. New filaments are named for the line ("PLA Matte"), including ones taken from the library, and the colour name ("Charcoal") is stored on the spool. Spoolman mode now shows the same subtype and colour name as the built-in inventory. When no filament or library entry fits the line, Bambuddy creates one from what the AMS reports instead of taking the first one with the same colour. Filaments that earlier versions named after a colour ("Black") are still reused, so existing installs don't get duplicates. A filament you renamed yourself in Spoolman is no longer reused for new rolls.
 - **LDAP group mapping finds groups on lldap and OpenLDAP (#3197, reported by @TOFM)** — Every login from an lldap directory got the Default Group, even for a user who was a member of a mapped group. Bambuddy read membership from the user's `memberOf` attribute but asked the server for "all attributes". lldap, and OpenLDAP's memberof overlay, leave `memberOf` out of "all attributes" and only return it when it is asked for by name. Bambuddy now asks for it by name wherever the directory's schema has it. It also asks the groups themselves which `groupOfNames` and `groupOfUniqueNames` entries list the user, searching from the directory root, because groups usually sit beside the users (`ou=groups` next to `ou=people`) rather than under the search base. That covers OpenLDAP without the memberof overlay, where there is no `memberOf` at all, and OpenLDAP with an overlay that tracks only one group class. Active Directory keeps `memberOf` complete and is not searched the second way. Checked against lldap 0.6.3, OpenLDAP 2.6 with and without the overlay, and Samba AD. Smaller things from the same report: **StartTLS now works with Active Directory and Samba AD**, which it never did: straight after StartTLS, and before logging in, the LDAP library read the server's schema, which those directories only allow once logged in, so every StartTLS connection failed with "operationsError" (LDAPS was unaffected); **Test Connection** against a server that doesn't offer StartTLS (lldap only does LDAPS) now says so and suggests LDAPS, instead of "Unsupported extended operation" and a number; support bundles no longer mask part of a longer dotted number such as that one as an IP address, which had made the message unreadable; and a user's first LDAP login logs the "no mapped groups" warning once instead of twice.
 - **LDAP group mapping finds groups on lldap and OpenLDAP (#3197, reported by @TOFM)** — Every login from an lldap directory got the Default Group, even for a user who was a member of a mapped group. Bambuddy read membership from the user's `memberOf` attribute but asked the server for "all attributes". lldap, and OpenLDAP's memberof overlay, leave `memberOf` out of "all attributes" and only return it when it is asked for by name. Bambuddy now asks for it by name wherever the directory's schema has it. It also asks the groups themselves which `groupOfNames` and `groupOfUniqueNames` entries list the user, searching from the directory root, because groups usually sit beside the users (`ou=groups` next to `ou=people`) rather than under the search base. That covers OpenLDAP without the memberof overlay, where there is no `memberOf` at all, and OpenLDAP with an overlay that tracks only one group class. Active Directory keeps `memberOf` complete and is not searched the second way. Checked against lldap 0.6.3, OpenLDAP 2.6 with and without the overlay, and Samba AD. Smaller things from the same report: **StartTLS now works with Active Directory and Samba AD**, which it never did: straight after StartTLS, and before logging in, the LDAP library read the server's schema, which those directories only allow once logged in, so every StartTLS connection failed with "operationsError" (LDAPS was unaffected); **Test Connection** against a server that doesn't offer StartTLS (lldap only does LDAPS) now says so and suggests LDAPS, instead of "Unsupported extended operation" and a number; support bundles no longer mask part of a longer dotted number such as that one as an IP address, which had made the message unreadable; and a user's first LDAP login logs the "no mapped groups" warning once instead of twice.
 - **In Spoolman mode, each spool's own size is used, not its filament's (#3194, reported by @worried-networking)** — Spoolman stores how much filament a full spool holds on the spool (**Initial Weight**) and uses the filament's **Weight** only when the spool has none, so one filament can have spools of different sizes. Bambuddy read only the filament, so a 250 g spool of a 1000 g filament showed as 1000 g with the wrong fill level, **Sync Weights from AMS** and AMS-percentage usage tracking charged it four times the real grams, and the AMS hover card's Spoolman fill level was off the same way. All of these, the weigh action and the SpoolBuddy scale now use the spool's own size. Creating a spool writes its **Label Weight** to the spool's Initial Weight, so a 250 g spool of a 1000 g catalogue filament is recorded as 250 g. Editing the Label Weight changes only that spool: it used to change the filament's weight while Spoolman kept the spool's old size, so the two disagreed from then on, and on a filament shared with other spools it linked this spool to a new duplicate filament instead. The spool form's **Cost per kg** is stored as Spoolman's spool **Price**, which Spoolman treats as the price of the whole spool; it is now converted at the spool's size both ways, and print cost divides a spool's own price by the spool's size. A catalogue price on the filament is still divided by the filament's weight. For 1000 g spools nothing changes. Saving a spool without changing its size or price no longer writes either, so a 250.7 g spool stays 250.7 g. Editing a spool that has no weight in Spoolman at all, on the spool or its filament, failed with an error; it now saves, and a Label Weight saved from the spool form becomes the spool's size.
 - **In Spoolman mode, each spool's own size is used, not its filament's (#3194, reported by @worried-networking)** — Spoolman stores how much filament a full spool holds on the spool (**Initial Weight**) and uses the filament's **Weight** only when the spool has none, so one filament can have spools of different sizes. Bambuddy read only the filament, so a 250 g spool of a 1000 g filament showed as 1000 g with the wrong fill level, **Sync Weights from AMS** and AMS-percentage usage tracking charged it four times the real grams, and the AMS hover card's Spoolman fill level was off the same way. All of these, the weigh action and the SpoolBuddy scale now use the spool's own size. Creating a spool writes its **Label Weight** to the spool's Initial Weight, so a 250 g spool of a 1000 g catalogue filament is recorded as 250 g. Editing the Label Weight changes only that spool: it used to change the filament's weight while Spoolman kept the spool's old size, so the two disagreed from then on, and on a filament shared with other spools it linked this spool to a new duplicate filament instead. The spool form's **Cost per kg** is stored as Spoolman's spool **Price**, which Spoolman treats as the price of the whole spool; it is now converted at the spool's size both ways, and print cost divides a spool's own price by the spool's size. A catalogue price on the filament is still divided by the filament's weight. For 1000 g spools nothing changes. Saving a spool without changing its size or price no longer writes either, so a 250.7 g spool stays 250.7 g. Editing a spool that has no weight in Spoolman at all, on the spool or its filament, failed with an error; it now saves, and a Label Weight saved from the spool form becomes the spool's size.
 - **In Spoolman mode, weighing a spool now uses the vendor's empty spool weight (#3195, reported by @worried-networking)** — Spoolman finds a spool's empty weight in three places: the spool's own **Spool Weight**, then the filament's, then the vendor's **Empty Spool Weight**. Its own `/measure` endpoint uses that order. Bambuddy stopped after the filament and used 250 g instead of the vendor's value. So a spool whose tare was set only on its vendor weighed against the wrong core: a Sunlu spool (211.7 g) at 1177 g on the scale was saved as 927 g remaining instead of 965.3 g. The same error was in three places, and each is fixed: the weigh action in the inventory, the SpoolBuddy scale, and the **Empty Spool Weight** shown in the spool form and used for gross weight in the list. All three now share one lookup, so they can't drift apart again. The SpoolBuddy "no spool weight set, using 250 g" warning now appears only when the spool, the filament and the vendor all have no weight. The spool form still sends the empty weight to Spoolman only when you change it, so opening and saving a spool does not copy the vendor's value onto it. Changing a filament's spool weight with **Keep old weight for existing spools** now keeps a vendor-inherited tare too: when the filament had no weight of its own, the spools that inherited the vendor's value get that value, not the new filament weight.
 - **In Spoolman mode, weighing a spool now uses the vendor's empty spool weight (#3195, reported by @worried-networking)** — Spoolman finds a spool's empty weight in three places: the spool's own **Spool Weight**, then the filament's, then the vendor's **Empty Spool Weight**. Its own `/measure` endpoint uses that order. Bambuddy stopped after the filament and used 250 g instead of the vendor's value. So a spool whose tare was set only on its vendor weighed against the wrong core: a Sunlu spool (211.7 g) at 1177 g on the scale was saved as 927 g remaining instead of 965.3 g. The same error was in three places, and each is fixed: the weigh action in the inventory, the SpoolBuddy scale, and the **Empty Spool Weight** shown in the spool form and used for gross weight in the list. All three now share one lookup, so they can't drift apart again. The SpoolBuddy "no spool weight set, using 250 g" warning now appears only when the spool, the filament and the vendor all have no weight. The spool form still sends the empty weight to Spoolman only when you change it, so opening and saving a spool does not copy the vendor's value onto it. Changing a filament's spool weight with **Keep old weight for existing spools** now keeps a vendor-inherited tare too: when the filament had no weight of its own, the spools that inherited the vendor's value get that value, not the new filament weight.