Ticket #10878 (closed PLIP: fixed)
Add "Site Administrator" role
Reported by: | davisagli | Owned by: | davisagli |
---|---|---|---|
Priority: | major | Milestone: | 4.1 |
Component: | General | Version: | |
Keywords: | Cc: | plip-advisories@… |
Description (last modified by jonstahl) (diff)
Proposer: David Glick
Seconders: Jon Stahl, Karl Johan Kleist
(This is a revised version of #9578.)
Motivation
There is a class of user who should have full access to manage content and configuration in a Plone site, but who should be protected from access to places where they are more likely to cause harm than good (such as the ZMI). This use case has been identified by consulting firms such as my own employer, Groundwire, who have expressed a desire to be able to give someone almost full Manager access to a site, but remove certain permissions. None of Plone's existing roles fills this need.
Proposal & Implementation
We propose adding a new role, Site Administrator, which grants most but not all of the permissions of the Manager role.
Persona: Jane - "Site Administrator". Jane is the "website responsible person" for a small/midsized Plone site. She's not a developer, or even an integrator, but coordinates with other people who play those roles. She is responsible for supervising the content creation and editing process. As such, she needs to be able to administer all of the content management aspects of her Plone site, but should not be able to do access things that assume system administration or Plone integrator/developer skills.
Things Jane should be able to do:
- Generally, do all things that a Manager can do, except...
Things Jane should not be able to do:
- Use the "Maintenance" control panel.
- Get to the ZMI
- Add/remove products
- Change themes
- Change cache configuration
Implementation & Deliverables
Implementing this proposal will proceed roughly as follows:
- Audit the current set of permissions to determine which should be enabled for the Site Administrator role [done]
- Audit items currently protected by the "Manage portal" permission to determine if some of these need to use a more specific permission to allow granting access to Site Administrator without giving Site Administrator "Manage portal". (For example, permission to view various control panels will need to be adjusted in this way.) I will also deprecate plone_control_panel.pt and implement the main control panel overview as a browser view, to aid in the permission change. [done]
- Assign the list of desired permissions to the Site Administrator role, either via rolemap.xml or by modifying import-time calls to setDefaultRoles in various packages (I'm not sure if this works for roles other than the default Zope ones). [done]
- Update the default workflows to assign their managed permissions correctly to the Site Administrator role. [done]
- Make adjustments to the users and groups control panels to ensure that there's no risk of privilege escalation. [done]
- Determine and document a best practice for how add-on products should make use of the Site Administrator role, in regards to custom permissions' default roles and to custom workflows. [decided, but not yet documented]
- Write upgrade steps to update the rolemap and workflows for pre-existing Plone sites. [done]
Risks & Assumptions
- Add-on products with custom permissions or workflows may need some updates to support the new role. I will try to ensure that non-updated products continue to work fine (with the exception of lacking support for use by Site Administrators), and that updated products can continue to work fine in 4.0.x.
- A reindex of the allowedUsersAndRoles index will be required when upgrading.
- The proposed name of the role should be considered irrelevant until we're done discussing the meat of the proposal. We can easily change the name at any point during implementation; please save your bikeshedding for later. ;)
Participants
David Glick
Progress
Shipped in Plone 4.1!
Change History
comment:1 Changed 6 years ago by davisagli
- Status changed from new to assigned
- Description modified (diff)
comment:2 Changed 6 years ago by elvix
This is an important feature that we have needed for a long time. I'll be happy to volunteer for testing.
comment:3 Changed 6 years ago by dukebody
I didn't have time to work on this myself, but count me in for discussion and testing. Could we protect each configlet with a different permission to have granular permissions in the control panel?
comment:4 Changed 6 years ago by jonstahl
Just a note that we should probably think about doing some auditing of important add-on products, and then pro-actively notify relevant product maintainers about how nice it would be for them to update their products to support this new role, and provide some clear instructions for how to do so. I'm volunteering for the auditing + notifying. ;-)
comment:10 follow-up: ↓ 11 Changed 6 years ago by ldr
alecm makes the point that SiteAdmin's must be prevented from adding Manager level users.
comment:11 in reply to: ↑ 10 Changed 6 years ago by davisagli
Replying to ldr:
alecm makes the point that SiteAdmin's must be prevented from adding Manager level users.
Or adding users to any groups that grant the Manager role, presumably. Noted.
comment:12 Changed 6 years ago by davisagli
(In [38799]) Add a new permission that grants access to the control panel for the SiteAdmin and Manager roles, and use it to protect the control panel and its actions. To facilitate this the control panel is now a browser view in plone.app.controlpanel called overview-controlpanel (mostly implemented previously by hannosch). plone_control_panel.pt is retained for backwards compatibility as a stub that calls the new view. refs #10878
comment:13 Changed 6 years ago by davisagli
comment:14 Changed 6 years ago by davisagli
- Description modified (diff)
Updated implementation section to indicate current status.
comment:15 Changed 6 years ago by esteele
Your PLIP has been accepted for consideration for Plone 4.1.
Framework Team voting on this PLIP was: Alec +1 Craig +1 Elizabeth +1 Laurence +1 Martijn +1 Matthew +1 Rob +1 Ross +1
The initial implementation deadline for your PLIP is October 1st, 2010. The Framework Team would certainly appreciate you finishing beforehand so that they may begin evaluating it as soon as possible. Announce its readiness here once your implementation is ready for review.
comment:16 Changed 6 years ago by sirgarr
This is an awesome PLIP.
One major challenge is that the "Manage users" permission is a super-permission -- if a role has this permission, than any user with that role can promote themselves to a Manager and go onto World Domination. But this permission is used in a great number of places, so teasing out a separate permission for it is a whole task in itself.
comment:17 follow-up: ↓ 18 Changed 6 years ago by jonstahl
David-
An email from Victor Fernandez de Alba at UPC Barcelona pointed out the importance of letting Site Admins manage Content Rules. He wrote:
We recently need to allow non-manager users the ability to create content rules in one of our large deployments. We realised that this is currenly not entirely possible due to some limitations in plone.app.contentrules although the existence of the "Content Rules: Manage rules" permission. The ZCML definitions of the rule conditions views are asuming that only a manager could add a condition to a rule and they are set to the cmf.ManagePortal permission. This setting is preventing managers to delegate content rule feature to be delegated. Of course, it's easy to override this from a custom product, but it seems that this is a desirable feature to have on Plone by default.
comment:18 in reply to: ↑ 17 Changed 6 years ago by davisagli
Replying to jonstahl:
The ZCML definitions of the rule conditions views are asuming that only a manager could add a condition to a rule and they are set to the cmf.ManagePortal permission.
I've already fixed this in my branch of plone.app.contentrules for this PLIP.
comment:19 Changed 6 years ago by davisagli
comment:20 Changed 6 years ago by davisagli
comment:21 Changed 6 years ago by davisagli
comment:22 Changed 6 years ago by davisagli
comment:23 Changed 6 years ago by davisagli
comment:24 Changed 6 years ago by davisagli
comment:25 Changed 6 years ago by davisagli
comment:26 Changed 6 years ago by davisagli
comment:27 Changed 6 years ago by davisagli
comment:28 Changed 6 years ago by davisagli
comment:29 Changed 6 years ago by davisagli
comment:30 Changed 6 years ago by davisagli
comment:31 Changed 6 years ago by davisagli
- Description modified (diff)
updated status in description
comment:33 Changed 5 years ago by eleddy
comment:34 Changed 5 years ago by davisagli
Responses to eleddy's review notes:
Upgrade failed on both existing sites from configuration 4100 to 4015. No obvious errors - not sure what happened. I am happy to help debug this. All I did was create a site in the 4.1 branch, zope 2.12, add a site, then run the plip buildout and restart. None of my sites successfully upgraded.
The PLIP branch of plone.app.upgrade needed to be updated since the release of Plone 4.0.1. Please update and try again.
WRT the upgrade I don't agree with automatically reindexing the allowedRolesAndUsers index. I am open to discuss this but this would kill large sites. I don't know how other people manage this but I know I have custom lazy workflow upgrading hacks in several large projects. Is there a way to make this optional or to make a decision based on the number of objects for example? This is especially important for projects that may not need or see the benefit of SiteAdmin and won't upgrade because of it.
Not reindexing by default would be a departure from the implicit policy we've had in the past regarding upgrades ("keep beginners from needing to think about upgrades as much as possible"), which I think is a good default. (The people who need to skip expensive upgrade steps are generally more capable of figuring out how to do so than people who don't are of figuring out that they need to run some extra upgrade step.) I'm open to adding some way to opt into disabling this, but would like input from the framework team on the best way to do that, so that I don't invent something just for this one case. Maybe an environment variable which causes expensive upgrade tasks to skip themselves and instead print a warning indicating what was skipped?
SiteAdmin can edit portlets, but cannot manage viewlets. Is this by design? I don't want to get into a bikeshed argument - just confirming.
Yes, that's by design. (Too easy to break the site via @@manage-viewlets.) If desired I could at least switch it to use a custom permission so that access to manage-viewlets can be granted to SiteAdmins in a customized rolemap.
The control panel at 'plone_control_panel' lists two "Users and Groups", one pointing to @@usergroup-userprefs and the other to @@usergroup-groupprefs. I don't know if this is a result of this plip or not but it is very confusing since they have the same icon and title.
This was a bug introduced with the move of the control panel overview to a browser view -- it was no longer checking the 'visible' flag of control panel actions. I've fixed this.
In the Users Overview control panel, clicked 'add new user' and added another user to the Site Adminstrators group. On reload, the user was added but their inherited role was not displayed (it was not checked, and the plone symbol wasn't there either). So I investigated and it looks like the groups are not getting assigned for reviewers or site admins. Clicking on the user and adding to the group manually works as expected.
Hmm, I couldn't reproduce this issue -- when I try the new user is added to the Site Administrators group and the "inherited role" symbol shows up.
Now this is a bikeshed argument but the version of this role that everyone sees is "SiteAdmin" (no space), which is small but reminds me of when plone roles we equivalent to going to your own beheading. Any way we can put a space in here, or, restrict it to one word so it feels refined? This is for sure small and I assume there is something ridiculous to make this small change so I won't argue too hard for it.
I'd prefer not to rename it unless absolutely necessary. :)
With the new site (the non upgraded is fine) there is an error trying to register as a new user (enable self registration on) that could be from redoing forms: ComponentLookupError: ((<Products.CMFDefault.formlib.schema.FileUpload object at 0x10aec1210>, <HTTPRequest, URL= http://localhost:8080/roels/@@register>), <InterfaceClass zope.formlib.interfaces.IInputWidget>, u)
The new registration form from plone.app.users doesn't work if you select a file upload field (such as portrait) at /@@member-registration. This is a bug which is present in existing Plone 4 releases and is unrelated to PLIP 10878. (FWIW, I suspect it's because formlib doesn't have a widget for this type of field, so should be solved when these forms get switched to z3c.form.)
comment:35 Changed 5 years ago by davisagli
comment:36 Changed 5 years ago by cah190
comment:37 Changed 5 years ago by alecm
comment:38 Changed 5 years ago by davisagli
- Status changed from assigned to closed
- Resolution set to fixed
comment:39 Changed 5 years ago by davisagli
- Description modified (diff)
- Summary changed from Add "SiteAdmin" role to Add "Site Administrator" role
Updated description to reflect the renamed role (now "Site Administrator" instead of SiteAdmin)
Add Karl as seconder.