Problem/Motivation
If a webform submission results in a failed mailchimp submission, we only have a global dblog error report.
Webform admins do likely not check this global log.
Additionally, even if logging is enabled, the submission neither reports success or error into the webform log.
In contrast, the email submission handler does report success.
This makes the whole integration a blackbox with unknown reliability for regular users / non-technical admins.
Proposed resolution
In case of submission error, always log to the webform log.
In case logging is enabled, also log success.
Remaining tasks
Discuss, decide, implement.
Comments
Comment #2
mbovan commentedAFAICS, webform module provides a (webform) log as "submission created" if logging is enabled. Do you mean we should add an additional webform log record in case a Mailchimp submission succeed?
The webform logs/log tab is only displayed if submissions are being logged.
However, this seems to be tricky to do properly with the current code.
The main limitation is that
WebformMailChimpHandlerusesmailchimp_subscribe()helper which does not provide enough information when an error occurs. There is an issue in Mailchimp module that aims to improve this behavior #2821953: Introduce a mailchimp service, and expose API exceptions to service users.The attached patch creates a webform log record in case Mailchimp subscriptions fails. As we don't know why Mailchimp subscription failed the current message is: An error occurred subscribing @email to list @list.
In order to have the actual reason, we could improve it once #2821953: Introduce a mailchimp service, and expose API exceptions to service users. lands. The other (workaround) option could be to query
mailchimpwatchdog records by email/list_id and create a webform log record based on it.Comment #3
miro_dietikerThis still doesn't report success similar to the e-mail handler. Please double check that.
Also checkout admin/structure/webform/submissions/log - the global webform log is not dependent on a specific form setting.. and to me it also seems that it does not depent to the global setting.
I would vote against workarounds and promote (and help solve) the original issues.
Comment #4
berdirDiscussed with Miro, to make sure that there are no misunderstandings here:
* Always log failures
* Log success *if* the log submissions checkbox is enabled.
* Do not work on #2821953: Introduce a mailchimp service, and expose API exceptions to service users. (as much as I would love to refactor that code), do not implement any workarounds, this is good enough for a first version. Lets just add "Check the logs for details." to the log message, search_api does this in a similar way.
Comment #5
mbovan commentedOk, adding success webform log if any sort of logging is enabled (either global or form logging).
It looks like this page does not depend on logging setting indeed. However, it can produce 403's when a user tries to access detail submission log records (in case logging was not enabled).
Comment #6
miro_dietikerWonderful. Let's test this in prod... ;-)
How about creating some issue for the inconsistent permission check?
Comment #7
mbovan commentedUpdated the message with: An error occurred subscribing @email to list @list. Check the logs for details.. Check the logs for details could be confusing IMHO, as a user is going to see this on the global-webform-logging overview page.
Created #2933933: Inconsistent access checks for log overviews in webform project.
Comment #8
berdirNot quite sure about the wording yet, because we are in the logs already. Maybe system logs or so, but lets wait and test this a bit on some sites before we finalize that text and commit it.
Comment #9
miro_dietikerI accidentally enabled the MailChimp cron queue processing (label is "use batch processing") at admin/config/services/mailchimp
This makes mailchimp_subscribe() always succeed and then later failing silently (yes with dblog record) if something was wrong.
However, Mailchimp won't know about that.
Thus the log message above should adapt the success message with a reference to the queue, if the checkbox is enabled.
Comment #10
primsi commentedLog entry updated.
Comment #11
primsi commented...
Comment #12
miro_dietikerLooks fine.
Comment #13
miro_dietikerCommitted this.