TYPO3 Core

I cannot reproduce this issue.
It's true that the query factory does not respect query settings, but in \TYPO3\CMS\Extbase\Persistence\Repository::createQuery, which is called by the findAll (and magic) method(s), the defaultQuerySettings (if present) are copied over to the query object.

Please see https://github.com/TYPO3/TYPO3.CMS/blob/v9.5.13/typo3/sysext/extbase/Classes/Persistence/Repository.php#L201 for more information.

If I misunderstood the problem, please provide further feedback.

The Problem is here:

https://github.com/TYPO3/TYPO3.CMS/blob/v9.5.13/typo3/sysext/extbase/Classes/Persistence/Generic/QueryFactory.php#L80

This is called before the defaultQuerySettings are applied in

https://github.com/TYPO3/TYPO3.CMS/blob/v9.5.13/typo3/sysext/extbase/Classes/Persistence/Repository.php#L201

Which means if you just use defaultQuerySettings you will override any preconfigured or contextrelated storagePageIds

therefore either the setting of the storagePageIds need to be done later - i.e. in Repository->createQuery after the clone OR the defaultQuerySettings need to be applied before, like in the patch I suggested..

sorry if that was not clear in my initial report

I have written a patch for fixing this issue in v10.

Hey. I had a look at the query settings magic in extbase and stumbled upon this issue.

I think I understand what happens, what this issue is about, had a look a the proposed patches, and came to a conclusion.

Let me sum up the situation:

Usually, when no defaultQuerySettings are set in a repository, then createQuery() creates some query settings. This is triggered through QueryFactory->create(). It applies settings derived from TCA of this table (via DataMapper) like respectStoragePage (from TCA ctrl rootLevel), and it also sets storagePids from TS configuration.

If you now set a defaultQuerySettings in a repository (eg. via initializedObject()), these query settings are used instead (Repository->create() does this after calculating own query settings, which is kinda stupid, too). They fully override the above calculated settings. This basically means: If you set defaultQuerySettings, you're saying "I know better" and you then need to take care of other things that would be usually applied, too. For instance, you'll have to apply storage pid restrictions yourself (again), if you want so.

The proposed patches try to merge both QuerySettings objects together by handing defaultQuerySettings over to the factory. This however is problematic, too: If your defaultQuerySettings set a storage pid that is NOT identical to that from configuration (because it fetches the value from elsewhere / dynamically), then the factory would happily override your storagePid again. The same is true for respectStoragePage: Lets say you setRespectStoragePage(true) in defaultQuerySettings for whatever reason (maybe you don't want categories from pid 0), then the factory would happily set this to false again, if TCA ctrl rootLevel = 1 is set. So this approach does not work well. The main issue is, that QuerrySettings does not know which setters have been explicitly called, so it can't know which default settings should be applied and which shouldn't. Implementing such a magic doesn't sound right, too: This query settings magic is already quite complex and often does wrong things, so I'm not too fond of adding 'dirty / explicitely triggered' handling to this class.

I came to the conclusion, we shouldn't change the behavior at this point: Instead I propose a patch to document it: "Hey, if you set defaultQuerySettings, then you need to apply other settings yourself since you shut down internal magic this way" ... something like that. I'll push a patch in this direction.

Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/69324

Applied in changeset b81a4b853e369ea2234eaa4f1e131163e52605ac.