- Shipped
- September 6, 2026 at 7:08 AM UTC
- Author
- Kamo
- Commit
- daf8e3b
The status menu on /support?tab=system-bugs leads with "Requires Verification" and a rule, then the individual statuses. It stands for NEW, IN_PROGRESS and FIXED — every report whose fix nobody has confirmed — so it gets no colour swatch: a dot would claim it was a status, and it is a question. Its count is summed from the three grouped counts /status-counts already returns, so the number is a promise about what picking it shows without a second round trip. The Divider is a direct child of the Select, not nested in a fragment; nested, it is not a child of the menu at all and the separator silently disappears. Fix Verified is drawn from the SERVER's canVerifyFix and nothing else. For the member who filed the report that flag is true while canManage, canEdit and canVoid are all false — so any attempt to derive the button from the other flags gets exactly the case it exists for wrong, and gets it wrong silently, because the platform-administrator case still works. Picking Won't Fix / Denied opens a prompt for an explanation before anything is written. The failure that pins is the one that looks like it works: a status change fired straight from onChange, with the reason box shown afterwards over a decision already saved and an email already sent. The reason is optional, and what is typed reaches both the reporter's email and the report itself. The stored reason renders under Change Status for whoever may retriage, and under the description for the person who filed it, who has no such control — one placement, two readings, because the block follows whatever came before it. The AI dispatch history is gone from the drawer, and with it `dispatches` from the detail type. Three statuses go. A saved filter naming one lands on "every status" rather than an error, and VERIFIED reads "Verified as Fixed" under a NEW dictionary key — the enum name is untouched, because the server stores statuses by name.