Ive been seeing problems with my users using saved grids with Filters.
If I switch filters off in the app>Save Grid clickboxes in the saved grid then none of these problems apply. BUT, I want to allow the user to save their refined search filters.
Problems:
- If you have filters on, then it saves the filters in the Save grid file(Sounds good), but it also saves the SQL WHERE clause that you used to bring up the grid. This may sound OK but it isnt.
I have an application that segregates all data by project so I NEVER want the project reference to be used when reapplying the grid format and filters as that would give the user a backdoor around the security.
- Save Grid in a project you currently have access to.
- I remove your access
- click on the saved grid and hey presto a SECURITY Breach because it has the old lookup SQL
Try to make the grid public (or anything else for that matter) and you get the same problem, but worse since a public grid has the filter of the person and project that created the save.
- The ability to delete grids you didnt create (e.g. public) is a well known problem and there are some good PHP hacks elsewhere to cover it.
I did create a Javascript override which solved this problem and avoids the need to hack the generated PHP code every time you change an app, which is when I discovered the filters problem above.
You can even hack the Save Grid file to remove anything resembling a filter, but that doesn’t seem to work (Or I missed something) as long as the filter clickbox is on.
-
Design Philosophy - The way scriptcase processes the saved grid is such that you cant intercept the parsing of the file and can’t influence it with code. As far as I can tell, the Save_Grid data is processed directly in the lower level functions and never exposes any of the workings/data to the outside world. It also doesnt redo the main SQL in the same way as normal because nothing appears on the Debug output. The usual ‘where’ variables are not updated.
-
Conceptual Limitations - The whole ‘filter’ design assumes that you have a single mass of data. As soon as you begin to segment it (e.g. by project), then underpining data doesn’t stay the same, and applying filters can never work… project one might have workstreams A, B and C while project 2 1,2,3,4,5,6,7. In this circumstance filters can never work.
You’d have to be very explicit about what filters can be saved (anything that is not a lookup by the segment (e.g. Project) and what ones cant and I for one cant fathom that entire logic. and you would need an event that lets you intercept the saved grid data (to fix the incompatibilities dynamically)
Conclusion
For me, the only option is to switch off filters in the saved grid capability, which is less than ideal
I would be very surprised if Netmake did anything about this.
I’d appreciate any further insight.