Tree Multiselect fields are `NULL` initially, preventing matching in e.g. Overviews

Technical assistance
1

Infos:

  • Used Zammad version: 7.1.3
  • Used Zammad installation type: docker-compose

Expected behavior:

  • New tickets created by an incoming email behave exactly like tickets without an assigned value in a tree multiselect (other selector kinds not tested) filters (matching “contains all not”/“contains one not”, not matching “contains all”/“contains one”).

Actual behavior:

  • No filter matches. This includes wrapping a NOT around the condition (e.g. NOT(contains-one(my-value))). This means that any e.g. overview using a filter on such a select will not show that ticket, regardless of the specific filter (unless they are included using a different path of an OR, independent of the tree multiselect field).

Steps to reproduce the behavior:

  • Add a tree multiselect to your ticket object.
  • Add an email address that creates a ticket when it receives a mail. It might break in other scenarios as well, but we only tested it with mails.
  • Write an email that opens a ticket.
  • Observe that it does not match any condition as described in “Actual behavior”.

Further information

  • Changing the tree multiselect once and then clearing it again in UI fixes the behaviour.
  • In the database, new tickets have the value NULL in the field of the tree multiselect (i.e. SELECT * FROM tickets WHERE my_tree_multiselect IS NULL; finds those tickets). Tickets that were manually assigned to no value via the UI contain the string {} instead (i.e. SELECT * FROM tickets WHERE my_tree_multiselect = '{}'; finds those tickets).
1 Like
2

What’s this supposed to do? What’s the use case?

3

Suppose I want to have an Overview showing all Tickets that do not have a specific value set in their tree multiselect. For example, I have a field depicting the type of request that my customer sent in. I want to have an Overview where all Tickets except those marked as “Waiting for funding” in that request-type-field are listed. This will, however, not include Tickets that were just created for the reasons mentioned in my original post, but I want those Tickets to be included as well.

1 Like
4

gotcha, i believe Zammad is supposed to work exactly this way.

You have 2 options in my opinion:
A) set a default in your multiselect
B) set a trigger to change your multiselect value whenever a ticket gets created - this way you can define the right value based on the customer/group/org/etc

5

i believe Zammad is supposed to work exactly this way.

Do you mean that the current bahviour is the intended one? The current behaviour feels very unintuitive to me as you cannot tell the difference between a NULL ticket and a {} ticket in the UI, they are both displayed with an empty tree multiselect.

You have 2 options in my opinion

Thanks. Option B was also my preferred workaround, but I’d rather see this fixed. It cost me a good chunk of time figuring this out which for future admins could be mitigated by fixing this - in my opinion - bug in Zammad.

1 Like
6

I just read through a few Zammad issues and it seems that you’re right. They had a similar issue affecting the text field object in version 6.1.

I’ll look into it a bit more when i got time, maybe the dev team can take a look too. I think this is the issue:

lib/sql_helper.rb

def array_contains_all(...)
  result = "(#{db_column(attribute)} @> ARRAY[...]::varchar[])"
  negated ? "NOT(#{result})" : "(#{result})"
end

def array_contains_one(...)
  result = "(#{db_column(attribute)} && ARRAY[...]::varchar[])"
  negated ? "NOT(#{result})" : "(#{result})"
end

Should use negated ? "(#{result} IS NOT TRUE)" : "(#{result})" instead - but that only works for Postgres.