Customizing roles on the sharing tab in 3.0.2
derek.richardson at gatech.edu
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 localroles.py and configure.zcml in plone.app.workflow.
> 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
sharing.py 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!
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?
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 plone.org (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