How To Store The Date of A Field Change?

Dmytro...thanks for prototyping this for me. Since I don't believe we can include Audit fields in the actual record view or reporting, then you are right: I am looking for something more like you described. I am going to take your updated version and give it a try. 

Mykola...thank you for the response. We are looking to be able to report on changes to the status and since I don't believe we can bring Audit data into reporting (or module layouts, like Record View), then I don't believe Audit is enough of a solution. I really do appreciate you giving it some thought and responding.

Combined with your earlier instructions on creating the Sales Stage Change Date field, this seems to be working in my development instance. Is there anything I should know about the code, such as expiration or SugarCRM upgrade maintainability, before I put this into my production environment? 

You are welcome, Vince

In my opinion, if the field's audit isn't a suitable option and you need to collect only one event (sales stage was changed) and store a current date in a custom RLI's field, the better way will be to add a custom code (after_save hook) to do this and you already have it.:)

If you think about tracking a wide set of such events (Opportunity's amount change more than X%, or RLI's close date move to the next quarter, etc.). I'd recommend looking at this. Maybe you will find this option more suitable for you.

I hope it will help.

Regards,
Mykola

Nice to hear that :)

Okay, here is some information:

1. ZIP extension generated in Logic Builder does not require anything but compartible Sugar platform itself to operate. It does not make any outbound calls by its own or anything like that , it also store neither PII nor any customer data.

2. As ZIP manifest says, configuration is compatible with all Sugar flavors, both SugarCloud and OnPrem, starting version 7.9 and till the latest one.

According to the 4years of upgrade experience, configuration extensions generated with Logic Builder pass health checks successfully - there were just a few occasions that demanded to refresh ZIP by regenerating it in the Logic Builder environment to ensure new Sugar version compartibility - all these cases were related to some methods depricated in Sugar.
 
For the ready-to-use solutions that I share in the Club for the free usage, I will do refresh myself - on the first clubber's inquiry - and upload refreshed ZIP in the Club in response (as you see, refresh takes a few min)
I say "will do" because so far, there was no necessity to do that regarding any of configuration I have shared here in the Club.
 
3. ZIP includes the flowchart drawing - that drawing the configuration is generated from.
Therefore anyone who has access to Logic Builder environment can extract a flowchart drawing from zip (its a JSON text, feel free to ask me how to get it), import it to Logic Builder environment, adjust logic there and generate own version of solution as a new ZIP - with a click

4. The configuration could be uninstalled any moment - apply regular Uninstall for ZIP in Module Loader for that. This approach also works if the task is to substitute old configuration with a new one - uninstall previos and installl new one

Let me know if any questions that remain unanswered

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!

hi Vince Outlaw
for similar requirements at Opportunity level I normally create a simple module to track the changes of certain fields (i.e. Sales Stage, Value) and have a BPM to update that module accordingly, see screenshot of sample module here:

Maybe that is an useful option for your requirement?