OK, it is becoming a bit more clear now, and I recall running into this before. Even though the code seems to be correct. Let me explain:
I had a condition on the task, that checked whether the value in field A was greater than the value in field B. When true, an e-mail should be sent out. The problem was that the e-mail was sent out no matter what. I drilled down to this code that does the actual evaluation of the task conditions. I added some background fatal logging in this method, which never logged anything to the background log. Calling the $task->evaluate method manually from com_vtiger_workflow.service did produce a log entry, and playing with it some more, the evaluation method worked correctly when called (producing the boolean you'd expect).
Then I remembered having this problem before: I had some workflow tasks that either never ran or always ran, when I had the conditions on the task. When I moved the condition from the task to the workflow (essentially splitting the tasks across multiple workflows), it would behave as expected. So I tried the same here and voila, the e-mail gets sent out when expected and doesn't get sent out when expected not to. So it works fine, but I need to place the condition on the workflow, in stead of on the task.
What I don't understand, is that this 'if' block seems to be correct. It shouldn't prevent the evaluate task from running (I also dumped the instance method names to the log, 'evaluate' was a method of the instance, so it should just invoke the abstract class method), but it does somehow.
EDIT
More accurately, it seems as though the $task->evaluate() in the 'if' block always returns true, not as if it is never executed.
SOLUTION
OK, this was really logical and not logical at the same time:
Every workflow task has an option to delay execution. When you check that, another checkbox will appear that will allow you to re-evaluate the conditions you set on the task when the actual execution of the task is done. E-mail tasks are delayed by definition, even when you don't check the 'delay' box. But the 're-evalution' won't be done if you don't explicitely tell the system to do so (by checking the hidden checkbox).
That means that any e-mail task where you don't check 'delay' and then 're-evaluate' will ALWAYS send out an e-mail, no matter what the conditions are.
I had a condition on the task, that checked whether the value in field A was greater than the value in field B. When true, an e-mail should be sent out. The problem was that the e-mail was sent out no matter what. I drilled down to this code that does the actual evaluation of the task conditions. I added some background fatal logging in this method, which never logged anything to the background log. Calling the $task->evaluate method manually from com_vtiger_workflow.service did produce a log entry, and playing with it some more, the evaluation method worked correctly when called (producing the boolean you'd expect).
Then I remembered having this problem before: I had some workflow tasks that either never ran or always ran, when I had the conditions on the task. When I moved the condition from the task to the workflow (essentially splitting the tasks across multiple workflows), it would behave as expected. So I tried the same here and voila, the e-mail gets sent out when expected and doesn't get sent out when expected not to. So it works fine, but I need to place the condition on the workflow, in stead of on the task.
What I don't understand, is that this 'if' block seems to be correct. It shouldn't prevent the evaluate task from running (I also dumped the instance method names to the log, 'evaluate' was a method of the instance, so it should just invoke the abstract class method), but it does somehow.
EDIT
More accurately, it seems as though the $task->evaluate() in the 'if' block always returns true, not as if it is never executed.
SOLUTION
OK, this was really logical and not logical at the same time:
Every workflow task has an option to delay execution. When you check that, another checkbox will appear that will allow you to re-evaluate the conditions you set on the task when the actual execution of the task is done. E-mail tasks are delayed by definition, even when you don't check the 'delay' box. But the 're-evalution' won't be done if you don't explicitely tell the system to do so (by checking the hidden checkbox).
That means that any e-mail task where you don't check 'delay' and then 're-evaluate' will ALWAYS send out an e-mail, no matter what the conditions are.