AnsweredAssumed Answered

Workflow action 'update' sets a flag that is never unset

Question asked by Alex Klimentov on Apr 18, 2018



I've encountered a peculiar bit of unintended functionality in the (default) workflow code, and after (a few hours of) debugging, traced it to a specific line in the 'include/workflow/action_utils.php' file. Our version of Sugar is 6.5, but as far as I could determine by checking the same file in the newer releases, that line is still there in 7.9 (although I might be wrong on that).


Note that everything that comes below refers to the core Sugar files and not custom ones, and the bits of code in question came with the original Sugar installation.


The unintended functionality in question is as follows. When an object is assigned to a user, the code in 'modules/teams/TeamSetLink.php' is supposed to check whether the user is a member of any of the teams this object is assigned to and, if not, add a team for that user to the list.


This bit of code is not executed under the following two conditions:

 - if $GLOBALS['sugar_config']['disable_team_access_check'] is set (which it isn't)


 - if $this->_bean->in_workflow is set.


Now, on our company's system, I discovered that when assigning some objects to a given user, there would appear an extra team (the user's default one) in the assigned teams list for that object, whereas with some other objects (but the same user) that simply would not happen.


As it turned out, the reason for this behaviour lies in the aforementioned 'include/workflow/action_utils.php'. When the objects are saved, the custom and default logic hooks are executed, including the default one that instantiates the WorkFlowHandler class in 'include/workflow/WorkFlowHandler.php'. Then, the objects that satisfy the conditions of any workflow with an "update" action trigger the function process_action_update() within action_utils.php. This functions ends with the following line:


$focus->in_workflow = true;


After a lot of logging and a lot of backtracing, I was able to convincingly establish that this flag is NEVER subsequently set to false until either the session expires, or the world ends, whichever comes first. This appears to completely contradict its established description in SugarBean.php ( "Set to true if the bean is being dealt with in a workflow" ). As far as I was able to establish, all other instances of this flag being set occur when a workflow is dealing with a temporarily created (e.g. a related) bean, and not with the main bean that triggered it, such as this bit of code in process_action_update_rel() in the same file:


$rel_object->in_workflow = true;




But I don't see any other occasions on which this flag would be set to the bean currently being worked on, nor do I believe that it should be the case here, either. In this specific case, as a result, when the function save() was subsequently executed in TeamSetLink.php, that flag prevented the team for the assigned user to be added to the list as the relevant bit of code is skipped when in_workflow is true (as mentioned above). I cannot say whether there are any other unintended consequences that arise due to the flag being set in perpetuity, but this feels very unintended.


Of course, in contrast, the objects that didn't satisfy the conditions of any workflows with an "update" action, did NOT trigger this function, and thus did not get that flag set to 'true'.


I haven't asked a question yet, so here it is: why? For what purpose is this flag being set there? Is it to appease Zeus, the Lord of Thunder, or am I just an idiot and there's an obvious reason I'm not seeing? If it's the latter, then what is the most straightforward way to fix the bug with the workflows that trigger an "update" action then disallowing the addition of a team to the list?


Many thanks,