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