New answers tagged

3

TBH, considering that new security features are on the way but not quite GA yet, maybe your best bet is just to write your own central helper classes that will handle CRUD/FLS to exactly the extent that is needed to pass review. Later when the new tools go GA, you can then probably reduce the complexity of the helper classes by refactoring them to use the ...


5

The best option today I think is to largely avoid CRUD & FLS and enforce security via custom permissions aligned with your business processes but that is not really answering your question. Part of the difficulty here is first understanding where to perform CRUD & FLS checks. For me the best answer to that is on service entry since it allows callers ...


3

The approach we took was to provide a special class, e.g. SecurityUtils, with a bunch of static methods on it that take the DescribeSObjectResult(s) or DescribeFieldResult(s) to be checked, e.g.: // Returns true if the user has access to all the specified fields public static Boolean canAccessFields(DescribeFieldResult[] fields) or // Throws an exception ...


6

There are a few different ways to attack this problem, but the most common is to create a user with permissions, and then use System.runAs to execute your tests. I normally grant permissions to my packages via permset and not profiles, so I create a user, give it a permission set that I created, and then run the tests. That way I don't depend on the admin ...


Top 50 recent answers are included