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

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.

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.