Core Workflow Error after updating to Zammad 6.1.0 (Package version)

  • Used Zammad version: 6.1.0-1695653179.60d00c06.buster
  • Used Zammad installation type: (source, package, docker-compose, …): Package
  • Operating system: Debian 10
  • Browser + version: Chrome, Firefox, etc.

After updating to Zammad Version 6.1.0 the UI is not working correctly anymore and we see following errors in the logs:

E, [2023-09-26T14:23:06.916326#39595-65400] ERROR -- : Error performing Core Workflow engine.
E, [2023-09-26T14:23:06.916520#39595-65400] ERROR -- : uninitialized constant CoreWorkflow::Condition::ContainsOneNot

            candidate = constant.const_get(name)
                                ^^^^^^^^^^
Did you mean?  CoreWorkflow::Condition::ContainsNot
               CoreWorkflow::Condition::ContainsAllNot (NameError)
app/models/core_workflow/condition.rb:83:in `condition_value_match?'
app/models/core_workflow/condition.rb:106:in `condition_match?'
app/models/core_workflow/condition.rb:112:in `block in condition_selector_match?'
app/models/core_workflow/condition.rb:111:in `each'
app/models/core_workflow/condition.rb:111:in `condition_selector_match?'
app/models/core_workflow/custom/ticket_time_accounting_check.rb:29:in `any_attribute_match?'
app/models/core_workflow/custom/ticket_time_accounting_check.rb:33:in `perform'
app/models/core_workflow/result.rb:123:in `block in run_custom'
app/models/core_workflow/result.rb:121:in `each'
app/models/core_workflow/result.rb:121:in `run_custom'
app/models/core_workflow/result.rb:99:in `block in run'
app/models/core_workflow/result.rb:94:in `run'
app/models/core_workflow.rb:34:in `perform'
app/models/ticket/screen_options.rb:99:in `attributes_to_change'
app/controllers/tickets_controller.rb:685:in `ticket_all'
app/controllers/tickets_controller.rb:68:in `show'
app/controllers/application_controller/has_download.rb:17:in `block (4 levels) in <module:HasDownload>'
app/controllers/application_controller/has_download.rb:16:in `block (3 levels) in <module:HasDownload>'
app/controllers/application_controller/has_download.rb:15:in `block (2 levels) in <module:HasDownload>'
app/controllers/application_controller/handles_transitions.rb:16:in `handle_transaction'

Please ensure that your database migrations are applied correctly.
You can cross check this by running

systemctl stop zammad
zammad run rake db:migrate
systemctl start zammad

Thanks for your help MrGeneration.

I saw that I wrote sometimes 6.0.1 in the Ticket I updated the ticket to the correct version at all points to 6.1.0 so it is not confusing.

I Run the command as you descripted but

zammad run rake db:migrate

gives no output. So I think therefore no changes was made and everything is ok right?

Started zammad after the migrate command but still have the issues. Also tried to clear the cache with:

zammad run rails r "Rails.cache.clear"

But this didn’t help either.

On the first look, there seems to be some missing migration. But when all migrations are executed correctly, you should check the existing core workflows in the system.

Do you have some core workflows configured?

Checked it and we didn’t use Core Workflows feature :frowning:

Are you using time accounting?

Checked it and yes time accounting is enabled.

Also checked if the error still occur when I disable time account and it seems the error is gone when I disabled time accounting feature. If I enabled it again the error will appear again.

Can you please update to the latest available package version of Zammad? I believe this was a temporary bug.

Sure I updated to the latest version (6.1.0-1695751330.fad26808.buster) but the error still occurs when I enable the “Time Accounting” feature.

Also run

zammad run rails r "Rails.cache.clear"

to be sure it is not a cache problem.

How exactly is your timeaccounting configured?
Is it the default configuration that’s defaulting to “state” without selecting?

If that’s the case change the setting to “contains not” with value “merged” (that should work for most use cases) and then submit. If it then works either a migration didn’t clean up that faulty configuration or there’s none. Not sure.

Currently the Timeaccountig was configured like in the screenshot.

I taked with the corresponding team and they didn’t use it at all. It was just something for testing purposes. So I disabled the feature and let it disabled. Therefore nor problem anymore :+1:

There seems to be a bug with this specific condition method.
When I see it correctly it should be possible to switch to “contains all not”, when you need it again.

Thank you I will keep this in mind if we need to use this feature again. Many thanks for the support from all of you!

BTW: Checked your suggestion and it works when I use “contains all not” the error will not occur anymore. Anyway I disabled the feature but just wanted to let you know :+1:

1 Like

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