[Zope-PTK] Membership packaging

[Andrew Kenneth Milton]

+----[ Kevin Dangoor ]---------------------------------------------
|
| I'd like to get some discussion going on packaging up Membership for the PTK
| and as a separate component. I have some time to work on this now, and I'd
| like to see people's thoughts before I start playing around with it.
| 
| Add "Membership" Things to LoginManager?
| 
| Currently, on its own, LoginManager doesn't handle the signing up of users,
| mailing of forgotten passwords, etc. It doesn't even have methods for adding
| users, etc. I get the impression from the TODO file that Ty would like to
| beef up the UI so that it is more readily usable out of the box. It seems to
| me that the easiest way to make Membership a separate component is to take
| the Membership stuff from the PTK, and massage it into an optional component
| for LoginManager.

I think we need a broader concept of what a User is, and we need a
conceptual User Management Product.

Into this product we plug in components like:-

o Login Manager 
     which only does the authentication from User Sources.

o Membership Manager
     which handles roles and stuff like mailing out passwords
     if you've stored them in plain text, or providing the 'hint' questions
     if you've stored them encrypted.

o Property Manager
     This obviously handles the attributes of a user in some way. It
     deals with the storage and retrieval of those properties. So the
     simplest case would be for it to create document in a folder with
     for each username and add properties to it. You could then add a 
     ZCatalog solution, an SQL solution, an LDAP solution etc..

I haven't really given much though about how to plug it all together, but,
I don't think we want some MegaLogin Product that does all of this stuff
as it will get too complicated. If stuff is broken down into smaller plug
ins we get the benefits of 3rd party mix 'n' match stuff. Using LDAP for 
properties, etc.

| Default User Object
| 
| Should the default user be in Python or in a ZClass? Does everyone like the
| current set of properties? (If memory serves, the user properties are: id,
| password, name [should last name and first name be separate fields?], and
| email address).

I prefer to have these things in Python, that's just me.

| How should the portal manager add properties to the user? Should they
| replace the class or extend it through some mechanism (sheet/attribute
| providers?)? If the manager changes the class used for the users, what
| happens to the previously defined users?

See above -- a UserPropertyManager if available.

| To start with, I would probably make the default user object in Python with
| the fields listed above (last name and first name separate). If the manager
| wants more properties, they should probably make their own user class to
| replace the default one, or make their own sheet/attribute provider.

Make it as simple as possible to start and don't wall yourself in :-)

-- 
Totally Holistic Enterprises Internet|  P:+61 7 3870 0066   | Andrew Milton
The Internet (Aust) Pty Ltd          |  F:+61 7 3870 4477   | 
ACN: 082 081 472                     |  M:+61 416 022 411   | Carpe Daemon
PO Box 837 Indooroopilly QLD 4068    |akm@theinternet.com.au|