[Zope-PTK] PTK, LoginManager and user maintenance

[Kevin Dangoor]

----- Original Message -----
From: "Dan L. Pierson" <dan@sol.control.com>
To: "Kevin Dangoor" <kid@kendermedia.com>
Cc: "Phillip J. Eby" <pje@telecommunity.com>; <zope-ptk@zope.org>
Sent: Wednesday, May 24, 2000 1:59 PM
Subject: Re: [Zope-PTK] PTK, LoginManager and user maintenance


> 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...

Just because the PTK Membership component would require LoginManager
certainly doesn't mean that people can't use other systems... That's the
great thing about breaking everything out into components. People can still
make use GUF or UserDB or whatever to handle their site membership, and the
other PTK components should work just fine as long as the users are
configured as required.

>  > 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 :-(

It shouldn't really be deep magic. I think pre-2.2, this would have been
easy... If you can delete the acl_users and then add a LoginManager through
the management interface, then you can do it programmatically, too. Of
course, you have to be logged in as superuser, and that's where the problem
comes in with 2.2. I'm sure we'll find a way though.

(Now, if you're talking about trying to migrate users from the roo
acl_users, that would take a bit more work... I'll leave that as an exercise
for the reader :)

> 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.

Some people will want their membership system in the root. Like you said,
you don't really want to go around giving people the Manager role in
general. Since the Membership thing would be a "component" it should really
care where you put it. You could have as many of these Membership things as
you want. (Though users might get annoyed if they already signed up for your
mailing list in one place and have to sign up for your bulletin board
separately :)

> 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.

Hmm... It seems like the cleanest place would be to have the Membership
system defaults to be an option when you're adding LoginManager. Maybe if we
put together all of the default packaging, we can convince Phillip to plug
it in to LoginManager.

Kevin