collective.lockdown 1.1.0

What it does

Site owners at the client side need permissions to properly manage content and users. However, if your setup is such that as an integrator you’re responsible for views and site configuration, the default Plone permission set for Site Administrator is too wide.

We’ve seen users switch the default layout to something not properly supported, or otherwise muck up the configuration of their site. Then they open a support ticket “the site is broken” — without disclosing what they just did.

On install, this add-on strips Site Administrator from a curated set of permissions on the Plone site root:

• every Plone Site Setup: * permission except Overview (so the Site Setup link in the toolbar still works) and Users and Groups (so user administration remains possible);

• Portlets: Manage portlets;

• Modify view template.

The control-panel index view self-filters its rendered configlets by per-configlet permission, so stripping the underlying permissions is sufficient to hide everything except the user management card.

The install handler writes role lists surgically via manage_permission (with acquisition disabled, so role grants cannot leak back in through Zope-root acquisition). Permissions outside the lockdown set are not touched.

Hidden control panel configlets

The upstream Users and Groups permission guards four configlets: Users, Groups, User and Group Settings, and Member Fields. Keeping that permission grants Site Administrator access to all four, which is wider than needed — site owners should only manage user accounts, not the global group/role mapping or member schema.

On install, the three other configlets (UsersGroups2, UsersGroupsSettings, MemberFields) get a TALES condition_expr on their portal_controlpanel entries that only evaluates true for users holding the Manager role:

python: member is not None and 'Manager' in member.getRolesInContext(portal)

The UsersGroups (Users) configlet is left untouched, so site owners still reach the user listing from the control panel. Manager users continue to see the full set. On uninstall, the conditions are cleared back to the upstream empty default.

Uninstall

Uninstalling via Site Setup → Add-ons restores every lockdown permission to its upstream Plone baseline — both the role list and the acquisition flag — using a snapshot of a vanilla Plone fixture captured at package build time. The configlet conditions are also cleared back to empty. The result is indistinguishable from a Plone site on which the add-on was never installed.

Installation

Install collective.lockdown by adding it to your buildout:

[buildout]

...

eggs =
    collective.lockdown

and then running bin/buildout.

Development

Routine tests run at the default level:

bin/test -s collective.lockdown

The upstream permission baseline lives in collective/lockdown/default_permissions.py and is checked against a vanilla Plone fixture by a level-2 drift detector. It is skipped from default runs, because running tests with side effects is unclean, and the data only changes on Plone upgrades. To audit and, if necessary, regenerate the snapshot:

bin/test -s collective.lockdown --at-level 2

On drift, the test rewrites default_permissions.py in place and fails with a diff summary — review and commit the result.

Note that when the default_permissions change, you’ll have to re-run the tests in order for them to pick up the newly generated default permissions correctly.

Contribute

• Issue Tracker: https://github.com/collective/collective.lockdown/issues

• Source Code: https://github.com/collective/collective.lockdown

License

The project is licensed under the GPLv2.

1.1.0 (2026-05-29)

• Switch fully to PEP-420 native namespace.

1.0.0 (2026-05-29)

• Initial release. [gyst]

• Rename from collective.lockdownclassicui -> collective.lockdown [gyst]