| Summary: | Add support for data filters in tables/queries/forms/reports data view | ||
|---|---|---|---|
| Product: | [Applications] KEXI | Reporter: | Dimitrios T Tanis <dimitrios.tanis> |
| Component: | General | Assignee: | Kexi Bugs <kexi-bugs> |
| Status: | CONFIRMED --- | ||
| Severity: | wishlist | CC: | inksi, staniek |
| Priority: | NOR | ||
| Version: | 3.0.x | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | Kexi Live Filter mockup | ||
Maybe it could be applied to tables also as a data preview/search feature. There could also be a button to produce a query object based on that table and that filters. That could be great for creating simple lookup queries to be used on forms. Summing up, your request is for ad-hoc filters. Right? If so, it's for a shared feature so tables/queries/forms/reports. Nearly all the sub-features (including filter on/off) are known for MSA users. This is more code task (eg. requires support in kexidb/predicate), for now re-assigned to me. Also you said: "Also using the same idea there could be a report property to display results on opening the report or not. When selecting NO, when opening the report it would contain a big button "Update Report" or something. That could allow to have a very big data source connected to the report, however the user will be given a choice to filter the report's results before displaying the report." This looks like request for caching. Right? Can be object-type-independent but also can be report-dependent. If you request something like this caching, I propose to file separate wish, so once we implement the feature, we'll be able to refer specifically to the wish #number :) Updated summary to 'Add support for data filters in tables/queries/forms/reports data view' I was thinking of ad-hoc filters, yes. About the reports, even though it could be implemented like this (caching) I thought of a simpler approach, combined with the ad-hoc filters: At first there are no data loaded. The user defines criteria for the ad-hoc filter, and pushes the refresh button. An SQL string is constructed from the filter's criteria and fed (at the background) as data source to the report which is then refreshed. Seems more simple/efficient at the time than implementing caching. *** Bug 337360 has been marked as a duplicate of this bug. *** |
Created attachment 61783 [details] Kexi Live Filter mockup Version: 2.4 alpha2 (Calligra 2.4 alpha2) (using KDE 4.6.0) OS: Linux When viewing the report, there could be a live drill down/filter section on the top or bottom of the window. That section would contain a table with the following columns: col A) A check box to whether include that filter in the results or exclude from the results. col B) A combo box having all the data source's fields. (containing either field caption or description in comments?) col C) A combo box containing filter criteria (eg less than, more than, equal to, not equal to, masked, etc) col D) A text box where the user could input the criteria as a string. col E) A check box to enable / disable the filter. col F) A button that when clicked would change it's caption to the number of records filtered filtered All the filters would build an SQL WHERE clause to be apllied on the data source. On the bottom there should be a check box to enable/disable auto update of the report when changing the values in the table and a seperate "Update report" button to manually update. There should also be two more buttons that when pressed would display the total number of records filtered and total number of records on the report. Also using the same idea there could be a report property to display results on opening the report or not. When selecting NO, when opening the report it would contain a big button "Update Report" or something. That could allow to have a very big data source connected to the report, however the user will be given a choice to filter the report's results before displaying the report. All in all that would allow to create a report based on a large dataset (table or query) without having to create a seperate form to filter the results before loading the report. Something like Live query or Live fiilter. (cool name by the way, isn't it?) Reproducible: Didn't try Expected Results: The whole section could be located in a docker (docked at the bottom) visible when opening a report of form in data view. Come to think of it, it is definately a better idea to have it as a docker. The formentioned section could also be applied to forms.