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

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

Hi Poojitha,

Thank you - so far as I see, both before_save and after_save perform the same in the interface...
Let me double-check with logging and get back regarding this here

Technically you can use the fetched row property in the after save method by fetching it into a protected static variable at the time the before save runs, then referencing that variable in the after save.

The problem with that in general is that it can be dangerous to change the value of a field in the after save, as it will have to trigger a save which repeats the after save. So you have to make sure your conditions have a way to avoid the loop. You are also doing two saves instead of one, and re-executing all your before and after save logic hooks at each save, so lots more processing.

Dmytro's application probably takes all that into consideration.

No builders that  ever could be  comparable to the pure code creation performed by experienced developers - builders are always about the  ability to get solution fast and for the reasonable cost and than to maintain it yourself (just like I switched to before_save and didn't spend time on creating another package)

Basic tech skills of the admins allows to avoid logic mistakes  when dealing with triggered events

In case of an infinite loop is mistakenly designed in a flowchart, yes, there is a stopper for the runtime. 

Not sure wether any stoppers in the code when infinite loop is written manually, perhaps,that might be a kind of developers warranty efforts in case that happends.

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

Hi John,

Thank you for your detailed explanations - you are completely right and I'm intrigued about DEBUG mode now!

Frankly, I had asked the Software Architect that created Logic Builder 4 years ago,  to remove this dropdown from OnDataChange operator 


but he refused because of the reasons of a significant difference))

Luckily, with this option in place, I can change between both *_save now - in a click - following the expert's advice!

I totally agree that each tool must be applied properly.

As a Sugar Partner that work with Sugar for more than a dozen years, we have projects with 5 systems integrated via enterprise bus, and an active subscriber customer with Sugar instance with, if I remember correctly, hundreds of thousands of records per hour updated via integration
Therefore, I know well - there could be solutions on the Sugar platform where no place for hooks or even regular API

For thousands-users scale projects that might include numerous integrations setting Sugar in the center as a Single Source of Truth (SSoT) about Customers, the trigger-based approach must be considered architecturally first - prior to any line of custom code is written (also manually, btw)

Yes, configuring tools are anti-optimum from a programming perspective - by their nature.

As more experienced developers are (we don't employ newbies), the more irritating the excessive and old-style code generated by a builder tool for they, would it be Logic Builder or Studio configuring tools - it is like any soulless machine is hated by a skillful professional.
I haven't known developers that prefer Studio configuring tool to manual adding custom fields! Has someone seen the opposite?
And that is awesome!
At least until subscribers look at the expert's nearest availability and expert's hourly rates.

From a business perspective - for the given scope, given system, given application, and given purpose (not a nuclear power station automation, in which our software architect is experienced also, btw) - while having the same business result in place (like on the video), the question in the difference between before_save and after_save are fairly controversial.
That was my argument while asking the software architect - the Logic Builder creator- to remove a dropdown mentioned in the picture above.
Didn't work, as you can see :)

Again, much appreciate your time and explanation!
My bad, that I started a discussion about *_save myself having a configuring business task as a topic starter!

Have a wonderful weekend!

Cheers!