[Mailman-Developers] Re: TOPICS
05 Mar 1999 18:35:36 +0100
[Paulo Eduardo Neves]
> Harald Meland wrote:
> > Anyhow, I guess that implementing this would be a lot easier (and
> > cleaner) if every list member had some "user objects" -- and that is
> > planned for after 1.0. So I guess we'll think about it all until we
> > have the infrastructure to implement it on top of in place.
> I've read in the TO-DO list about User profiles, is it the same of user
Not quite, but they're not unrelated, either.
> Could you explain the idea behind it?
Well, the motivation I have for implementing "user objects", is that I
don't want one particular user that is subscribed to several Mailman
mailing lists (on the same Mailman installation) to have to remember
one password per list.
If Mailman had an installation-wide database of all members subscribed
to any of the lists, and each list had "pointers" pointing to specific
user objects in this database (meaning that the users corresponding to
the pointed-to objects are members of the pointing-from list), the
user password could be kept in the user object instead of with each
You'd also get a lot of other benefits from this, of course:
* User objects could know about the different mail aliases belonging
to one user (meaning that Mailman would know that
`firstname.lastname@example.org' and `email@example.com' were really
the same user, which is very handy for "restrict posting privilege
to list members")
* Admins are users as well -- thus their _single_ admin password,
which would work for all the lists they admin, could be stored in a
(special) user object. Lists with multiple admins wouldn't need
their admins to share the single list password anymore.
* If some person changes email address, update the person's user
object -- and all the mailing lists the person is a member of
automatically goes to the new address. Ditto for disabling
delivery when going on vacation etc. Having separate settings for
different lists should of course remain possible.
... just to mention a few things.
None of this is set in stone, of course -- these are just some ideas I
have, nothing has actually been implemented.
"Member profiles", I think, means that you each user can organize
their subscriptions into hierarchies (within their user object) --
thus, any changes made to the root node in the hierarchy gets
inherited by all your subscriptions.
* Root node
* Python mailing lists
* "Mailman-users" subscription options
* "Mailman-developers" subscription options
* Work-related mailing lists
* "postmaster" subscription options
* "hostmaster" subscription options
* "webmaster" subscription options
Your local mail system has recently been upgraded to support
addresses of the form `firstname.lastname@example.org', signifying that
mail to this address goes directly into your IMAP folder called
You want to use separate mail addresses for the python lists and the
work-related lists -- so you enter each of these "member profiles"
and update them, and the changes propagate down the tree to the
different lists. Voila :)
> I believe it would solve well a problem I have. I have an announcement
> list where I send messages about a lot of topics. Not all topics are of
> interest of all subscribers (i.e. Joe doesn't want to know about events
> in other state).
> It looks like user profiles (or Topics) would solve this problem.
Topics are not the same as member profiles. The (hypothetic) user
"Topics" setting are meant to signify what subset of messages you want
to receive from a topic-enabled Mailman list, while member profiles
are for specifying defaults for subsets of your list subscriptions
(regardless of whether the subscribed-to lists are topic-enabled or
I was merely stating that for implementing topics, one needs to keep
so much user-specific information (on what topics are deemed
interesting) in Mailman, that keeping off implementing it until
_after_ the introduction of user objects (which will provide a handy
mechanism for storing user-specific information) would seem like a