Is it possible to create a global after_save logic hook?

I need to create an after_save logic hook that will run on all or a list of modules (array of module names to check) when a record in any of them is saved.

Instead of copying and pasting logic hook definitions to each and every module, is there a way to create such a hook globally? What kind of files should I put where?

I understand that global logic hooks are placed in ./custom/modules/logic_hooks.php, but is there any way to trigger a global logic hook on the save actions of any module?

I can see that an after_save logic hook in that logic_hooks.php file does work, but it does not seem right for my situation since in my log I can see that it triggers several times on a simple page load.
Is this because SugarCRM is based on modules and making a global after_save logic hook makes it trigger on many underlying system modules that are not even touched by the user directly?

I wonder if it would cause performance implications if I simply had a condition that allows the hook to only continue if the module that triggers it is in a list of allowed modules.

Edit: Actually the problem I have now is that I am unable to log function arguments and whenever I try to Sugar tells me "there was an error while connecting to the server".

According to the documentation the after_save logic hook should have arugments $bean, $event and $arguments, but like I said - none of them can be logged and when it tries to log it the saving is actually completely prevented.

  • Hi Artis Plocins 

    You can setup a global LogicHook without big deal, but you need to validate the bean's module at the very beginning of the LogicHook method before triggering the hook. So this validation should make sure the bean's module is in a specific list.

    Cheers

    André Lopes
    Lampada Global
    Skype: andre.lampada
  • I've got it that far, but my problem is currently that I cannot get any arguments in the logic hook function.

    I would normally check the $bean argument for the module name, but as I described in an edit of my original post - I can't get any arguments in the first place.

    I've managed to figure out that the function arguments I was trying to log were too large. I can log $bean->name, but I need a reference for what other properties a bean has. Is there a list of properties for it anywhere?

    So far the only way that worked for me to get anything like the module's name was get_class($bean), but I know that some modules have class names that are different than the actual module name.

  • I've managed to put this all together after numerous tests and experiments using any information I could find around. Also, the developer documentation does not list the actual way that team sets and team manipulation for beans works.

    So, to create a global module hook:

    1. Create a logic hook definition in custom/modules/logic_hooks.php as per the global hooks described in documentation, but use one of the module hook types like after_save or before_save
    2. Create a logic hook file as usual (normally placed in custom/modules/logic_hook_name_example.php)
      NOTE: Within the logic hook method take care not to log large variables or the system will be impaired
    3. You can both get and set the primary team and team set IDs using $bean->team_id and $bean->team_set_id properties respectively

    Since the purpose of this logic hook for me was to manipulate teams and team sets, I wrote that as a full example.

  • Hi Artis,

    it seems your solutions could fit my needs... I want to achieve that when a record is created from a parent module, the team and team_set will be inherited from the parent to the child record.

    Do you perhaps still know how you implemented this? I am completely missing the entry.

    We're on version 9, short before 10/11

    Your input would really appreciated
    Thank you
    Rene

  • I'm not a Sugar developer and I could be wrong, but in general there could be a number of relations (flex relate, relate fields, relationships) set from the record created to other records prior to new record saving hook is triggered, therefore it might not be obvious which one of relation should be treated as parental.

    If you like to make inheritance work for some particular cases with parental relation specified, that might be configurable with Logic Builder tool - drop me a line with the use case description and I'll try to get back with solution

    Best Regards,
    Dmytro Chupylka

    integroscrm.com
    We make work in Sugar CRM system faster, more convenient and efficient

  • If you have a child-parent relationship then perhaps you want an after relationship add logic hook rather than a before or after save. Generally each of the records has to be saved (so they each have an ID) and then related to each other. 
    In the arguments of an after_relationship_add logic hook you have a $bean (the bean of the record you are on) and in the arguments 

    $arguments['related_module'] and $arguments['related_id']

    will give you the module name and id of the related record so you can get the bean of the record you just related to your $bean.

    $relatedBean = BeanFactory::retrieveBean($arguments['related_module'], $arguments['related_id'])

    Manipulating Teams on the $relatedBean to match the $bean should then be relatively simple if you follow some guidelines you can find here:

    https://support.sugarcrm.com/Documentation/Sugar_Developer/Sugar_Developer_Guide_11.0/Architecture/Teams/Manipulating_Teams_Programmatically/index.html

    FrancescaS

  • here is the use case - if I create a task in Sugar and specify relations to Contact and Case for it, which one of the relations is truly parental for the Task from the business perspective and, consequently, which Team/AssignedTo to inherit?

    IMHO it's not obvious in general and should be considered per each case - there is hardly a place for a global implementation

    However, there is an option - to agree on a root object (e.g. Account) and draw a hierarchy from the root to other modules, specifying the particular relation for each node. Then implement inheritance node by node.

    We used this approach for two of our customers - for the first one with coding, for the second one - with Logic Builder configuring, which allows changing criteria of inheritance with simple flowchart editing.

    Best Regards,
    Dmytro Chupylka

    integroscrm.com
    We make work in Sugar CRM system faster, more convenient and efficient

  • I agree. At this time, we don't have enough details to recommend a solution for the determination of what is a parent-child relationship in this scenario, however the information that would be needed to implement the logic is all there, in the beans.

  • 100% true, it is in the beans.

    However, Sugar Admins an Sugar Consultants may not know what "beans" are and even haven't to be acquainted with general Sugar development practices to configure data inheritance for their Sugar instances.

    Here is an example of how new Note could inherit parent_name record's Teams Set and AssignedTo (use fullscreen mode to watch)


    I used the Logic Builder no-code tool (https://logicbuilder.integroscrm.com) to configure this behavior and get with a click an installable zip, that activates configured functionality.

    The Logic Builder flowchart for this case is fairly simple and could be designed and adjusted without any Sugar coding skills:



    Also, an example of how to set a team for child records with SugarBPM could be of interest, it is described in this post:
    https://sugarclub.sugarcrm.com/dev-club/f/questions-answers/4575/using-sugarbpm-to-change-child-teams/22738  


    Best Regards,
    Dmytro Chupylka

    integroscrm.com
    We make work in Sugar CRM system faster, more convenient and efficient

  • You and I clearly see things from different perspectives.


    I admire your insistence on selling the Logic Builder on every question that is asked in the SugarClub, I am sure it is a great tool for any non-developer, but we are in the "Developer" club here, so it is a fair assumption that those of us who discuss things here are familiar with Sugar's terminology, or at the very least, willing to learn it, and are very much aware that the proposed solutions may involve coding.

    Please respect that.