How To Store The Date of A Field Change?

I have not worked with RLIs but I assume you can work with logic hooks. In which case, I would use a simple before save logic hook.

I do this in Cases to record the date of the last Status change:

I created a field in cases case_last_status_change_date_c of type DateTime

then in the before save logic hook I compare the status to see if it changed:

function before_save ($bean,$event,$arguments){
   $today = $GLOBALS['timedate']->nowDb();
   if($bean->status != $bean->fetched_row['status']){          
      $bean->case_last_status_change_date_c = $today;
   }
}

(I use a variable for the timestamp because I use it elsewhere in my before save logic too)

FrancescaS

Hello Francesca,

I have drawn an after_save logic hook for this case and it works.

Do you suggest switching in the logic hook drawing above from after_save to before_save in the starting On Data Change operator?
Is there a reason for that?

Thanks,

Hi Dmytro,

As per my understanding, in the before save logic hook we can compare the new bean values and before values by using the fetched row. This might be the reason why @Francesca Shiekh has used the Before Save logic hook.

We cannot use the fetched_row property in the After save method in the Logic hook.

Hope this information helps.

PK,

https://www.bhea.com

Hello Clubbers,

regarding after_save or before_save

I've added logging into the flowchart - so that to track the Previous and New values for after_save in the out-of-the-box View Log - and generated a new ZIP with these adjustments:


Then deployed new configuration to Sugar:



Now, I opened View Log to observe configured after_save logic hook behavior and edited RLI record.

For doing that I had opened an RLI record, changed a Sales Stage for RLI, and, on data is refreshed, has looked at View Log

From this, the configured logic hook is called once - no repetitive blocks in the log.
Also, both New and Previous values of SalesStage are provided in the logic hook.

It seems for this particular case, there is no difference whether to use after_save or before_save.

Dmytro,

I am not going to labour the point and this will be my last post on this issue here but, just to try to keep future clubbers on track and as you have gone to the trouble of testing your solution, I will add these comments.

Your assertion that because there are no FATAL errors listed in the log then the before_save and after_save hooks have only run once and therefore there is no difference between them is not correct. It simply means that the part of your function that does something has not executed. That is no surprise as it should only run under certain conditions. Those conditions only exist on the first save and so no code will be executed for subsequent save events unless a user alters the data to make the conditions true again. If you want to see further proof then re-run your test with DEBUG mode switched on (not in a production instance though!) and track the workings in finer detail.

Although your solution works using after_save it is quite important in terms of development to understand what your solution is doing in order to know why using "after_save" here is wrong. When you save a record in Sugar the core code does several things: in terms of what we are looking at; first it runs any "before_save" logic hooks, then it saves the data to the database, then it runs any "after_save" logic hooks. This much can be seen from the names of the hooks if nothing else.

If an "after_save" contains a "$bean->save();" event, what happens is this: Sugar runs the "before_save" hooks, then saves the data to the DB, then runs the "after_save" hooks. At this point it finds a "save" event and so does the cycle again, "before_save", DB save, "after_save". In this last step it does once again run your code - however the conditions that it looks for are no longer true (the Status is the same between saves on the second go) so it does not execute the code. That does not mean that it hasn't run the hooks - I can assure you that it definitely has run them all twice in this scenario. This explanation should make it clear how and why infinite loops can crop up if not properly accounted for.

When you consider what Sugar actually does in the background (the DEBUG log is a good place to start) when doing this cycle you will see that, by executing the save event multiple times you are causing Sugar to consume multiple amounts of memory. While this is not an issue for one user on a demo system, when you scale up to potentially thousands of users running the saves in a short space of time you can see that it might cause memory or performance issues. This is why it is vital as a designer/developer to fully understand the impact your changes are having on a system as a whole.

By the way, I have taken a look at your solution code and, ironically, the technique Francesca suggested of using a statically defined global variable to record the "fetched_row" data in the "before_save" to use in the "after_save" is actually used in your code anyway! In fact this is older style coding and current hook parameters include the "stateChanges" array within the "arguments" parameter which is probably where you should be checking for updated values. Again, storing the whole record in a variable on "before_save" just to use in the "after_save" might be a waste of memory and processing. In this specific instance it is a double waste as the changes to the custom date field can (and should) be done in the "before_save" meaning no need to run a second save event.

No-Code tools can be good and they do have their place but that place is not as a replacement for a properly defined and executed change management process which should also incorporate comprehensive Solution Architecture / Design phases and impact assessment. Even a "small" change like this can have onward consequences in scale.

As I said, I am not going to push any more. I hope I have properly explained why "before_save" should be used in this specific instance.

Thanks,

JH.

Thank you John Hawkins for pointing out the stateChanges in the hook parameters, that older style coding is in fact something we have carried with us since v6.0 and I really should carve some time to update my custom logic hooks where that is still in use!

FrancescaS

Thank you John Hawkins for pointing out the stateChanges in the hook parameters, that older style coding is in fact something we have carried with us since v6.0 and I really should carve some time to update my custom logic hooks where that is still in use!

FrancescaS