The program organizing committee often needs to send targeted email to the presenters of sessions, even those sessions not accepted for the program. It would be great to have a way to easily allow organizers to filter and send these messages to presenters.

We used the http://drupal.org/project/views_send module to achieve this in a past conference, which worked pretty well.

One issue was that it was difficult to not send duplicate emails to presenters for the multiple sessions they may have submitted. Maybe it was just a matter of setting up the views correctly? Here are the types of communications necessary from the organizing committee viewpoint.

Accepted Sessions

  • Send email to each presenter of a session to confirm a session was accepted.
    • A presenter with multiple sessions accepted should get a confirmation email about each session accepted.
  • General communications to each presenter of a session as conference approaches.

Deferred Sessions

  • Send email to each presenter of a session that was not accepted.
    • Presenters with multiple sessions deferred should get a message about each session not accepted.

Comments

Status:Active» Postponed (maintainer needs more info)

"A presenter with multiple sessions accepted should get a confirmation email about each session accepted." This makes sense to me.

However, it seems like it would conflict with "One issue was that it was difficult to not send duplicate emails to presenters for the multiple sessions they may have submitted. "

Is that just a matter of changed requirements? Thanks!

I think the conflict comes when you need to communicate with presenters about general news or information. In that case, you don't want to send duplicate messages for each session, as just one is enough. So I probably should have broke up the above scenarios into 3 categories:

Accepted Sessions

  • Send email to each presenter of a session to confirm a session was accepted.
  • A presenter with multiple sessions accepted should get a confirmation email about each session accepted.

Deferred Sessions

  • Send email to each presenter of a session that was not accepted.
  • Presenters with multiple sessions deferred should get a message about each session not accepted.

General Communications with Presenters

  • General communications to each presenter of a session as conference approaches.
  • Only need to send one email even if presenter has multiple sessions.

Status:Postponed (maintainer needs more info)» Active

Got it - thanks for the clarification!

Views_send seems like a decent solution for COD.
It stores the default values for the message, as well as the fields from the view that are used to determine where the message is sent, in variables which makes it export-friendly. It does need a bit of work here and there (eg, I just wrote a patch for #964026: "Remember these values next time when you will send mass mail" ignored).

We should be able to use the 'distinct' checkbox and require the "Presenters" relationship to control whether we send one email per presenter per session or just one email per presenter, and provide these as displays on a separate view linked from the main session moderation displays.

Since we'll already have controls for sending the message, I think we would want the presenter contact displays to not include filters from the session moderation Views.

So, I see us creating one display for each of mrshaver's scenarios in #2, plus an additional display for "session has been scheduled" in case organizers want to confirm that presenters can make their assigned session times.

Assigned:Unassigned» ezra-g

I've built a feature based on the above, as well as a "presenter confirmation" flag that allows each presenter to confirm that she can present at the scheduled date and time. I'll be working on contributing this hopefully this week.

Title:Communicating with presentersCommunicating with speakers
Status:Active» Needs review
StatusFileSize
new76.41 KB

Here's an initial version of the patch. I'm going to prepare a short screencast to explain the functionality here.

StatusFileSize
new69.67 KB

This contains a bunch of revisions. I'm going to test on a fresh install and do a short screencast.

StatusFileSize
new79.66 KB

Here's a revised patch. A short screencast should be available in 30 minutes at http://vimeo.com/24293009 .

One thing I've noticed is that while the user's name is correct in the message, only the last name appears in the "to" part of the email. It seems like combining two fields into a single column isn't supported by views_send, so we should either stick with last name or use username instead.

I marked #1114018: Presenter confirmation as a duplicate.

Here's a revised version of this patch that switches from using full name to username for the email's "to" name. I haven't tested this as extensively as the previous patch but will do a quicker run through before committing, which I plan to do this week.

Here's a revised version of this patch that switches from using full name to username for the email's "to" name. I haven't tested this as extensively as the previous patch but will do a quicker run through before committing, which I plan to do this week.

StatusFileSize
new73.88 KB

Oops - Here is yesterday's patch.

Title:Communicating with speakersCommunicating with speakers, speaker confirmation
Status:Needs review» Fixed

I tweaked the views filters further and removed some unrelated changes from the patch. This is committed: http://drupalcode.org/project/cod_support.git/commit/a6c32c5 .

I credited mshaver in the commit message for describing the feature that we've got here, and for building part of the feature that this contributed one is based off of. Thanks!

StatusFileSize
new65 KB

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.