another possible angle on all of this is CMFMember, which replaces the default memberdata tool with one that provides Archetypes-based memberdata objects. this already provides some (most?) of the functionality you're suggesting in the userdirectory tool, i believe. i'm pretty sure that Archetypes and CMFMember are still Plone-specific for now, but i thought i heard rumblings that Archetypes might be considered to be rolled directly into the CMF... if not it could probably be made to at least work w/ CMF-sans-Plone. -r Lennart Regebro wrote:
Hi all!
I'm gonna try to verbalize my thoughts on this subject, but they are still quite fuzzy, so bear with me if I sound confused. :) And sorry for the length of tha mail...
Today there are many parts involved in the Member Data Waltz (or is it a two-step). There is the user folder, of course, there is the portal_membership tool and there is the portal_memberdata tool. So what you do is that you ask the portal_membership tool for the information, but it takes the user object from the user folder (which already keeps contains some user data) and then asks portal_memberdata to wrap the user with it's data. Then there is also the portal_registration tool, who also does most of it's things by asking portal_membership. :)
Missing from this is both the possibility to do transforms of data, and also the possibility to have several user directories, like for example having most users in an LDAP directory, but some users (like managers) local. To solve this, in CPS there is a portal_metadirectories tool involved (I don't know if there are other alternatives to this for non CPS use), so then we have five different "tools", three of which may store some parts of the actual user data, and all which seem to overlap in functionality in different ways.
My suggestion of how to do all this is refactor this into the following pieces:
1. A user folder 2. A user directory tool 3. A membership tool
1. The user folder stays as it is. It will functionally overlap with the user directory a lot, but that is to allow third-party userfolders to still work. I would actually not mind seeing all of the three parts above merged, but I think that should be a Zope 3 thing, in that case.
The search API here need only return a list of userIds, btw. If you want the data, ask the membership tool.
2. The user directory tool would basically be a merge of the memberdata tool and CPS's memberdirectory tool.
It would contain a set of directories. One could be internal, others could be external. For example one LDAP directory, and one Zope directory. These directories should all implement advanced search functionality. The main directory tool would perform a search by calling the searching on all directories.
The tool need to be able to perform transforms. One source may for example store a users fullname in the fields "Name" and "Firstname" another may store it as "Name" and "Family name" and a third just as "Fullname". The tools would need to be able to create a "fullname" property out of these properties.
The data may need to be merged for all the users, since you may want to store user data in the Zope directory also for LDAP users. Or maybe this is overkill, I'm not sure.
3. A membership tool, that merges todays membership tool with the registration tool. Again, I think this really should belong in acl_users, but that is not feasible for Zope 2.
OK, flame away!
//Lennart
_______________________________________________ Zope-CMF maillist - Zope-CMF@zope.org http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests