Problem/Motivation

As discussed in the parent issue #3200985: [meta] Fix undesirable access checking on entity query usages work on the MR for #2785449: It's too easy to write entity queries with access checks that must not have them identified many cases in core tests - touching 80+ files - where entity queries currently do not explicitly call checkAccess(). In preparation for #2785449: It's too easy to write entity queries with access checks that must not have them all of these now need to explicitly all checkAccess with TRUE or FALSE.

This is major as it blocks #2785449: It's too easy to write entity queries with access checks that must not have them.

The dilemma

This is an awful lot of changes, and the logic of tests is often hard to understand. Therefore it's unrealistic to expect anyone to study every case in detail. While we can do our best to identify cases where access checking seems part of the intended logic of the test, we will need a basic heuristic to fall back on. Should we expect TRUE or FALSE for accessCheck in tests?

The advantage of setting all test uses to TRUE is that we don't change the behavior of any test, and therefore run no risk of inadvertently undermining our coverage of possible regressions by removing access checking when it is intended.

However, using TRUE suggests that the test is intentionally considering access as part of its logic. And in mostly that is not the case, in which case FALSE is a better default for future tests. Therefore using TRUE everywhere would (a) confuse the logic and apparent intention of the existing tests, but making it seem like they care about access when they don't, and (b) create many examples of using TRUE unnecessarily that may set bad precedents for future tests.

It's hard to know how many cases thee will be of tests that use an entity query and do care about access. I suspect the answer is very few, because tests that really case about access are often functional tests that make their assertions about rendered browser content not queried entities. A test that really cares about access and is using an entity query for that purpose is likely to be quite explicit that it is testing access.

Proposed resolution

Set accessCheck(FALSE) on entity queries in core tests unless there's clear evidence from the test comments and method names that it is concerned with access.

Issue fork drupal-3204163

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

jonathanshaw created an issue. See original summary.

catch’s picture

+1 to using FALSE here, most of the queries in tests are checking the contents of the database where you don't want access to run.

longwave’s picture

+1 also to FALSE by default and then discussing the cases (if any) that break if we do that.

jonathanshaw’s picture

Status: Active » Needs review
renatog’s picture

Status: Needs review » Reviewed & tested by the community

#5 really works well
Updating to RTBC

longwave’s picture

RTBC+1, there is no need for tests to follow access control so these can all be FALSE.

  • catch committed 65873ad on 9.2.x
    Issue #3204163 by jonathanshaw: EntityQuery accessCheck: tests should...

  • catch committed e84a71f on 9.1.x
    Issue #3204163 by jonathanshaw: EntityQuery accessCheck: tests should...
catch’s picture

Version: 9.2.x-dev » 9.1.x-dev
Status: Reviewed & tested by the community » Fixed

Committed/pushed to 9.2.x and cherry-picked to 9.1.x, thanks!

Status: Fixed » Closed (fixed)

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