Simple workflow task condition error

[Guido1982]

I have a very simple workflow. It sends an e-mail when a certain checkbox (custom field) is set to true (has changed to - true: boolean). I've got 20 workflow tasks like these but this one doesn't work for some reason. When I remove the condition (the workflow runs on every save) and edit a record the e-mail gets sent. When I add the condition, it doesn't. The field is a custom field and the label is quite long. It had a question mark in the label that I removed, but that didn't do the trick. Any ideas what this simple thing could be?

[joebordes]

Paste here the metadata of the field (vtiger_field row).

[Guido1982]

tabid fieldid columnname tablename generatedtype uitype fieldname fieldlabel readonly presence defaultvalue maximumlength sequence block displaytype typeofdata quickcreate quickcreatesequence info_type masseditable helpinfo
22 750 cf_750 vtiger_salesordercf 2 56 cf_750 Order klaar om ingepland te worden 0 2 100 26 61 1 C~O 3 0 BAS 1 NULL

I hope this turns out somewhat readable...

[joebordes]

there isn't anything there that seems odd. if you want to try changing the label for something smaller and more compact and then translating that string you can do that but I don't think that is the problem.

Try activating the BACKGROUND log

https://github.com/tsolucio/corebos/blob...erties#L50

that should give you detailed information on the evaluation

[Guido1982]

This problem is not related to the field. I tried checking another field (checkbox), that gave me the same problem. The other field I checked was not a custom field. The problem occurs when I use 'has changed' or 'has changed to' in a workflow task condition on a checkbos. When I switch off the condition evaluation or change the condition to 'exists', or 'is', it works. The condition serialization in the database is:

O:11:"VTEmailTask":20:{s:18:"executeImmediately";b:0;s:15:"attachmentsinfo";a:0:{}s:9:"dzattinfo";a:0:{}s:10:"workflowId";s:3:"112";s:7:"summary";s:69:"Verstuur e-mail naar Franka als order klaar is om ingepland te worden";s:6:"active";b:1;s:7:"trigger";N;s:8:"fromname";s:0:"";s:9:"fromemail";s:20:"crm@cbx-nederland.nl";s:7:"replyto";s:20:"crm@cbx-nederland.nl";s:7:"subject";s:53:"Order $salesorder_no is klaar om ingepland te worden";s:7:"content";s:188:"<p>Order $salesorder_no bij $(account_id : (Accounts) accountname) is klaar om ingepland te worden. Bekijk de order <a href="$(general : (__VtigerMeta__) crmdetailviewurl)">hier</a>.</p>
";s:9:"recepient";s:22:"guido@cbx-nederland.nl";s:7:"emailcc";s:0:"";s:8:"emailbcc";s:0:"";s:4:"test";s:144:"[{"fieldname":"so_goodsreceived","operation":"has changed to","value":"true:boolean","valuetype":"rawtext","joincondition":"and","groupid":"0"}]";s:2:"id";i:147;s:13:"attfieldnames";s:0:"";s:13:"attachmentids";s:0:"";s:10:"reevaluate";i:1;}

---

I tried turning on the background log, but that gave me a lot of information. Been browsing for some time but I don't know what to look for.

---

I did the following: in data/VTEntityDelta I added some log calls:

PHP Code:

    public function hasChanged($moduleName, $recordId, $fieldName, $fieldValue = null) {
        global $log;
        $log->debug("DELTA");
        $log->debug($moduleName);
        $log->debug($recordId);
        $log->debug($fieldName);
        $log->debug($fieldValue);
        if (empty(self::$oldEntity[$moduleName][$recordId])) {
            return false;
        }
        @$fieldDelta = self::$entityDelta[$moduleName][$recordId][$fieldName];  // we know this will be empty sometimes, so we ignore the error
        $result = $fieldDelta['oldValue'] != $fieldDelta['currentValue'];
        $log->debug("DELTA2");
        $log->debug($fieldDelta);
        $log->debug($result);
        if ($fieldValue !== null) {
            $result = $result && ($fieldDelta['currentValue'] === $fieldValue);
        }
        return $result;
    } 


Then I checked the log for the specific field I'm editing. I see a lot of checkboxes where both my "DELTA" and "DELTA2" searchterm are showing:

Code:

2018-07-18T10:39:16+00:00 DEBUG index DELTA
2018-07-18T10:39:16+00:00 DEBUG index SalesOrder
2018-07-18T10:39:16+00:00 DEBUG index 115825
2018-07-18T10:39:16+00:00 DEBUG index send_to_workshop
2018-07-18T10:39:16+00:00 DEBUG index 1
2018-07-18T10:39:16+00:00 DEBUG index DELTA2
2018-07-18T10:39:16+00:00 DEBUG index
2018-07-18T10:39:16+00:00 DEBUG index
2018-07-18T10:39:16+00:00 DEBUG index

But on the field I'm checking, I see:

Code:

2018-07-18T10:39:21+00:00 DEBUG VT DELTA
2018-07-18T10:39:21+00:00 DEBUG VT SalesOrder
2018-07-18T10:39:21+00:00 DEBUG VT 115825
2018-07-18T10:39:21+00:00 DEBUG VT so_goodsreceived
2018-07-18T10:39:21+00:00 DEBUG VT 1

And there is no "DELTA2". I think for some reason the method is failing for these fields. Not sure why yet.

---

UPDATE
I see: 'self::$oldEntity' is empty, while for other fields it is set to the entity object. The function is designed to return false in that case, so the task will never trigger. But why is my entity object empty?

[joebordes]

HI

I tested the checkbox has changed conditions. I recorded the session:

https://youtu.be/J68ZzQNVgZQ

then I noticed that you were saying INSIDE the task. I deleted the condition on the workflow and added them to the update field task: they worked exactly the same as on the workflow.

Could it be that you have some other workflow that is causing this effect or some code in a before-save event?

[Guido1982]

Well, the good thing is I got it to work, the bad thing is I still don't understand why the earlier version didn't.

When I was looking at your video, I was thinking about the place of the condition (on workflow vs on task) as well, but then I read you had thought of that as well and you tested it.

I performed the same trick you did, setting a text field only when the value of the checkbox changed to 1, and that worked! It left the text field alone when expected and altered it when expected.

Then I duplicated that task, but then used a send-email task and then that one didn't.

I also opened my entire coreBOS folder for this project and searched ALL files for the checkbox's name. No results came up other than the log files, which is correct because I logged a lot of these changes. But no events that changed the field whatsoever.

To be clear: this task was inside a workflow. The workflow had no conditions of its own. There were 3 tasks in the workflow, including this one. None of the other tasks touched the checkbox I was trying to monitor. I added a fourth task that updated a text field, the task had the 'has changed to true' condition and it worked. The original task, that was setup the same but used a send-email task didn't.

Then I created a completely new workflow and added the condition 'has changed to true' to the workflow and added only the one task (send e-mail). I made the workflow function unitll the first time a condition was met. This worked!

So basically the 'old' setup worked when I used it to update a text field, but not to send an e-mail. Moving that task to its own workflow did the trick. I'm glad it's working now, but I have no idea why the old one didn't work. Somehow, the e-mail task could not get the EntityDelta right, which whomever created it knew would sometimes happen, considering the code and comments they wrote. It's too bad they never added a comment that stated why they knew this wouldn't work sometimes.

[joebordes]

I'll try to find some time to test the email task but that should be the same as the conditions are evaluated outside the task itself, I mean they are evaluated and then the task is launched (or not) with no control of which type of task it is. I will try anyway as soon as I can.

As to your last comment, I understand you are referring to this line:

Code:

@$fieldDelta = self::$entityDelta[$moduleName][$recordId][$fieldName];  // we know this will be empty sometimes, so we ignore the error

that line will be empty when we are creating a new record, in that case there is no previous data so we ignore the error. In other words, the "Has changed" is not supported on creation (I think).

[Guido1982]

I agree condition evaluation and task delegation are separate so it really shouldn't matter what kind of task you use, but still that is the behaviour I experienced. Still would like to know better what is happening here since there must be some logical explanation.

Your explanation seems like a logical one, but still during debugging I tested exactly that (the oldEntity object) and saw that didn't exist in this use case. If I have some time I'll try and reproduce this test so I can be more exact about what I did and which results I got.