[POC] "Additional filters" for the input screen settings
Description
@zonky2 sent me a link to the Contao Community. This POC brings this use case functionality to the core.
For instance:
In the backend, a user must only edit his/her items.
(property: attribute of the item, expression: value for the filter using expression language)
Checklist
- [ ] Read and understood the CONTRIBUTING guidelines
- [ ] Created tests, if possible
- [ ] All tests passing
- [ ] Extended the README / documentation, if necessary
- [ ] Added myself to the
@authorsin touched PHP files - [ ] Checked the changes with phpcq and introduced no new issues
Why not using only the expression language? Then you could also compare like this item.group in (user.groups)
Why not using only the expression language? Then you could also compare like this item.group in (user.groups)
Because the filter builder requires a key-value definition (see https://github.com/MetaModels/core/pull/1205/files#diff-e2a09a92365d013895094701bda0ef64R157).
And I'll use this PR as a basis for the permission check in the frontend. When on the one hand, the permission check in the frontend will deny access whenever the "additionalFilters" fail, on the other hand, on item creation initial data need to be set (like vice-versa to the permission check).
--> When a new item will be created in the frontend, an event listener will set the initial data (i.e. $item->set('owner', 'current_fe_user') (then I need a key-value definition defined in the "additionalFilters" as well).
//cc @zonky2 @discordier
Why don't we use our selection of an existing filter here?
With a filter with the "Own SQL" rule you would have all possibilities to manipulate the input mask - e.g. Owner, Group,... or "do not display the mask if field xy is filled in".
The implementation via MCW is intended for simple filters such as user rights - more complex filters should be installed at the point via an event.
The implementation should not only be responsible for filtering, but also set the necessary values when creating a data record.
Will we postpone this to 2.2? @richardhj are you still working on this?
I set this to 2.2...
Closing - we have an alternative solution in MM 2.3