Monday, August 26, 2013

MIXED_DML_OPERATION: An inconsistent message


FATAL_ERROR|System.DmlException: Insert failed. First exception on row 0; first error: MIXED_DML_OPERATION, DML operation on setup object is not permitted after you have updated a non-setup object (or vice versa): User, original object: Account: []

This is an error on the surface not hard to understand, as numerous blog posts have explained; it means you can't run DML against regular SObjects in the same transaction that also runs DML against setup object (User, Group, Territory, etc.).  The fix for it is kinda odd, but workable: separate the two kinds of DMLs by system.runas(), which provides separate execution context so they don't collide.  If this workaround doesn't bother you enough, there are two other oddities related to the issue that would probably prompt you to say "there's something wrong with this picture":
  • I've yet to see an official documentation of the error - cause, background, and remedy - anywhere.  Not even from someone who's from Salesforce posting on a community place.
  • For test code, the error only shows when it's executed from the UI (Setup page or Developer Console).  It's not a problem if the test is run via IDE (or even during deploy I suspect).
 It's one of those lingering pesky things that bother developers.  I'll keep bugging people from the inside when I get a chance, and call for a celebration when it's fixed.

UPDATE:  Here are the two official links regarding the message: the origin of the error and specifically, how you handle it in a test context.

Tuesday, August 20, 2013

New permission dependency: Create and Manage Communities


I recently saw this error message when trying to edit a custom administrator profile.  Looks like the new Community related privilege is now required when you grant other advanced permissions.  I'm not entirely sure that makes sense - from a user's point of view anyway.  It may very well be the case that since Community is now a fundamental part of the framework, any other major change to the data model also alters Community properties, but this requirement is nonetheless a hassle to understand and manage for administrators.

Fortunately it may not impact too many orgs, as few would have the need to set up and grant custom admin rights, but I'm still a bit disappointed that SFDC didn't engineer it to be more friendly to an enterprise environment.

Thursday, August 1, 2013

Salesforce names: what's not to use

To developers what matters are the API names because they're referenced in code, have strict rules on the composition, and harder to change.  That's why API names often automatically created for you when things are set up via the UI, and you have limited choices in what you can put in the API names.  However there are things in Salesforce.com that don't really have the distinction between names (labels) and API names - they're one and the same.  For instance, workflow rules, layout, and profiles don't really have a separate API name.  Since they're plain names, Salesforce doesn't really restrict what characters you can use for them like API names.  That is fine most of the time, but could get you in trouble when migrating changes using SFMT, the ANT based tool.

The problem is with how ANT retrieve entities.  For things that will occupy its own file, such as profiles, their names become the files name.  If you use some character in entity name that's not compatible with file names (such as /), ANT won't complain but simply URL encode the character, so / becomes %2F.  This breaks the match between file names and your package.xml, which renders the whole thing undeployable.  For some reason ANT also does this to characters like period, which isn't even incompatible with file names.

So the advice is to stay safe with just letters, numbers, and underscore, so you know you can script deployment without worries.