Built-in communication-tools should consistently handle communication-preferences
Overview
In the discussion and review of #1378 (closed), several quirks and inconsistencies were flagged. These quirks/inconsistencies can produce confusion. We'll close #1378 (closed) because it addresses a particular quirk, but we should still have a record to prompt follow-up on other quirks.
Concepts:
- A communication preference is a field stored on a contact record which indicates how that person prefers to communicate. Example: They prefer email over text; they do not want you to initiate phone calls (but if they call you on the phone, then you should still take the call!).
- One's respect for communication preferences depends on the subject-matter and the data:
- The Subject Matter -- a confirmation or receipt; an end-of-year tax report; a notice about changes in an event; an inquiry about event attendee's arrival/accommodation/diet; an inquiry/support-thread initiated by the constituent; an appeal to renew an existing membership; an appeal to fill out a general survey; an appeal to fill out a survey about something which you just did; notifications about progress in case-work; education about the org's work; ad nauseum.
- The Data -- a database which is only used for donations; a database which is used for a mix of donations, events, case-work, support; etc. (The meaning of your data depends on where it comes from, what forms you presented to people, the context of those forms, etc.)
- Given the same subject-matter and the same data, a user may still choose different tools -- one-on-one email; search+checkbox+email; CiviMail blast to a smart-group; CiviRules trigger; scheduled reminders; sui-generis application logic; etal.
For example... depending on how the specific membership program works, it's entirely reasonable to send content about renewals through a scheduled-reminder... or a CiviMail blast... or a one-on-one message. For a last-minute notification about changes in an event, I can totally see people using the individual mailer, the adhoc mail-blast, or a normal mail-blast.
Current behavior
There are several built-in tools. They are often hard-coded to respect a specific communication-preference (e.g. quietly skipping records due to communication-preferences).
This is confusing because:
- Different tools have different defaults, so they behave differently.
- Tools often do not provide a clear indication that records are being skipped.
- The default comm-prefs may be misapplied due to an incorrect expectation about the subject matter or data. (Ex: CiviMail was originally written with an expectation that it's used for newsletters. If you use it to send a last-minute logistical update for an event, then it will quietly use the wrong comm-pref.)
Proposed behavior
- Any built-in communication tool should have built-in support for comm-prefs.
- "Built-in support for comm-prefs" means:
- It defaults to behavior which respects the comm-prefs.
- It warns the backend-user/admin if they're requesting an action that would break a comm-pref.
- It warns the backend-user/admin if some action is being skipped due to a comm-pref.
- It allows the backend-user/admin to decide how/whether/which comm-pref is appropriate to the task at hand.
Comments
This issue is not ripe for coding. To address it, I would expect that one would next need to:
- Audit the existing comm-tools to note how they do (or don't) handle comm-prefs
- Design some mockup for how to consistently present comm-prefs in the existing tools