[ImBaphomettt]

One commit and two merges of main. Who may change the settings keeps a list of ban templates, each a reason and a length, and the ban dialog offers them: picking one fills in the reason and the length, which the staff can still change before banning. An active ban can now be edited, its reason, its end or both, under a permission of its own, Edit bans. Each edit is kept with the ban, with who made it, when, and what it replaced; the audit log, the Bans page and the player's profile show them, and a connecting player is checked against the ban as it now stands. The bridge and the contract do not change.

What changed

Ban templates (8c7d166)

• crates/observer-domain/src/bans.rs: BanTemplate (reason, minutes, null for a permanent ban) and BansSettings::templates. checked keeps a template only with a reason a ban takes and a length from a minute to ten years, keeps a template listed twice once, and takes 50 at most.
• crates/observer-store/migrations/0019_ban_edits_templates.sql: table ban_template, in the settings' order. They are saved with the refusal message through PUT /api/servers/default/bans/settings, with the settings' permission and the password again, and that body now requires templates: a client that leaves it out is refused rather than emptying the list. GET /api/servers/default/bans/templates gives them to whoever bans (PLAYERS_BAN).
• Settings › Bans and kicks: a Ban templates row lists them with their lengths; a template is added or edited in a dialog, moved up or down, removed, and the list is saved through the category's save bar.
• The ban dialog: a Template select above the length, when the settings hold templates. Picking one fills in the reason and the length; once either is changed, the select reads None again.

Editing an active ban (8c7d166)

• PATCH /api/servers/default/bans/{code} takes BanEditRequest: a new reason, a new end (ends: never, or in a number of minutes counted from the edit), or both. Only an active ban is edited (ban_not_found, ban_not_active); an edit that changes nothing is not kept, and the schema refuses one.
• Permission BANS_EDIT (bit 32, sensitive, area Players, implies BANS_VIEW): the end moves either way, sooner included.
• Table ban_edit, in the same migration: who made each edit, when, and the reason and the end before and after. The ban keeps who made it and when. Ban::edits lists them, latest first, in the list, a profile's bans and the edit's answer.
• Audit action ban_edited; its details hold reason and endsAt, whichever changed, each before and after.
• The refusal at playerConnecting, the drop of a connected player and the events observer:playerRefused and observer:playerBanned read the ban as it is stored, so they carry the new reason and end.
• The panel: on the Bans page, a row's menu holds Edit ban… and Lift ban…, which on a phone stay two buttons; the profile's notice of an active ban has Edit ban… beside Lift ban…. The edits fold under the ban's reason, on the page and on the profile: who, when, the reason before, the end before and after.
• web/src/bans/fields.tsx: the length choice, the reason field and the range hint, which the ban dialog, the edit dialog and the template dialog share.

The audit details of the bans' settings (8c7d166): bans_settings_changed now names each changed setting with its value before and after (refusalMessage, tokenMatches, templates), rather than the whole settings twice; the audit log words the templates as reasons and lengths.

README (8c7d166): the Bans section.

Merges of main (6270411, fd8fa6c)

• 6270411 merged Run the fake FXServer tests on ports the system gives, so that two runs on one host no longer collide #56, Follow the server's resources on a Resources page, and start, stop, restart or rescan them #57, Show the integration contract in the panel, on a Documentation page drawn from the file the binary ships #59 and List the server's entities, draw them on the live map and delete them a hundred at a time #61. Follow the server's resources on a Resources page, and start, stop, restart or rescan them #57 and List the server's entities, draw them on the live map and delete them a hundred at a time #61 took bits 26 to 28, so BANS_EDIT moved after them; AuditAction::ALL was counted again. The bindings were generated again from the merged Rust.
• fd8fa6c merged Kick a player or everyone, and raise announcements and direct messages for the server's resources, in contract 5 #58, which took bits 29 to 31: BANS_EDIT is bit 32, and the owner's mask in crates/observer-web/src/tests.rs is 1ffffffff; AuditAction::ALL holds 123 actions. Bans::ban keeps Kick a player or everyone, and raise announcements and direct messages for the server's resources, in contract 5 #58's txAdmin event and BansSettings::checked its clean_message(text, max). The settings' category is Bans and kicks, the kick message after the templates. The refusal message's audit detail is keyed refusalMessage, since Kick a player or everyone, and raise announcements and direct messages for the server's resources, in contract 5 #58 gives message its own label for announcements, and the fixture of Kick a player or everyone, and raise announcements and direct messages for the server's resources, in contract 5 #58's kick message tests gains templates: [].

Why

The ban dialog offered lengths only, while most bans are for a handful of reasons; txAdmin keeps templates for them. And a ban could not be corrected: a typo in a reason the player reads, or a wrong length, meant lifting it and banning again under a new ban ID, the one the player quotes to appeal.

Notes for review

• Editing is a permission of its own rather than part of Ban players: an end brought closer lets a player back in, which banning does not allow. Whoever holds Edit bans moves an end either way.
• A new length counts from the edit, as a new ban's counts from the ban; the dialog says when the ban will end, and what it replaces.
• txAdmin has no event for an edited ban: with Send txAdmin's events too, an edit raises nothing.
• Open branches: Let in approved players only, and close the server for maintenance to all but a list, under another name in the server list, in contract 6 #60 and Let server resources hold a stop until they have saved, in contract 7 #55 number their migration 0019 too; whichever merges after this one renumbers. Let in approved players only, and close the server for maintenance to all but a list, under another name in the server list, in contract 6 #60 also adds permissions, after bit 32. The conflicts this branch adds for them: crates/observer-store/src/migrations.rs for both, and web/src/audit/details.ts for Let in approved players only, and close the server for maintenance to all but a list, under another name in the server list, in contract 6 #60.

Verified

• cargo xtask check on Windows at fd8fa6c: fmt, icons, clippy with -D warnings with and without test-catalog, 3,475 Rust tests in 49 test binaries, none failed, bindings unchanged, and in web/ format, lint, type check, 925 tests and the build, under Node 26.13. GitHub Actions starts no job, as on the PRs before this one: this local run stands in for it.
• crates/observer-store: a 0018 database keeps its bans through the migration, with no edit and no template.
• On a debug Observer with the fake FXServer, at 8c7d166: a player whose ban was edited twice is refused at connection with the new reason and end, in the message and in observer:playerRefused. PATCH answers 403 bansEdit to an account that bans or lifts without the permission, and 200 to one that holds it. The Bans page, the profile, the three dialogs and the settings' row seen at 1440, 1024, 375 and 320 px, dark and light, with no console error and nothing scrolling sideways, on the dev server and on the panel the debug Observer serves.

Not verified

• A real FXServer: the bridge does not change, and nothing here runs in its Lua.
• Linux, and cargo xtask e2e: no flow covers bans.
• The panel in a browser after the two merges: the merges are checked by the tests only.