Skip to main content

Policies

A policy is a single action that runs when a member transitions into a tier. Five built-in policies ship with the add-on, and the policy registry accepts third-party policies via the mc_sun_policy_register code event.

Built-in policies

PolicyWhat it does
notify_userSends a tier-specific email to the member. Subject and body templates are configurable per tier. Skipped if the member set the Don't notify me about Sunset transitions preference on their account privacy page.
notify_adminSends a tier-specific email to Admin notification email.
deindex_profileMarks the member's profile so it no longer surfaces in member-list search results, profile-lookup APIs, or the global search index. Reversible.
anonymize_fieldReplaces one or more profile fields with a placeholder. The originals are snapshotted under category profile or custom. Reversible. Supported fields: about, signature, location, website, custom_title, plus every textbox or textarea custom user field.
release_usernameRenames the member to Member#<user_id> and records the previous username in xf_mc_sun_released_username. The released-username row blocks re-registration for the Released username lockout window. Reversible only if no other account has claimed the username in the meantime.

The Policies page

The Policies page at AdminCP > Users > Sunset > Policies is a grid: tiers across the top, policies down the side. Tick the cell to assign a policy to a tier. Each policy has its own settings panel below the grid for any tunables (which fields to anonymise, which user field to read for the released-username placeholder, the subject and body of the notify emails).

The matrix is seeded on fresh install with this default assignment:

WarnedSoftHardReleased
notify_user
deindex_profile
anonymize_field
notify_admin
release_username

anonymize_field is configured to anonymise about, location, and signature by default.

The seed only runs on a fresh install. Upgrades never touch a customised matrix.

Execution order and atomicity

Policies execute in the order they appear in the matrix UI. The transition runs inside one database transaction:

  1. The Sunsetter captures snapshots for every field any assigned policy will mutate. Each snapshot row is dated and tagged with a category (pii, profile, or custom).
  2. Each policy runs. Success, skip, and failure all write an audit row.
  3. If any policy fails the entire transaction rolls back. The member stays at their previous tier, the snapshots are discarded, and the audit log shows which policy failed and why.

This guarantees that a partial transition never leaves a member with some fields anonymised and others not.

Dry-run

Every policy implements a dry-run path. The Preview page on the dashboard, the --dry-run flag on mc-sunset:evaluate, mc-sunset:transition, and mc-sunset:test-policy, and the dry-run option on the retention enforcer job all surface what each policy would do without writing to the database. Use this before flipping the master switch on a fresh install.

Custom policies

Custom policies extend MC\Sunset\Policy\AbstractPolicy (or AbstractNotificationPolicy for email policies) and register through a mc_sun_policy_register listener. Once registered they appear on the Policies page alongside the built-ins. See the addon's Policy/ directory for the reference implementations.