[Zope-dev] Re: _setName issue (was declarePrivate doesn't)

[Shane Hathaway]

Chris Withers wrote:

>I remember you raising the issue requiring _setName, so I geuss you're the man
>to ask when it doesn't work ;-)
>
>>From the SQL class in SQL.py:
>
>    manage=manage_main=DTMLFile('dtml/edit', globals())
>    manage_main._setName('manage_main')
>
>    __ac_permissions__=(
>        ('Change Database Methods', ('manage', 'manage_main')),
>    )
>
>Now, I subclass this to make my FS ZSQL Method and haev the following in the
>subclass:
>
>    # Make mutators private
>    security.declarePrivate('manage','manage_edit','manage_advanced')
>    
>    security.declareObjectProtected(View)
>
>    security.declareProtected(ViewManagementScreens, 'manage_main')
>    manage_main = Globals.DTMLFile('custzsql', _dtmldir)
>
>So, manage_edit and manage_advanced have indeed become private..
>
>..but '/manage' still brings me up the edit form on my FS ZSQL Method.
>
>Why? I wondered...
>
>Well, in SQL.py, there's a _setName to make manage use the manage_main name,
>which in my subclass is protected by ViewManagementScreens. So, this seems to
>take precendence over the declarePrivate.
>
>That feels like a bug to me, what do otehr people think?
>
It's ugly, but it's working correctly.  When 
ZopeSecurityPolicy.validate() checks whether you can access the 
attribute you retrieved by the name "manage", it finds an attribute 
whose name is supposed to be "manage_main".  So it checks whether you 
can access the name manage_main, and you can.  Sometime we should look 
into whether we can change this odd behavior without breaking stuff.

I suggest there's no reason to use the name manage_main for your 
"custzsql" method.  Call it "manage_customize" or something similar 
instead, then make sure manage_options lists manage_customize first. 
 Declaring the name "manage" to be private actually has no effect, but 
declaring manage_main to be private would.

Shane