Closes: #9583 - Add column specific search field to tables #15073
Conversation
| @@ -5,7 +5,7 @@ | |||
| <div class="col-auto d-print-none"> | |||
| <div class="input-group input-group-flat me-2 quicksearch"> | |||
| <input type="search" results="5" name="q" id="quicksearch" class="form-control px-2 py-1" placeholder="Quick search" | |||
| hx-get="{{ request.full_path }}" hx-target="#object_list" hx-trigger="keyup changed delay:500ms, search" /> | |||
| hx-get="" hx-target="#object_list" hx-trigger="keyup changed delay:500ms, search" /> | |||
There was a problem hiding this comment.
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.
Should not impact functionality
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.
From my testing, I haven't found any issues with it.
…field_to_tables' into 9583-add_column_specific_search_field_to_tables
…ction for column filters
| @@ -5,7 +5,7 @@ | |||
| <div class="col-auto d-print-none"> | |||
| <div class="input-group input-group-flat me-2 quicksearch"> | |||
| <input type="search" results="5" name="q" id="quicksearch" class="form-control px-2 py-1" placeholder="Quick search" | |||
| hx-get="{{ request.full_path }}" hx-target="#object_list" hx-trigger="keyup changed delay:500ms, search" /> | |||
| hx-get="" hx-target="#object_list" hx-trigger="keyup changed delay:500ms, search" /> | |||
There was a problem hiding this comment.
Should not impact functionality
Do we know this for sure? IIRC we specify the full path for a reason, I just can't recall why.
| field.field.widget.attrs.update({ | ||
| 'id': f'table_filter_id_{field.name}', | ||
| 'hx-get': url if url else '#', | ||
| 'hx-push-url': "true", | ||
| 'hx-target': '#object_list', | ||
| 'hx-trigger': 'hidden.bs.dropdown from:closest .dropdown' | ||
| }) |
There was a problem hiding this comment.
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.
I have went ahead and made a possible modification to this.
In bulk views, I initialize two copies of the form:
- A copy of the form for the filtering tab
- A copy of the form for the table column filtering
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.
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.
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.
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
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.
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.
|
Another concern: There's no way to quickly discern when a column filter has been applied. |
|
Suggestion - could we make the funnel icon smaller (use a smaller font-size for it) I think it would be just as visible and would reduce the header height to what it was before. |
This is outside of the htmx container, so it doesn't get refreshed, I am not sure if there is an easy way to do this. Perhaps extracting the filtering chits in the same request, but any suggestions are appreciated.
This is just the way the dropdown works. When the dropdown closes, it reloads the htmx container, which includes all of these fields.
I have fixed this. Removing btn did the trick
Should be fixed via a max-width CSS attribute on the dropdown menu.
Done |
Should pop the badges now |
|
Still some weirdness - If I select a filter then I do a page refresh I get doubling up of the chits (see below) I tried it on feature branch and this doesn't happen.
|
|
If I select a filter (works correctly) then click on another filter again (as I want to change what it is filtering on) I get a blank drop-down so I can't actually select anything else. Sort of weird, possibly a timing thing as if I click around to other filters after a couple seconds they start rendering correctly
|
|
If you do select a filter (I did site -> Butler Communication) then click the checkbox next to Name (for select all in list) it doesn't select anything in the list. I also tried on feature and it works correctly.
|
|
Will take a peek when I can. |
I think this is simply a timing thing as the HTMX re-renders the whole table, including headers. Not sure if there is a way around this, an "easy" way would be to return the whole table but only swap the tbody on operations surrounding the column filters/search. I think the only way to handle this would be to break up the HTMX request into multiple more components with some OOB swaps, however that doesn't seem to work as intended. |
I can't recreate this. I am able to select the full list as intended. We might need some additional testing on this one. |
This one should be fixed. See comments for other two. Open to suggestions on those. |
|
This is looking really good Dan, I just see one minor issue - if you select a filter, then click the select all (next to name) it will show the "Select all xx devices matching query" the count is all the items in the table, not the filtered count. If you go through the filters tab and do the filter that way, then click the select all it will not show the "Select all xx..." message.
|
Just checked, this bug is present in both feature and develop (it is a long standing bug I believe, just maybe no issue for it). I think it would be pretty easy to fix but we should track it as a separate bug IMO. |
|
@DanSheps I'm not seeing the behavior with the select-all on feature (see screenshot), I'm only seeing it on your branch. I just go to filter tab, select a filter and then do the select-all button. If I do select-all after doing the filtering by the drop-downs, that is where I see it. What are the steps you are using when seeing it on feature?
|
|
Do a quick search, not a filter. The quick search does an HTMX request on the table only. The issue is the edit div doesn't get updated because it is outside the scope of the htmx request. We need to do an OOB swap for that as well. |
|
@DanSheps can you open a separate bug for the select-all issue? |
Closes: #9583 - Add column specific search field to tables
The plan is to use the existing filterset to generate form fields on the table column headers to allow for inline-filtering using HTMX requests
Progress
Todo
Add input fields for "name"Not needed - Quick search is suitable for thisFix filter float (Move before field name perhaps)DoneAdd show/hide filter (Optional)Outside of scope