- ๐ธ๐ฎSlovenia useernamee Ljubljana
Ok, I figured it out and added a section to the
README.md
file. - ๐ธ๐ฎSlovenia useernamee Ljubljana
Enabling confirmation was not problematic but there's a strange access check in webform that allowed me to access confirmation page only when logged in as admin:
/webform/src/WebformEntityAccessControlHandler::checkAccess
// Check 'view' operation use 'submission_create' when viewing rendered // HTML webform or use access 'configuration' when requesting a // webform's configuration via REST or JSON API. // @see https://www.drupal.org/project/webform/issues/2956771 if ($operation === 'view') { // Check is current request if for HTML. $is_html = ($this->requestStack->getCurrentRequest()->getRequestFormat() === 'html'); // Make sure JSON API 1.x requests format which is 'html' is // detected properly. // @see https://www.drupal.org/project/jsonapi/issues/2877584 $is_jsonapi = (strpos($this->requestStack->getCurrentRequest()->getPathInfo(), '/jsonapi/') === 0) ? TRUE : FALSE; if ($is_html && !$is_jsonapi) { $access_result = $this->accessRulesManager->checkWebformAccess('create', $account, $entity); } else { if ($account->hasPermission('access any webform configuration') || ($account->hasPermission('access own webform configuration') && $is_owner)) { $access_result = WebformAccessResult::allowed($entity, TRUE); } else { $access_result = $this->accessRulesManager->checkWebformAccess('configuration', $account, $entity); // <- this denies access to confirmation page !!! } } if ($access_result instanceof AccessResultReasonInterface) { $access_result->setReason('Access to webform configuration is required.'); } return $access_result->addCacheContexts(['url.path', 'request_format']); }
- ๐ฆ๐นAustria fago Vienna
If we could easily support confirmation pages, that would be best. Else I guess we should at least have a working default.
Generally, we are not warning users of not supported stuff, that would be lots of work, would it? Or should we make an exception for that crucial setting and grey-out/disable not supported options? This means, enabling the module takes over all webforms and considers them decoupled. Maybe it would be nice to allow configuring that, but again, complexity, so I think it's ok to keep it simple and make all webforms deocupled once turned on.
- ๐ฌ๐งUnited Kingdom james.williams
See #3401338-10: Several errors and warnings in the console โ : this is due to the module's invalid approach of trying to make the Stripe payment request whilst building up the AJAX request to submit the form back or forward. We've got a merge request there with a fix that should fix this problem too as it moves away from overriding any standard AJAX behaviour :) Please can you try the fix out to see if it solves your problem? Thanks!