Re: [Mailman-Developers] GSOC Project Discussion
On May 13, 2013, at 10:52 PM, varun sharma wrote:
- Suspend emails in vacation and post from multiple email ids: IMember interface present in interfaces/member.py is already providing the delivery_status enum in _client module via rest api but the user.save() is currently not functional, so the member preferences are not getting saved right now. Similarly, IUser interface in interfaces/user.py is providing the user.addresses attribute from IAddress interface to _client module but due to the problem of user object not getting saved, this functionality is also not working. For these two features, i don't think there is any requirement from mailman core interfaces.
I think to do vacations right, you will need some additional support in the core. One question to answer first is: what's the scope of a vacation stop? Does it apply to an address, user, member, or all of the above?
For example: when I go on vacation, do I want all deliveries to stop to all mailing lists I'm subscribed to on a particular site, or just to some subscriptions? My thinking is that two use cases would be good to support:
Stop all deliveries from this site for a user. This would mean setting vacation stops for all of the user's subscriptions to all of their mailing lists on a domain (it probably should not be cross-domain).
Stop all deliveries for a specific subscription or list of subscriptions. For example, when I go on vacation, I might want to only receive mailman-developers traffic but nothing else from python.org.
These two use cases imply to me that a vacation stop is tied to a subscription (i.e. an IMember) and a global stop is just a trivial case of a set of specific stops.
A few other core-touching changes:
The expiration date for a vacation stop should be set when the stop is created. A user should not have to do anything to start getting their email again. When the expiration date passes, the traffic starts up again.
You should be able to set a vacation stop to start sometime in the future. E.g. I know I am going on vacation from next Tuesday to Friday, so let me set that up now while I'm thinking about it. Don't make me wait until Tuesday morning when I'm freaking out about catching my flight. :)
You should be able to query the system to see what vacation stops you have coming up, or are in progress. Maybe even view the history of your vacation stops (but that implies more record keeping, so maybe not).
You should be able to adjust the start and end dates of the vacation stop, if they haven't already passed. You could use this to extend a vacation, or change the start date to Monday if you have to leave early. A special case of this would also be to cancel a vacation stop right now.
Remember that vacations shouldn't be used as a way to more permanently disable delivery to a mailing list.
All of this implies to me a new table/record which records future and non-expired vacation stops. The table would have a start and end datetime and a link to an IMember. Then likely the member_recipients.py handler would take these stops into account when calculating who to deliver this message to.
Question: Should you be able to add a vacation stop to moderator or owner emails?
- Merge identities : Not exactly sure about additional core requirements, but i think it can be achieved by expanding IAddress interface.
Mostly this will be able sending out and coordinating the various confirmations messages that will be necessary. E.g. you're logged in as anne@example.com and you make a claim to merge aperson@example.com. You need to prove that you own the latter address too in some way.
Once you've confirmed ownership of both addresses, you need to IUser.link() them both to the same IUser. This may involve unlinking and deleting an obsolete IUser record from an IAddress.
Cheers, -Barry
On May 17, 2013, at 3:16 PM, Barry Warsaw <barry@list.org> wrote:
Question: Should you be able to add a vacation stop to moderator or owner emails?
Would it be easier if we just treated owners and moderators as a couple of additional mailing lists.
In other words, for list XXX@example.com, we also have virtual lists <XXX(owners)>@example.com and <XXX(moderators)>@example.com Where the list names are accessible only from within MM.
Thus a moderator would be subscribed to the <XXX(moderators)> list and that subscription handled just as any other subscription would be handled.
Richard Wackerbarth writes:
Would it be easier if we just treated owners and moderators as a couple of additional mailing lists.
That would require additional, complex attributes that aren't appropriate for most lists to be given to all lists. They'd have to have a .virtual_list_for attribute, for example. If non-null, you can't post to it. (Or can you? Messy.) The owner list would have to have a .cant_delete_last_subscriber attribute. These lists need to be suppressed when working with the set of "real" mailing lists. These lists should be exempted from spam-checking since only Mailman core ever posts to them. (Or should they? See above.) I think this all violates duck-typing and gets messier, not easier.
Thus a moderator would be subscribed to the <XXX(moderators)> list and that subscription handled just as any other subscription would be handled.
I don't think this will fit users' models of the moderator and owner roles. Mailing lists have moderators, not an auto-generated associated mailing list containing only the moderators.
My $0.02.
Steve
I'm not convinced that it would require all of the items that you enumerate.
First, you have to look at how messages might get to the list. Since I specified that the list was a virtual list (unreachable), the only source of messages would be from the internal queue handlers. Thus they would bypass spam filters, etc. and go directly to the distribution queue.
True, we would have to make the lists "hidden" to normal users. But this is not a significant change in list handling. We already have the requirement to hide other lists.
As for "empty lists", that is really a function of how empty lists are handled in general. Perhaps a "divert if empty" policy should be available for all lists. And, at the top of the chain we assure a "last desperation" address because no-one has the right to delete THAT one entry.
I agree that it might be messier. But it still might be cleaner if you want the moderators, etc. to have all of the "subscription options"
On May 17, 2013, at 9:38 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
Richard Wackerbarth writes:
Would it be easier if we just treated owners and moderators as a couple of additional mailing lists?
That would require additional, complex attributes that aren't appropriate for most lists to be given to all lists. They'd have to have a .virtual_list_for attribute, for example. If non-null, you can't post to it. (Or can you? Messy.) The owner list would have to have a .cant_delete_last_subscriber attribute. These lists need to be suppressed when working with the set of "real" mailing lists. These lists should be exempted from spam-checking since only Mailman core ever posts to them. (Or should they? See above.) I think this all violates duck-typing and gets messier, not easier.
Thus a moderator would be subscribed to the <XXX(moderators)> list and that subscription handled just as any other subscription would be handled.
I don't think this will fit users' models of the moderator and owner roles. Mailing lists have moderators, not an auto-generated associated mailing list containing only the moderators.
That all depends on how you present it, not on how you implement it. IIRC, the list of moderators is a roster, just like the subscribers. A different template can make two rosters appear to be quite different.
My $0.02.
2 yen :)
Steve
Richard Wackerbarth writes:
I agree that it might be messier. But it still might be cleaner if you want the moderators, etc. to have all of the "subscription options"
We don't. Some are meaningless (notMeToo, noDups), some should not be available (noMail -- at least not if a vacation facility is available).
I don't contest that there are strong similarities between a "list of moderators" and a "mailing list of subscribers". What I'm saying is that they're not the same, there are several variations on the theme, and we must strongly consider deriving them from a more general type.
I don't think this will fit users' models of the moderator and owner roles. Mailing lists have moderators, not an auto-generated associated mailing list containing only the moderators.
That all depends on how you present it, not on how you implement it. IIRC, the list of moderators is a roster, just like the subscribers. A different template can make two rosters appear to be quite different.
The developers are users too, though. I think the implementation, not just the presentation, should correspond to our notions of "what things are."
Steve
On May 18, 2013, at 12:29 AM, "Stephen J. Turnbull" <stephen@xemacs.org> wrote:
I don't contest that there are strong similarities between a "list of moderators" and a "mailing list of subscribers". What I'm saying is that they're not the same, there are several variations on the theme, and we must strongly consider deriving them from a more general type.
I don't think this will fit users' models of the moderator and owner roles. Mailing lists have moderators, not an auto-generated associated mailing list containing only the moderators.
That all depends on how you present it, not on how you implement it. IIRC, the list of moderators is a roster, just like the subscribers. A different template can make two rosters appear to be quite different.
The developers are users too, though. I think the implementation, not just the presentation, should correspond to our notions of "what things are."
Yes. But, as you note, "what things are" can be viewed as two cases of a "distribution list". And that conceptual object can include more of the characteristics of a mailing list than just "a roster".
It is often useful to look for similarities rather than differences.
Steve
On May 17, 2013, at 04:58 PM, Richard Wackerbarth wrote:
Would it be easier if we just treated owners and moderators as a couple of additional mailing lists.
In other words, for list XXX@example.com, we also have virtual lists <XXX(owners)>@example.com and <XXX(moderators)>@example.com Where the list names are accessible only from within MM.
Thus a moderator would be subscribed to the <XXX(moderators)> list and that subscription handled just as any other subscription would be handled.
This is an interesting question, but let me rephrase it into MM3 terminology to see what we can coax out.
MM3 has this notion of "rosters", and they are a fundamental object in the system, as described by the IRoster interface. Through a roster, you can get at the IMembers, IUsers, and IAddresses which are contained in the roster. You can also look up an IMember from a given email address; if it's in the roster then you get back the matching IMember, otherwise you get None.
Mailing lists point to a bunch of rosters, and this is in fact how the subscriber information is accessed. A mailing list will have:
- an owners roster
- a moderators roster
- an administrators roster (all owners + all moderators)
- a members roster
- a roster of regular delivery members
- a roster of digest delivery members
- a roster of subscribers (all regular + all digest)
- a roster of "non-members"
So, when we want to send a message of a post held for moderator approval, we send that message to every IMember in the administrators roster.
Here's where it gets interesting. Rosters are not modeled as rows in a table, they are modeled as queries. This is cool because you can actually compose rosters, or pull their information from any source, including those external to the core.
One of the use cases for rosters that I've always had in mind are a better way to do MM2-style umbrella lists. Let's say you have one mailing list for all of your band's New York fans, and another for all of your band's San Francisco fans. It should be very easy to compose a parent (i.e. umbrella) list which had a roster combining the New York and San Francisco rosters, and it is this roster that you would deliver to when your new tour was starting.
Another use case: say a site is doing maintenance and they want to inform every subscriber on the system that it will be unavailable for a while. You could easily compose a roster that included every registered (and validated) email to every mailing list, and then you'd send a message to that roster.
I think this same kind of arrangement would work for some of the things that dlists wants to do, or topics, etc. and I'm sure you can come up with a zillion other use cases.
So, in this model, what is "a mailing list"? It's really all the configuration stuff *around* rosters, such as how you send a message to that roster from outside the system, what gets stuffed into Subject headers, and message footers, how do posted messages get transformed on the way to the roster membership, and who gets to send messages to them.
I think this isn't far from what you're asking in your original question, and there's much to explore here. Whether the full power of this can be or should be exposed to the web ui, or the mail boundary, is much fuzzier in my mind. But I can clearly see how a determined developer could make this work pretty easily.
-Barry
OK. Then a "roster" represents the distribution list for a "feed" of outgoing messages. The "mailinglist" represents the reception point(s) for the incoming messages and the directives for handling the processing of those messages.
The thing that hasn't been addressed is how an individual recipient can affect the processing of messages that are processed while he is a member of a roster.
In particular, how do the "user settings" come into play? Presumedly, a user can have different settings for each list to which he is subscribed.
What, if any, individual settings apply to moderator feeds? Are these different from those which apply to the feed that the individual receives as a member of the list?
On May 30, 2013, at 6:07 PM, Barry Warsaw <barry@list.org> wrote:
On May 17, 2013, at 04:58 PM, Richard Wackerbarth wrote:
Would it be easier if we just treated owners and moderators as a couple of additional mailing lists.
In other words, for list XXX@example.com, we also have virtual lists <XXX(owners)>@example.com and <XXX(moderators)>@example.com Where the list names are accessible only from within MM.
Thus a moderator would be subscribed to the <XXX(moderators)> list and that subscription handled just as any other subscription would be handled.
This is an interesting question, but let me rephrase it into MM3 terminology to see what we can coax out.
MM3 has this notion of "rosters", and they are a fundamental object in the system, as described by the IRoster interface. Through a roster, you can get at the IMembers, IUsers, and IAddresses which are contained in the roster. You can also look up an IMember from a given email address; if it's in the roster then you get back the matching IMember, otherwise you get None.
Mailing lists point to a bunch of rosters, and this is in fact how the subscriber information is accessed. A mailing list will have:
- an owners roster
- a moderators roster
- an administrators roster (all owners + all moderators)
- a members roster
- a roster of regular delivery members
- a roster of digest delivery members
- a roster of subscribers (all regular + all digest)
- a roster of "non-members"
So, when we want to send a message of a post held for moderator approval, we send that message to every IMember in the administrators roster.
Here's where it gets interesting. Rosters are not modeled as rows in a table, they are modeled as queries. This is cool because you can actually compose rosters, or pull their information from any source, including those external to the core.
One of the use cases for rosters that I've always had in mind are a better way to do MM2-style umbrella lists. Let's say you have one mailing list for all of your band's New York fans, and another for all of your band's San Francisco fans. It should be very easy to compose a parent (i.e. umbrella) list which had a roster combining the New York and San Francisco rosters, and it is this roster that you would deliver to when your new tour was starting.
Another use case: say a site is doing maintenance and they want to inform every subscriber on the system that it will be unavailable for a while. You could easily compose a roster that included every registered (and validated) email to every mailing list, and then you'd send a message to that roster.
I think this same kind of arrangement would work for some of the things that dlists wants to do, or topics, etc. and I'm sure you can come up with a zillion other use cases.
So, in this model, what is "a mailing list"? It's really all the configuration stuff *around* rosters, such as how you send a message to that roster from outside the system, what gets stuffed into Subject headers, and message footers, how do posted messages get transformed on the way to the roster membership, and who gets to send messages to them.
I think this isn't far from what you're asking in your original question, and there's much to explore here. Whether the full power of this can be or should be exposed to the web ui, or the mail boundary, is much fuzzier in my mind. But I can clearly see how a determined developer could make this work pretty easily.
-Barry
On May 30, 2013, at 06:37 PM, Richard Wackerbarth wrote:
OK. Then a "roster" represents the distribution list for a "feed" of outgoing messages. The "mailinglist" represents the reception point(s) for the incoming messages and the directives for handling the processing of those messages.
The thing that hasn't been addressed is how an individual recipient can affect the processing of messages that are processed while he is a member of a roster.
In particular, how do the "user settings" come into play? Presumedly, a user can have different settings for each list to which he is subscribed.
Yes. Keep in mind though that we have three data types that are associated with a "user" (each of these are described by interfaces in the mailman/interfaces directory). Each email address the system knows about is represented by an IAddress record. An IUser record doesn't have much more than a created_on date, a user_id, a display name, and a password, but it has a number of abstract methods and attributes for convenience.
Addresses are usually, but not necessarily, linked to users in a many-to-one relationship. An address can have at most one user, but a user can have many addresses. A user can also have a preferred address.
IMember records represent subscriptions, and (loosely) tie a mailing list to either an IAddress or an IUser. For the latter, the user must have a preferred address.
Each of these three data types can be associated with a preferences record, and there is a defined order of lookup for any particular preference. From most highest priority to lowest it goes: member, address, user, system default.
So how can a user have different settings for each subscribed list, even if they are subscribed to all of them using their preferred address (i.e. through the IUser record)? Each subscription is represented by a unique IMember record, and each one of those can have their own preferences.
User settings come into play in a number of situations. For example, in the "member-recipients' handler, where we calculate who is going to receive a mailing list message, we'll look at their setting for 'receive_own_postings'. If that's false, we won't add that user to the list of recipients. Similarly, this handler will look at whether their delivery status is enabled and whether they are receiving "regular" (i.e. not digest) deliveries.
User settings may also come into play in the final delivery stage. If the mailing list is set up to do personalization (and/or VERP), then when we're sending the personalized copy, we can pull information out of the user or member record, such as their name and address for full personalization, or other information for custom footers.
What, if any, individual settings apply to moderator feeds? Are these different from those which apply to the feed that the individual receives as a member of the list?
Yes, because the other thing that an IMember associates with the subscription is the role of the subscription. So if you are both a member of the mailing list (you get list postings) and a moderator, then there are two IMember records linking your address/user to the mailing list, but they would have different roles, and each IMember could have different preferences. Moderator/owner delivery doesn't go through the same set of handlers as regular delivery so not everything would honor different preferences. For example, you can't get digest delivery of owner messages.
-Barry
Barry Warsaw writes:
Here's where it gets interesting. Rosters are not modeled as rows in a table, they are modeled as queries. [...]
One of the use cases for rosters that I've always had in mind are a better way to do MM2-style umbrella lists. Let's say you have one mailing list for all of your band's New York fans, and another for all of your band's San Francisco fans. It should be very easy to compose a parent (i.e. umbrella) list which had a roster combining the New York and San Francisco rosters,
Meta: It would be nice if you would distinguish between the meanings of "should" in this kind of discussion. Do you mean
- One requirement for a good admin interface it to make it easy to compose umbrella lists.
or
- This architecture is expected to make it easy for an admin interface to compose umbrella lists.
or both?
On May 31, 2013, at 04:45 PM, Stephen J. Turnbull wrote:
Barry Warsaw writes:
Here's where it gets interesting. Rosters are not modeled as rows in a table, they are modeled as queries. [...]
One of the use cases for rosters that I've always had in mind are a better way to do MM2-style umbrella lists. Let's say you have one mailing list for all of your band's New York fans, and another for all of your band's San Francisco fans. It should be very easy to compose a parent (i.e. umbrella) list which had a roster combining the New York and San Francisco rosters,
Meta: It would be nice if you would distinguish between the meanings of "should" in this kind of discussion. Do you mean
- One requirement for a good admin interface it to make it easy to compose umbrella lists.
or
- This architecture is expected to make it easy for an admin interface to compose umbrella lists.
or both?
#2 mostly. I'd rather not call them umbrella lists in Mailman 3, because I think they'll operate differently and better-ly than in MM2. The current architecture allows for easy composability, although there isn't much support for this in the current code base. I.e. it would mostly be hand-coding right now, but I think the hooks are there.
As to #1 - it would be nice! But probably not a requirement. :)
-Barry
Thanks barry, you have very well explained both the use cases to me.
On Sat, May 18, 2013 at 1:46 AM, Barry Warsaw <barry@list.org> wrote:
On May 13, 2013, at 10:52 PM, varun sharma wrote:
- Suspend emails in vacation and post from multiple email ids: IMember interface present in interfaces/member.py is already providing the delivery_status enum in _client module via rest api but the user.save() is currently not functional, so the member preferences are not getting saved right now. Similarly, IUser interface in interfaces/user.py is providing the user.addresses attribute from IAddress interface to _client module but due to the problem of user object not getting saved, this functionality is also not working. For these two features, i don't think there is any requirement from mailman core interfaces.
I think to do vacations right, you will need some additional support in the core. One question to answer first is: what's the scope of a vacation stop? Does it apply to an address, user, member, or all of the above?
For example: when I go on vacation, do I want all deliveries to stop to all mailing lists I'm subscribed to on a particular site, or just to some subscriptions? My thinking is that two use cases would be good to support:
Stop all deliveries from this site for a user. This would mean setting vacation stops for all of the user's subscriptions to all of their mailing lists on a domain (it probably should not be cross-domain).
Stop all deliveries for a specific subscription or list of subscriptions. For example, when I go on vacation, I might want to only receive mailman-developers traffic but nothing else from python.org.
These two use cases imply to me that a vacation stop is tied to a subscription (i.e. an IMember) and a global stop is just a trivial case of a set of specific stops.
A few other core-touching changes:
The expiration date for a vacation stop should be set when the stop is created. A user should not have to do anything to start getting their email again. When the expiration date passes, the traffic starts up again.
You should be able to set a vacation stop to start sometime in the future. E.g. I know I am going on vacation from next Tuesday to Friday, so let me set that up now while I'm thinking about it. Don't make me wait until Tuesday morning when I'm freaking out about catching my flight. :)
You should be able to query the system to see what vacation stops you have coming up, or are in progress. Maybe even view the history of your vacation stops (but that implies more record keeping, so maybe not).
You should be able to adjust the start and end dates of the vacation stop, if they haven't already passed. You could use this to extend a vacation, or change the start date to Monday if you have to leave early. A special case of this would also be to cancel a vacation stop right now.
Remember that vacations shouldn't be used as a way to more permanently disable delivery to a mailing list.
All of this implies to me a new table/record which records future and non-expired vacation stops. The table would have a start and end datetime and a link to an IMember. Then likely the member_recipients.py handler would take these stops into account when calculating who to deliver this message to.
Question: Should you be able to add a vacation stop to moderator or owner emails?
I think the owner or moderators also should be allowed to use the in vacation suspension of mails from the mailing lists they moderate or own, given all the administrative tasks that need their attention must be added to their ToDo queue. eg: Lets say there is a mailing list that requires moderator's approval for any new user to join. If one of the moderator has set "on vacation" for his account, then he should only get "pending approval request" in his ToDo task list. If some other moderator responds to that request, then it will be automatically removed from the ToDo list of all the moderators, including the one "on the vacation" and the moderator "on vacation" will never know if there was any request.
Also there can be email alerts as soon as some task is added to the ToDo list but if the user is "on vacation" then he will not receive any of these emails until he disables his "on vacation" flag. All the pending ToDo tasks/(tasks done in his absence) may be emailed him at once when he comes back from the vacation.
- Merge identities :
Not exactly sure about additional core requirements, but i think it can be achieved by expanding IAddress interface.
Mostly this will be able sending out and coordinating the various confirmations messages that will be necessary. E.g. you're logged in as anne@example.com and you make a claim to merge aperson@example.com. You need to prove that you own the latter address too in some way.
Once you've confirmed ownership of both addresses, you need to IUser.link() them both to the same IUser. This may involve unlinking and deleting an obsolete IUser record from an IAddress.
Cheers, -Barry
Mailman-Developers mailing list Mailman-Developers@python.org 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/varunsharmalive%40...
Security Policy: http://wiki.list.org/x/QIA9
participants (4)
-
Barry Warsaw -
Richard Wackerbarth -
Stephen J. Turnbull -
varun sharma