โšก๏ธ Live updates comments, jobs, and issues, tagged with #webform will update issues and activities on this page.

Issues

The last 100 updated issues.

Activities

The last 7 days of comments and CI jobs.

  • ๐Ÿ‡ธ๐Ÿ‡ฎ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']);
        }
    
  • ๐Ÿ‡ธ๐Ÿ‡ฎSlovenia useernamee Ljubljana
  • ๐Ÿ‡ฆ๐Ÿ‡น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!

Production build 0.71.5 2024