Launchpad itself

Bug #246022
Comment #5

Comment 5 for bug 246022

Revision history for this message

Barry Warsaw (barry) wrote on 2009-01-12: Re: Cannot contact all members of a team at once

Sorry Curtis, a few of the typos in your comment are making it a little hard to follow, but let me see if I understand your proposal. (e.g. there's no get_contact_email_addresses method).

You'd like to be able to send one message to the mailing list, and have the Mailman side use something in the email to determine what set of recipients to send the message copy to. If the message is created on Launchpad, adding some tag that Mailman could recognize would not be difficult. Heck, we could even stick in the 'Urgent:' header that Mailman already recognizes.

The problem is that Mailman really has just one list of members and it has no knowledge of which addresses belong to which people. It does know which addresses are disabled and which are enabled, and we use this trick to allow all team members to post to the list from any of their validated addresses, but limit delivery to just those that are explicitly subscribed. "Explicitly subscribed" are just the Mailman list member addresses that are enabled.

We could definitely use the Urgent: header approach to, as I said, bypass the disabled flag check, but it means every list member will get a delivery at every address they've validated with Launchpad. I for example would get 7 copies, which doesn't seem like a good idea.

I think to do what you're proposing, you'd have to dynamically update the Mailman list of members whenever you had an Urgent message to deliver, but that seems infeasible because you'd also have to reset the mailing list's membership flags once the urgent message is delivered.

I can think of some hacks of various complexity and effectiveness to make this work. We could hack Mailman to track the launchpad id for each address it knows about, then do de-duping on those when the Urgent message came in. That'll mean a non-standard list attribute and an extension of the xmlrpc protocol to communicate that information to Mailman. Or we could use the Real Name (i.e. displayname) to de-dup, but that's not really going to work and would require some custom code too.

Another way to do this would be to utilize Mailman's bin/inject program, or the Python API to that command. That API accepts a list of explicit recipients which overrides the recipients normally calculated by Mailman. The problem here is that the Launchpad side doesn't have access to that because the systems are separated. So Launchpad can't directly call that method or command. We could however extend the xmlrpc protocol between the two systems to add a 'send_urgent_message' action. When Mailman saw this action during it's normal LP polling loop, it would have to get the team name, message text, and recipient list. Then it would parse the message and call the inject() method with the explicit list of recipients.

That's probably the least hacky way to do it, and thinking about it now, it's the way I'd recommend implementing it, if you don't want to bypass the mailing list. Though I'd still like to explore the bypass-the-mailing-list approach. :)

Sorry Curtis, a few of the typos in your comment are making it a little hard to follow, but let me see if I understand your proposal.  (e.g. there's no get_contact_email_addresses method).

You'd like to be able to send one message to the mailing list, and have the Mailman side use something in the email to determine what set of recipients to send the message copy to.   If the message is created on Launchpad, adding some tag that Mailman could recognize would not be difficult.  Heck, we could even stick in the 'Urgent:' header that Mailman already recognizes.

The problem is that Mailman really has just one list of members and it has no knowledge of which addresses belong to which people.  It does know which addresses are disabled and which are enabled, and we use this trick to allow all team members to post to the list from any of their validated addresses, but limit delivery to just those that are explicitly subscribed.  "Explicitly subscribed" are just the Mailman list member addresses that are enabled.

We could definitely use the Urgent: header approach to, as I said, bypass the disabled flag check, but it means every list member will get a delivery at every address they've validated with Launchpad.  I for example would get 7 copies, which doesn't seem like a good idea.

I can think of some hacks of various complexity and effectiveness to make this work.  We could hack Mailman to track the launchpad id for each address it knows about, then do de-duping on those when the Urgent message came in.  That'll mean a non-standard list attribute and an extension of the xmlrpc protocol to communicate that information to Mailman.  Or we could use the Real Name (i.e. displayname) to de-dup, but that's not really going to work and would require some custom code too.

Another way to do this would be to utilize Mailman's bin/inject program, or the Python API to that command.  That API accepts a list of explicit recipients which overrides the recipients normally calculated by Mailman.  The problem here is that the Launchpad side doesn't have access to that because the systems are separated.  So Launchpad can't directly call that method or command.  We could however extend the xmlrpc protocol between the two systems to add a 'send_urgent_message' action.  When Mailman saw this action during it's normal LP polling loop, it would have to get the team name, message text, and recipient list.  Then it would parse the message and call the inject() method with the explicit list of recipients.

That's probably the least hacky way to do it, and thinking about it now, it's the way I'd recommend implementing it, if you don't want to bypass the mailing list.  Though I'd still like to explore the bypass-the-mailing-list approach. :)