Filtering disregards `column.pipeArgs` when performing the filter operation

[ChronosSF]

Description

If you use pipeArgs to modify how say a date is rendered, filtering will disregard it leading to unexpected behavior.

• igniteui-angular version: all
• browser: n/a

Steps to reproduce

1. Open the attached sample.
2. Try filtering the date column by typing the exact date seen in the first record (cond eq)

Result

The record is filtered out

Expected result

The record should pass the filter

Attachments

idzhlh--run.zip

[onlyexeption]

Still reproducible when checking out PR #14465. Note: By setting format prop in pipeArgs, both the cell value and the inputFormat in gridFiltering changes. However, the issue with the filtering itself seems to persist.

[pipeArgs]="{ format: 'dd/MM' }"

results in

[damyanpetev]

@ChronosSF The issue looking at the same and the description steps has to do quite specifically with the timeZone option for display format and while I agree in theory, I don't think it's the same thing as what the side quest of #14465 turned into (inferring edit formats from locale by default and then if possible from display(pipe) format).

The time zone/offset handling is its own feature IMO (and its own can of worms really), since it implies converting actual values regardless of the format. As in if the grid displays a column in UTC-7, it makes sense the Filtering UI editors to 'accept' values with the same offset - which actually translates to the editors producing search value shifted with the desired offset instead of the local one as they do now for filtering to apply correctly. However, the exact same logic applies for the actual editing process as well, no? We've done a similar feature in past products that was baked into the editors themselves and that's something we can consider again. Also feels weird for pipeArgs to be the controlling point for that, perhaps it's either a column option or a separate field in the new editor options?

PS: The case with date or date[-time] column edit format without year I imagine is pretty edge, not sure if we need to explicitly handle the display/input format in such case (not how the filtering is set up) - better yet, should be pretty easy to scope the compared parts with a custom FilteringOperation and reusing the part handling of the existing IgxDateFilteringOperand.

[github-actions[bot]]

There has been no recent activity and this issue has been marked inactive.

[github-actions[bot]]

There has been no recent activity and this issue has been marked inactive.