Core Workflow: Add a new condition operator to catch modified fields in the UI for existing tickets

[YetAnotherGerrit]

Used Zammad Version

6.3.0-1713332260.1e2f95d3.bookworm

Environment

• Installation method: package
• Operating system (if you're unsure: cat /etc/os-release ): Debian 12
• Database + version: PSQL15
• Elasticsearch version: 7.17.20
• Browser + version: MS Edge Version 124.0.2478.51

Actual behaviour

When using "has changed" in a "selected condition" the core workflow is not persistent until the "update" button is pressed. The Core Wokflow instead is "false" a moment before the "update" button is used.

Expected behaviour

When using "has changed" it is true until the ticket has been saved.

Steps to reproduce the behaviour

• Create a custom ticket attribute "handover" (textarea). Disable all visibility check boxes, for the field to not be visible by default.
• Create a core workflow with the following conditions:
  • Selected Condition: If "owner" "has changed"
  • Action: "handover" "show"
  • Action: "handover" "set mandatory"
• Create a trigger that writes the "handover" as an internal note to the ticket, when "handover" has changed.

The attribute "handover" is not filled with content, because it is hidden a moment, before the ticket is saved.

Support Ticket

Ticket#10146515

I'm sure this is a bug and no feature request or a general question.

yes

[rolfschmidt]

The has changed operator has a special functionality. It is only true for the moment when the owner has been set. It's use case is to e.g. prefill input fields with specific data.

In your use case it's is wrong used since the the submit is a different action and so the field is not changed anymore. It's sounds like you want to use:

If owner is set

instead, which would make more sense.

[YetAnotherGerrit]

The has changed operator has a special functionality. It is only true for the moment when the owner has been set. It's use case is to e.g. prefill input fields with specific data.

That does not feel right from a user perspective.

In your use case it's is wrong used since the the submit is a different action and so the field is not changed anymore. It's sounds like you want to use:

But the owner "has changed" compared to what is in the database. Which is what this option is used for in all situations I have worked with it. At least, when used in "selected condition".

If owner is set
instead, which would make more sense.

This will not work. Because in above's use case, the admin wants to force agents to fill a field "handover" whenever the ticket is hand over to another agent.

If this is not considered a bug (which I highly disagree), there is no solution for the described use case. And actually, I could not think of any use case "has changed" has a reliable use for in that case.

[rolfschmidt]

Yeah, your understanding of the operator is wrong. I created and linked a task for documentation for @ralf401 to share more knowledge about the usage of the operators. I can check if I can add new operator for your use case, but your case is not solvable with the current set of operators atm I think.

[dominikklein]

I think the operator should then be renamed or? I was first also thinking differently. I understand also both use cases.

[rolfschmidt]

I think the operator should then be renamed or? I was first also thinking differently. I understand also both use cases.

yes, we could try a different naming. I was thinking about the following:

is modified (NEW, Always true for new tickets, but set to true for existing tickets only if the field has different value than the saved ticket)
is modified to (NEW, Always true for new tickets on value match, but set to true for existing tickets only if the field has different value than the saved ticket and value match)
just changed (RENAMED, previous: has changed)
just changed to (RENAMED, previous: changed to)

[YetAnotherGerrit]

I still do not understand, what the condition does, if he doesn't react to changed values. And why does it even make sense, to keep a condition, that reverts itself, before ticket update?

Edit: I will make an appointment with you/colleagues to help me understand.

[YetAnotherGerrit]

I just understood and learned, that conditions are not working with all operators. Then maybe we need a warning, if a user choose a not working condition/oeprator-combination?

[rolfschmidt]

I think the operator should then be renamed or? I was first also thinking differently. I understand also both use cases.

yes, we could try a different naming. I was thinking about the following:

is modified (NEW, Always true for new tickets, but set to true for existing tickets only if the field has different value than the saved ticket) is modified to (NEW, Always true for new tickets on value match, but set to true for existing tickets only if the field has different value than the saved ticket and value match) just changed (RENAMED, previous: has changed) just changed to (RENAMED, previous: changed to)

I talked to @YetAnotherGerrit. We will try my proposal and if possible also check defaults for new tickets.