maziggy 5015b02760 fix(backup): don't let an old backup commit blank an archive's owner (#2656) ...

`created_by_id` and `deleted_at` both went into the archive `fields` dict
    unconditionally, via `entry.get(...)`. A backup commit taken before the
    collector wrote those keys carries neither, so `.get` yielded None for both
    and the overwrite branch — a blanket `setattr` over every key — wrote NULL
    over a live owner.

    That is exactly the failure carrying `created_by_id` was added to fix, only
    now inflicted on rows that were fine: `_ensure_archive_visible` fails closed
    on a NULL owner, so the archive 404s for the person who owns it. It emitted
    no note either, because `archivesOwnerCleared` only fires for an id that
    isn't in `valid_users`, not for an absent key — and the row still counted as
    restored. `deleted_at` had the mirror problem: an old commit silently
    un-deleted, since `archivesUndeleted` reads the same absent value.

    Absent is not the same as explicitly null. Both keys now only enter `fields`
    when the entry actually carries them, so an old commit leaves the column
    alone on overwrite and a current one can still say "this archive has no
    owner" or "this archive is live". Same shape as the tag-column rule: don't
    clear what the backup doesn't know about.

    Behaviour change to an existing test, called out deliberately:
    `test_overwrite_undeletes_a_locally_deleted_archive_and_says_so` now has to
    put `deleted_at: None` in the entry to mean it.

    Tests: 2 regression (owner and deleted_at both left alone by a key-less
    entry) + 2 controls (an explicit null is still honoured, with its note).
    Both regressions confirmed failing against the pre-fix service.

2026-08-15 14:14:04 +02:00

..

app

fix(backup): don't let an old backup commit blank an archive's owner (#2656)

2026-08-15 14:14:04 +02:00

tests

Raise the chamber-temperature ceiling from 60 to 65 C

2026-08-15 14:00:43 +02:00

__init__.py

…