Epic: Search Improvements

[bryanculver]

Proposed Changes

• [ ] #976
• [ ] #1711
• [x] #923
• [x] #1416
• [x] #422
• [ ] #39
• [ ] #38
• [x] #1638
• [ ] Add missing indexes on commonly searched fields
  • [ ] #1641
  • [x] #1639
  • [ ] #1861
  • [ ] Evaluate models individually for common end-user filtering
    • Past research has been limited to known issues/internal use of .filter()
    • Poll known deployments for common search patterns

Justification

[itdependsnetworks]

This was my thought process to solve this use case. The specific wireframe is about rbac controls, that being said, the same should be able to apply for within in each ObjectListView search on the right side. Perhaps it should only show when you click an "advanced" button and would not include the content type (as the it would be known by the context of which objectlistview you are in)

[bryanculver]

This was my thought process to solve this use case. The specific wireframe is about rbac controls, that being said, the same should be able to apply for within in each ObjectListView search on the right side. Perhaps it should only show when you click an "advanced" button and would not include the content type (as the it would be known by the context of which objectlistview you are in)

@itdependsnetworks Are you suggesting this wireframe solves ALL of the desired search improvements of this epic? Or particular ones.

[glennmatthews]

I think we need to have two separate tracks of filtering improvement epics, but maybe I'm the only one drawing the distinction.

The items tracked in this epic are about the free-text "Search" filter (both the global "search" across multiple models, as seen on the home page, and the "search"/"q" field seen on individual filter-forms) to cover a broader swath of use cases.

The other epic (I can't find a specific "epic"-tagged issue at the moment, though I thought we had one - but see #1400, #1483, #1605) is for making filter-forms capable of expressing all supported filter operations rather than the current manually-coded and limited subset exposed by our bespoke FilterForm classes. @itdependsnetworks wireframe above applies to that epic, IMHO.

[bryanculver]

I think we need to have two separate tracks of filtering improvement epics, but maybe I'm the only one drawing the distinction.

The items tracked in this epic are about the free-text "Search" filter (both the global "search" across multiple models, as seen on the home page, and the "search"/"q" field seen on individual filter-forms) to cover a broader swath of use cases.

The other epic (I can't find a specific "epic"-tagged issue at the moment, though I thought we had one - but see #1400, #1483, #1605) is for making filter-forms capable of expressing all supported filter operations rather than the current manually-coded and limited subset exposed by our bespoke FilterForm classes. @itdependsnetworks wireframe above applies to that epic, IMHO.

I agree we have discussed these and being distinct different items. To me searching and filtering are one-in-the-same but I do also see that they are different.

This phrase here:

"search"/"q" field seen on individual filter-forms) to cover a broader swath of use cases

I would include negation (I want to search for everything not assigned an address in 10.100.100.0/24, !10.100.100.0/24) to be a search use case but that negation would probably lead to UI/UX enhancements that would be applied to filter-forms.

@lampwins Can we review the searching/filtering improvement stories and have a clearer delineation of the two?