Reactivation

Reactivation is per-tier configurable. The model in effect at login time is the model assigned to the tier the member is currently in.

The five models

Model	What happens at login
auto	Tier resets to Active, every snapshot is restored, no notice shown. The member never knows they were sunsetted.
auto_notify	As auto, plus an email to Admin notification email so staff are aware.
request	Login completes (session is created), but a controller_pre_dispatch listener walls every request off to a lockout page. The member submits a reactivation request from the lockout page; staff approve or reject it through the moderation approval queue.
manual_only	Login is rejected with a "contact us" page. No session is created, no request is filed. Used when staff want a member to come through email rather than the self-serve queue.
partial	Tier resets to Active and a session is created, but only non-PII snapshots (profile and custom categories) are restored. PII snapshots (released usernames) stay anonymised: the member picks a fresh username on first save of their profile.

The defaults are tuned for graduated severity:

Tier	Default model
Warned	auto
Soft sunset	auto_notify
Hard sunset	request
Released	partial

Request-model flow

The request model is the most involved. When a member sunsetted into a request-model tier logs in:

1. The login completes normally; a session is created.
2. The lockout listener walls every request to /mc-sunset. The lockout page, the contact form, the visitor account menu, and logout are the only allow-listed destinations.
3. The lockout page shows current state: No request yet, Pending review, or Rejected.
4. The member clicks Request reactivation. The submit creates a row in xf_mc_sun_reactivation_request and posts a moderation approval-queue row (content type mc_sun_reactivation_req).
5. A moderator with the Handle sunset reactivation requests permission either approves or rejects from the moderation queue or from AdminCP > Users > Sunset > Reactivation requests. Both surfaces stay in sync.
6. On approval the Reactivator runs the full restore (tier → Active, snapshots restored). On rejection the lockout page updates to reflect the rejection and, optionally, a cooldown window before the member can submit a fresh request.

The lockout page allows the visitor account menu to load over AJAX so the member can still reach Log out from any walled page.

Rejection policy

The After a rejected reactivation request option controls what happens next:

Value	Behaviour
allow	The member can submit a fresh request immediately.
block	The lockout page never shows the Request reactivation button again. Manual admin action only.
cooldown	The member must wait Re-request cooldown days before submitting again.

Frozen tier

While a request-model member is sitting in their tier waiting for a decision, the evaluator and the mc-sunset:evaluate CLI both skip them. Their score is irrelevant until the request resolves; they cannot tier up out of the lockout simply by appearing to be active again.