🇺🇸United States @jrockowitz

I forgot to push my MR.

The MR is very safe and fixes the most likely culprit to this issue.

You can add headings and break points to create containers; otherwise, you need to support the nesting and adjust your code accordingly.

There are APIs like \Drupal\webform\Utility\WebformFormHelper::flattenElements to help access nested elements.

I don't think we can safely add a lock behavior on submissions to the core webform module. Still, a contributed module could implement locking via a handler and the validateForm methods.

@scuba_fly If you have to contribute a solution, please post it here.

We need to know the steps required to reproduce this issue.

If all the tests pass, this should be committed. Ideally, someone could confirm that this fixes the issue.

The request object should be passed to WebformAddonsController and not injected.

The call to $container->get('request_stack')->getCurrentRequest(); is problematic via CLI.

I have seen this issue, but can't consistently reproduce it.

My best guess is the$instance->request = $container->get('request_stack')->getCurrentRequest(); in \Drupal\webform\Controller\WebformAddonsController::create

https://git.drupalcode.org/project/webform/-/blob/6.3.x/src/Controller/W...

The patch is bypassing access checking for submissions. We need to go after the root cause.

jrockowitz → made their first commit to this issue’s fork.

If the tests pass. this is RTBC

jrockowitz → changed the visibility of the branch 3533744-allow-signature-element to hidden.

This is.RTBC if all the tests pass

I think the problem is that #default_value can contain indexed and associatives and the translation UI can immediately support this.

This feels very safe and addresses an issue that has been around for a while.

The MR feels like a very safe way to help mitigate this situation since I user just needs to update the webform module to address the problem. Moving to RTBC

If the tests pass, I think this is RTBC

I am doubtful the tests will pass and this will need a little more work.

If MR tests passes this should be merged since it is very simple code improvement checkboxes.

This feels very safe to commit AS-IS. Thanks

If all tests pass, this should be RTBC.

jrockowitz → changed the visibility of the branch 6.3.x to hidden.

We can't start adjusting standard and shared code the WebformArrayHelper to fix pagination. We need to get the root cause and address the problem.

Since this was researched and the conclusion was to remove the aria-expanded, I think we should commit this patch AS-IS.

If you need an element that has a limited list of options with autocompletion, you should use a select menu with select2, choosen, or choices.

Were there a client side event to tap into, it'd make things a lot easier to tweak.

I would be very open to adding a simple alter options event below all instances of

          // Allow custom options.
          if ($select.attr('data-options')) {
            options = $.extend(JSON.parse($input.attr('data-options')), options);
          }

I am not sure of the right syntax, maybe this could be a later enhancement.

I am leaning toward merging this AS-IS.

RTBC if all tests pass.

This feels like edge case but a valid issue.

Can you please add an example to webform.webform.test_element_time.yml with a new test via \Drupal\Tests\webform\Functional\Element\WebformElementTimeTest?

Looks good. Thanks

jrockowitz → made their first commit to this issue’s fork.

Ouch, Drupal 11.1.8 is throwing errors. I am not sure I have the bandwidth to address them.

The MR adds the below warning to the webform dialog details widget.

→

1. ... a warning could be shown, if Enable site-wide dialog support checkbox is checked, which informs users that this option also needs the Allow users to post submissions from a dedicated URL for all webform option to be enabled

I am always open to adding documentation to the UI.

1. ... an error could be triggered on form save, if Enable site-wide dialog support checkbox is checked, but Allow users to post submissions from a dedicated URL for all webform option is disabled.

'Enable site-wide dialog support checkbox" allows webform dialogs to be used on any page of the website, which is a good thing. Some sites might be using this API to open nodes via Some page →

1. ... place the dialog option within the Allow users to post submissions from a dedicated URL fieldset to show the relation more clearly and make it dependent

Webform dialogs support does not have to be tied to posting submissions.

1. ... use form state to only show the dialog option and links, if Enable site-wide dialog support checkbox is checked (but I think that might be confusing!)

Better documentation is more important.

This enhancement makes sense, we just need to add a little test coverage to \Drupal\Tests\webform\Functional\WebformListBuilderTest

Regular expressions are working but the UI/UX is not displaying the help text.

→

This look good to me.

I think we might want to address this issue because of the modules and custom code could trigger webform_token_info() and generally developers are not expecting webform_token_info() to render anything or trigger the theme layer.

We are just adding a little defensive and optimization code.

This is welcomed improvement. Let's commit it to 6.3.x after the tests pass.

I cleaned up the dependencies and removed the _LENIENT_ALLOW_LIST settings because the styleguide has D11 release.

jrockowitz → made their first commit to this issue’s fork.

Committing my change which has test coverage and fixes the issue.

Please review the MR.

Below are the changes and improvements.

• On webform save and delete, track which webforms have CSS/JS libraries defined.
• Use the same logic for clearing library definitions via \Drupal\webform\EntitySettings\WebformEntitySettingsAssetsForm::save and \Drupal\webform\Form\AdminConfig\WebformAdminConfigLibrariesForm::submitForm.
• Add global CSS/JS routes (/webform/assets/global.css and /webform/assets/global.js).
• Add \Drupal\webform\Controller\WebformAssetsController with fast_404 support.
• Update \Drupal\webform\Hook\WebformLibrariesHooks::libraryInfoBuild to create global and webform specific CSS/JS libraries.
• Remove duplicate code for attached webform assets \Drupal\webform\WebformSubmissionForm::attachLibraries.

Questions

• Are there any major concerns with this improvement?
• Are we okay with /webform/assets/global.css and /webform/jassetst/global.js paths?

jrockowitz → changed the visibility of the branch 3497954-store-webform-with-css-js-in-state to hidden.

I managed to rebase the branch but this definitely needs review and work

jrockowitz → changed the visibility of the branch 3257570-delete-webform-improvements to hidden.

I think resolving 📌 Ensure that submission are deleted when a webform is deleted Needs work should prevent this issue.

Okay, this was easier than I thought once I realized I need to search for the word 'Trident'

Please rebase this for webform 6.3.x

Gotta love easy to reproduce bugs with one-liner fixes.

jrockowitz → made their first commit to this issue’s fork.

The 'Minimum amount of items' is solely for the minimum amount of items displayed by the multiple value widget, and it is not used via server-side validation.

We can't start validating the 'Minimum amount of items' without breaking existing webforms. I appreciate the MR and looks good.

Currently, there is no way to require a minimum number of values. I don't think most sites need this feature.

We could change the label from 'Minimum amount of items' to 'Minimum amount of items displayed'

I am not seeing any warning about changing a field's schema via https://www.drupal.org/docs/drupal-apis/update-api/updating-database-sch... →

Good catch!

My only concern is how the update hook handles changing the 'webform_submission_data.sid' schema when there are millions of records.

jrockowitz → changed the visibility of the branch 3462738-sid-schema to hidden.

jrockowitz → made their first commit to this issue’s fork.

I am very hesitant to make this change, as I hope the development team won't have significant API changes in the near future.

Yep, we need to support browsers with JavaScript disabled.

Your code is a good solution for sites that require users to have JavaScript enabled, which 99% of the web these days.

I can't replicate this issue using the attached example webform via the Olivero theme.

I think the issue is coming from a contrib or custom theme. If this is not the case, please provide more information.

→

I could see someone using a number element to store 10-digit numbers with leading zeros

The best compromise I can think of is to make this a configurable global setting.

We could turn this on for new webform installations. What is your opinion?

I was able to replicate this issue. Please review the attached MR, which is relatively safe to commit.

I recommend setting the image style for uploaded images to address this issue.

→

If you need PDF-specific image styles, they can be applied using custom code via existing preprocess hooks.

Yes it is on purpose because the hardcoded arguments limit who can access/see the submissions.

@see \Drupal\webform\WebformSubmissionListBuilder::buildSubmissionViews

Great catch and simple to fix. Attached is an example webform

jrockowitz → changed the visibility of the branch 3452423-datelist-test to hidden.

jrockowitz → made their first commit to this issue’s fork.

I can't replicate this issue using Claro. What admin theme are you using?

The MR is POC. Let's see if any tests break.

The pattern you are looking for is '.{3,}' attached is an example webform