Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
M
Mailing
  • Project overview
    • Project overview
    • Details
    • Activity
  • Issues 34
    • Issues 34
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Incidents
  • Analytics
    • Analytics
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Create a new issue
  • Issue Boards
  • Development
  • Mailing
  • Issues
  • #24

Closed
Open
Opened Aug 31, 2018 by ginkgofjg@ginkgofjgDeveloper

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?

The unexpecteds:

  1. This is cosmetic, but the API metadata are wrong. The API Explorer describes the params as though they were for unsubscription.
  2. 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.
  3. 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.

The approaches:

  1. This should be a trivial update to the API's _spec() function.
  2. 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.
  3. Confirmation is handled by CRM_Mailing_Page_Confirm which 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
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: dev/mail#24