In many of my previous implementations I have used advantage of Apex code running in System mode however never tried how far it can go in terms of capabilties. There is no specific Salesforce documentation which can explain that what is allowed or not allowed in System mode.
In this post, we will go through some scenario and will try to understand what really is possible in Apex System mode and when it can fail.
Before diving more lets discuss how many types of mode do we have in Apex ?
User Mode : As per this Salesforce post, all Profile level permissions, sharing rules and Field level security are enforced in Apex if it runs in User mode. Standard Controller and Anonymous Apex runs in User mode.
System Mode : Same post conforms that custom controller, trigger, Apex class, controller extension works in System mode. Means eventhough user does not have necessary profile level permission, record level permission or field level permission, but still they can perform any operation on it.
161 : Sometimes while deleting record it gives error “Object cannot be Deleted”. What is the reason for this kind of error ?
This is generic error message prompted by Salesforce many times, which is not well informative. To get informative message, we can try to delete same record in “Developer Console”. In Developer Console Debug log, we will get exact error message.
Example : Lets say there is one record which is parent of more than 2000 records and grand parent of 5000 records. In such scenario from developer console it gives error something like “record cannot be deleted because it has many associated objects” However in User Interface, it will just display that “Object cannot be deleted.“
162 : Why are Visualforce pages served from a different domain?
If we see carefully, all our Visualforce pages are served like “c.YOURSERVER.visual.force.com/apex/YOURPAGENAME” ,
And because of this most of time we run into Same-Origin Policy error in Javascripyt if we try to access parent page from Iframe. Following reason is explained by one of the evangelist of Salesforce:
“The move to separate domains has one very specific purpose: leverage the browser security model (same domain policy) to protect our customers and the salesforce.com service from cross site scripting and cross site request forgery attacks.
Moving to the serving pages from separate domains is a critical component of our ongoing commitment to insure the highest level of security and availability for everyone.
In the world where everything is served from the same domain any custom page that you visit had full access to any other page in your org and also any page served from salesforce.com itself. This included potentially malicious code that was installed as part of a force.com package.”