The patch in comment 30 no longer applies when updating to 10.3. I have attached a rerolled version.
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.
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.
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.
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.
dswier β created an issue.
dswier β created an issue.
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.