Reactivation requests
AdminCP > Users > Sunset > Reactivation requests.
Reactivation requests are created when a member sunsetted into a request-model tier submits the request form on their lockout page. Each row in this list mirrors a moderation approval-queue row of content type mc_sun_reactivation_req.
Filtering
The page-action header is a dropdown showing the current filter and the count for each state: Pending, Approved, Rejected, or All. Defaults to Pending.
Per-request actions
Click any row to open the review page. The review page shows the requester, the member's current tier and entered-tier date, the original request date, and any prior reviews (admin note, decision, who decided). The footer has three buttons:
| Button | Effect |
|---|---|
| Approve | Runs the full Reactivator flow: tier resets to active, every snapshot restored, the audit log records the approval, and the moderation queue row is removed. The member's next login completes normally. |
| Reject | Marks the request rejected. The member's lockout page updates to the rejected state on their next request. After a rejected reactivation request controls whether they can submit again. |
| Reject and notify | As Reject, plus sends the mc_sun_reactivation_rejected_email to the member. The optional admin note is included in the email body. |
Approvals and rejections from the AdminCP page and the moderation approval queue stay in sync through xf_mc_sun_reactivation_request._postSave. Approving from one closes the queue row on the other automatically.
Permission
The AdminCP page requires the Manage Sunset admin permission. The moderation approval queue requires the Handle sunset reactivation requests moderator permission. They are independent; granting one does not grant the other.