[Mailman-Developers] Architecture for extra profile info

[Stephen J. Turnbull]

Richard Wackerbarth writes:

 > The "root" of the tree covers all of the lists.  Under that top
 > node, we might create nodes for "Customer Plans", for example,
 > "Bronze", "Silver", "Gold" and "Platinum".  Each of these nodes
 > would specify some limits that applies to the level of service.

But here the limits apply to *principals*[1], not lists, AFAICS.
Sure, you can record them on the lists, but you'll still have to check
the principal's ID/authorization (presumably site admins can do
anything they want, even to a list owned by a Bronze customer who
can't do it for himself.  Note how you repeatedly write "[principal]
be allowed":

 > Let us assume that the Bronze service plan allows the customer to
 > have only lists set up by the Provider staff.  That user might
 > still be allowed to set other parameters, for example, the
 > subscription policy and the"welcome message".  Under the Silver
 > Plan, a customer might be allowed to set up new lists within their
 > own email-domain.
 > 
 > In both of these cases, a subordinate node would be created under
 > the appropriate "plan" node for the list(s) of that customer.  And
 > under those nodes, we would find various individual lists.

I could see this organization being usable in a case where a customer
wants to have some Bronze-plan lists and some Gold-plan lists.
However, I could also abstract "customer" as a principal which is a
group of accounts with a common billing address.  Then accounts would
be authorized, and the customer would log in as an account-user as
appropriate, rather than log in as a customer-user.  The user
interface could provide a su-like way to switch accounts of a single
customer, and/or a sudo-like way to work with "foreign" accounts.

It's not obvious to me that your way of doing things is better for
this use-case.  If it's not plausible that it's better (I make no
claim that it's not at this point), it fails to justify an experiment
with a generic organization for lists.

 > Another right is the ability to permit the administrator to
 > associate additional persons to nodes within their portion of the
 > tree.  By doing so, that administrator "delegates" the ability to
 > perform certain operations to this added person.

This is more plausible as a use-case, since the "certain nodes" need
not be all the nodes for that administrator.  OTOH, we already have
"list owner" and "moderator" roles, and those *are* attached to each
list.  It's not clear to me that we need to provide for adding
additional roles, but I'll keep it in mind.



Footnotes: 
[1]  A generic term covering users, groups of users, accounts, and in
general "entities that can be authorized".