Skip to content

[POC] "Additional filters" for the input screen settings #1205

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed

Conversation

richardhj
Copy link
Member

@richardhj richardhj commented Nov 4, 2017

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.
screen shot 2017-11-04 at 23 53 02
(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 @authors in touched PHP files
  • Checked the changes with phpcq and introduced no new issues

@zonky2 zonky2 added enhancement This issue is about an enhancement (aka new feature) Up for discussion This ticket will be up for discussion in one of our next calls labels Nov 5, 2017
@dmolineus
Copy link
Contributor

Why not using only the expression language? Then you could also compare like this item.group in (user.groups)

@richardhj
Copy link
Member Author

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

@zonky2 zonky2 modified the milestones: 2.1.0, 2.2.0 Mar 9, 2018
@zonky2
Copy link
Contributor

zonky2 commented Aug 18, 2018

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".

@zonky2 zonky2 removed the Up for discussion This ticket will be up for discussion in one of our next calls label Aug 29, 2018
@zonky2 zonky2 modified the milestones: 2.2.0, 2.1.0 Aug 29, 2018
@zonky2
Copy link
Contributor

zonky2 commented Aug 29, 2018

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.

@discordier
Copy link
Member

Will we postpone this to 2.2? @richardhj are you still working on this?

@zonky2 zonky2 modified the milestones: 2.1.0, 2.2.0 Dec 19, 2018
@zonky2
Copy link
Contributor

zonky2 commented Dec 19, 2018

I set this to 2.2...

@zonky2 zonky2 modified the milestones: 2.2.0, 2.3.0 May 9, 2022
@zonky2 zonky2 modified the milestones: 2.3.0, Future Jan 17, 2023
@zonky2 zonky2 self-assigned this Jan 17, 2023
@zonky2
Copy link
Contributor

zonky2 commented Feb 20, 2023

Closing - we have an alternative solution in MM 2.3

@zonky2 zonky2 closed this Feb 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement This issue is about an enhancement (aka new feature)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants