Search broken since upgrade from 6.4.1 to 6.5

Technical assistance
1

Hi,

i have an issue with the search api after updating to 6.5.
I have extended my tickets with some fields and try to query them.

An example query would be:

https://zammad/api/v1/tickets/search?query=custom_text:*123*

Which should return something like this (i have removed every other ticket attribute to make it shorter):

[
    {
        "id": 1,
        "custom_text": "123,234,345,456,567"
    },
    {
        "id": 2,
        "custom_text": "123 234 345 456 567"
    },
    {
        "id": 3,
        "custom_text": "644 223 112 555"
    }
]

This worked until 6.4.1.
Now after upgrading to 6.5 the ticket with id 1 is missing from the result.

It seems that a comma in the value of the field breaks a query using a wildcard. I think also a semicolon breaks the query.
The field is a string type field for up to 500 characters.

Infos:

  • Used Zammad version: 6.5
  • Used Zammad installation type: package
  • Operating system: debian
  • Browser + version: Brave 1.78

Expected behavior:

  • Retrieving results when querying a custom field of type string using wildcard selector (*) even if the field contains a comma or semicolon

Actual behavior:

  • As soon as the custom field contains a comma or semicolon the wildcard selector in the search query is ignored

Steps to reproduce the behavior:

  • Create a custom field for tickets of type string (simple textfield). Create or edit a ticket and insert comma separated text into this field. E.g. “123,456,789”.
    Then try to query this using a query like this:
https://zammad/api/v1/tickets/search?query=custom_field:*456*
2

You are expected to read the release notes. Especially the breaking changes, hint hint.

3

I have read the release notes and have fixed stuff like “users/me/?full=true” not returning the same object as before, but i have no clue what in the release notes could affect this type of search issue.

Could you give me a hint where i can look up things to solve this?
Or is this a permanent change and this type of query is not possible anymore?

4

Maybe the remark with the required searchindex rebuild…?

5

I did this, now a second time to be sure that the first one did not fail. But the index was rebuilt successfully.
But the query doesn’t work.

6

This is the output of the rebuild, in case of not believing that i really rebuilt the search index:

sudo zammad run rake zammad:searchindex:rebuild
Dropping indexes... done.
Deleting pipeline... done.
Creating indexes... done.
Creating pipeline... done.
Reloading data...
  - Chat::Session...
    done in 0 seconds.
  - CoreWorkflow...
    done in 0 seconds.
  - Cti::Log...
    done in 0 seconds.
  - Group...
    done in 0 seconds.
  - Job...
    done in 0 seconds.
  - KnowledgeBase::Answer::Translation...
    done in 0 seconds.
  - KnowledgeBase::Category::Translation...
    done in 0 seconds.
  - KnowledgeBase::Translation...
    done in 0 seconds.
  - Macro...
    done in 0 seconds.
  - Organization...
    done in 1 seconds.
  - Overview...
    done in 0 seconds.
  - PublicLink...
    done in 0 seconds.
  - Report::Profile...
    done in 0 seconds.
  - Role...
    done in 0 seconds.
  - StatsStore...
    done in 10 seconds.
  - Template...
    done in 0 seconds.
  - TextModule...
    done in 0 seconds.
  - Ticket::Priority...
    done in 0 seconds.
  - Ticket::State...
    done in 0 seconds.
  - Ticket...
    done in 6914 seconds.
  - Trigger...
    done in 0 seconds.
  - User...
    done in 46 seconds.
  - Webhook...
    done in 0 seconds.
7

Is there a chance that the way you’re making the request looses the trailing wildcard? I can’t reproduce the issue you got this exact URL. But if I remove trailing wildcard it works like you described - item without commas is found, but comma-separated one is missing…

8

No i don’t think that the trailing wildcard is lost when the request has been send.
I am using postman for this and also tested it against the search of the zammad website.

From the devtools i can see that the zammad website is generating a very similar request:

Link:

https://zammad/#search/custom_field%3A*456*

Resulting request:

https://zammad/api/v1/search?query=custom_field%3A*456*&by_object=true&limit=50&_=1747315091581

In the results the element with id 1 is missing, but should be returned, as it matches the pattern.
This worked fine with 6.4.1.

It broke after the update.
The search index has been rebuild 3 times after the update.
First after updating, a second one after i was blamed not having done this and a third time to be able to copy the output of the rebuild process.

I saw that querying with a post request is also possible. But i haven’t found a way how i can nest the conditions with logical operators (and/or).
Is there a documentation for that or could you give me an example how this would look like?

ChatGpt told me that this may correlate with this issue: https://github.com/zammad/zammad/issues/5558

Could this be true? And if so, is there a minor update planed in the next weeks that could contain this fix?

Atm i am trying to replace all values that contains comma separated values with spaces in the database and then rebuild the index to have a workaround for this.

9

It is already available in stable. So a normal update would bring you the latest available 6.5 version.
Hard to tell on what version you are, the thread template usually asks for this, but we don’t have much control over what users insert there (if anything). You can double check within version, there’s a commit ID which you can use to look up the commit history of Zammads stable branch to see if it’s older than the 16th April or not.

1 Like
10

The exact version is:

6.5.0-1743671234.61b4a196.bookworm amd64

This is what apt gives me as.
But indeed there is an update available to

6.5.0-1747300878.df5248ff.bookworm amd64

I will try this and report back. Thanks for the hint :slight_smile:

11

Yep, your on a version from 3rd April.

12

That was the fix. It works with the update :slight_smile:

1 Like
13

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.