Customizing roles on the sharing tab in 3.0.2

Derek Richardson derek.richardson at
Sun Oct 21 05:30:44 UTC 2007

Derek Richardson wrote:
> Hey. I'm upgrading from 2.5.1 to 3.0.2 and have sharing tab issues.
> My current (2.5.1) site uses roles 'Reader', 'Writer', and 'Owner'. 
> These show on the sharing tab and all my users understand them.
> When I migrate to 3.0.2, I get 'can add', 'can edit', 'can view' and 
> 'can review'. My users will not understand these (my users have limited 
> adaptive expertise).
> So, I want to revert to the old roles. I know I can add them as 
> utilities ala and configure.zcml in 
> That's the note on page 85 of _Professional Plone Development_. (Thanks 
> jonstahl for pointing me at this note!).
> The trick seems to be, not adding my new/old roles, but deleting the 
> old/new roles (the ones added in 3.0). I can write python code to 
> unregister the utilities (I think...). I know of no zcml directive to 
> unregister a utility. This seems like a difficult (and, security-wise, 
> somewhat scary) road to travel. Is there a better way of accomplishing 
> what I want ('Reader', 'Writer', and 'Owner' replacing 'can add', 'can 
> edit', 'can view', and 'can review')?
> ...

I'm replying to my post, rather than Martin's, because I ended up doing 
something that he mentioned on irc but not in his post: overriding the of the sharing view to filter out all roles other than the ones I 
defined. That way I minimize the damage I've done to plone core. The roles don't 
go away and I can always revert to them, they just don't show up as options for 
users to select. This is all working now. Yay!

New questions:

1 - Is there a way to get plone.recipe.zope2instance to install my 
overrides.zcml? The zcml config option doesn't seem to do this and I didn't see 
an 'overrides' option in the docs on pypi. I had to create my slug manually.

2 - So, in the original site, the configuration (not done by me, though, a year 
ago, I wouldn't have known better, either) was done TTW and the existing roles 
were repurposed rather than creating brand-new roles. In my new filesystem 
package that does roles and workflows, I'm defining new roles starting with a 
prefix (that will hopefully remain unique) to now use in the workflows. The 
problem is migrating the old role names and mappings to the new role names. This 
is complicated by the fact that, since we didn't create our own roles but 
repurposed existing ones, I'm betting the 3.0 migrates the repurposed roles to 
be the new roles. If I am wrong in this assumption, then I merely need to 
migrate the old local role assignments to the new names. But, if I'm right, then 
I need to migrate the 3.0-equivalents to the new names. Pointer to the migration 
code (I've never looked either for or at the Plone migration code before)?

Also, I plan to unassign any local role assignments to the stock roles (managers 
should only be assigned at site root and all other roles assigned will (I 
think?) be the new roles). Does anyone see a reason why this is unwise?

3 - In our site, we use workflow to control visibility of items (owner-only, 
owners-readers-writers, all logged in users, and anyone including anonymous). 
We're on an intranet, so content starts out in a fairly restricted state and 
owners can choose to open it up. With the advent of the 'logged in users' 
virtual group in 3.0 (woo hoo!), we can now almost use the sharing tab alone to 
control visibility. This would be a great win, as none of our users really 
understand the workflow + sharing tab combo. The only thing standing in our way 
is the lack of a 'world' virtual group that includes anonymous. I would like to 
write the code for this, but the lack of it in Plone 3.0 gives me pause, as I 
would think that, if this were not a Bad Idea (tm), it would already be there. 
So, is there a solid reason for not doing this?

A promise:

After this gets done, I think I will have written a fairly comprehensive 
security (roles and workflows and sharing tab) package for Plone 3.0. I will 
document this in a How-To on (unless someone convinces me the what 
I've done is horrible and others shouldn't be encouraged to do the same). I 
still feel bad, Martin, for never getting the time to send suggestions for 
improving the testing How-To as I had said I would, so consider this an an 
attempt to compensate. ;)


More information about the Product-Developers mailing list