jkingsnorth → created an issue. See original summary → .
I hit the same problem today.
Is this due to https://www.drupal.org/node/3034742 → ? Though that was ages ago.
https://git.drupalcode.org/project/rest_log/-/merge_requests/16
Opened this MR as a suggested fix, which backtracks on part of the change made in https://git.drupalcode.org/project/rest_log/-/commit/eca7c579ea2e9ffa6a6...
jkingsnorth → created an issue.
Thanks for the fix, apologies for the delayed response.
I'm going to close this issue because it's not been updated for 10 years.
I had a similar problem, but rebuilding node access permissions via the Reports > Status report page fixed the initial problem, and fixed it for access controls applied thereafter.
Makes sense. It felt like a caching issue when I came across it. Thanks for the reply.
The patch in #15 does not work for me.
In my use-case we have recaptcha set up as a fallback for recaptcha_v3.
When we fallback to the 'I'm not a robot' checkbox, we tick the box and then we get the loading spinner in the element, but it doesn't verify us.
The patch in #13 does work OK in our use-case.
Hi! Can you explain why? I'm just interested as this fixed a problem for me, but I don't really understand why.
Argh! Yes! This solved a really weird problem I was having where the form was only having ajax applied and working for anonymous users, but not when logged in. I'm not sure how this fixes it - but it does...
Right, I found some guidance here https://www.drupal.org/docs/drupal-apis/update-api/updating-entities-and... → and had a go at this change based on that documentation. Here's a MR: https://git.drupalcode.org/project/rest_log/-/merge_requests/13
Would appreciate thoughts/feedback. My concern is that the update could take a long time to apply if there is a lot of data in the table!
Oh man I thought this was going to be straightforward, but it looks like that isn't the case. there's a whole developer module (https://git.drupalcode.org/project/field_type_converter/-/blob/1.0.x/src...) which supports field type changes because it needs a new field creating rather than updating the existing one? Am I missing something here?
JKingsnorth → created an issue.
I think this would be a great improvement, but I think there's some work needed on the PR.
When opening any existing clients, we see the error:
Warning: Undefined array key "scopes" in Drupal\openid_connect_windows_aad\Plugin\OpenIDConnectClient\WindowsAad->buildConfigurationForm() (line 269 of modules/contrib/openid_connect_windows_aad/src/Plugin/OpenIDConnectClient/WindowsAad.php).
I think this is because we'll need an update hook to set the configuration (even as empty) on any existing clients.
I think we also need to add the 'scopes' as an item in the schema.yml file.
As a headstart, you could take a look at how custom scopes were implemented in the 'generic' provider of the parent module: https://git.drupalcode.org/project/openid_connect/-/commit/21bd2ae21b640...
JKingsnorth → changed the visibility of the branch 3432443-grouprole-mapping-broken to hidden.
JKingsnorth → created an issue.
JKingsnorth → created an issue.
PR here: https://github.com/eileenmcnaughton/civicrm_entity/pull/467
I suggest moving the cache clear to the 'top' of the submit handler, so the caches are cleared before the new settings are saved.
I don't think it's necessary to clear the caches again at the end [=
JKingsnorth → created an issue.