Usage

Managing Locks

Navigate to Settings → Icecube → Locks in the control panel to see every lock in your project. From here you can create, edit, enable, disable, or delete locks.

Creating a Lock

  1. Click New lock on the Locks page.
  2. Choose the target type: entry, asset, category, or global set.
  3. Pick the specific element you want to protect.
  4. Decide what the lock covers: lock editing, lock deleting, or both.
  5. Optionally set a per-lock password. If you leave it blank, the master password from plugin settings is used.
  6. Optionally add notes explaining why the element is locked — these appear in the unlock modal and as a badge on the element’s edit page.
  7. Save the lock. It’s active immediately.

What Users See

When a user opens a locked element’s edit page, Icecube injects a “Locked by Icecube” badge at the top of the page, along with any notes you added.

If they try to save or delete a locked element without unlocking first, Craft blocks the action and shows an error:

This item is locked by Icecube. Enter the unlock password to save.

The Unlock Flow

  1. The user clicks Save or Delete on a locked element.
  2. Icecube shows an unlock modal asking for the password.
  3. If the per-lock password is set, the user enters that. Otherwise the master password works.
  4. On success, Icecube grants a time-limited unlock session for that specific element and action.
  5. The user can now save or delete the element for the duration of the session (default 10 minutes).

Entering the wrong password repeatedly triggers a temporary lockout — by default, 5 wrong attempts locks that user out of that element for 5 minutes. See Configuration to tune it.

Users need the Unlock locked content with password permission to complete this flow. Without it, they never see the modal and can’t unlock at all. See Permissions.

Where Locks Apply

Locks are enforced on every web request, not just in the control panel. Front-end form submissions, GraphQL mutations, Element API writes, and other plugins saving elements programmatically all go through the same check.

Console commands are the one exception. There’s no session in which to enter an unlock password, and blocking them would break routine maintenance like craft resave, migrations, and garbage collection — all of which require server access already.

Unlock Sessions

Unlock sessions are scoped to a single element and a single action (edit or delete). Unlocking an entry for editing doesn’t unlock it for deletion, and unlocking one entry doesn’t unlock any others.

Sessions last for the number of minutes configured in Unlock TTL (default 10, max 1440). Once they expire, the next save or delete triggers the unlock modal again.

Bypass Users

Admins (if Admins Bypass is enabled) and users with the Bypass all locks permission never see the unlock modal or the lock badge. Saves and deletes happen as if the lock didn’t exist. See Permissions for details.

Draft Autosaves

Icecube only blocks canonical saves. Draft autosaves pass through untouched, so editors can keep drafting work-in-progress without being interrupted by the unlock modal every few seconds. The lock engages when the draft is published to the canonical element.