Files
bambuddy/backend/app/core
MartinNYHC 659d77c205 Store a failure reason in one vocabulary, not three (issue #2974)
failure_reason was written three different ways and nothing reconciled
    them. derive_failure_reason wrote English display labels ("Layer shift"),
    older builds of the archive editor wrote the translated label in whatever
    locale that user was running, and the two stale-archive paths wrote
    English prose sentences. All three reach one column -- the archive PATCH
    has mirrored the field onto the latest print-log entry since #1444 -- and
    the Failure Analysis widget groups on the raw value, so one real cause
    occupied several buckets. On a live install before this landed:
    print_log_entries held 91 rows reading "User cancelled" beside 1 reading
    "userCancelled".

    In an English UI those two render as the same words twice with different
    counts, which is why nobody spotted it. In any other locale one of them
    stays English, because a stored label has no key for t() to resolve. The
    editor was worse than cosmetic about it: its reverse lookup compared the
    stored value against t() in the current locale, so for a non-English user
    nothing matched and the dropdown opened empty over an archive that
    plainly showed a reason.

    The keys were already canonical and already enforced.
    _FAILURE_REASON_KEYS in api/routes/print_log.py rejects anything else
    with a 400 and explains why in its own comment -- the widget renders
    values back through t(), so an unrecognised one surfaces as a raw string.
    derive_failure_reason had simply never been held to that rule. It now
    produces keys, and the cancel branch returns userCancelled.

    The two "Stale - ..." sentences become one new noStatusUpdate key. Both
    describe the same observation, that no end-of-print status ever arrived;
    which of the two situations occurred is already carried by status --
    cancelled at the stale-cleanup site, the reconciled outcome at the
    reconnect site -- so collapsing them loses nothing and gives Statistics
    one bucket instead of two sentences that could never be translated. It
    had to enter the vocabulary rather than merely be tolerated, because the
    editor discards any value it does not recognise.

    Existing rows are converted by a startup migration folding 168 historical
    labels onto the 12 keys across both columns. It is exact rather than a
    guess: every label across all 14 locales resolves to exactly one key,
    with no collisions. The map is a frozen snapshot rather than something
    read from the locale files at run time -- it maps what was written
    historically, so regenerating it from the current translations would
    silently stop recognising the very rows it exists to convert. A value
    outside the map is left alone; guessing would be worse than leaving one
    honest string in its own bucket. There is no one-shot settings flag, on
    purpose: the statement only matches values in the map and a key is never
    a label, so it is self-terminating, and a flag would permanently skip
    anyone who restores an older database.

    The last part is a data-loss bug that was not in the report. The editor's
    fallback to '' was not merely a wrong-looking dropdown -- the empty
    selection was then saved over the stored text, so opening the editor on
    an archive whose reason was free text and pressing Save destroyed the
    classification. An unrecognised value now keeps its own option and
    survives a save.
2026-08-28 12:41:46 +02:00
..
…
2026-08-17 15:59:25 +02:00
…
…
…