Bug: Core Workflow "set to" not considering previously worked with objects

Infos:

  • Used Zammad version: Zammad version 6.0.0-1690808786.95163353.jammy
  • Used Zammad installation type: (source, package, docker-compose, …) package
  • Operating system: Server is Ubuntu 22.04, client browsing is Windows 11 22H2
  • Browser + version: Edge (115.0.1901.188 (Official build) (64-bit)
    ), FireFox (115.0.3 (64-bit)) Opera One(version: 100.0.4815.76)

Expected behavior:

Wanting to build out selection of Ticket Type → (Incident) → Incident Category (this is initially hidden and shows up fine after selecting Incident - this part is working):

I have another core workflow, which should be showing a “Computer Name” field once the “Incident Category” changes to “Issue with a Computer”

Actual behavior:

When selecting the “Issue with a Computer” Incident Category, the Core Workflow never displays the new field:

Here is the core workflow:

Here are all the core workflows so far:

Here are all my objects so far:

UPDATE: Check my response below, I believe this is due to a bug with the “set to” condition not considering currently selected values.

Digging into this a bit more - it appears like Zammad is not considering a previously selected field as “set”.

In the above example, the “Incident Category” object is never presented, despite the group being previously set (and used previously to show the Ticket Type object):

If I change the condition from a “set to” selection to “Not Set”, the “Incident Category” object does show up once you select the Ticket Type (intended behavior, except we need to use the Group selection as a filter - so if it’s set to an IT team it will add in the IT incident options (I’m stripping them all out in a previous step):

I believe there is a bug with the way it’s considering things “set”, which is causing it to not consider what is currently set in the UI.

I think this is, because you are using the changed to operator which is running only once and not the best choice your use case.

Can you try this condition:

Group not set
Type is Incident

The changed to operator is only for the rare use case where you want to pre select something once.

1 Like

Type is incident works. I need “Group is” to work, and it’s not. I believe there is a bug here. I’ve simplified these rules down by just always displaying the group + type, and still nothing. “Group not set” works in combination with “Type is Incident”, however my goal for conditions is “Group is ABC Help Desk, DEF Help Desk, GHI Help Desk, etc” + Ticket Type is Incident THEN show the Incident types object. The groups are not registering as having a value, even when they do, rendering the “group is XYZ” useless. Everything looks like this:

But the “Incident Type” object never shows:

We have 1 to 1 the same error. Anyone has an idea how to fix it?

I do not, and it’s really preventing me from implementing Zammad at this point. I’ve passed it on to a web developer I work with regularly - he is familiarizing himself with the system and going to try and see if this is a simple fix or not, at this point I’m waiting to see what he says.

1 Like

When I see it correctly, the example is with the customer role or?

Is the field, in general, available for the customer role?

At least for me it’s working correctly, when I build such a similar situation.

  1. Hide some fiels (group, state, incident type)
  2. Show Group field again based on Organization value
  3. Show Incident type based on group + type selection
1 Like

The general hiding of the fields works well. Also showing the fields based on objects that are present with the general Zammad installation like group or type works great. If you change the rule that a certain value of a self created selection field is requested, it does not work anymore. If you use the operator “was changed” it works.
@dominikklein which version are you using?

I tested on develop and stable.

We would really need example workflows that are not working, to check it.
The example from @bahusafoo is working for me.

1 Like

Are you able to show us steps on how you set up your workflows, etc.? I’ve deleted rules, reinstalled zammad, etc. at this point - I can’t get my example to work at all. I installed from the package, not from source - I’m not sure if that would make a difference. Are there logs I can check for workflows firing?

I can reproduce it when I use a custom object attribute select field: Core workflow "is"/"is not" conditios are not working for custom select fields · Issue #4752 · zammad/zammad · GitHub

The installation should be not important.

At least for me, your example with only the “static” Zammad fields from the screenshots is working (but maybe it’s one simple piece that I did not completely reproduce).

1 Like

So I found something in addition to the custom select fields that may be contributing to my specific case.

Context: Each org in my environment will have 4 groups: Information Technology, Maintenance, Materials Management, Human Resources - we don’t want other orgs’ groups showing for end-users outside those orgs - in theory this should all work well.

I have a workflow early (priority 1) on that removes all groups from the group selection, and another (priority 2) that adds specific ones back later on based on the user’s organization (The specific named groups mentioned above that are named after their specific org).

In my testing, it appears that once a group is removed and added back, its value is no longer considered in core workflow logic in later workflows down the line of priority. Removing the step that removes them, and changing the org specific filtered workflow to instead remove all other groups vs adding back the org’s specific groups allows it to work, as the group is never removed and then added back.

I hope this makes sense.

Fyi @dominikklein @jns this is being tracked @ Core workflow "is"/"is not" conditions are not working for custom select fields · Issue #4752 · zammad/zammad · GitHub. I made a video that actually helped me narrow down what is happening and posted there along with a simplified example for recreating it.

Basically, once an option is cleared from a select field, if you add it back later it no longer works for “is/is not” logic.

The root cause of this has been fixed, FYI (GitHub Issue). Thank you to all who were involved!

1 Like

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