Skip to content
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

Issues with searching lists and campaigns; spaces and tags #1058

Closed
MaximilianKohler opened this issue Nov 25, 2022 · 5 comments
Closed

Issues with searching lists and campaigns; spaces and tags #1058

MaximilianKohler opened this issue Nov 25, 2022 · 5 comments
Labels
bug Something isn't working

Comments

@MaximilianKohler
Copy link
Contributor

Version:

  • listmonk: (v2.2.0)
  • OS: Ubuntu

Description of the bug and steps to reproduce:

On the "lists" page, I have a list called "Thanks ALL", if I search "all" or "thanks" it shows up. If I search "Thanks all" it doesn't show up. I renamed it to "Thanks_ALL" and it shows up when I search for that ("_all" also brings it up, which is great). So it seems to be an issue with spaces. Also, tags seem totally useless. I created a test tag "asdf" on one list, and searched "asdf" and no results.

I noticed there are tags on campaigns too, and those tags don't bring up results in the campaign searches either. The only functional use of tags that I can tell is in the "Subscribers" list you can click on tags to sort by lists.

@MaximilianKohler MaximilianKohler added the bug Something isn't working label Nov 25, 2022
@knadh knadh closed this as completed in 8e3e1b9 Nov 27, 2022
@MaximilianKohler
Copy link
Contributor Author

MaximilianKohler commented Feb 23, 2023

Now when I have lists like Thanks_ALL and I search "all" or _all I get 0 results. and if I search thanks_ I get a bunch of lists that have no _.

@knadh
Copy link
Owner

knadh commented Feb 26, 2023

"all" is a stop word in the Postgres English fulltext search which gets eliminated in search. I'm not sure if Postgres has a configuration that allows all words.

@MaximilianKohler
Copy link
Contributor Author

But it was working before (see OP)?

@knadh
Copy link
Owner

knadh commented Feb 26, 2023

In v2.3.0, the search was switched to use Postgres' built-in Fulltext search instead of the naive string search that was in place until v2.2.0. Fulltext is the correct approach.

@MaximilianKohler
Copy link
Contributor Author

MaximilianKohler commented Feb 26, 2023

Ok. Do you know of a list of the stop words, so I know what I can't use and what I can replace ALL with? I searched and found https://www.postgresql.org/docs/current/textsearch-dictionaries.html#TEXTSEARCH-STOPWORDS but it doesn't list the stop words.

I'm not sure if Postgres has a configuration that allows all words.

Looks like it does: https://stackoverflow.com/questions/19134979/postgresql-full-text-search-and-reserved-words-preserving-some-words - but that's too technical for me to understand.

EDIT:

Found this "list of stopwords" https://superuser.com/questions/479400/list-of-stopwords-in-postgres-9-1
https://github.com/postgres/postgres/blob/master/src/backend/snowball/stopwords/english.stop

And "directions to switch between using no stop words and all stop words" https://stackoverflow.com/questions/1497895/can-i-configure-postgresql-programmatically-to-not-eliminate-stop-words-in-full

I guess these are both things that I have to figure out and change on my end? If so, that's kind of a pain. I guess for now I'll use numbers (A11) instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants