Summary: | Safer application of options for each filter criterium in a pivot table | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | Markus Elfring <Markus.Elfring> |
Component: | Calc | Assignee: | Not Assigned <libreoffice-bugs> |
Status: | RESOLVED WORKSFORME | ||
Severity: | enhancement | CC: | ilmari.lauhakangas, libreoffice-ux-advise |
Priority: | medium | ||
Version: | 6.2.4.2 release | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Crash report or crash signature: | Regression By: | ||
Bug Depends on: | |||
Bug Blocks: | 103381 |
Description
Markus Elfring
2019-06-11 17:56:37 UTC
(In reply to Markus Elfring from comment #0) > I would find it occasionally more appropriate to restrict these options to > a smaller column list. Please give an example. Thing is, providing options per entry (there are just two more) would bloat the dialog. The better approach is to introduce new column in the document for those complex scenarios and/or to filter the data that goes into the pivot table. (In reply to Heiko Tietze from comment #1) > Thing is, providing options per entry (there are just two more) > would bloat the dialog. I find that software extensions will be needed for better selection of properties for filter criteria. Please take another look at application consequences around options like the following. * Case sensitive * Regular expression * Function list I don't understand why you would need a filter like <Foo>="a" (case sensitive) AND <bar>="\n" (regular expression). And usually the table contains of numbers where these options are irrelevant. (In reply to Heiko Tietze from comment #3) The property “Case sensitivity” matters for the application of regular expressions, doesn't it? > And usually the table contains of numbers where these options are irrelevant. I find this view too limited. Would you like to take any more contents (with other data types) better into account? We had this topic on the agenda for the weekly design meeting. Having options for each of the 3 parameters is an overkill and impairing usability. So closing as WFM. (In reply to Heiko Tietze from comment #5) > Having options for each of the 3 parameters is an overkill and impairing usability. I got other application expectations. I hope that this view can be reconsidered. > So closing as WFM. Would other contributors like to adjust the software situation any more? Will any nicer solution ideas appear? |