[Zope-CMF] Re: odd __roles__ behavior in certain CMF tools

Tres Seaver tseaver@zope.com
Wed, 13 Feb 2002 00:58:42 -0500


Gary Poster wrote:
> Tres, in one of my products I have a problem that I believe I have traced to
> the following CMF oddity.  These tests are on a Windows Zope 2.5 binary
> distribution, with CMF 1.2.
> 
> What it comes down to is that *all* CMF tools that do not inherit from
> OFS.Folder do not have the __roles__ method defined (even though, of course,
> all of them have been called with Globals.InitializeClass).  This lack of
> __roles__ is evident in pdb both if I traverse down and look at __roles__ in
> the tool instance (I should see nothing or something like
> ['Manager','Anonymous'] but get an Attribute Error instead) and even if I
> look at the classes themselves, as is evident in the following excerpt from
> a pdb transcript:
> 
> 
> pdb> from Products.CMFDefault import URLTool
> pdb> URLTool.URLTool.__roles__
> *** AttributeError: __roles__
> pdb> from Products.CMFCore import SkinsTool
> pdb> SkinsTool.SkinsTool.__roles__
> <Python Method object at 01632B50>
> pdb> from Products.CMFCore import WorkflowTool
> pdb> WorkflowTool.WorkflowTool.__roles__
> <Python Method object at 013E3AD8>
> pdb> from Products.CMFCore import DiscussionTool
> pdb> DiscussionTool.DiscussionTool.__roles__
> *** AttributeError: __roles__
> pdb> from Products.CMFCore import CatalogTool
> pdb> CatalogTool.CatalogTool.__roles__
> <Python Method object at 01632B50>
> 
> Notice, as I said, tools that inherit from OFS.Folder have a __roles__
> method, and the rest don't.  I tested all of the standard tools and this
> held true.  I even discovered that if I add OFS.Folder as a base class to
> one of the non-folder tools then __roles__ suddenly appears for them.  I
> tried to further isolate what the difference was but didn't get very far
> (it's not the OFS.Folder base classes, though).
> 
> Is this correct behavior?  If it is, I'd love to know why, 'cause it's
> giving me grief :-).  If it would be an error but you can't duplicate this,
> I'll clean my distro up and try again to see if it is the effect of one of
> my few installed products, but it's fairly clean already (it's just a
> development installation with OrderedFolder and two custom products).

Hmm, I can see the behavior you report, but I can't see how it
should cause something else to break.  What is essentially missing
is the following line from each of the non-folderish tools::

   security.declareObjectProtected( 'Manage portal' )

Under the covers, this declaration sets the "default" permission
for instances of the class, which ends up getting the '__roles__'
attribute set.  However, all the methods of those tools are protected
by their own permissions, which should guarantee that they are accessed
only by authorized users.  You can see that this is so by examining the
keys of the tool class' dictionary::

   >>> from Products.CMFDefault import URLTool
   >>> URLTool.URLTool.__dict__.keys()
   ['_actions', 'getRelativeUrl', '__call__', 'getPortalObject',\
    'meta_type', 'getRelativeUrl__roles__', '__module__', \
    '__factory_meta_type__', 'getRelativeContentURL', \
    'getRelativeContentPath__roles__', '__ac_permissions__', \
    'manage_overview__roles__', 'icon', 'id', 'manage_overview', \
    'listActions', 'listActions__roles__', \
    'getRelativeContentURL__roles__', 'getPortalPath', 'manage_options', \
    '__call____roles__', 'getPortalPath__roles__', \
    'getPortalObject__roles__', 'getRelativeContentPath']

Can you describe the problem which the absence of '__roles__'
in the class dictionary causes?

Tres.
-- 
===============================================================
Tres Seaver                                tseaver@zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com