[Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

On Apr 28, 2013, at 9:58 PM, Stephen J. Turnbull <stephen at xemacs.org> wrote:

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

That is the case in my hypothetical example. However, the mechanism applies to any property of the lists such as a default value for some user preference.  In my example, the property is, perhaps, "Administrator can/cannot create a new list"
Equally, the content of a "Greeting Message" or the "Default Language", or any other property can be treated in the same manner.

> I could see this organization being usable in a case where ...

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

You seem to be missing the point that "one size fits all", or in this case, one hierarchy, is not a flexible strategy.
By having a generic structure and allowing each installation to customize the hierarchy to fix their individual need, we provide a mechanism that better suits the needs of a larger group of installations.

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

I'm advocating that we attach the roles (whatever they may be) to an entire collection of lists.
The purpose of a hierarchical structure, whether one fixed structure or a generic recursive one, is to provide a mechanism to
assist the "principal" in managing a number of lists that have common properties.

Actually, by establishing a flexible hierarchy, it may be possible to eliminate some of the functionally similar roles. For example, a "Domain Administrator" might be nothing more than a "List Administrator" attached to a higher node in the tree of Lists.