function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
stcforcestcforce 

regarding access to objects

i have some code that is running in a class that observes sharing but have observed that the code is sucessfully returning entries from emailtemplates, brandtemplates, users, profiles, folders while testing as a non-sysadmin user. My issue is, i don't know quite what to expect with these object - I don't know where they fit into the scheme of things. Can anyone direct me to a explanation of what objects or individual records a user can access when talking about objects on which the object permissions and the sharing model don't describe what is available (as seems to be the case) ?

thank you.

Best Answer chosen by Admin (Salesforce Developers) 
sfdcfoxsfdcfox

Sharing on metadata is similar to any other sharing. EmailTemplate objects are stored in a Folder object, which has permissions on which users/roles/groups can access them. Generally speaking, the "with sharing" keywords provide all the security you need. If an update throws an exception because of a sharing violation, you can safely assume they don't have access, for example. All users with View Setup & Configuration can view Profile records, even though they can't modify them. An attempt to rename a profile as a non-administrator, for example, should yield an insufficient privileges exception. View Setup & Configuration allows broad access to most of the setup/metadata tables, but won't allow modification of those values. To completely restrict access to all those tables, disable View Setup & Configuration. Generally, if a user can "use" a particular feature in the UI, they can also query these values through the API. Hopefully that clears up your confusion.

All Answers

sfdcfoxsfdcfox

Sharing on metadata is similar to any other sharing. EmailTemplate objects are stored in a Folder object, which has permissions on which users/roles/groups can access them. Generally speaking, the "with sharing" keywords provide all the security you need. If an update throws an exception because of a sharing violation, you can safely assume they don't have access, for example. All users with View Setup & Configuration can view Profile records, even though they can't modify them. An attempt to rename a profile as a non-administrator, for example, should yield an insufficient privileges exception. View Setup & Configuration allows broad access to most of the setup/metadata tables, but won't allow modification of those values. To completely restrict access to all those tables, disable View Setup & Configuration. Generally, if a user can "use" a particular feature in the UI, they can also query these values through the API. Hopefully that clears up your confusion.

This was selected as the best answer
stcforcestcforce

Thank you for your response. So users with that permission can see query all records on objects like user, profile etc (from a with sharing context)?

sfdcfoxsfdcfox

That's correct. They will only be able to view those records, but not update or create them (see such permissions as Manage Users and Modify All Data).