[Zope-dev] Re: Member tools refactoring (Was: Better MemberData search for CMF)

[Rob Miller]

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 at zope.org
> http://mail.zope.org/mailman/listinfo/zope-cmf
> 
> See http://collector.zope.org/CMF for bug reports and feature requests
>