Unexpected behavior from api.MailingEventSubscribe.create
In creating a custom e-newsletter sign-up form for a client, I encountered the following unexpected behaviors. I'm happy to submit one or more corrective pull requests but would first like to:
- confirm that this is not an unexpected use of this API,
- confirm that these behaviors are unexpected,
- get two cents from others on the approach, and
- get acceptance criteria for the PR(s) -- i.e., what tests do I need to write/pass?
- This is cosmetic, but the API metadata are wrong. The API Explorer describes the params as though they were for unsubscription.
- Suppose contact X is already a member of a mailing group Y. If their IDs are passed to this API, the contact's status in the group is "downgraded" to "Pending" and the user must reconfirm membership by clicking the link emailed to them.
- The contact's DO NOT MAIL and NO BULK EMAILS Communication Preferences are not updated. These changes should not be effected by the initial API call, but after the user clicks the confirmation link emailed to her.
- This should be a trivial update to the API's
- The API delegates to
CRM_Mailing_Event_BAO_Subscribe::subscribe(). I would fix the problem in the delegate by checking for group membership and bailing out early if the record already exists with the appropriate status.
- Confirmation is handled by
CRM_Mailing_Page_Confirmwhich delegates to
CRM_Mailing_Event_BAO_Confirm::confirm(). I would unset the communication preferences in question in the delegate.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information