[Mailman-Developers] GSOC Project Discussion

[varun sharma]

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 at list.org> wrote:

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

>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
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers at 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%40gmail.com
>
> Security Policy: http://wiki.list.org/x/QIA9
>