[Mailman-Developers] GSOC Project Discussion

[Barry Warsaw]

On May 13, 2013, at 10:52 PM, varun sharma wrote:

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

>2. 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 at example.com and you make a claim to merge aperson at 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