Cospeaker emails via reviews notifications app

[efloehr]

A friend reported that his co-speaker did not also receive the acceptance email.

Line 487 in symposion/reviews/views.py:

rn.to_address = proposal.speaker_email

Should probably be:

rn.to_address = [ speaker.email for speaker in proposal.speakers ]

[efloehr]

To do it right, the ProposalBase model method notification_email_context should probably add the additional speakers to it as well, to allow for templates that list all speakers... but at least sending the notice to additional speakers as well as the main one is probably initially sufficient.

[lukeman]

Thanks Eric,

I know we've been talking about this through email, but I wanted to state publicly that this is something I'll be getting to as soon as I'm back in the core Symposion code (hopefully in the next week).

Previously co-presenters were treated second-class citizens on proposals and the feedback we've gotten makes it clear that that was a bad assumption and we've already started addressing that in other areas.

[dpoirier]

We're going to try to fix this in our Pycon fork this week (deadline coming up for the site) and will contribute whatever we come up with back upstream here.

Unfortunately, to_address here is an EmailField, so we won't be able to just assign a list of addresses to it.

[dpoirier]

After looking into this a bit, we're not going to get to it this week after all. Agree with @lukeman that the right approach is to address this more broadly. And result notifications won't be going out anytime soon anyway.

[dpoirier]

In case it helps, here are some other places I'm told co-speakers were not included:

• Not listed as speaker on schedule
• Not listed as speaker on list of accepted talks
• Talk not listed next to co-speaker's profile
• Not receiving notifications that the primary speaker received. E.g. an email went out about a meeting that all speakers were supposed to attend, but co-speakers didn't get it.

[lukeman]

@dpoirier Sounds right.

This isn't entirely related, but on the general subject of upstream merges, I realize it's probably too late at this point since you're fighting a deadline, but the PyCon 2013 code used an older method of including Symposion that might make extensive changes tough to mesh back into the module (unfortunately we didn't establish a healthy project/module pattern until after PyCon was baked).

The new style is over at https://github.com/pinax/pinax-project-symposion which is basically a Django startproject template. Again, I realize this is probably too late for your needs on a deadline, but our goal is for the module to be flexible enough that all customizations per conference would be held in the project package with the Symposion module exposing hooks and reusable things as needed.

[lukeman]

@dpoirier Thanks for the list. I'll make a broader set of issues for those.

[dpoirier]

Any updates on this issue?