Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Closes: #9583 - Add column specific search field to tables #15073
base: feature
Are you sure you want to change the base?
Closes: #9583 - Add column specific search field to tables #15073
Changes from 18 commits
4c39516
e762755
f7294f7
664a0eb
cc423f5
50557c0
03f67f3
3243ebd
b54cfd6
5f69666
06c1aff
4ae6683
c3f1a96
f81f76f
0309796
84151cb
77bfd62
25a4e94
f257f4a
8a7df0b
a422a3c
8ad79a6
a9aa0cb
35cff12
1c995fa
479c69b
5830ae9
fd38255
30e6531
f130678
0ad1db9
b12ce97
77cb8ac
d6ab7b7
012e815
852535e
f2c74db
882aa30
8d65973
92c3bbc
4381ea9
92f6f42
764c676
ee83895
a288712
e12ae3a
1958965
7e5d8ea
694fcd3
451a1f4
434cf37
e7649f0
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
Large diffs are not rendered by default.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed full path, as this will allow taking into account filters on the form (to facilitate pushing of the filters from the column as well).
Should not impact functionality
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we know this for sure? IIRC we specify the full path for a reason, I just can't recall why.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From my testing, I haven't found any issues with it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure this approach is tenable: We're using the same form field for both the column and the regular filter form (behind the second tab). Setting HTMX attributes on a non-HTMX form field should be avoided, and overriding its ID may cause problems. IMO we should try to identify a cleaner approach.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have went ahead and made a possible modification to this.
In bulk views, I initialize two copies of the form:
Since this render_table_filter_field tag is only used by the table coumn filtering logic, this shouldn't be a problem anymore.
Let me know if this approach is a more "safer" one while allowing for some code re-use. I can go a little deeper and perhaps modify all filtersets to add a "column filter" tuple to allow a more clean approach to limiting the columns as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AFAICT this should work fine, but do we need a full form instance for the columns? It might suffice to make a copy of the relevant fields from the filter form and attach them to their respective columns.
Though with either approach, I feel like we're missing a step. The current implementation depends on the column name and the field name matching (
form_field=table.filterset_form|get_filter_field:column.name
). This should work ~95% of the time but inevitably we're going to find exceptions. I'd like to see if we can devise a more robust approach, short of duplicating the field definitions.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of initializing the form right away, we could copy the form definition and then remove fields that not present on the table before intitialization. This feels like excess code for very little gain however
I think we should handle this on a case-by-case. The only other option would be looking at the table and building a completely new form class dynamically based on the table field types, however we then would likely lose all the custom filtering unless we tie it with the existing filter form somehow.