Skip to main content

Protect plone sites against site admins

Reason this release was yanked:

Replaced by collective.lockdown

Project description

https://github.com/collective/collective.lockdownclassicui/actions/workflows/plone-package.yml/badge.svg Coveralls https://codecov.io/gh/collective/collective.lockdownclassicui/branch/master/graph/badge.svg Latest Version Egg Status https://img.shields.io/pypi/pyversions/collective.lockdownclassicui.svg?style=plastic:alt:Supported-PythonVersions License

collective.lockdownclassicui

Lock down the Plone classic UI against the Site Administrator role.

This restricts Site Administrator to: manage content, and manage users.

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.lockdownclassicui by adding it to your buildout:

[buildout]

...

eggs =
    collective.lockdownclassicui

and then running bin/buildout.

Development

Routine tests run at the default level:

bin/test -s collective.lockdownclassicui

The upstream permission baseline lives in collective/lockdownclassicui/default_permissions.py and is checked against a vanilla Plone fixture by a level-2 drift detector. It is skipped from default runs 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.lockdownclassicui --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

Maintainers

  • [gyst] Guido A.J. Stevens

License

The project is licensed under the GPLv2.

Contributors

Changelog

1.0.0 (2026-05-28)

  • Initial release. [gyst]

Project details


Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

collective_lockdownclassicui-1.0.0.tar.gz (31.4 kB view details)

Uploaded Source

Built Distribution

If you're not sure about the file name format, learn more about wheel file names.

collective_lockdownclassicui-1.0.0-py3-none-any.whl (12.0 kB view details)

Uploaded Python 3

File details

Details for the file collective_lockdownclassicui-1.0.0.tar.gz.

File metadata

File hashes

Hashes for collective_lockdownclassicui-1.0.0.tar.gz
Algorithm Hash digest
SHA256 5a3ac0842f4904517e39f6cbe48fccb843876c15ee06b753c2ccda2984ad585f
MD5 cd31728b2043ec1c77c94be439e885ff
BLAKE2b-256 60cd329eecffff2c288481fa77322e38838185691f4b92540682a91e1c9d1783

See more details on using hashes here.

File details

Details for the file collective_lockdownclassicui-1.0.0-py3-none-any.whl.

File metadata

File hashes

Hashes for collective_lockdownclassicui-1.0.0-py3-none-any.whl
Algorithm Hash digest
SHA256 ca78ca9968efcad64440bf90532cb7133b47a96961ddf4f0c137893254abe4d4
MD5 78f408365ccae3068463207da5ad046a
BLAKE2b-256 454508c6b16a8908f10507c9f1f04502db5a68f08f6ca7e5135b23b42b93e590

See more details on using hashes here.

Supported by

AWS Cloud computing and Security Sponsor Datadog Monitoring Depot Continuous Integration Fastly CDN Google Download Analytics Pingdom Monitoring Sentry Error logging StatusPage Status page