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". _______________________________________________ Mailman-Developers mailing list [email protected] http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
