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
participants (4)
-
Barry Warsaw
-
Richard Wackerbarth
-
Stephen J. Turnbull
-
varun sharma