On Sat, Nov 10, 2001 at 10:33:09PM +0100, abel deuring wrote:

> I had exactly the same problem and solved it this way:
> 1. define a method 'catalog_permission' in the classes of the objects
> that will be indexed:
> 2. define a new Catalog class, with a newly defined method
> searchResults:
> A more reliable implemetation should make sure that only those objects
> are indexed, which define a method catalog_permission. Or
> Catalog.catalogObject could be overloaded to automatically build the
> information to be thrown into the catalog_permission index.

Abel, the code helps a lot, but only if you have unique role-names...
Consider following situation:

o 5 organisations, each one has a folder at the "root" - level
o the most stuff in these folders is accessible by any authenticated user
  i.e. no special roles required
o each folder contains a extra folder that is accessible only to users
  which have the OrganisationMember role (the role is assigned as soon as
  the user  tries to access the contents of the protected subfolder and 
  authenticates himself succefully, the uniqueness of this role is 
  garanteed by an LDAP tree, a user gets the OrganisationMember role only if
  he is in the right organisation)

Now the real problem is, the role is called OrganisationMember (or s.th. like 
that) _everywhere_, so the catalog_permission KeywordIndex returns a list of
roles that are allowed to "View" or "Access Content Information" on the 
specified object, but if the role is called everywhere the same 
(OrganisationMember), I can't restrict the result set to show only 
"allowed" objects because if a user is authenticated in another organisation
he'll get the OrganisationMember role and I can't check the permission
by specifying the catalog_permission index as AUTHENTICATED_USER.getRoles()
anymore... I could trick this behaviour by defining differently called roles for 
all organisations but that's kind of "static", I'd like the system to be

Anyway, thanks for the code, now I have a "base" I can work on :)


Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope )

Reply via email to