[Zope-CMF] Better MemberData search for CMF

[Jens Vagelpohl]

> Currently CMF's MemberDataTool has
>   searchMemberData(search_param, search_term, attributes=())
> but it can only do a search on one attribute. It returns a list of 
> dictionaries.
>
> CMFLDAP's MemberDataTool inherits the one from CMF, and so actually 
> does the search only in cached members. This is a big problem for me.

The way it is done in CMFLDAP stems from how the LDAPUserFolder reacts 
to calls such as getUsers, which will retrieve all users. Calls like 
that are inappropriate and even dangerous for any user folder that has 
a storage with large numbers of records. Zope (and possibly the storage 
backend used by the user folder) will come to a standstill if all of a 
sudden thousands of records come flooding back and they all need real 
Zope user objects created for them.

The LDAPUserFolder has a notion of caching users to avoid the speed 
penalty caused by having to go to LDAP. I made the conscious decision 
to implement getUsers in a way that will only look at the 
currently-cached users. Anything else is potentially disruptive for the 
running Zope or the LDAP backend.


> Plone (in MembershipTool) has
>   searchForMembers(**kw)
> that could search on arbitrary attributes but actually only does it on 
> name, email, roles, and last_login_time. It returns a list of user 
> objects.
>
> CMFLDAP's PloneLDAPMembershipTool seems to be more intelligent than 
> its MemberDataTool and do the full LDAP search, but I'm not sure.

The PloneLDAPMembershipTool's searchForMembers is different in response 
to specific Plone needs. In my opinion it still sucks really bad. If 
you look at the code in searchForMembers in the standard Plone 
membership tool you will see that it does the "dangerous" thing of just 
grabbing all users from the user folder and then looking at each user 
to see if the search criteria fit.

There's another item that makes searching members in a CMF-based portal 
more complicated: Users that you find in the user folder are not 
necessarily members, even if the user seems to have the Member role. 
You always end up having to introspect the MemberData tool to see if it 
has a member data wrapper with the same ID.


> I'd like to propose a standardized API on which we can agree for the 
> future:
>   MemberDataTool:
>     searchForMembers(mapping, maybe_some_options=None, **kw)
> It would search on all the keys of mapping+kw.
> The options would be there to ask for a substring or exact match. To 
> be decided later.
> I'd like it to return a list of users, but this may be problematic 
> from a security point of view. What do you think? Otherwise we could 
> make it take an attributes=('email', 'fullname') args, and return a 
> dict with at least the specified attributes.

If you want to go the "sequence of dictionaries" route then the 
properties as defined on the MemberData Tool should be looked up to 
define a set of standard attributes to return, meaning attributes above 
and beyond the user name.


> A side problem is that this method will have to have knowledge of how 
> to do a search in the user folder. And there are lots of those, with 
> nowhere an standardized API in sight to do search either :-( (actually 
> I don't know any that can do a search appart from LDAPUserFolder). 
> Maybe we could take the oportunity to define one ? Searching for 
> userids, roles, groups (for me), is a prerequisite for me.

A standard API for such searches on the user folders would be a 
prerequisite for any of this so that the user folder, which is the only 
link in this chain that really knows how to make the search efficient, 
can do so. That would completely eliminate that nasty pattern of "I 
will grab all users myself and then look at each user object".

jens
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2355 bytes
Desc: not available
Url : http://lists.zope.org/pipermail/zope-cmf/attachments/20031030/bf71866c/smime.bin