вообще, я почему поднял эту тему - я не сторонник проверок доступов к сущностям на стадии запроса. Куда логичнее включать голову заранее и проверять доступы ещё до начала формирования запроса. Иначе в один прекрасный день Mysql скажет тебе, что больше 40 джоинов в одном запросе делать нельзя

и это ты всего лишь количество юзеров хотел посчитать...

В D6 или в D7 был очень круто написан Advanced Forum, например, чтобы вывести последних 10 юзеров зареганных на форуме, там выбирались все и пыхом брались последние 10
#дедовскиефлешбеки

у меня на восьмёрке помню прикол был, надо было загрузить через jsonapi 50 нод с референсами на другие ноды и юзеров. И с кучей фильтров, по дате, статусу и т.д. И вот когда в jsonapi внедрили проверку доступов к сущностям, тогда и узнал я про 40 джоинов. А там суть в том, что поскольку права проверяются по принципу "имеет разрешение на просмотр или является автором", то с каждым референсом джойнится таблица юзеров и проверяется, чтобы uid автора был такой же как у текущего юзера. В итоге больше никогда не юзал jsonapi и ни разу не пожалел

loadByProperties() использует EntityQuery:

  public function loadByProperties(array $values = []) {
    // Build a query to fetch the entity IDs.
    $entity_query = $this->getQuery();
    $entity_query->accessCheck(FALSE);
    $this->buildPropertyQuery($entity_query, $values);
    $result = $entity_query->execute();

да понятно, что использует. Непонятно совсем другое, я писал выше. Непонятно, что в entityQuery теперь принудительно заставляют указывать, нужна ли проверка доступа, а в loadByPropertiies этой возможности нет в принципе. Это как если поставить на проходной завода две вертушки, и на одной требовать пропуск, а на другой не требовать

Всё же это разные вещи. Я писал же выше, там далеко не только с accessCheck отличие.  Много чего еще там тоже не провернуть. Это простая выборка с последующей загрузкой. Если туда вбрасывать опции от EntityQuery, то получится EntityQuery.

а где я писал, что в них нет отличий?

Там также нельзя контролировать типы условий по свойствам. Там тупо всё через IN проверяется.

Ну просто смысл перегружать метод лишним если он справляется с тем для чего создан.

а смысл нагружать вахтёршу проверкой пропусков, если ей и так тяжело?🤣

Ну так это же хелпер метод, основной инструмент как не поверни EntityQuery.

просто, есть расхожее мнение, что проверки доступа - это нечто связанное с безопасностью.  И если заткнули одну дырку, то почему бы не заткнуть остальные?

Так в ядре наоборот почти все вызовы EntityQuery обновили на accessCheck(FALSE), вместо дефолтного TRUE. Кому надо контроль - EntityQuery и голова с руками.

а, я думал, что они вызывали вообще не указывая метод accessCheck, а теперь заставили его вызывать

Да, так и было, они очень давно начали рефакторинг перед депрекацией. Почти все вызовы были без accessCheck, а значит, по дефолту становилось TRUE, но большинство таких вызовов теперь явно указывают FALSE как и в loadByProperties.

С 9.1.6 примерно началась сильная движуха на эту тему. Очень много ишьюсов закрыли. Это уже как просто точка во всём этом.

Если кого это изменение вдруг напугает, то все это уже с 9.1.6 и далее есть и сейчас. В 9.2.0 чутка докинули где недоглядели или забыли, и депрекацию объявили. То есть ничего страшного случиться не должно. Зато некоторые косяки должны уйти. Например когда юзер хочет удалить все сущности через массовое удаление, но к части из них у него нет доступа, и получается что он видит 0, модуль отключить не может (или что он там хочет сделать, для чего удаляет), а сущности по факту есть.

о да, было такое помню, что вбо не удаляло

в целом, получается, что основное изменение не в том, что надо метод вызывать, а в том, что в классе QueryBase раньше было явно объявлено protected $accessCheck = TRUE; а сейчас написано просто protected $accessCheck; этим и вызвана необходимость вызова метода