Jun 27, 2015

How to Abort a Scheduled / Queued Apex Job by Name


For the advanced salesforce developers out there.... in the past (before Winter 14 release) there was no way to query for a Scheduled, Future, or Batch job by the name that was given to it. You had to track the ID of the job as the job was being created and store this into a custom object or setting for future reference.

Thanks to a feature from Winter 14 which stemmed from this idea, you can easily query the CronTrigger object filtered by the job name.  Remember to increase your API version in your class if this does not work.

Now we can query for the apex job by name and perform a system.abortjob with confidence that we have the correct job.

Here is a nice block of code that can be used in your application or something to keep handy for an Execute Anyonymous situation.



Jun 9, 2015

This change set requires the "##.#" or later platform version

Overview
It's that time of the year again (one of three times, actually), where you might be attempting to make some fixes in a sandbox that has already been upgraded to the next release and uploading a Change Set from that org to Production where the next release hasn't been applied yet.

Error
This change set requires the "##.#" or later platform version

Scenario
  • Sandbox 1: Summer '15
  • Production: Spring '15

Resolution
By chance, did you get to this point by following a normal deployment pattern? You know, where you deploy from a developer sandbox to a full sandbox and are now ready to deploy to Production? 

Chances are, the full sandbox you deployed to was also upgraded to the next release. You probably already know that upon upload, a Change Set's components are locked down. But did you also know that the API version of that Change Set is set and locked based on the target org's API?




This means that when you uploaded from your developer sandbox to the full sandbox, the Change Set was set to the latest API version and is now locked to it. When you attempt to upload this same Change Set to production, you get the "This change set requires..." error message.

Out of luck? Nope! Just "Clone" the Change Set and re-upload.



When you create a new Change Set by cloning, you're creating a new instance of the Change Set with all the original components and is unlocked so new components can be added.  At this point, the API number has yet to be set as well.

This time, don't upload to a sandbox first; upload it directly to Production so the Production org's API number is set on the Change Set and the upload is allowed.



Jun 8, 2015

User Level Visualforce UI Control w/ Custom Permissions

Overview

As you are developing a Visualforce interface for Salesforce.com users to interact with, you may find that certain form elements (panels, links/buttons, etc) may or should not apply to certain users.  Standard Salesforce user control can prevent users access to a specific page, objects, tabs, or other larger components without allowing much flexibility for the occasional granularity you need.

Sample Scenario

The objective below is to develop a page which offers four command buttons to perform four different actions (Purchase Media, Create Media, Borrow Media, and Rate Media) in a library environment.  In this library environment, there are three different groupings of users (listed in order of privilege); those will complete and full access, librarians, and borrowers.  Full access will be able to perform all actions, librarians can do all but purchase media, and borrows can only borrow and review media.

Approaches


  • User Object Custom Fields:  You could create boolean toggles/checkboxes or minimally a multi-select picklist to allow org Admins to designate access on a per user level.  Downsides are that you're creating a field(s) and it leaves room for admin error (what was it... librarians can purchase or not?).  There's also the cost of querying for these fields via SOQL against the context's execution.  The fields could be included in a package, but would require post-installation configuration (maybe a post-install script to default all).
  • Custom Settings:  You could also create a Custom Setting of the hierarchy type, but still room for admin error.  On the pro-side, Custom Settings are cached and easily accessible via system methods, so it won't count against your SOQL queries.  Can also be included in a package and require the same post-install configuration or defaulting through a post-install script.
  • Custom Permissions:  Depending on your usage, these may or may not count against your SOQL limits.  Management is much easier as you can group individual permissions into a larger Permission Set and then apply the Permission Set(s) to a user.  Now all an Admin has to do is remember which Permission Set to apply to user(s).  Like the other two, can also be included in a package.  They also have the unique benefit in that they can be used to provide custom permissions to users authenticating in Connected App.

Custom Permissions 


We'll be checking out Custom Permission creation, assignment, and usage in the samples below.  To do so, we'll build a Visualforce page with four buttons, one for each possible permission, as well as show two page block sections that show which permissions the current user has.  One page block section will use the $Permission global variable to make that determination straight from Visualforce without a controller (see "Global Variable Way" below) and the other page block section will use Apex to determine applied permissions (see "sObject/SOQL Way").

Here's the end result:


Before we get to the good stuff, let's see how to create the Custom Permissions and get them applied to a User first...

Creating Custom Permissions

  1. Navigate to Setup --> Build --> Develop --> Custom Permissions


  2. Click on the "New" button and provide the various details about your Custom Setting.  The thing to remember here is it's up to you to determine what this "permission" stands for - at the end of the day, it's just a name that stands for a single or multiple privileges/abilities for a user to do thing.  In this example, anything within our Custom App involving the borrowing of books should refer to this setting.



Assigning Custom Permissions to Permission Sets

  1. Navigate to Setup --> Administer --> Manage Users --> Permission Sets



  2. Click on the "New" button, provide the required details about your permission set, and then click on the "Save" button.



  3. Within the "Apps" section, click on the "Permission Sets" link



  4. Select the appropriate permissions and then click on the "Save" button



Assigning Permission Sets to Users

  1. Navigate to Setup --> Administer --> Manage Users --> Users


  2. Click on the name of a User


  3. Within the User's Related Lists, hover over "Permission Set Assignments" and click on the "Edit Assignments" button


  4. To apply a Permission Set and its related Custom Permissions, move the Permission Set from the "Available Permission Sets" column to the "Enabled Permissions Sets" column.


Using Customer Permissions

With the creation and assignment out of the way, let's look at how we can use them to control Visualforce UI elements based on their assignment.  

Global Variable Way

Directly from Visualforce, it's as easy as...

Here's an example from the full VF page:


sObject/SOQL Way

We need to access several objects.  First we'll need to query for all CustomPermissions.  Then we'll query for SetupEntityAccess records that apply to the current user based on PermissionSetAssignments - see snippet below.  In the full sample, I've set up a set<string> called LibraryPermissions that will contain the DeveloperNames of CustomPermissions applied to the current user.  I'll also create a method to return string.valueOf(LibraryPermissions) so the Visualforce page can just use CONTAINS(LibaryPermissionsStr, 'the permission I want to check').

Apex Snippet (full code at bottom)


VF Usage



Practical Usage

Showing the permissions is one thing, but using Custom Permissions in a practical way that helps you control UI elements is another.  Using either technique, we can show/hide buttons that apply to that user according to the Permission Sets applied.

Here's a quick snippet of  rendering commandButtons accordingly:


Recap

So there we go!  We've effectively modified a UI by leveraging the semi-new Custom Permissions and demonstrated how they can be created, applied to a User through the use of Permissions Sets.  While showing/hiding buttons isn't too glorious of an example, we'd love to hear how you use them in the comments or on Twitter @crmscience!