Skip navigation

Category Archives: javascript

Today I was creating some new Salesforce Permission Sets for objects with hundreds of fields, where the PermissionSet needed access to just about every field on the object. If you’ve ever been in this scenario, you know what this means — get ready to manually check hundreds of checkboxes!


Being a developer, any time you have to do something repetitive, you start going nuts — there’s got to be a way to do this faster! 

In this case, the solution seemed pretty straightforward: just use jQuery to go find all checkboxes, and check them! From Chrome, Firefox, or Safari, just do a right-click, select “Inspect Element”, and then enter this one easy line of code:


That line of code, again, is:


This should work great, but there’s just one problem — Salesforce standard pages don’t usually include jQuery!

This leaves us with two options. One, we can resort to native DOM manipulation methods. If you are very comfortable with native DOM methods, then this is the way to go. Here’s the code:

// document.querySelectorAll returns a NodeList,
// so in order to leverage the ECMAScript 5 "forEach" method of Arrays,
// we'll convert our NodeList to an Array using slice'input[type="checkbox"]')).forEach(function(e){e.setAttribute("checked","checked");});

For a comparison of the complexity of these two approaches, take a look at this Gist.

If the DOM works for you, you’re done! However, if you don’t think you can remember how to code this every time, and/or prefer jQuery, never fear — there’s a really easy way to inject jQuery into any page you may be visiting: the jQuerify Chrome Extension. To get it, just go to the Chrome Extensions library and search for “jQuerify”:


Once you’ve added this extension, you now get a handy little button at the top right corner of Chrome, that lets you, with one-click, embed jQuery into any page, including your Salesforce PermissionSet / Profile editor!


Now, you can confidently run the aforementioned line of jQuery code, and ALL Checkboxes will be automatically checked! Yahoo!


Whichever method you use, DOM Native or jQuery, all it takes to repeat this magic when you move to the next Object with hundreds of fields is to go back to the Developer Console, hit the Up Arrow key on your keyboard, and voila, you’ve got your last-run script. Hit return, and the magic repeats!

Use Firefox and Firebug instead of Chrome? There’s an identical plugin for Firebug, called Firequery.

To help foster an ongoing conversation among Salesforce ISV and OEM partners — aka developers of Salesforce AppExchange apps — I started this discussion on the Salesforce ISV Partners LinkedIn group, which I encourage fellow ISV’s/OEM’s to join:

Let’s pool our thoughts – best practices for Salesforce ISV/OEM app development

One of the best practices I brought up was the need to properly “protect” or “sandbox” your application’s references to external JavaScript libraries within complex “mash-up” pages that include JavaScript code written by various other ISV’s / OEM’s / consultants / developers, as well as underlying JavaScript code.

These days, more and more apps being developed on the Salesforce Platform rely heavily on external JavaScript libraries such as jQuery, jQuery UI, jQuery Mobile, ExtJS, Sencha Touch, KnockoutJS, AngularJS, Backbone, MustacheJS, Underscore, JSONSelect, etc. Leveraging these libraries is definitely a best practice — don’t reinvent the wheel! As jQuery quips, “write less — do more!” As a Salesforce consultant, I think, this is generally the goal 🙂

Problems emerge, though when multiple ISV’s include different versions of these JavaScript libraries as Global Variables within their Visualforce Pages or Visualforce Components — because whichever version is loaded last will, by default, overwrite the earlier version. This makes it very difficult to mash-up / integrate Visualforce Components or Pages from multiple ISV’s into a single page. When faced with this, a common developer response is to stop using the latest version of the external library and trying to make their code work against the earlier version of the library forcibly included in the page (perhaps by a managed Visualforce Component or embedded Visualforce Page).

Fortunately, there IS a better way to avoid this.

In a nutshell, the solution is: “protect” or “localize” your references to any external libraries, preferably in a JavaScript namespace corresponding to your managed package.

For instance, if your Salesforce application has the namespace “skuid”, you’re already going to probably have various JS Remoting functions available within the “skuid” JavaScript object that Salesforce automatically creates in pages with controllers with JS Remoting methods — and as an ISV, you are ensured of your managed app’s namespace being Salesforce-unique. So this namespace is just about the safest global variable you can use in the Salesforce world (anyone else who messes with it is being very, very naughty)

As a brief side-note, here’s how to ensure that your app’s “namespace global” has been defined before using it:

// Check that our Namespace Global has been defined as already,
// and if not, create it.
skuid || (window.skuid = {});

To protect your external library references, store a unique reference to these libraries within your namespace’s object, e.g. IMMEDIATELY after loading in an external library, such as MustacheJS,

// Load in Mustache -- will be stored as a global,
// thus accessible from window.Mustache
(function(){ /* MustacheJS 0.7.2 */ })()

// Store a protected reference to the MustacheJS library that WE loaded,
// so that we can safely refer to it later.
skuid.Mustache = window.Mustache;

Then, even if some other VF Component or Page loads in a different version of this library later on, you will still have access to the version you loaded (0.7.2)

// (other ISV's code)
window.Mustache = (function(){ /* MustacheJS 0.3.1 */ })()

// THIS code will run safely against 0.7.2!
skuid.Mustache.render('{{FirstName}} {{LastName}}',contactRecord);

// THIS code, however, would run against the latest version loaded in, e.g. 0.3.1,
// and thus FAILS, (since Mustache 0.3.1 has no render() method)

How to avoid having to use global references all the time

Some of you are probably thinking, “Great, now I have to prepend this global namespace all over the place!” Fortunately, with JavaScript, that’s not necessary. By wrapping your code in closures, you can safely keep using your familiar shorthand references to external libraries without worrying about version conflicts.

For instance, say that your application uses jQuery 1.8.2, but other Visualforce Components on the page are using jQuery as old as 1.3.2! (SO ancient… 🙂 What’s a developer to do?

Well, jQuery provides the helpful jQuery.noConflict() method, which allows you to easily obtain a safe reference to a version of jQuery immediately after you load it into your page. So, as an example, in YOUR code, you need to pull in jQuery 1.8.2:

<!-- load jQuery 1.8.3 -->
<script type="text/javascript" src="//"></script><script type="text/javascript">// <![CDATA[
// Get a safe reference to jQuery 1.8.3 var jQuery_1_8_3 = $.noConflict(true);
// ]]></script>

Then, to your horror, another Visualforce Component, that the customer you’re developing for has “got to have” in this same page (and which you don’t want to iframe…), has loaded in jQuery 1.3.2, but not bothered to namespace it!!! Therefore, both of the commonly-used jQuery globals (jQuery and $), now refer to jQuery 1.3.2!

Fortunately, FOR YOU, you’re safe! You got a protected reference to jQuery 1.8.3, and your code can carry on using $ without any issues, as long as you wrap it in a closure:


       // Add "edit-mode" styles to this table row

// Identify jQuery 1.8.3 as what we are referring to within this closure,
// so that we can carry on with $ as a shorthand reference to jQuery
// and be merry and happy like usual!

This one’s for you, coffee-shop hopping developers who go to make some changes to your code in Eclipse and — blocked! Login must use Security Token! Uggh. But I hate Security Tokens – sure, sure, it makes way more sense to use them. Definitely a best practice. But, well, sometimes I’m lazy. I confess – I very often just use Trusted IP Ranges.

So, for those of you out there that have been in my situation, and like me don’t like entering Security Tokens into your Eclipse, SOQLExplorer, Data Loader, etc., and prefer to just use Trusted IP Ranges and basic username/password, I’m guessing you find yourselves doing this over and over again:

  1. Show up at Coffee Shop you haven’t been to before – or at which you’ve never done any development on a particular project / org.
  2. Login to Eclipse.
  3. Try to save something.
  4. Fail – you’re at a non-trusted location and you’re not using the Security Token!
  5. Login to
  6. Go to your Personal Information.
  7. Copy the IP address from your most recent login.
  8. Go to Network Access, and add a Trusted IP Range, and paste in the IP Address from Step 7 into both Start and End IP Address. Click Save.
  9. Go back to Eclipse and resave.

Wish there was a way to do this faster?

There is – here’s a little convenience script for the uber-lazy, coffee-shop hopping, Security Token-hating developer – if there are any of you out there other than me, this if for you!

The Idea: a one-click link in a Home Page Component

My idea: create a Home Page Component for the Left Sidebar that, in one-click, adds a new Trusted IP Range corresponding to the current IP you’re at.

Problem 1: there’s no way to get your current IP address from just pure client-side JavaScript. Lots of server languages can give you this, but not client-side JavaScript.

Problem 2: how to quickly create a new Trusted IP Range? There’s no API access to the Trusted IP Range object (which is probably a good thing from a security perspective 🙂

Problem 1 Solution: Use JSONP + an External Site

To make this a reality, I took the advice of StackOverflow and leveraged JSONP, which allows you to send an AJAX request to an external website and have the result returned in JSON format to a pre-designated callback JavaScript function, which immediately gets called. The basic syntax of this is

Problem 2 Solution: URL Redirect with params passed in

One thing I love about the platform is that almost every action you might want to take, whether for modification of metadata or data, can be initiated by going to a specific URL. To create a new Account record, you go to “/001/e”. To view all users, you go to “/005”. And almost any field on a particular page can be pre-populated by passing a corresponding URL Parameter (although these are not always consistent). And so it is with Trusted IP Ranges – to create a new Trusted IP Range, head to “/05G/e”. And to pre-populate the Start and End IP Address, you simply have to pass in the right query string parameters: “IpStartAddress” and “IpEndAddress”.

All together now! The final product.

So here’s the final solution:

  1. Go to Setup > Home Page Components > Custom Components.
  2. Click New.
  3. Enter a name, e.g. “Add IP to Trusted Ranges”, and select “HTML Area” as the type. Click Next.
  4. For Position, select “Narrow (Left) Column”.
  5. Click the “Show HTML” checkbox on the far right, and enter the following code for the body, then click Save.

<script src=""></script><script type="application/javascript">  function addIPToTrustedRanges(){  jQuery.getJSON( "", function(data){ var ip =; window.location.href= "/05G/e?IpStartAddress="+ip+"&IpEndAddress="+ip; } ); } </script><a href="javascript:addIPToTrustedRanges();">Add Trusted IP (using Smart IP)</a>

6. Go to Home Page Layouts, and add this Home Page Component to your layout as a System Admin.

Now return to your home page, and voila! Here’s what you’ve got: a link that, when you click, it takes you to a prepopulated new Trusted IP Range – just click Save, and boom, get back to Eclipse and save your code!



How does it work?

Nothing crazy here, but I’ll step through the code anyhow:

  1. Load jQuery from the Google API’s CDN, so that we can use the handy getJSON() method.
  2. Define a global function called  addIPToTrustedRanges – this function performs an AJAX callout to the endpoint  “;, passing in the name of a callback function to execute with the JSON data that this endpoint returns. So Smart IP basically returns a little string of data that is a JSON-serialized JavaScript object, whose “host” property is your current IP Address (the real one, not some NAT-translated private IP). Then jQuery calls your callback function, which, in the getJSON() method, is defined as an anonymous function in the second parameter — and passes in  this JSON string as an argument to the function. This is all legal, within the confines of the JavaScript same-origin policy, because of JSONP.
  3. In our anonymous callback function, we do a URL redirect, passing in our current IP address as both the Start and End IP Address as parameters to the new Trusted IP Address page:
  4. Then we click Save, and we’re done!