locked
CRM 2011 JavaScript Error: Only forsome users types but not others... RRS feed

  • Question

  • I am firing the following code on a form load even for a CRM entity form.  When doing so, depending on the user I get a runtime error. I'm hoping someone might know what permission or other issues might be causing this.  The error is very generic and looks to be throw from CRM and not my code, nor a plugin, but the JavaScript itself.  Here's the error...

    "An error occurred.  Please wait a few moments and try again. If the problem persists, contact a system administrator."

    When I run it as an admin, it works fine. When I run it as one type of user it works fine as well.  But when I run it as one of our other user types, they get a runtime error.  What could be unique about that one user type that might cause a runtime error.  Are their specific permissions that have to be set to allow the following code to function?

    Interestingly, even when we get the error, the code seems to have ran correctly and completed. So maybe the JavaScript is not where the error is occurring.  In the plugins, I have logging and custom errors and none of those get reached.  So I don't think this is firing from a plugin.  I suspect it is the JavaScript code itself. 

    What this is doing is identifying some temporary Accounts we used in our business process. For those, I don't want the user to be able to modify them name, type, or account number. So to mark these I tag them as DUMMY accounts in the account number. So the JavaScript just verifies if the tag is there in the account number and if so, sets the fields to read only. Why would one particular user type not be able to execute this sort of code? 

    Best regards,

    Jon

    SetReadOnlyForDummyAccounts = function () { var readOnly = false; try { var accountNumber = Xrm.Page.getAttribute("accountnumber").getValue(); if (accountNumber != null) { var index = accountNumber.indexOf("DUMMY"); if (index >= 0) { readOnly = true; } } } catch (err) { alert('Error:' + err ); } SetReadOnly("name", readOnly); SetReadOnly("customertypecode", readOnly); SetReadOnly("accountnumber", readOnly); }

    I have a library with a few helper functions. Here's the  SetReadyOnly() function.

    function SetReadOnly(fieldName, isReadOnly) {
          Xrm.Page.getControl(fieldName).setDisabled(isReadOnly);
    }


    Jon Gregory Rothlander


    Monday, January 5, 2015 10:02 PM

Answers

All replies

  • Hello,

    I'm not pretty sure regarding your if (debug)... code. Could you please comment lines where you use it , publish the code and check again?


    Dynamics CRM MVP/ Technical Evangelist at SlickData LLC
    My blog

    Monday, January 5, 2015 10:49 PM
    Moderator
  • Andrii,

    I'm not sure what you are asking, so I just removed the debug code, as it serves no purpose here other than showing that the alerts are not displayed except when in debug mode. 

    Debug is used as a Boolean.  When it is set to true, all of the debug statements are executed, when false, none are executed. It allows for a application level setting to turn off/on all debug alerts in the code.

    Are you just suggesting that the debug code might be causing my problem?  That is possible, so I will remove it and check again.

    Best regards,


    Jon Gregory Rothlander


    Tuesday, January 6, 2015 2:46 PM
  • Hi Jon,
    maybe the user that have the issues is using IE8?
    Because you are using indexOf in your code, and IE8 sometimes generate errors with indexOf

    My blog: www.crmanswers.net - Rockstar 365 Profile

    • Marked as answer by jonrothlander Wednesday, January 7, 2015 7:12 PM
    Tuesday, January 6, 2015 2:55 PM
  • I did a search for that online and yeah, there's a lot of issues around that with IE8.  Thanks for the suggestion. 

    But hopefully no one is still using IE8!  But it is certainly possible. 


    Jon Gregory Rothlander

    Tuesday, January 6, 2015 4:45 PM
  • Well, before I was able to test anything this morning, my testing team said the issue is now gone! Maybe they realized they were testing it from IE8 and they just don't want to admit it!

    Thanks for your suggestions! at least if it shows up again, I will be better prepared to deal with it.


    Jon Gregory Rothlander

    Tuesday, January 6, 2015 6:17 PM