FEATURE: in:tagged and in:untagged advanced search filters (PR #7721)

Similar to in:solved or in:unsolved, the filters check for an existence of the topic_id in the topic_tags table:

  • in:tagged means that at least one tag exists for a topic
  • in:untagged means that no tag exists for a topic

Screen Shot 2019-06-28 at 08 49 43 (Running from boot_dev --init with this branch)

see: https://meta.discourse.org/t/how-to-search-filter-untagged-topics/119641/2

GitHub

You’ve signed the CLA, joshmoore. Thank you! This pull request is ready for review.

This pull request has been mentioned on Discourse Meta. There might be relevant details there:

https://meta.discourse.org/t/how-to-search-filter-untagged-topics/119641/5

Totally support this change, but we got to add some tests here.

Thanks, @SamSaffron. I had starting taking a look into that. Is it primarily or even just https://github.com/discourse/discourse/blob/master/test/javascripts/acceptance/search-full-test.js.es6 that needs adding to?

oh only the ruby part @joshmoore have a look at search_spec no need to add js tests for this.

Before:

$ RAILS_ENV=test ./bin/docker/bundle exec rspec spec/components/search_spec.rb

Randomized with seed 39106
.........................................................................................

Finished in 19.1 seconds (files took 2.88 seconds to load)
89 examples, 0 failures

Randomized with seed 39106

After:

$ RAILS_ENV=test ./bin/docker/bundle exec rspec spec/components/search_spec.rb

Randomized with seed 36721
...........................................................................................

Finished in 23.04 seconds (files took 3.09 seconds to load)
91 examples, 0 failures

Randomized with seed 36721

It’s less clear to me if a3c8f503e0b3ec2d7f6923fa5e759104ddf74ec2 et al. can be accepted as is. Feel free to either force push it away (or to have me do so). Otherwise, I don’t have any further planned changes, @SamSaffron(, … once travis is green)

This is definitely getting there, but I would like the advanced section de-cluttered a bit:

image

We already have a natural spot for people to pick:

[any tag]
[untagged]
[tag name1]
....

I guess on click then select kit should add those 2 options on top? @jjaffeux any specific recs here?

@joshmoore as it is a “visibly changing stuff” PR be sure to always add a screenshot or two to the comments cause it helps people figure out what happened to the UX here.

I am pushing this off to 2.4 (this basically means I can not merge it in for 2 weeks, but we will definitely get it merged very early here in 2.4)

Thanks heaps for this work @joshmoore !

I guess on click then select kit should add those 2 options on top?

Hmmm… would definitely need more input to know the preference here. One option would be to have the “Tagged” section not usable if “in:untagged” is chosen. The same could hold for “in:tagged” but it’s less technically wrong.

Alternatively, “Any tag” and “No tag” could be added beside “All the above tags”.

Finally, another option would be to just list this in some as yet non-extant help section. I started adding a section to discourse_api_docs/swagger.yml but that won’t help the general user.

be sure to always add a screenshot :+1:

"I am pushing this off to 2.4

If I were to split off the first two commits into a separate PR, could they be considered earlier?

@joshmoore I definitely think it is worth splitting this into 2 PRs now. One for the server support another for the client.

I feel on the server side this change is straightforward and I am happy to merge it today. The client side needs a bunch of refinements imo

cc @jjaffeux

Yes split it please, it’s unclear to me reading the PR what is the actual UI output. And there’s almost no js code so we should just merge server side first.

Thanks, @SamSaffron and @jjaffeux. I’ve added a screenshot for the UI side of things. I’ll create a slimmer server-side PR now.

Please see: https://github.com/discourse/discourse/pull/7822

Thx.

I’m unsure. What we have:

  • Should have at least a tag
  • Should have no tags
  • Should have these tags
  • should have ALL these tags

I think the UI we have ATM is correct but we should make sure it doesn’t end up in weird states, eg: one menu has tags, the other has are untagged.

One alternative is to remove options from dropdown, and to have a radio list under “Tagged”:

Tagged: [ potential list of tags] ( ) Any tag ( ) All the above tags ( ) No tags ( ) None of the above tags (worth to add ???)

@awesomerobot what do you think ?

and to have a radio list under “Tagged”:

In terms of correctness, I agree. I hesitated because of the difficulty of getting all the across to the user in the space that’s currently allocated.

Since the right hand options really just end up filling in the search bar, I found it straight-forward enough to deal with the query:

in:tagged and un:tagged

manually. i.e. “no results are found, duh, that doesn’t make sense”. Of course, the more options you add in, the trickier it gets.

I still feel everything “tags” belongs in the tags combo, really uneasy mixing this about in 2 places.

Any ideas here @awesomerobot?

Yeah it’s tricky to cover every case in the dropdown… specifically the OR and NOT cases. We need some way to toggle between AND | OR | NOT… but then also when “All tagged” or “untagged” are selected those options are irrelevant.

A dropdown within a dropdown? I’m on the fence about this but it could work.

Screen Shot 2019-11-12 at 12 38 03 PM

Screen Shot 2019-11-12 at 12 33 08 PM

Screen Shot 2019-11-12 at 12 34 42 PM

Screen Shot 2019-11-12 at 12 34 36 PM