[Zope-PTK] PTK, LoginManager and user maintenance

[Dan L. Pierson]

Kevin Dangoor writes:
 > IMHO, people should be able to add "Membership" as a feature to any site. I
 > could see people wanting this, independent of any other PTK pieces. I think
 > the "Membership" component can be designed to only use LoginManager.

I agree about wanting membership as a separate site feature.  I'm glad 
that you agree that it can require LoginManager.  Let's see if anyone
else screams...

 > In general, I don't think the parts of the PTK care where member objects are
 > coming from (and they shouldn't). Applications built on top of Zope
 > (including the parts of the PTK) automatically know who the user is and what
 > roles they possess, and that should be generally sufficient.

No, they shouldn't care.  All they need to care about is that they can 
get the user object and that it has certain methods and properties and 
property sheets.
 
 > I'm not sure what the best way is to create an easily plugged in Membership
 > system that automatically creates a LoginManager with the appropriate user
 > management functions. That's something to think about... But, once we figure
 > that out, then the Portal can just create one of those when it is
 > instantiated.

Ah yes, this is the rub.  To really make a plug in Membership system
like you describe we have to be able to replace the root acl_users
with our own correctly configured LoginManager.  Deep magic :-(

Or do we?  Would you really want members to have their access info in
the root?  That means that a member with Manager role (which might be
needed to manage her home page) could manage the whole site.  Bad,
very bad.  Of course this is the wrong way to set things up.  PTK
currently only gives a member 'Member' role, then uses Local Roles to
make them the owner of their home folder.  Still, I'm uncomfortable
with automagically replacing the root acl_users, even if it is
possible.

Other than the root problem, a pluggable Membership system doesn't
seem tooooo hard.  It does have to either create or replace acl_users
wherever it's installed (create is probably better), or be able to
modify an existing LoginManager to support its requirements (e.g. by
adding Specialist methods, UserSource(s) and/or calling
manage_setStorage on an existing UserSource).  From my 
recent discussion with Phil, the later doesn't sound impossible.