TYPO3 Core

In v8 the filter does not work, but no exception is thrown.
In v7 the filter work as expected.

We discovered another issue with this filtering:

If a group record is disabled it still shows up in the filter but it is not present in the demand object (since extbase does not do mapping for hidden records). If the filter is set to such a record no exception occurs but the filtering is not applied either.

My conclusio so far: 9.5 master, php 7.2, apache, Linux, MySQL 5.6

• √ I don't get any exception at all
• There is no difference if any of the users is disabled
• If you want to filter by a group which is disabled, the filter doesn't work
• √ If you want to filter by a group which is enabled (no matter if their related users are disabled or not) , the filter work without changing anything

• Basically I can't get an exception (tried some scenarios with Daniel already)
• For me – another bug – the query for the usergroup needs a rewrite (see typo3/sysext/beuser/Classes/Domain/Repository/BackendUserRepository.php:97) to also support disabled usergroups, as this is something the module must support for such scenario.

TYPO3 Version 9.5.0-dev
Webserver Apache/2.4.29 (Win32) OpenSSL/1.1.0g PHP/7.2.2
PHP Version 7.2.2
Database (Default) MySQL 5.5.5-10.1.30-MariaDB

After filtering a group:
(1/2) Doctrine\DBAL\DBALException
An exception occurred while executing 'UPDATE `be_users` SET `uc` = ? WHERE `uid` = ?' with params... (Really biiiig object ;-))

And i can see a disabled group in the filter, too.

Please note that this issue exists since <https://forge.typo3.org/issues/39141> (since TYPO3 6.something).

When BE users have selected a group, and so added this big overhead in their UC, each time the UC is updated (which is quite often in typical BE usage), a lot of MySQL write operations happen (example: up to several MB per BE request that modifify UC).

When using a MySQL master/slave setup, even for a non-busy instance (only 3 BE admins using the BE at the same time, only a few dozen of BE users per BE groups), this can lead to several GB/minute additions to the MySQL binary log (which will "slow down", and then crash)!

So I think that the priority of this bug should be raised, and that the fix should be backported to all supproted versions.

Basically the idea of storing everything does not seem that good. Besides that LazyObjectStorage extends ObjectStorage which has serialize and unserialize methods that would throw an exception - however since \Serializable is not (correctly) implemented, this is not triggered. In my scenario on master (10.0-dev) the backend user uc should be filled with 16 MB of serialized data...

Patch set 2 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/+/61117

Patch set 3 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/+/61117

Patch set 4 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/+/61117

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

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