TYPO3 Core

Sadly I know of no extension which integrates this to the "normal" record list, but technically it should be possible, so maybe digging for something like that in the extension repository could be fruitful?

The "DB Check" -> "Full search" backend module of EXT:lowlevel allows do define very specific filter rules to find record lists and save these as presets. However that might be a bit complex for editors.

There is a PSR-14 Event ModifyDatabaseQueryForRecordListingEvent (see https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/12.0/Feature-98490-PSR-14EventToAlterTheRecordsRenderedInRecordListings.html) that you can use to conditionally add more WHERE conditions to your record list, by evaluating the table name. Then however you will never be able to edit/view rows that have 'verfied' not set, so that might not be what you're actually looking for?

Thank your for confirming as well. My idea is that we can add it in TCA settings to make it easier for editors to implement them

Somewhere along in

$GLOBALS['TCA'][<tablename>]['columns'][<colname>]['tablefilter']

[
  'type' => 'checkbox', # mapped to 1 or 0. WHERE verified = 0|1
  'label' => 'Verified'
]
...
[
  'type' => 'select',
  'label' => 'Type',
  'options' => [ ['Type 1', 'type_1'], ['Type 2', 'type_2'], .... ] # or we can emit the `options` and it will be populated with all possible values from DB for that column
]
...
[
  'type' => 'text',
  'label' => 'Search Term',
]

In DatabaseRecordList.php probably the simplest way is to obtain these filter configurations, build HTML representations of it, and put it in `getTable()` as a new form. I am looking at RecordSearchBox to see how they can filter by text, but I haven't found the exact query builder code for it.

That sounds interesting! I am not too sure we should enhance the TCA for this kind of filters. Instead, something along how the RichttextEditor is configured might be better. So have a seperate place where to define filters.

I actually believe setting this with TypoScript (and not a seperate YAML file or so) would be beneficial. This way, Page and User TS Config could be created to individually apply filters both to usergroups, single users, and also even make specific filters available to specific pages.

So then you could do nice stuff like this:

• In SysFolder A you setup News records and you allow filtering by title and category, very plain
• In SysFolder B you could setup another filter that applies to the same News model (different records though) and you could filter those by different criteria, like an author start/enddate

Since the FormEngine display of records is bound to the page tree, both evaluating TS config and Page TS config should fall into place quite nicely.

What do you think?