CiviCRM Community Forums (archive)

Sorry if this concept is already discussed somewhere, but searching for it is difficult...

We're facing some issues that make it difficult to reliably ensure that contacts are permanently un-subscribed or opted-out from our email lists.

An example: Sally registers for an event and also signs up her son Max using her email. Several weeks later we send out an email newsletter with the de-dupe mailings setting checked. Sally receives the email and chooses to opt-out. Her contact record is marked  "opt-out". Good. However Max's record is left with the same email address and is not marked as opt-out. Our next newsletter won't send to Sally's contact record (good), but it will send to Max's contact record (bad) because he has the same email address as Sally -- so Sally's opt-out essentially didn't work.

Though there may be some work-arounds to this particular case, I could come up with other similar examples. It strikes me that the underlying problem here is with the data model used to store un-subscribes and opt-outs.

Here's what I think would be better:

• The tables `civicrm_contact` and `civicrm_email` become joined through a many-to-many relationship with an additional table like `civicrm_contact_email`
• `civicrm_email` gets a unique index on the `email` field
• (perhaps) `civicrm_email` also gets a new field `is_opt_out` (though there could be other approaches here)
• The point is: when processing an opt-out, CiviCRM marks the email as opt-out instead of the contact

Ok clearly there are a lot of other things to think about with this sort of hypothetical change. For example, if someone wants to un-subscribe (instead of opt-out) from a particular mailing list, it would be great if that could happen at the email-address-level as well, but we'd still want to retail the functionality to have contacts attached to groups instead of just having email addresses attached to groups. Complicated for sure. As well, what would happen to fields like `civicrm_email.location_type_id`, `is_billing`, etc. I imagine they'd get moved to the new `civicrm_contact_email` table.

Is this stuff on anyone else's mind? Are the reliable work-arounds that people use currently? Is anyone else interested in working on these issues? I don't have experience as a CiviCRM developer, but I'd love to help out somehow if I can!