🇧🇪Belgium @f2boot

Thanks for checking, sorry for not being clear enough earlier.

In my case, I am accessing the Media directly (that needs setting "autonomous URL for media" in /admin/config/media/media-settings) and the File attached to the Media got access denied.

In your case, you access the Node and the Media is checked for access, which is fine since, indeed, it has isAccessControlled TRUE and it probably does not go to the final "return access_allowed" = FALSE (as described above) in isAccessAllowed (because one of the terms is returning access_allowed = true by the part of the function cheking taxonomy_term)

Yes, it also occurs with version 3.1.35. (and is still solved by the patch)

As far is I can see, the isAccessAllowed function from AccessChecker service in PbE iterates recursively over the entities referenced by the entity being checked. In the case of a Media, the File entity that is referenced is treated.
If setting "Require all terms granted", isAccessAllowed defaults access_allowed to FALSE. Since the File entity has no reference to taxonomy term, nor further entity reference (except uid), it is not changing the default and ends up with access denied while it was actually not meant to be AccessControlled by PbE.

By checking the referenced entity isAccessControlled (false), it is not treated and therefore not access denied.

A question subsists: should we clear the cache of isAccessDenied. I thought no, so iIset the parameter passed to the function accordingly.

Thanks

f2boot → created an issue.

Patch in #7 is working for me
(aligning with changes in page_manger since patch from Path has unnecessary query appended is committed)

voleger → credited f2boot → .

Drupal in #43 was also working for Drupal 10.3.1,
but Drupal 10.3.2 brings some clean up of comments in views module. Patch in #43 includes some of these that are therefore not needed anymore => removed from this patch

I had to complete the signature, adding :array, indeed.
Patch attached

There is actually at least one other cause for such a Warning.
Because of

    foreach ($counters as $key => $counter) {
      if ($counter['amount'] === 0) {
        continue;
      }

in getCounter() function

$counter['warning']['amount'] (line 118)
$counter['error']['amount'] (line 121)
may not be set in buildRenderArray() function if there are no warning/error.

Attached patch goes for "isset" check, alternative would be to remove the foreach and keep all three counters

Looks like the problem might be around the final logger (logger.drupaltodrush).

For me, trace was:
Got error 'PHP message: Uncaught PHP Exception Symfony\\Component\\DependencyInjection\\Exception\\ServiceCircularReferenceException: "Circular reference detected for service "Drupal\\Core\\Logger\\LoggerChannelFactoryInterface", path: "options_request_listener -> router.route_provider -> path_processor_manager -> simple_sitemap.engines.path_processor -> simple_sitemap.engines.index_now_submitter -> simple_sitemap.logger -> logger.channel.simple_sitemap -> Drupal\\Core\\Logger\\LoggerChannelFactoryInterface -> logger.syslog -> workspaces.manager -> logger.channel.workspaces"."

https://www.drupal.org/project/drupal/issues/3103620 🐛 Dependency on config storage causes circular reference in service container Needs review solved it for me

Looks like patch suggested in #3 did if for me too

Sorry, got a bit too enthousiast.
Here is a new try, limiting "return" in patch #5 to empty string

Patch #5 breaks Data Comparison if value = 0 so let's check if value is a string before going for return