Undefined context error when user resets password

30 minutes later, that's me again, and again it doesn't work (same error)
So, I rebuilt rights, and now it works.
For how long?

H gilbertdelyon

Nice catch! Unfortunately I haven't been able to reproduce it either. Though, looking at some code I can see how theoretically it could happen.

This can happen when AccessRule::getValue(); is called before the context is set.

For example, it should happen like this:

$access_rule->setContext(ExecutionContext::create('view', ['user' => $this->currentUser]);
$access_rule->getValue();

If it never calls setContextExecutoinContext it could trigger that error. Are you able to do some debugging and isolate where $access_rule->getValue(); is being called?

Thanks for this prompt answer.
This morning it works again, without any changing any thing in the settings. But I am not confident an I will test again periodically
I will do my best and help you and find the culprit event, but I am not a professional coder, only a part time hobbyist.

Another thing I noticed:
When Acces Policy module is running,
and when user opens the "edit profile" form
he doesn't see the “visibility_users_groups” field.
When the admin opens the "user profile" form he can see it.

This is good, because only the admin can set the user groups,
but I dont know if it's the normal behaviour.
And may be this is the reason of the issue?

Xdebug? I am not at all familiar with this tool. Seems it needs a learning curve. Sorry I will not be able to help in this way.
But in the meantime I found a way to trap the error more precisely, at least on my production site.
I explain how to,
Initial status:
A user, named “testuser”, tries to refresh his password. It works!
Repeat again a couple of times. Still works. So far so good.

Disconnect “testuser”
Connect as “admin”
Go to “admin/config/performances” and clear the cache.
(Notice: cache lifetime is set to 15 minutes on my site, may be not the best value?)
Disconnect “admin”

Now “testuser” tries again to refresh his password,
and BINGO! Here is the error in line 256.

Disconnect “testuser”
Try again to refresh password. It works!

Hope it can help.

Thanks for the step-by-step, that is very helpful!

Unfortunately I still can't reproduce it. Would you be willing to share an export of the access policies? Maybe there's something about the configuration that I'm not thinking of.

1. Go to /admin/config/development/configuration/single/export
2. Select Configuration Type > Access Policy
3. Select the access policy you want to export.

See attached file
Something strange:
Access is controled as expected in my main site with this config, but...
There is probably someting wrong in it because if I import it in a clone of the main site, and then delete cache and rebuilt rights, access control is not working at all.
Thanks in advance for your help

My site is running a custom subtheme of Bartik.
This subtheme as now been running for 2 years without any issue.
I can reproduce the error very easily

I just made some tests with native Bartik and also with Olivero, and...
In these themes I cannot reproduce the error.

So, the error could come from
- the fact I am using a subtheme
- or from my custom code
I will investigate and keep you informed.

result of investigations:
While running Bartik: I cannot reproduce the error

While running a subtheme of Bartik: I can easily reproduce the ERROR "line 256"

My subtheme is as simple as possible with only 2 files:
bartiksub.info.yml

name: BartikSub
type: theme
base theme: bartik
description: 'Theme enfant pour site G-FAMILY.'
version: '1.0'
core_version_requirement:  ^9 || ^10

bartiksub.theme

<?php
// that's all

So, my conclusion is that the error is coming from the fact that I am using a subtheme.
What do you think?

I added a new subtheme based on bartik but unfortunately I still couldn't reproduce it. Very mysterious.

My hunch is that it's related somehow to hiding the fields on the user's profile. I would try disabling the code and see if it stops happening.

Start with access_policy_entity_field_access() in access_policy.module and work from there.

Also, what over fields do you have on the user?

Here is a patch to address the fatal error. I'm still curious why this would be called in this context but AccessRuleArguments are designed to work without the context so it's a good thing to add anyway.

Let me know if this resolves your issue.

You are on the right way!
This is what I did:
in access_policy.module (line 327

/**
 * Implements hook_entity_field_access().
 */
function access_policy_entity_field_access($operation, FieldDefinitionInterface $field_definition, AccountInterface $account, FieldItemListInterface $items = NULL) {
/*
if ($items && $items->getEntity() instanceof AccountInterface) {
    return \Drupal::service('class_resolver')
      ->getInstanceFromDefinition(EntityOperations::class)
      ->userFieldAccess($operation, $field_definition, $account, $items);
  }
*/
  return \Drupal::service('class_resolver')
    ->getInstanceFromDefinition(EntityOperations::class)
    ->entityFieldAccess($operation, $field_definition, $account, $items);
}

This is the result:
bartik & bartiksub ("empty")
No more error. :-)
But of course the field is now displayed in user form, and this is not good ( I could hide it in css, bad practice )

Attach:
Crop of user fields
Crop of user fields form

The patch seems to work in my test site. :-))
I will test in production site and keep you informed.

I appreciate your prompt and efficient assistance. Thank you so much.

Are you by chance restricting taxonomy terms with an Access Policy? In particular, Groupes Utilisateurs? If so, that may explain why CurrentUser:;getValue(); is being called in the first place.

Are you by chance restricting taxonomy terms with an Access Policy? In particular, Groupes Utilisateurs?

No, Acces Policy only uses "Groupes Utilisateurs" taxonomy terms for content acces control, but doesn't control acces to terms.

That's me again.
May be I was wrong in my privious post.
I dont intend to restrict access to "Groupes Utilisateurs" taxonomy terms, but may be I did it by mistake, or unsufficiant knowledge of Access Policy settings (there is a learning curve for me because translation in french is only partial I need to understand many things)

See attached file.
Field access.png →

So, I just made a test after selecting "Libre" (free) instead of "Droits" (Rights).
It doesn't change the behaviour. Only the patch does a good job!
I tested it in production site and it also works.

Glad to hear the patch worked! I'll commit that and then mark this as resolved :D

I was referring to something along the lines of Step #7 of the Restrict Content by Department tutorial → . However, it sounds like you're not doing that.

I can confirm-
- There is no "taxonomy" access rule in my settings
- Only one "content" access rule

Automatically closed - issue fixed for 2 weeks with no activity.