v2.0 - improveing filters functionality

[ioleo]

Lately I'm focusing on improveing the filters functionality, which is the next milestone. I'm opening this issue to announce the incoming changes and make room for discussion and other ideas. The PR should be ready this week.

Improvement	Related Issue	Status
dynamic filters		reverted
empty or null filter	#669	done
save in token instead of session	#640	todo
filter on related entity field	#434	done
filtering translated content	#580	done
configure predefined filters and link to them	#135	todo

The improvements will introduce BC breaks, so the major version number will increase to v2.0. The next version will be based on newest v1.1 branch (Twitter Bootstrap 3).

So to use it, you'll have to upgrade if you used the v1.0 branch (however - I've done that myself lately, it's not really hard).

Since I'll be refactoring the whole filters functionality - if you have any ideas what else I could improve, please share.

[ioleo]

Dynamic filters improvement

Filters will be moved above the list. This will make more space for the list and allow displaying more columns.

The filters panel will be hidden by default, only the panel header will be visible. Clicking the header toggles show/hide filters panel.

The filters form will be a collection of filter items. A filter item can represent either:

• a filters group (see note)
• a single filter
• a comparison operator

Note: A filter group is a collection of filter items. In fact the filter form type is a filter group itself. This allows infinite grouping and nesting of filters.

There will be a button to add "filter group" and a button to add "filter" for selected field.

Between filters or filter groups there will always be a comparison operator (automatically added, when you add new filter or group).

This will allow to dynamically construct ANY filtering query.

For example, you could construct such filtering criteria for User:

• (created_at >= 2012-01-01 AND created_at < 2013-01-01) OR (age > 18 AND gender == female)
• (age >= 15 OR parent_aproval == true) AND (singup_date < 2014-01-01 OR admin_approved == true)

[bobvandevijver]

:+1:

I would like to link to #580 as that would probably be fixed with this update. Now we really need to upgrade to the v1.1 branch, something we just postponed because of it's complexity with the bootstrap css (we have some done some custom thingies to make it work)

[ioleo]

@bobvandevijver thanks, I've added it to TODO list, though right now I'm not sure how to implement this, but I'll definately try, once the base for this change (dynamic filters) is ready

[ioleo]

I have an idea how to implement filtering on related entities which may also solve filtering in translated content.

[bobvandevijver]

@loostro If you need any help, let me know!

[ioleo]

@bobvandevijver When the first step and biggest change (dynamic filters) is ready, I will submit a PR, so you can (a) comment & discuss, (b) help me with ideas how to implement other features from the list. I hope to send the PR around this monday.

[ioleo]

Adding an old idea (#135) to link to prefiltered lists. However, my idea for this goes beyond what @hellomedia proposed. I think we need a way to configure prefiltered lists as in some cases we want to add credentials checks and add parameters.

For example, a USER can access a prefiltered list of his own comments, but not someone else's.

Also, we probably want to create a sub-route for each prefiltered view. Eg.

• /users -> normal list for users
• /comments -> normal list for comments

I have something like this in mind:

• /comments/by-user/{id} -> prefiltered list of comments
• /comments/by-date/{date} -> prefiltered list of comments

This behaviour can already be hand-written, but maybe adding a way to generate these is a good idea? This is something to discuss.

[ioleo]

As unfortunately I had to do a complete system reinstall I'll probably submit the PR later - probably around this wednesday.

PS. No data was lost, just time wasted to fix my PC and probably got a few extra white hairs :P

Update: reinstalling and reconfigureing takes longer than I expected. Thursday is more likely for the PR push.

[bobvandevijver]

@loostro Good luck with the reinstall!

I do not know for sure if the prefiltered lists are such an good idea. I am convinced that the AdminGenerator is something that you only should use in admin interfaces, and in that case the normal filters as you proposed should be more than enough. Normal users should never have to access an admin interface, or at least, not for just any view.

If you really want such behaviour, you can always add it yourself. This might give the programmer more control over these prefiltered lists.

[ioleo]

@bobvandevijver I've been thinking about that a few days ago and I came to a conclusion, that adding a new action to the controller (and a route for it) which mimics list action (except, it modifies the query) is actually quite easy.

Actually I use AdminGenerator to power some backends with many users (regular, elevated, managers, and super-admins) and it works quite well thanks to credentials option.

[ioleo]

I've decided to simplify the dynamic filters a bit and remove "infinite nesting". I've changed my mind becouse:

• an ordinary user does not need filtering via complicated nested criteria on daily basis, and even if he does, then it's probably better if developer creates another list/ or scope
• filters with nesting level 2 or higher became not really clear/readable to the user
• i've run into many problems while developing this, up to a point where I decided it's not worth the hardships

After rethinking, I've decided to redesign things, so that:

• filters form contains a collection of filter groups
• each group contains a collection of filters
• groups are linked by OR operator
• items grouped together are linked by AND operator

So, a filter form like that:

Group 1:
  Item 1.1
  Item 1.2
Group 2
  Item 2.1
  Item 2.2

Would be translated to Group1 ( Item 1.1 AND Item 1.2 ) OR Group 2 ( Item 2.1 AND Item 2.2).

[ioleo]

I'm going on holidays and will continue working on this when I'm back, 19th.

[ruben-podadera]

Just a comment to say I have done filters on top + filter on related entities columns on our project. The code is not very clean and it only works with propel but I can send it if you want to have a look

On the screenshot you can see the entreprise column filter which is related to user. Declaration looks like that :

User-generator.yml :
...
filters:
    params:
        display: [email, firstname, lastname, Company_Name, enabled]
...

[ioleo]

@ruben-podadera the "advanced" filters were created on the new-unstable repository. As you can see here it seems that building nested conditions is "too hard to understand" for some customers.

As the result I plan to simplify the filters.. and I had something like on your screenshot in mind :) Except, I was thinking about two rows on top:

[ condition ] [ ..value.. ]

For example, for integer field, the condition would be a select box with options:

• greater than
• greater than or equal
• equal
• not equal
• less than equal
• less than

I'll be workin on it this week, I'll drop info here when I'm done.

[ruben-podadera]

@loostro Actually we are only using filters for text columns, thus the default filter does exactly what we want, so no need for 2 rows for us. What we where interesting was the possibility to filter on related table column's. Anyway I'm looking forward to see your changes. Thanks for your work

[cedriclombardot]

If i remind well you can set filterOn option to define a related table

params: model: Admingenerator\DemoBundle\Entity\Movie namespace_prefix: Admingenerator bundle_name: DemoBundle fields: is_published: help: If you want to see this content on you website actors: filterOn: actors.name Le 31 oct. 2014 14:39, "Ruben" notifications@github.com a écrit :

@loostro https://github.com/loostro Actually we are only using filters for text columns, thus the default filter does exactly what we want, so no need for 2 rows for us. What we where interesting was the possibility to filter on related table column's. Anyway I'm looking forward to see your changes. Thanks for your work

— Reply to this email directly or view it on GitHub https://github.com/symfony2admingenerator/AdmingeneratorGeneratorBundle/issues/758#issuecomment-61260822 .

[ioleo]

@ruben-podadera I've reverted to old filters (one-per-column) in the new-unstable repo. Then I've changed the GUI to match your screenshot. Also added a few improvements (like custom filters, similar to custom scopes) which can be used to filter translatable content OR on related entity field.

Also added "null" and "not null" filters.

The new-unstable branch now is only missing good documentation and demo

[ioleo]

@cedriclombardot the filterOn seems to be not working (for joined tables), are you sure it was implemented? a quick search shows that in current master the filterOn option information is not used to join related tables

maybe at some point when refactoring that functionality was lost? either way it should be reverted/or implemented somehow

[ruben-podadera]

@loostro thanks for the feedback, I will give a try when I have some free time (but currently we are being a bit busy ...)

[cedriclombardot]

If i remind well yes it was developed : i found some traces on https://github.com/symfony2admingenerator/AdmingeneratorGeneratorBundle/blob/c5471f8bd5d291becf7d9f7fc30cf0472bd5cb67/Generator/Column.php. Perhaps was brocken since !