fix(filament-manager): don't write a preset setting_id into a spool's filament id

[marciogranzotto]

Defers to #12060. @JaKuBisz identified this root cause first and #12060 is the more
complete fix — it also adds a Generic <type> fallback for free-typed brands, a one-time
migration that backfills the broken setting_id on existing spools, and the remaining-weight
fix. This PR is offered only as a minimal one-file variant of the same correction, in case a
focused change is easier to land first. If #12060 is going in, close this one.

Relates to #11937 (also reported in #11562, #11654, #11871). My duplicate issue #12078 is closed.

Problem

A spool's setting_id field must hold a filament_id — that is the only thing it is ever matched against:

// src/libslic3r/PresetBundle.cpp — get_filament_by_filament_id
if (filament_preset.filament_id == filament_id) { ... }

// src/slic3r/GUI/AMSMaterialsSetting.cpp:1557
bool has_preset = bundle && bundle->get_filament_by_filament_id(sp->setting_id).has_value();
if (has_preset) { lib_brand_to_spools[brand].push_back(*sp); }
else            { unsupported_spools.push_back(*sp); }

AddEditDialog resolved that value as:

matchedCloudFilamentId
|| matchedPresetItem?.setting_id
|| matchedPresetItem?.filament_id
|| initSpool?.setting_id

matchedCloudFilamentId only resolves on an exact match against the global cloud catalogue:

settings.find((it) => it.filamentVendor === brand && getCloudSettingDisplayName(it) === name)

A user's own custom filament is never in that catalogue, so the first term is empty and the chain falls through to the preset's setting_id. Preset setting ids are PFUS + 14 hex while filament ids are P + 7 hex (or GFxxx), so the stored value can never equal any preset's filament_id — the spool is shown under Unsupported Filaments permanently. Re-picking the filament in the dialog re-runs the same fallback and does not help.

On my install this affected 13 of 35 spools. Every broken spool held a PFUS… value that was the setting_id of the very preset it should have pointed at. The same filament appeared in both states (PLA Velvet OK on 6 spools / broken on 7), confirming it is per-spool write data rather than a preset problem — the healthy ones were created earlier via a path that resolved the real filament_id.

Change

Drop the wrong-namespace term at both resolution sites (handleSubmit and the filaId memo that mirrors it), and correct the comment that documented the old order.

Why this is safe

In the preset/list payload, all 325 preset items carry both filament_id and setting_id — zero items have setting_id without filament_id. So matchedPresetItem?.setting_id could never act as a useful fallback: whenever it was set, filament_id was set too. It could only shadow the correct value.

That said, this is one machine's profile set — please confirm there is no profile source where an item legitimately has a setting_id but no filament_id. If such a case exists, ordering the term last rather than removing it would be the safer variant.

Note this fixes newly created spools only; records already written with a PFUS… id need their setting_id rewritten to the matching filament_id.

Difference from #12060

#12060 orders the term last (cloud filamentId > preset filament_id > preset setting_id);
this PR removes it. Both fix the reported bug — ordering it last is the more conservative
choice and is fine. The note above about all 325 preset items carrying both ids is the
argument for removal, not a requirement.

This PR also fixes newly created spools only; it does not migrate records already written
with a PFUS… id. #12060 does, which is a further reason to prefer it.

🤖 Generated with Claude Code