Custom Object works some of the time

[RonSteiner1]

We have a custom object that is supposed to check if a particular radio button has been set to "Yes" and then populate a text field. It executes on save by binding our function to the Save and Save and Close buttons, and works most - much? - of the time. However, there are a number of times where the text field is not updated even though the conditions have been met.  Of course, we have not been able to replicate the issue - we can only see that there are records with the radio button = "Yes" and the text field remains empty.

After searching through numerous posts in this forum, I noticed two things that I suspect could relate to this, but I would like confirmation.

First, I noticed that our code binds using  $("#master_btnApply1").bind('click', function() {...}. However, I've seen other examples using $('#master_btnSave1').unbind('click').prop("onclick", null).click(function() {...}. 

Second, our code does this binding inline in the code. I've seen numerous recommendations that a better approach is to put these in Sys.Application.add_load. 

Would either or both of these possibly cause this issue? Should I make both changes? Again, I have not been able to replicate the issue, so it's difficult to test.

-Ron

[DavidPetty · Accepted solution]

@RonSteiner1 for Archer version 6.12+, I use the following to hijack the various save and apply buttons:

     // Clone Save Button
     $('#master_btnApply1').clone().attr('id', 'btnCustomSave').css({"margin-right" :"12px"}).insertAfter('#master_btnApply1');
     $('#master_btnApply1').attr('id','master_btnApply1ORG').hide();
     $('#btnCustomSave').attr('id','master_btnApply1').unbind('click').prop("onclick", null).click(function(e){
          e.stopImmediatePropagation();
          e.preventDefault();
          CheckTextFieldMinimumLength('apply');
     });

     // Clone Save And Close Button
     $('#master_btnSave1').clone().attr('id', 'btnCustomSaveAndClose').insertAfter('#master_btnSave1');
     $('#master_btnSave1').attr('id','master_btnSave1ORG').hide();
     $('#btnCustomSaveAndClose').attr('id','master_btnSave1').unbind('click').prop("onclick", null).click(function(e){
          e.stopImmediatePropagation();
          e.preventDefault();
          CheckTextFieldMinimumLength('save');
     });

     // Clone Apply (disk icon) Button
     $('#master_btnApplyIcon').clone().attr('id', 'btnCustomApply').css({"margin-right" :"12px"}).insertAfter('#master_btnApplyIcon');
     $('#master_btnApplyIcon').attr('id','master_btnApplyIconORG').hide();
     $('#btnCustomApply').attr('id','master_btnApplyIcon').unbind('click').prop("onclick", null).click(function(e){
          e.stopImmediatePropagation();
          e.preventDefault();
          CheckTextFieldMinimumLength('apply');
     });

     // Remove Save and Save and Continue Right-Click Menu
     $('.rmText:contains("Save and Close")').parent().parent().hide();
     $('.rmText:contains("Save")').parent().parent().hide();

Just replace the function CheckTextFieldMinimumLength found above with your function, and this can sit outside of the Sys.Application.add_load function. You'll also need to add the following to your function to call the original save or apply button:

if (action == 'save') {  
      $("#master_btnSave1ORG").click();
 } else if (action == 'apply') {
      $("#master_btnApply1ORG").click();
 }

Alternatively, you could add inside of Sys.Application.add_load a click event for that radio button that would either set the text field or clear it (if you choose so).  Ideally this would be cleaner approach than hijacking the save and apply buttons.

[RonSteiner1]

@DavidPetty Our requirement is that the field only get updated on a save so a click event on the radio button wouldn't work. I'll update what I have to your code and at least verify that everything still works. Unfortunately, as I said, since I can't replicate the problem, I can't tell if this takes care of it :(. 

Also, when is it necessary to use the Sys.Application.add_load vs. just including functions in-line?

-Ron

[DavidPetty]

No problem : D

Anytime you need to get data from a field in a record when it loads it should be done inside of the Sys.Application.add_load function.

Is the text field that's being updated is the access set as public?

[RonSteiner1]

Yes, it's public.  Our environment is pretty much locked down, so everyone is using either Chromium Edge or Chrome on Windows 10 with JavaScript enabled.  What's really weird is that, for the same person, it works one day and not another.

[DavidPetty]

You could add some console.log() in various places in the code and have that user open the developer tools window and select console and see what's outputted.

[RonSteiner1]

That's on my to-do list if these changes don't fix things. The big issue is that this application has a significant amount of bureaucracy around it when it comes to Production, so even something as innocuous as putting in console.log can be a big headache. Especially given that it generally works. I just did a DB query on the history log for one such person and found that it worked sixteen times and failed six, some of them even on the same day.

[RonSteiner1]

@DavidPetty I marked this as the solution because everything continues to work using your suggestions. But I have one hopefully final question. The trigger for this action is when the user tries to save and a particular Yes/No checkbox has been set to "Yes". We do this by capturing the initial value at the top of the script then the new value in the function called by the cloned button and then comparing. Should we be doing the initial value capture in a Sys.Application.add_load function? Is it possible that if we are not doing it there, that initial value could be unpredictable?

[DavidPetty]

Yep, the initial value should be capture in Sys.Application.add_load.