Submission isn't sent to CiviCRM if Mollie handler exists

Hi @DieterHolvoet, it is definitely the wrong variable, so I will accept your MR. I am not sure if works after the merge. I had some success with by coupling the cmrf_processor to the webform update event:

and using the payment status in the condition.

That makes this module obsolete.

I don't think that makes it obsolete. We still need the mollie_payment_id and mollie_payment_status variables in CiviCRM and that doesn't happen with the module disabled. Well, it doesn't happen with the module enabled either, but that's a different issue.

The issue seems to be that WebformSubmissionHandler::sendToCivicrm() is invoked after form submission, even though the handler was disabled earlier by cmrf_form_processor_mollie_webform_handler_invoke_post_save_alter. This means that once Mollie pings back with the payment status, sendToCivicrm() doesn't do the API call since $this->isSubmittedToCiviCRM is already TRUE.

Okay, I was able to create a timeline using a lot of random logger placements:

• The submission is created.
• cmrf_form_processor handler is disabled by cmrf_form_processor_mollie_webform_handler_invoke_post_save_alter
• MollieTransactionEventSubscriber writes the payment status to the submission. The submission is updated.
• cmrf_form_processor handler is not disabled because of $paymentHandler->checkConditions() returning FALSE
• Submission is sent to CiviCRM without the mollie_payment_id and mollie_payment_status
• Mollie reports back the payment status
• Submission is not sent to CiviCRM because it was sent before

@Klaas do we really need that extra check in MolliePaymentHandler::checkConditions()? Because getting rid of that and the !$cmrfHandler->isDisabled() check in MollieFormProcessorSubscriber fixes the issue.

Just realised MolliePaymentHandler comes from the Mollie module, never mind.

DieterHolvoet → changed the visibility of the branch 2.0.x to hidden.

Okay, do you have a suggestion for a different solution? For now I'm going to remove \Drupal\mollie_webform\Plugin\WebformHandler\MolliePaymentHandler::checkConditions in a patch, that fixes the issue as well. I'm not even sure why that extra check is needed.

Hi Dieter,

I have added some documentation in the code about the checkconditions. As follows.

Sometimes a form processor is used to implement two payment options, for example a Sepa payment or an online mollie Payment. This can be implemented by making the mollie payment handler conditional. The forms processor must here only be disabled when the mollie payment checks are valid.

When no conditions on the mollie handler the conditions check is always true .

I know, I read your documentation and I understand. I don't know if you noticed but Mollie has an extra check in their overridden checkConditions method, that's the source of the issue. Not the standard conditions check.

/**
 * {@inheritdoc}
 */
public function checkConditions(WebformSubmissionInterface $webform_submission) {
  $conditions_are_met = parent::checkConditions($webform_submission);
  // If not all conditions are met no further checks are need.
  if (!$conditions_are_met) {
    return $conditions_are_met;
  }
  // If other conditions are met, check that there is no payment already by
  // validating that there is no payment status set yet.
  $element_key = $this->mollieWebformHelper
    ->getMolliePaymentStatusElementNameFromWebformSubmission($webform_submission);
  return empty($webform_submission->getElementData($element_key));
}

Hi @Dieter, thanks. I did not notice this. The reason that it works in my use case is that I do not have a paymentstatus element in my form. The effect is that empty($webform_submission->getElementData($element_key)) is always true. The form processor uses the 'mollie_payment_status' field that passed to it in the same way as the mollie_payment_id field.