[Mailman3-dev] Problem with the schema

[Barry Warsaw]

On Wed, 2005-03-30 at 10:08, Ian Eiloart wrote:

> Sounds to me like you're thinking that a roster is a property of a mailing 
> list. That must be incorrect, it's the situation that you want to get away 
> from.

Not really, and not the way it's currently designed.  But each mailing
list is created with its own primary member roster, as well as rosters
for its list of owners and moderators.  Rosters can be composed though
and needn't be that closely tied to a mailing list.

> Now, it may be that you want to have some special rosters that exist ONLY 
> for specific lists. For example, when creating a list FOO in domain BAR, 
> you might want to create a roster FOO at BAR_recipients for the default 
> recipient list. you might also want _owners, _moderators, _poster etc. I'd 
> also want an _exceptions: for people who can't get off a roster like 
> "staff", but want off of a particular list.

All good ideas.  Not all are currently embodied in the schema, but some
are (you probably want an ultimate blacklist, e.g. people who should
never ever be sent an email by the system because they've complained).

> While I'm here, it would be nice to have pseudo-users for "posters", with 
> wildcards like *@example.com to allow all local users to post to a list.

I've thought about that.  Although it's not there currently, I think
with our roster design we could support such things (including rosters
which reference external resources that make their recipient lists
available through an interface).

> This scheme would allow you to delete lists without worrying about losing 
> rosters, but maintain 2.x functionality for those that don't care about 
> rosters. You'd delete a list by deleting it's one entry in the LISTS table, 
> all related entries in the ACLS table, and all the special rosters. You 
> could disable a list by flagging it as disabled, or (better) setting a 
> disabled date in the past. Most admins would want to disable a list for a 
> while before deleting it.

Yep, agreed.  A big goal for me is keeping MM3 simple for the common use
cases -- simpler than it is now! -- without sacrificing flexibility and
usability in larger systems.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman3-dev/attachments/20050401/3c296d70/attachment.pgp