[Zope-PTK] Getting it all to work ;-)

Bill Anderson bill@libc.org
Wed, 28 Jun 2000 12:45:03 -0600


Shane Hathaway wrote:
> 
> Kevin Dangoor wrote:
> > The problem is that with LM by itself, you can't just add a user like you
> > can with a UserFolder. So, if UserFolder was replaced by LM now, people
> > could download and install Zope, but they wouldn't be able to add any
> > objects until they figure out how to add a user to the LoginManager (because
> > objects can't be owned by the superuser in 2.2).
> 
> Actually, yes you can.  "Special" objects like an acl_users folder can
> indeed be owned by the superuser, as well as any objects created inside
> them.  Last I checked, with the patch to LoginManager, you can replace
> the root acl_users and have the superuser own it and any objects inside
> it.
> 
> The real issue is that ZPatterns is not stable, and LoginManager is
> based on ZPatterns.
> 
> > I guess it could be like a rite of passage... "Hey, I just managed to add a
> > user, and now I can add DTML Methods!" :)
> 
> Reply: "Now try to configure ZClass permissions--without good docs!"
> Arghhh.  Oh well, I finally figured out the permissions problem (I've
> been battling it for a couple of days), now I've got another snag on
> the wizardry... but I'll probably find a fix soon.
> 
> > The forms for joining, emailing forgotten passwords, changing passwords,
> > etc. There should be some UI routines for managing users, but those don't
> > exist yet. Those forms used to be in DemoPortal, but it seemed like
> > functionality that people would probably really like to have, even if they
> > don't need to set up a whole PTK-style Portal.
> 
> On a related note: Can someone tell me why it is that PTK has been
> designed to store information about users in the user objects?  Why not
> store the preferences in the member folders?  Wouldn't that be easier
> and more logical??


What about sites/portals that don't have or need folders for members to
put content in? Slashdot-like sites come to mind as an example. You want
to store member data, but not provide a folder for them.

What if the username changesm whilst the uid stays the same? Could
obliviate the member folder's usefullness, as it retains a
username==membername mapping, as opposed to a uid->username mapping.
Uhh... I hope that was clear enough....