Infos:
- Used Zammad version: 5.0.3
- Used Zammad installation type: package
- Operating system: Debian 11
- Browser + version: doesn’t matter
Expected behavior:
- filter rules should work on a first match, it should also be possible to reorder it via drag&drop
Actual behavior:
- it looks like that last match wins
Steps to reproduce the behavior:
- create three filter like:
- to contains: support@example.de with name ‘support-queue’ - moved into group support
- to contains: web-support@example.de with name ‘queue for web-team’ - moved into group web-support
- from contains: important@otherdomain.com with name ‘important mails from customer’ - moved to group important
So now if someone writes to web-support@example.de we expected that it goes to web-support group, but it goes to support group, because it contains the word ‘support’ and there filters processed in alphabetical order and on a last-match-wins basis (which is nowhere documented).
Same thing with our last filter (from) which has a to support@example.de, here also it doesn’t got to the important group it goes to the support group. In debug mode you see that:
D, [2022-04-28T13:05:06.440801 #747423-178520] DEBUG -- : ESC[1mESC[36mPostmasterFilter Load (0.8ms)ESC[0m ESC[1mESC[34mSELECT "postmaster_filters".* FROM "postmaster_filters" WHERE "postmaster_filters"."active" = $1 AND "postmaster_filters"."channel" = $2 ORDER BY "postmaster_filters"."name" ASC, "postmaster_fi
lters"."created_at" ASCESC[0m [["active", true], ["channel", "email"]]
[... other queues ...]
D, [2022-04-28T13:05:06.442205 #747423-178520] DEBUG -- : process filter queue for web-team ...
I, [2022-04-28T13:05:06.442374 #747423-178520] INFO -- : matching content 'x-any-recipient' contains web-support@
D, [2022-04-28T13:05:06.444749 #747423-178520] DEBUG -- : ESC[1mESC[35m (1.1ms)ESC[0m ESC[1mESC[34mSELECT COUNT(*) AS "size", MAX("object_manager_attributes"."updated_at") AS timestamp FROM "object_manager_attributes" WHERE "object_manager_attributes"."active" = $1 AND "object_manager_attributes"."editable" = $2
AND "object_manager_attributes"."object_lookup_id" = $3ESC[0m [["active", true], ["editable", true], ["object_lookup_id", 2]]
D, [2022-04-28T13:05:06.446678 #747423-178520] DEBUG -- : ESC[1mESC[36mGroup Load (0.6ms)ESC[0m ESC[1mESC[34mSELECT "groups".* FROM "groups" WHERE "groups"."id" = $1 LIMIT $2ESC[0m [["id", 7], ["LIMIT", 1]]
D, [2022-04-28T13:05:06.446914 #747423-178520] DEBUG -- : perform 'x-zammad-ticket-group_id' = '{"value"=>"7"}'
D, [2022-04-28T13:05:06.447852 #747423-178520] DEBUG -- : process filter support-queue ...
I, [2022-04-28T13:05:06.447971 #747423-178520] INFO -- : matching content 'to' contains support@example.de
D, [2022-04-28T13:05:06.449352 #747423-178520] DEBUG -- : ESC[1mESC[35m (0.4ms)ESC[0m ESC[1mESC[34mSELECT COUNT(*) AS "size", MAX("object_manager_attributes"."updated_at") AS timestamp FROM "object_manager_attributes" WHERE "object_manager_attributes"."active" = $1 AND "object_manager_attributes"."editable" = $2
AND "object_manager_attributes"."object_lookup_id" = $3ESC[0m [["active", true], ["editable", true], ["object_lookup_id", 2]]
D, [2022-04-28T13:05:06.450177 #747423-178520] DEBUG -- : ESC[1mESC[36mGroup Load (0.3ms)ESC[0m ESC[1mESC[34mSELECT "groups".* FROM "groups" WHERE "groups"."id" = $1 LIMIT $2ESC[0m [["id", 2], ["LIMIT", 1]]
D, [2022-04-28T13:05:06.450367 #747423-178520] DEBUG -- : perform 'x-zammad-ticket-group_id' = '{"value"=>"2"}'
Also you can’t say in the filter rules something like
- to contains support@example.de and to contains not web-support@example.de
because it just possible to have one ‘to’ per filter rule. It would also be great to have a option “stop proceeding after matching” or something like that.