Suggestion: Combine sources and tags into one "filter" box

[jorgenbele]

Using GitHub inspired filter syntax we can have:

source:argus source:another_source is:open is:acked object:50

Representing:

{
  "sourceSystemIds": ["<argus pk>", "<another_source pk>"],
  "open": true,
  "acked": true,
  "tags": ["object=50"],
}

We can still make selecting sources easy by adding "source:<source_name>" for all sources to the autocompletion.

Considerations

Pros:

• Allows for copy-pasting of filters
• More easily extendable with new filtering capabilities
• Uses filter syntax that is already known to users
• Improved user experience (according to me)

Cons:

• Might require some users to learn how to use this new filtering system

Backend vs frontend?

This feature can easily be implemented in the frontend without changes to the backend.

[hmpf]

I like this idea! We might have to check it with our users though. Also, there's the matter of what to do with misspellings, and the fact that tag values have no validation whatsoever except they may not be the empty string.

[jorgenbele]

I want to try to make a component for this that just builds a normal filter. Making it default but allowing users to switch to the old system using a setting in the UI would be a nice compromise I think.

As for validation, that should be possible to do in the frontend when converting to the backend filter structure. Displaying a red outline when there are mistakes will provide users with enough feedback to fix their mistakes.

[jorgenbele]

I've worked some on creating a demo component for this feature. You can try the component in-browser from here: https://react-ts-dxdxo4.stackblitz.io/

Some of the features of it are:

• It's just text, so you can easily share your filters, import them, and edit them just like you do with regular text fields.
• Adding new terms (is:acked, is:open, source:argus, etc.) can still be done by using the drop-down, so it combines one of the nice features of the chip-based system.
• You can easily replace terms by moving the cursor to somewhere in the term (terms are space seperated), and then choosing another term in the drop-down.

Some of the non-features differences:

• Removing terms now require you to edit the text.
• You cannot as-easily select multiple sources, because of the space-seperated thingy.

I have some ideas for a next-iteration of this component:

• Treat the filter as a set of filter terms.
• Instead of having the autocomplete drop-down be for the current term, as it is in this component, make it more like a multi-select drop-down. You could then select "is:acked", "is:open" in two clicks, without closing the select component. Now you instead have to first select "is:acked", then add a space, and then select "is:open" from the drop-down.

[hmpf]

Thinking aloud: Gmail and github has, in addition to the text-box to write a query, controls to design a query. In github (when filtering issues/pr's) they are always on, and in gmail they are always off. I think it would be wise to also have controls. They build and show the query, but manually changing the query need not update the controls. This makes it easier to discover the syntax of how a query may look like. I'd say: in the beginning have both controls and textbox visible, and later allow the user to hide the controls.

[podliashanyk]

I don't see too many benefits of combining the two to be honest. It will also be reasonably tricky to implement in the new (HTMX) frontend since the source field per now is multiple-select input field and the tags field is a free solo input field. In other words their validation and implementation is very different now making this feature much more complex that when it was originally suggested.