Showing posts with label AJAX. Show all posts
Showing posts with label AJAX. Show all posts

Wednesday, November 11, 2015

Salesforce AJAX Toolkit update call fails *silently* with field access issue

Some simple button code with Salesforce Ajax Toolkit (connection.js) to send a lead to queue (and related assignment logic in Apex):
{!REQUIRESCRIPT("/soap/ajax/30.0/connection.js")}

var updateRecord = new Array();
var myquery = "SELECT Id, CompleteOwner__c FROM Lead WHERE Id = '{!Lead.Id}' limit 1";

var result = sforce.connection.query(myquery);
var records = result.getArray("records");

if (records[0] && (records[0].CompleteOwner__c === undefined || records[0].CompleteOwner__c === null)) {
    var update_lead = records[0];

        update_lead.OwnerId = "{!$Setup.CompleteQId__c.Id__c}"; /* To complete Q */

        showProgress();
        var callback = {onSuccess: updated, onFailure: failed}
        updateRecord.push(update_lead);
        sforce.connection.update(updateRecord, callback);
...
...
The trouble is, the update call returned successfully, but update didn't happen at all - I couldn't even capture the API call with a debug log.

It turns out the trouble is the CompleteOwner__c field.  If that's taken out, the code works fine.  The user has no write permission to the field, but, the code isn't updating it either.  Apparently merely having that field member in the record data structure prevents the update from taking place, without any failure message.  Changing the highlighted part to this, which uses an new object for update without that field member, fixed the problem.
var update_lead = new sforce.SObject("Lead"); //can't use query result for update update_lead.id = "{!Lead.Id}";

update_lead.OwnerId = "{!$Setup.CompleteQId__c.Id__c}"; /* To complete Q */
 The frustrating part is the silent failure.  Why not just fail the call when there's a non-writeable (by permission) field? 


Wednesday, February 2, 2011

Client side vs. server side on Visualforce

What I needed to do was to disable a drop down box based on the selection in another drop down. Fairly common requirement. The controller drop down starts as disabled, so I set disabled property in , and used JavaScript from onchange to toggle disabled in HTML DOM from the controlling drop down. All sounded fine and dandy and the UI worked as it should, until I realized that the form never returned anything from the controlled drop down no matter what its status was.

It looks like the client side JavaScript did nothing to enable the controlled element. As far as the server was concerned, it's a field it can discard. I didn't do any HTML/JS debugging to confirm that, but it certainly felt that way. Once I switched the controlling mechanism to server-side processing/AJAX, it started to work as intended.

The only drawback with the AJAX way was that it's a bit slower. Action from the client-side Javascript was instant. With AJAX and its server round trip, it took about one second for the controlled drop down to change status.