Managing Unsubscribe/Opt Out for contacts who must receive emails

[adharris]

We have several thousand contacts in our CiviCRM database with whom our organization has a professional relationship and therefore these contacts should not be allowed to opt out/unsubscribe from business-related emails.

We have tried using the ad-hoc email that does not go through CiviMail, but we really need the open rates and bounce tracking that CiviMail provides.

Is there a way that we can still send emails via CiviMail, but prevent contacts from removing themselves from certain groups using opt out/unsubscribe?  For example we might have an "Employees" group that we want to send an bulk email to so we can track read rates, but contacts should not be able to unsubscribe/remove themselves from the "employees" group.  Furthermore, if the contact receives one of our normal newsletters (by virtue of being in another mailing list), and opts out via the link in that newsletter, they should still receive emails when we send to the "Employees" group.

Thanks!

[Donald Lobo]

Currently no

But this has come up fairly often in the past week and folks (thanx stefan and naught on IRC) have given us "semi-good" reasons as to why it might make sense to exclude those links in a few cases.

I think the next step might be to allow a hook to suppress this validation. I checked the code and the only place this check is done is:

CRM/Mailing/Form/Upload.php

We'll need to restructure the validate code a bit and put the error message for this in its "own" element. Once we do this, the validate hook can potentially override it and unset it

Would be great if you can work on this and submit a patch. We can help you out on IRC. Should not be too hard, IMO

lobo

lobo

[adharris]

Thanks for pointing me to the right file.

I took a look at that file and came up with a slightly different solution.  It appeared that the actual set of required email tokens is set in CRM/Utils/Token.php.  I noticed that the token checking code already handled an OR condition ( only one of {action.optOutUrl} and {action.optOutAddress} is required).  I created a new token called {action.optOutExemption}, and added it to that OR condition.  Now I can bypass the validation by including that token in another footer.

Code: [Select]

Index: CRM/Utils/Token.php
===================================================================
--- CRM/Utils/Token.php (revision 164)
+++ CRM/Utils/Token.php (working copy)
@@ -45,6 +45,7 @@
                                                       'forward',
                                                       'optOut',
                                                       'optOutUrl',
+                                                      'optOutExemption',
                                                       'reply',
                                                       'unsubscribe',
                                                       'unsubscribeUrl',
@@ -103,6 +104,7 @@
                                             'domain.address' => ts("Domain address - displays your organization's postal address."),
                                             'action.optOutUrl'  =>
                                             array(
+                                                  'action.optOutExemption' => ts("'Opt out exemption' - Exempts the email from needing to have an opt-out link"),
                                                   'action.optOut'    => ts("'Opt out via email' - displays an email address for recipients to opt out of receiving emails from your organization."),
                                                   'action.optOutUrl' => ts("'Opt out via web page' - creates a link for recipients to click if they want to opt out of receiving emails from your organization. Alternatively, you can include the 'Opt out via email' token."),
                                                   ),

I didn't do anything to add this to the listing of tokens that are presented to the user, in order to prevent the user from adding it manually if inappropriate. 

[Donald Lobo]

The only issue with the below is its a hack to core and u'll need to repatch it on a upgrade. However it is a nice solution.

I'm conflicted about making this part of the main code base, since most groups are likely to use (and hence abuse) it, since its fairly easy to do so (in which case we should then just drop the requirement). We do firmly believe that giving the enduser an option to opt-out of all mailings is needed for most mailings

lobo

[adharris]

I was trying to figure out how to achieve the same results without hacking core, but couldn't quite come up with anything.   Perhaps the list of required/available tokens should be alterable via a hook?  CiviCRM could then ship without the exemption, but it would be trivial to add it when absolutely necessary.

I totally agree that the vast majority of the time users should be allowed to opt out.  I think this solution doesn't even really solve our problem (a user could opt-out from a newsletter, then they still wont get our required emails). What we need is the ability to designate that a contact has a professional relationship with our organization, and should receive business-related emails regardless of their opt out status, and then the ability to flag a certain mailing to be a business-related email.

It seems that the set of business contacts should be a smart-group (to provide maximum flexibility).  adding a checkbox to designate an email as "business related" seems pretty easy.  The part I get lost at is how to ignore the opt-out condition for these contacts.

[naught101]

I signed up to this forum to post this exact query, more or less.

dlobo: you note that there have been a few "semi-good" reasons for disabling the opt-out requirement, I'm wondering if there are any more than semi-good reasons for keeping it?
Considering the farily arduous sign-up process and the anti-spam-in-triplicate on each forum post, I'm guessing it's due to the CiviCRM team being worried (understandably) about civiCRM being seen as a Spam Machine. This is pretty unreasonable though, really, as there are plenty of other softwares out there that make sending spam easy with far less overhead than CiviCRM, I can't see CiviCRM ever being used in any massive way as a spam-machine.

adharris mentions one good reason for removing the requirement, that I hadn't thought of. I have a couple more. I volunteer with a small, reasonably radical social change group, that conducts direct action, and various other activities of dubious legality, (although, I would of course argue, of non-dubious morality). We use civiCRM for newsletters for our contacts (for which we obviously include an opt-out), but we also use it for Media mail-outs, for which we do not want the recipients to be able to opt-out. The emails on these mailouts are media addresses, they're public, designed to receive emails from organisations from ours, we do not spam, just send media releases when we need to (eg. 2-4 times a month). for these organisations to be able to opt out potentially decreases our (relatively feeble, minimum-finance) voice.

Secondly for the aforementioned reasons of dubious-legality, we sometimes (very rarely) need to be anonymous, and would like to send our media releases from the CRM without including any reference to the CRM installation (eg. the opt-out URL).

Obviously including an opt-out is good form, and a sane default, and I understand the dilemma, but it would be great to know the good reasons for making it a no-negotiation requirement, as that seems a little overkill to me.

Anyway, just thought I'd have a little rant. Keep up the good work. I guess I'll just stick with adharris's hack for now

[lesley]

 I've just set up a footer with the optout/unsubscribe links as a dot. It's a scruffy solution but good enuff for us

[petednz]

(just fyi anyone else coming here) the latter is fine for people who see the html version of the email/footer - anyone looking at plaintext will see the whole url

[FrTommy]

To prevent enduser abuse could the mailing list not have an option called "prevent opt-out" when it's being set up. I would assume that most orgs limit the ability of setting up a mailing list to an administrator. That would prevent random abuse by an end user of just including a token.

So in adharris example the Employees mailing group would be setup to prevent opt-out. Any emails sent to that mailing list would exclude the opt-out check. It would cause there to be a more indepth code rewrite but I think it is a better solution than using a token solution that any enduser could use.

[Eileen]

I see a few possibilities

1) Allow civimails to go out without an opt out but only after people do something to show it's really intentional
2) set lots of warning messages when Opt out not used
3) Only let users with a specific permission send emails without optout
4) use a site wide setting as to whether civimails can be sent without opt outs
5) tie the opt out to groups as per previous suggestion
6) accept that people are already getting around it by making the opt out message invisible & hence the forcing of it is a bit hit & miss so give up on it
7) some combination of the above

[kennedy]

As a work around the issue i am giving my contacts the option to manage their subscriptions i.e create a custom field with multiselect options for all your preferences: (for example, monthly newsletter, employees newsletter, job announcement etc).
Use CiviCRM webform to create a form call it profile center  or anything you wish with the exposed contact details, the custom field and any other additional data.
copy the link on the form, under additional options on the civicrm tab something like this:
(http://www.yourdomain.com/profile-center?cid1={contact.contact_id}&{contact.checksum}), add it to the footer template ie

 you can customize you footer template to be something like this:
manage your subscriptions | unsubscribe from our mailing list

[petednz]

someone may be better placed to update this but eileen thinks this {action.optOutExemption} is now in core but still not available in the tokens list - ie it is there to be used if you know that it can be used but you would be unlikely to stumble on to it via normal UI

[nant]

very useful thread

[petednz]

more useful if we get this in core ;-)

https://issues.civicrm.org/jira/browse/CRM-16062