Repository navigation
Settings: account-status banner and gated-feature messaging #50
Description
Activity
Implemented in #170 — work continues in the PR from here.
The banner ships with per-status copy, an explicit locked-feature list, and a real call to action (verify-email for probation, appeal for restricted/suspended/banned), amber for probation and the view's existing red for the three that need intervention.
AccountCapabilitiesis the truth table behind it, re-exposed asCan*/*BlockedReasonpairs so a locked control can bindIsEnabledandToolTipand explain itself before the click rather than after.bannedis refused at sign-in — a stale token for a closed account is discarded instead of opening a shell that 403s on everything — whilerestricted/suspendedstill sign in and read, as documented.Two honest caveats.
MainWindowis the right host and is off-limits while #149 is in flight, so the banner sits at the top of Settings for now; re-parenting it is mechanical since nothing in the view model is Settings-specific. And the per-action disabling has its binding surface built and tested but no call sites yet — every gated action (compose, dig, follow, DM, media/cross-post/schedule, create list/doc/org) lives in a file #149 owns. The test account isactive, so the other four statuses were constructed locally rather than observed; 59 assertions cover them.- added a commit that references this issue
on Sep 24, 2026
Gap
GET /api/userreturnsaccountStatus(andcleared), which the app does not model or surface. Per/help/accountthe web shows a banner at the top of the home page explaining the current status.The five statuses
Why it matters
Without this, a probationary or restricted account gets bare
403s from half the app with no explanation — the single worst first-run experience available.Acceptance criteria
AccountStatusandClearedonCurrentUser.MainWindow) for any status other thanactive, naming what is locked and linking to verify-email or support as appropriate.banned/suspendedare handled gracefully at sign-in.