Auto number fields – you had better get them right in version 1.0

Here is another item to add to the list of painful restrictions in managed packages:

For the sake of Google search matches the error message text is: “Error: Auto number fields cannot be added to a custom object when the custom object has already been uploaded in a Managed – Released package”.

“Don’t rebase dates” option in “Export to DOT file”

When exporting a copy of your Trialforce master org that contains a configured version of your managed released package, there is a “Don’t rebase dates” option. Salesforce support provided this explanation:

• If you check the “Don’t Rebase Dates” checkbox, it means don’t rebase the dates. In that case, you preserve the record date in the DOT’ted org. For E.g.:, if the record date in source org is 11/24/10, the record date in DOT’ted org is 11/24/10.
• If you uncheck the “Don’t Rebase Dates” checkbox, it means rebase the dates. In that case, the record date in the DOT’ted org = signup date of the DOT’ted org + (created date of the record in source org – signup date of the source org).

Security Review Costs Now $300 not $5000

The $5000 pricing was pretty discouraging especially if you wanted to create multiple small applications, so this Review fees now only $300? is indeed good news.

AppExchange Security Review – CRUD Security and FLS (Field Level Security)

I will soon be submitting an application into the Force.com AppExchange Security Review process. In preparation I took a look at articles like Testing CRUD and FLS Enforcement and so realized that I needed to add some extra code to my custom UI code.

The first thing I looked at was this apparently salesforce sponsored project OWASP ESAPI implementation for Force.com. Useful to look at but I got no response to emails or issues so be warned.

In the end I added the minimum code I could think of which blocks the custom UI if any object or field level permissions are turned off as at present I do not have requirements for fine grained control. Given that some of the custom UI manipulates multiple objects at once to accomplish the required business logic, this sails close to the describe call governor limit. So don’t manipulate more than 10 types in a piece of code because you won’t be able to implement the (apparently) required security…

The biggest issue I ran into was in the testing of this code. The unit tests need to check that users running under profiles that allow access are not blocked and that users running under profiles that don’t allow access are blocked. But the bad news is that there appears to be some insidious caching that gets in the way. See my response-less post How to test CRUD Security and FLS despite implicit describe caching?. And its not that the describe caching just spans multiple test methods in a test class but it appears to span all the test classes in a test run too. So right now the “don’t allow access” tests are turned off. Not good.