in Plone 2.05, the membership has a key function, setLocalRoles, which 
in effect implements the Sharing tab.

It seems to ignore Proxy Roles (i.e. if I call setLocalRoles from a 
script that is proxied as Manager, it nonetheless fails the "if 
'Manager'" test below.)

My problem is that I have Project Owners (who are not Managers), and I 
want to let them assign Customer roles on certain folders to other users.

Options:

    - Make the Project Owners "Customers" on their own projects (works, 
but it's confusing, and may trip me up later)

    - monkey patch the code below, so that it checks if the Manager role 
is proxied in the calling script (** How would I do this?**)

    - or ???

Thanks.
[...]
[...]

On Wednesday 07 September 2005 07:03 pm, Christoph Berendes wrote:[...]

AFAICT from a quick peek, getRolesInContext does not show proxy roles. 
Which makes sense, sorta--they don't have that role in their context 
(context==object they're being called on).

Current logic in setLocalRoles is:

- check the roles you have. If it contains "Manager" or the role you want 
to assign, allow it

A reasonable substitute would be:

- check for the "Manage portal" permssion, and get the roles you have. If 
you can "Manage portal" or have the role you to assign, allow it

I actually liike that better--I dislike magic use of the "Manager" role. 

Happily, the "validate" method call (find all the details in 
AccessControl, in lib/python) *does* check for proxy roles, so this 
should work fine.

So, you could either (a) patch setLocalRoles, above, or (b) monkey-patch 
it, or (c) write an ExternalMethod that you call instead of 
setLocalRoles, and you handle the permission checknig yourself, then just 
go ahead and do the rest of setLocalRoles in your ExtMethod.

Possible that we're missing something more obvious, though. Might want to 
take this one for a quick spin on the Zope list and make sure my advice 
doesn't suck.

HTH. let me know if I'm too opaque here.

- j.
[...]

You're missing the patch for "checkPermission" that I submitted that
fixes this (honors proxy roles).  You could lobby with Zope corp to get
my patch incorporated as below...  See issue ZC #1774
(http://www.zope.org/Collectors/Zope/1774).
 Regrettably, it does not
seem to be getting put into the core yet, but if some other people were
to ask, it may press the bug a bit.

Thanks,
Tim

-----Original Message-----
From: Joel Burton [mailto:joel(at)joelburton.com] 
Sent: Wednesday, September 07, 2005 7:24 PM
To: zpugdc(at)lists.zpugdc.org
Subject: Re: [ZPUGDC] setLocalRoles seems to ignore proxy_role settings

On Wednesday 07 September 2005 07:03 pm, Christoph Berendes wrote:[...]
[...]
[...]

AFAICT from a quick peek, getRolesInContext does not show proxy roles. 
Which makes sense, sorta--they don't have that role in their context
(context==object they're being called on).

Current logic in setLocalRoles is:

- check the roles you have. If it contains "Manager" or the role you
want to assign, allow it

A reasonable substitute would be:

- check for the "Manage portal" permssion, and get the roles you have.
If you can "Manage portal" or have the role you to assign, allow it

I actually liike that better--I dislike magic use of the "Manager" role.


Happily, the "validate" method call (find all the details in
AccessControl, in lib/python) *does* check for proxy roles, so this
should work fine.

So, you could either (a) patch setLocalRoles, above, or (b) monkey-patch
it, or (c) write an ExternalMethod that you call instead of
setLocalRoles, and you handle the permission checknig yourself, then
just go ahead and do the rest of setLocalRoles in your ExtMethod.

Possible that we're missing something more obvious, though. Might want
to take this one for a quick spin on the Zope list and make sure my
advice doesn't suck.

HTH. let me know if I'm too opaque here.

- j.

--
Joel Burton - joel(at)joelburton.com
Independent Zope/Plone/Content Management Consultant Chair, Plone
Foundation (http://plone.org/foundation)

--
To unsubscribe send an email with subject 'unsubscribe' to
zpugdc(at)lists.zpugdc.org.
Please contact zpugdc-owner(at)lists.zpugdc.org for questions.
http://zpugdc.org/lists/zpugdc/archive/2005/2005-09/1126133916644/112613
5380696