Tiers
Every evaluated member lives in exactly one tier. Tiers are stored as the single source of truth in xf_mc_sun_user_state.tier; inactivity is never persisted as a boolean.
The five tiers
| Tier | Default threshold | What it means |
|---|---|---|
| Active | : | Default state. Members who have never been evaluated, or who scored below the Warned threshold, sit here. Active users with a state row exist when a member was previously sunsetted and then reactivated. |
| Warned | 180 days inactive | A soft warning state. Default policy fires notify_user so the member knows their account is at risk. Profile content is untouched. |
| Soft sunset | 365 days inactive | First destructive tier. Default policies de-index the profile from search results and anonymise the about, location, and signature fields. Snapshots of the originals are captured so reactivation can restore them. |
| Hard sunset | 730 days inactive | Same destructive footprint as Soft, plus a notify_admin policy. The Hard tier is the precursor to username release; once the member sits in Hard past the Hard to released window (default 730 days), the retention enforcer queues the Released transition. |
| Released | 1825 days inactive | Username goes back into the available pool. The previous username is recorded in xf_mc_sun_released_username so it survives user delete and continues to block re-registration during the lockout window. |
Transitions
The evaluator runs on schedule, computes a target tier for each candidate, and enqueues a TransitionUser job if the target differs from the current tier. A transition is one atomic operation:
- Snapshot any field the new tier's policies will mutate.
- Run each assigned policy in order.
- If any policy fails the transaction rolls back and the audit log records the failure. The user stays at their previous tier.
- Write the new tier, the new entered_tier_date, and the new score.
- Write one audit row per policy executed (success, skip, or fail) plus one for the transition itself.
Transitions are idempotent: re-running a transition that already completed is a no-op.
Frozen request-model users
A member sunsetted into a tier whose reactivation model is request is frozen. The evaluator and the mc-sunset:evaluate CLI both skip them: their tier cannot move up (fresh activity does not undo the lockout) or deeper (their inactivity score does not push them further along) until the reactivation request is approved or an admin resolves the state manually.
This is the only state where the score is decoupled from the tier. It exists so a locked-out member who logs in repeatedly cannot escape the lockout simply by accumulating last-activity timestamps from the lockout page itself.
Who is excluded
The evaluator only considers members whose xf_user.user_state is valid. Banned, deleted, awaiting-approval, and email-confirmation accounts are never candidates. Members of any group listed in Excluded user groups are also skipped, and members whose account is younger than Minimum account age are too.
Tier identifiers in code and CLI
The tier names above are the user-facing form. In the database, the CLI, and the policy assignment grid, tiers are lowercase identifiers: active, warned, soft, hard, released. Pass these literals to --to= on mc-sunset:transition, see them in the tier, from_tier, and to_tier audit-log columns, and reference them when authoring custom policies.