Scheduler condition gets ignored

[herzkerl]

Infos:

• Used Zammad version: 3.3.x
• Used Zammad installation source: source
• Operating system: Debian
• Browser + version: Safari, newest

Expected behavior:

• Trigger condition for ticket type gets ignored

Actual behavior:

• Schedulder condition for ticket type shouldn’t be ignored

Steps to reproduce the behavior:

• I’ve set up a scheduler that reminds customers of unpaid invoices. Every invoice get’s BCC’ed to Zammad and have their ‘type’ set to ‘Beleg’.
• The scheduler filters for ‘type’ = ‘Beleg’, but doesn’t list any tickets below the conditions
• When removing ‘type’ as a condition, the tickets are listed below the conditions
• Yes, I have tripple-checked (within the rails console, also) that the ticket type does indeed show ‘Beleg’

Also, this stopped working recently, so maybe something got changed in a recent update.

[MrGeneration]

I’m sorry, but I can’t reproduce this.
No matter if my object is hidden or not, it will list and work on tickets as expected:

If it still doesn’t work, please share your exact scheduler configuration.
I anticipated the object the be a select value

[herzkerl]

After fiddling around it seems it is (or was) a bug. I’m not sure what exactly went wrong, but I’d like to dig deeper to maybe contribute to a fix.

Could you tell me if the database record should store the key or the value of a list item?

(In my opinion only key would make sense, but it looks like ‘postmaster filter’ doesn’t work correctly (maybe only sometimes?) and stores the value of the list item (i.e. the ‘text’ that it shown in the text field) inside the database.)

Thank you!

[herzkerl]

Still trying to narrow it down. Please note that in the following example, PostmasterFilter should set the ‘ticket type’ (x-zammad-ticket-type) to ‘monitoring’ (all lowercase)—but the ticket shows ‘Monitoring’ with a capital M.

=> #<PostmasterFilter id: 4, name: "[Gruppe ändern] monitoring@* > Typ: Monitoring / G...", channel: "email", match: {"from"=>{"operator"=>"contains", "value"=>"monitoring@"}}, perform: {"x-zammad-ticket-type"=>{"value"=>"monitoring"}, "x-zammad-ticket-group_id"=>{"value"=>"5"}}, active: true, note: "", updated_by_id: 3, created_by_id: 3, created_at: "2019-01-15 14:50:07", updated_at: "2020-06-16 14:49:35">,

=> #<Ticket id: 1XXXX, group_id: 5, priority_id: 2, state_id: 4, organization_id: 5, number: "331XXXX7", title: "[Veeam Backup & Replication] [Warning] Backup Job ...", owner_id: 1, customer_id: XXX, note: nil, first_response_at: nil, first_response_escalation_at: nil, first_response_in_min: nil, first_response_diff_in_min: nil, close_at: "2020-06-16 13:10:44", close_escalation_at: nil, close_in_min: nil, close_diff_in_min: nil, update_escalation_at: nil, update_in_min: nil, update_diff_in_min: nil, last_contact_at: "2020-06-16 13:10:44", last_contact_agent_at: nil, last_contact_customer_at: "2020-06-16 13:10:44", last_owner_update_at: nil, create_article_type_id: 1, create_article_sender_id: 2, article_count: 1, escalation_at: nil, pending_time: nil, type: "Monitoring", time_unit: nil, preferences: {"channel_id"=>6}, updated_by_id: 1, created_by_id: XXX, created_at: "2020-06-16 13:10:43", updated_at: "2020-06-16 13:10:44">

This has been the case since I’m using Zammad, for there’s not a single Ticket with the type ‘monitoring’ (lower case):

irb(main):214:0> Ticket.where(type: 'monitoring').count
=> 0

irb(main):215:0> Ticket.where(type: 'Monitoring').count
=> 7290

[MrGeneration]

Just a small follow up from my end:
Values you’re selecting and inserting in Zammad (from select fields) should always be the key being put to that attribute.

I don’t know what went wrong in your system, but the key should be used consistently all through the system. Note that if you changed the key values, Zammad will not update the existing keys on tickets which may cause issues.

However, technically the custom object knows that there’s an historic option no longer being available.

[herzkerl]

Weird—it could have been a bug in an earlier version of Zammad. Seems to work correctly now. For sake of completeness, I have changed the ticket type accordingly:

irb(main):011:0> Ticket.where(type: 'Monitoring').update_all(type: 'monitoring')
=> 7309

Thank you very much, @MrGeneration!