[triangle-zpug] proxy role for a portal_catalog call

[Chris Calloway]

Edmund Moseley wrote:
> I am trying to adapt the events object to include a rooms field, and 
> then not allow double-booking of rooms.
> I put the room field on a second schemata page, and then call a method 
> which calls the portalCatalog to see which rooms are available, in order 
> to populate the rooms vocabulary.
> This all seemed to work until I login as a member who does not have 
> permission to see all events. I assume I need to assign a proxy role on 
> this method or on the call to the portal_catalog, such that I can always 
> check all existing events to see which rooms are taken.
> How do I set a proxy role on a python method on the filesystem? Is there 
> a better way of accomplishing this?

Good question for a good solution which you explained above, Edmund.

I assume we may or not know about .metadata files in Zope.

Filesystem objects can have associated metadata files. That's how 
filesystem objects get things like titles and security settings, etc..

Metadata files resemble .ini files. That is, they have sections, and 
each section has keyword/value pairs. A metadata file lives in the same 
directory on the filesystem and the filesystem object and has the same 
filename as the object with .metadata appended.

For instance, here is the metata file for the controller python script 
CMFPlone/skins/plone_login/register.cpy (which is 
CMFPlone/skins/plone_login/register.cpy.metadata). This file just 
happens to contain an example of a proxy role (since users who are 
registering to be members need some elevated permissions in order to 
create a new member):

*** begin register.cpy.metadata ***

[default]
title=Register a User
proxy=Manager,Anonymous

[validators]
validators = join_form_validate

[actions]
action.failure=traverse_to:string:join_form
action.success=traverse_to:string:registered
action.prefs=traverse_to:string:prefs_users_overview

*** end register.cpy.metadata ***

So you can see that proxy roles go in the "default" metadata section and 
simply follow the keyword "proxy" with "=" and a comma separated list of 
roles.

If you set this up in the ZMI and then use FSDump to write to the 
filesystem, FSDump will create metadata files for you from what you 
entered in the ZMI. It's a good way to see what metadata keys and 
sections are available. Something useful: you can control cacheing and 
security declarations with metadata files. For validator and controller 
scripts, some of the metadata available are very finely granular.

http://www.zope.org/Members/tseaver/FSDump
http://plone.org/products/fsdump

This is similar to how Joel advised developing workflows with 
DCWorkflowDump. Create all the linkages in the ZMI and use the dumper 
tool to write it out to the filesystem.

Here's some sparse documentation:

http://www.jazkarta.com/technology/plone/plonebook/ch7.rst
http://plone.org/documentation/tutorial/best-practices/tutorial-all-pages
http://plone.org/documentation/tutorial/best-practices/filesystem-development

-- 
Sincerely,

Chris Calloway
http://www.seacoos.org
office: 17-6 Venable Hall   phone: (919) 962-4323
mail: Campus Box #3300, UNC-CH, Chapel Hill, NC 27599