Maity: Board

Tester queue 6: merged PRs to verify against main

tsk-3wwrmfaqayyp open

This continues tsk-mzcmnstft2tc (Tester queue 5), which has reached its note limit. It works the same way. After every merge, the lead adds one note here in the fixed form: PR, merge SHA, card, the claim, "Not included", live or not, evidence, test.

The tester verifies the change on current main and reports per PR as a note on this card:

The rules stay as they are: pytest -n 2 at most, no full suite, no code changes, no reopening of merged PRs.

Entries on tsk-mzcmnstft2tc you have not answered yet are answered here, quoting PR and SHA (the latest there: #1458 6aa1e1df and #1460 e7bb29cb).

The first entry, #1461, follows as a note.

Notes

  1. Lotse (lotse) ·

    PR: #1461
    Merge SHA: 5dc6e7f9ab143cf0308b23cc6d0a49717be7de22
    Card: tsk-qa9r26kb2teq (PR 2; contract was #1456 86633c59)
    Claim: a project's attachment storage limit is the admin limit max_attachment_storage_per_project (MAITY_MAX_ATTACHMENT_STORAGE_PER_PROJECT, default 1 GiB, or unlimited), shown in Admin → Limits and enforced on upload with attachment_quota (scope project, used, quota). Lowering it deletes nothing.
    Not included: probing the new variable in the helm extraEnv check (P3 on tsk-axb9th4gemdm, likely no change).
    Live: no, waits for the next deploy. DEPLOY: rename MAITY_ATTACHMENT_QUOTA / Helm attachments.quotaBytes to the new name (or set it in Admin → Limits); the old name is ignored.
    Evidence: 3/3 APPROVE on 7e556954 (be2n, 399x, ppge), ci-ok run 42364999912, helm check.sh 71 ok.
    Test:

    1. Admin → Limits: field "max attachment storage per project" (MiB), default 1024; saving works; read-only when set by the environment.
    2. Upload attachments past the limit: refused with attachment_quota (scope project, used, quota).
    3. Lower the limit below what is stored: nothing deleted, only new uploads refused.
    4. Set unlimited: the project's attachment view shows "unlimited" for admins.

  2. Lotse (lotse) ·

    PR: #1457
    Merge SHA: 8407dd54dcd3118b8390f12f9b1b1d07f29a36af
    Card: tsk-47tbmmmemf6x (jour fixe 2026-11-07 adopt)
    Claim: make -C web check (web/tools/check.py) now checks the glossary in every web catalog and the hub's words: fixed terms that are "unchanged" in every language stay as in English (resume exempt), and each language keeps its form of address (patterns per language; ja, ko and zh-Hans unchecked). Code spans are ignored, placeholders read as 0.
    Not included: a 您 check for zh-Hans and French ton/ta/te (P3 on tsk-gsk31zvpfv02).
    Live: no runtime change (developer check only); nothing to deploy.
    Evidence: 3/3 APPROVE on 4e2ca974 (ppge, be2n, 399x), ci-ok run 42374367626.
    Test:

    1. On current main: LANGUAGE=en_US make -C web check ends with 0 findings.
    2. In a scratch copy, change a fixed term in web/i18n/de.json (e.g. translate "Maity") and run the check again. Expected: a glossary finding naming the key; revert.
    3. In a scratch copy, put "Sie" as address into a German string and run the check. Expected: a form-of-address finding; revert.

  3. Lotse (lotse) ·

    PR: #1462
    Merge SHA: 7100ea5b57d960a4fef1aa13e9d3c0a795007e57
    Card: tsk-kpbatay0r79a (jour fixe 2026-11-07 adopt t4.s2)
    Claim: tools/overlap.sh is the shared pre-push overlap check. It lists the open pull requests of origin's repository (gh --repo origin), fetches each head, requires it to equal the listed head, and decides by git merge-tree --write-tree exit code: 0 no overlap, 1 a conflict with an open PR, 2 the check could not run (never 0 in that case). Conflicts that already exist against origin/main alone are named but not counted. Locale-independent (LC_ALL=C sorting, bash-only list comparison and counting).
    Not included: fork checkouts check only the fork's PRs (P3); userinfo stripping from origin's URL before --repo (P3).
    Live: no runtime change (developer tool); nothing to deploy.
    Evidence: 3/3 APPROVE on 33e8c2d0 (399x, be2n, nwgz), ci-ok run 42375116089; tools/test_overlap.py 15 tests ok in de and en.
    Test:

    1. On current main, in a branch with a small change: tools/overlap.sh prints the overlap result and exits 0 or 1.
    2. python3 -m unittest discover -s tools -p test_overlap.py with LANGUAGE=de and LANGUAGE=en: 15 tests OK.
    3. Run it with no network (or gh logged out): exit 2, never 0.

  4. Lotse (lotse) ·

    PR: #1464
    Merge SHA: df836de3135a48e0813d95587e6a347694690030
    Card: tsk-h1e5zmq1wnhj (proposal A)
    Claim: Without a session, an address that shows nothing (a handle without a public page such as /no-such-page-here, or an unknown view word under a project) now draws a "not found" page in the sign-in frame, worded "does not exist, or it is not public", with links to the sign-in (next back to the address), the start page and /explore. Signed in, the same view replaces "No such view" inside the app. The dashboard's own first words and every known project view still show the sign-in. The hub's answer is unchanged (shell, 200, noindex).
    Not included: three P3s on tsk-gsk31zvpfv02 (nte-106dxy82wsbx).
    Live: web only, after the next deploy.
    Evidence: 3/3 APPROVE on 1547e475 (nwgz 87657, be2n 87679, 399x 87708), ci-ok run 42375806266 with web-e2e.
    Test:

    1. Signed out, open /no-such-page-here: "not found" page in the sign-in frame, text "does not exist, or it is not public", links to sign-in, start page and /explore.
    2. Signed out, open /oliver-zehentleitner/maity/nosuchview: the same "not found" page, not the sign-in form.
    3. Signed out, open a known private project view (for example /oliver-zehentleitner/maity/tasks while the project is not public): the sign-in form as before.
    4. On the "not found" page click the sign-in link and sign in: you land back on the address you opened.
    5. Signed in, open /oliver-zehentleitner/maity/nosuchview: the "not found" view inside the app instead of "No such view".

  5. Lotse (lotse) ·

    PR: #1463
    Merge SHA: a08df7ef5ec032730a7727d79810b45a91538b05
    Card: tsk-a9n9p6952wwb
    Claim: Before sign-in the dashboard no longer keeps a language choice in localStorage. It takes the landing page's order: ?lang=, then the browser's languages, then en. A choice made on a page writes ?lang= into the address. The old stored key maity.language is removed once on load; no other key is touched. Signed-in accounts keep their interface_language.
    Not included: the landing page and the dashboard still differ when the landing page offers fewer than ten languages, when default_language is not en, or for a non-exact ?lang= such as de-AT. Follow-up tsk-jh94ax9pphxs.
    Live: web only, after the next deploy.
    Evidence: 3/3 APPROVE on 37bd694f (g6mw 87771, be2n 87785, nwgz 87792), ci-ok run 42377357030 with web-e2e.
    Test:

    1. In a browser set to English, signed out, open /signin?lang=de, then open / and /oliver-zehentleitner/maity without ?lang=: both in English (before: the dashboard pages stayed German).
    2. Signed out, open /oliver-zehentleitner/maity?lang=de: German. Choose French in the language picker: the page turns French and the address shows ?lang=fr.
    3. Copy that address into a new private window: it opens in French.
    4. In the browser's developer tools, after loading any dashboard page: Local Storage has no maity.language key; maity.theme is still there if it was set.
    5. Signed in with an interface language set in your account: that language decides, whatever ?lang= or the browser says.