My Schedular module gives you the opportunity to set certain fieldvalues on a related record whenever you delete a Schedular record: (https://github.com/Luke1982/newSchedular/blob/master/modules/Schedular/eventhandlers/modules_beforerecorddelete/forSalesOrder.php). As you can see in this example I used it to clear out a related SalesOrder's duedate when a Schedular record is deleted.
In my local installation I'm testing a an upgrade from an old coreBOS version and I've noticed the duedate does not clear out. Upon further investigation I saw that in fact, the clearing did happen, but was immediately reversed (I could see that in the 'View history' widget). I turned on the debug log and saw that a query was happening after the Schedular-launched query that in fact reversed the duedate setting. The Schedular query that cleared the duedate was also visible, but as I said, that happened first, then the duedate was reversed by yet another query.
In the current installation, this doesn't happen and I haven't changed anything to the Schedular module. Have there been any changes, maybe in the aftersave event handling or system-workflows that could cause this? I can't asses from the log entries what part of the application is doing this.
UPDATE
I found out what was happenning. Apparently, I created a workflow in the Schedular module with a custom task. That task did NOT function in the 'old' installation, at least not as expected. In the new installation, that task suddenly started to function. Since I use the regular save method to update the related record (intentionally, to trigger workflows), the task fired and reset the SalesOrder duedate.
UPDATE 2
Well, the workflow WAS functioning in the 'old' installation, since it was meant to update the SalesOrder's duedate when the Schedular record's date changed. Somehow, that workflow never did that when the Schedular record was deleted, or maybe the order in which workflows and afersave event fire was changed, not sure about that. Anyway, the workflow task now ALWAYS updates the SalesOrder, so I'll add a check that checks the Schedular record for 'deleted' before it updates the SalesOrder record.
UPDATE 3
I can't alter my workflow task to do what I want, which is: update the salesorder duedate only if the Schedular record is NOT deleted. I tried an INNER JOIN on the vtiger_crmentity table WHERE 'deleted' on vtiger_crmentity was 0, but apparantly, the workflow is fired before the crmentity table is updated with the deletion of the Schedular record. I tried installing an 'on delete' workflow task for the Schedular record, but that will only allow me to update fields on the Schedular record, since the SalesOrder is related through an M:M relation, not a M:1.
UPDATE 4
I solved this by:
In my local installation I'm testing a an upgrade from an old coreBOS version and I've noticed the duedate does not clear out. Upon further investigation I saw that in fact, the clearing did happen, but was immediately reversed (I could see that in the 'View history' widget). I turned on the debug log and saw that a query was happening after the Schedular-launched query that in fact reversed the duedate setting. The Schedular query that cleared the duedate was also visible, but as I said, that happened first, then the duedate was reversed by yet another query.
In the current installation, this doesn't happen and I haven't changed anything to the Schedular module. Have there been any changes, maybe in the aftersave event handling or system-workflows that could cause this? I can't asses from the log entries what part of the application is doing this.
UPDATE
I found out what was happenning. Apparently, I created a workflow in the Schedular module with a custom task. That task did NOT function in the 'old' installation, at least not as expected. In the new installation, that task suddenly started to function. Since I use the regular save method to update the related record (intentionally, to trigger workflows), the task fired and reset the SalesOrder duedate.
UPDATE 2
Well, the workflow WAS functioning in the 'old' installation, since it was meant to update the SalesOrder's duedate when the Schedular record's date changed. Somehow, that workflow never did that when the Schedular record was deleted, or maybe the order in which workflows and afersave event fire was changed, not sure about that. Anyway, the workflow task now ALWAYS updates the SalesOrder, so I'll add a check that checks the Schedular record for 'deleted' before it updates the SalesOrder record.
UPDATE 3
I can't alter my workflow task to do what I want, which is: update the salesorder duedate only if the Schedular record is NOT deleted. I tried an INNER JOIN on the vtiger_crmentity table WHERE 'deleted' on vtiger_crmentity was 0, but apparantly, the workflow is fired before the crmentity table is updated with the deletion of the Schedular record. I tried installing an 'on delete' workflow task for the Schedular record, but that will only allow me to update fields on the Schedular record, since the SalesOrder is related through an M:M relation, not a M:1.
UPDATE 4
I solved this by:
- Setting a REQUEST variable that indicates deletion of the schedular record in my beforerecorddelete event
- Using that REQUEST variable to asses whether I should launch the workflow task to the salesorder or not.
But, have there been any changes in the last two years regarding the order in which beforedelete hooks and workflows are executed? Because in the old installation this was working as intended. Maybe by accident, but it did..