πŸ‡ΊπŸ‡ΈUnited States @dswier

Account created on 23 May 2012, over 12 years ago
  • Technical Account Manager at AcquiaΒ 
#

Merge Requests

Recent comments

πŸ‡ΊπŸ‡ΈUnited States dswier

The patch in comment 30 no longer applies when updating to 10.3. I have attached a rerolled version.

πŸ‡ΊπŸ‡ΈUnited States dswier

Thanks for your comment, @Jonne! We were also on Drupal 10.2.2, so I updated, and that did indeed solve the issue for us.

πŸ‡ΊπŸ‡ΈUnited States dswier

I recently ran into this issue in the process of testing our upgrade to D10.2. My use case is the very same as the initial post. We are calculating if the user is over 18, and if not we display the parent/guardian information fields. The logic in our computed twig field is slightly different, but the result is the same. Instead of saving a yes/no value, the value of our field was markup saying "Please provide the name of a Parent/Guardian". We had also been using the computed_twig field being "filled" as the condition for displaying the other fields. Just like OP, this stopped working between 9.5 and 10.2. In troubleshooting, I did also try checking for a value from the computed field, but that didn't work either. What I did see was that if my condition was the value being empty, the parent/guardian fields would always display. Therefore, my conclusion was that these computed fields don't seem to have a value that is available to the #states system anymore. We haven't found a workaround yet, but I don't have a full understanding of all the systems at work yet.

πŸ‡ΊπŸ‡ΈUnited States dswier

I needed to make some changes to the rerolled patch after we discovered some changed behavior on our site. We had been using the patch in #11 πŸ› Role assignment from attributes does not work when provisioning accounts Needs review , and it appears the reroll changed how it worked slightly. The way our SSO setup is configured, you get returned to Drupal right after registering, and should then be logged in. What we started seeing after applying the reroll in #21, was that the user was not instantly logged in. It seems the new patch started doing
return $account;
Where the #11 patch was keeping what the module was already doing.

$this->synchronizeUserAttributes($account, TRUE);
return $this->externalauth->userLoginFinalize($account, $authname, 'simplesamlphp_auth');

This new patch puts it back to the previous code, so that the user's attributes get synced and they are logged in at the end.

πŸ‡ΊπŸ‡ΈUnited States dswier

I am working on an upgrade from 9.5 to 10.2, and previously we had been using the patch in #8 that now doesn't apply. Trying out #21, we discovered that blocks we had been using this negate condition on were showing up again where they shouldn't be. I am not familiar enough with core code to understand what patch #20 is doing, but I found that reverting just those changes brought back the behavior we were expecting. I'm attaching a patch without those changes. If the code in #20 is still necessary, I'd be glad to help with any changes, but first I would need some help understanding what it is supposed to be doing.

πŸ‡ΊπŸ‡ΈUnited States dswier

dswier β†’ created an issue.

πŸ‡ΊπŸ‡ΈUnited States dswier

Thanks for reporting your solution @gabriel.passarelli. I used the patch in #70 since we're still on 9.5, and then adapted your JS snippet into my own custom JS. With that combination, the forms we were trying to get both AJAX and native browser validation to work on are now working.

Production build 0.71.5 2024