Apex Code Development You need to sign in to do that
Don't have an account?
Jessica Landisman How to limit which fields can be viewed in search results based on user role
Using Apex code and Visual Force pages, I have been able to limit what fields on an account, contact, or opportunity that a user can see based on his role and the role of the owner of the record.
There is a loophole in that the users can create custom views, and then they can see the fields I am hiding from them on the Account,Contact, and Opportunity pages by including those fields in a custom view.
Is there a way to limit the fields displayed in a search result based on SF configuration, Apex code, or some combination of the two?
You can use Field Level Security (FLS) to determine which fields are read/writeable for specific users:
http://wiki.developerforce.com/index.php/Enforcing_CRUD_and_FLS
Visualforce will automatically enforce your FLS settings.
I do not think that FLS will solve my entire problem for the following reason.
I need a scalable solution that will allow me to configure the system based on user roles and possibly with custom code. My team cannot configure each field's security for each user. We could configure each field based on user role.
Is there a way to intercept the display of search results for a given field and only display the field based on business rules?
Jessica, FLS under Profiles is really the optimal solution - set up a profile corresponding to role and hide the fields. Alternatively, although I suspect it's a lot less efficient, you could write your search page and have your controller inspect the results using the sobject.describe calls and filter based on your business rules. I wrote an open source search and replace function that you could use as a springboard for the work: http://wp.me/p1Almn-P (the link to the google code project is in the body of the post).
FLS under Profiles is limiting because it does not allow those in the corresponding role to enter the data that they are not allowed to view for the contacts/accounts/opportunities/etc that they own. That means that others in a high role will have the right to read that data but also the responsibility to enter that data for those lower in the hierarchy.
For example, Joe is in the role/profile not allowed to see a contact address. Joe enters a contact but is not allowed to enter the contact's address because he does not have rights to view those fields under the FLS configuration. Therefore, Joe's boss will have to enter that information. That seems like an inappropriate delegation of responsibility that is created simply to prevent Joe from seeing the address of ac
I will look at your code posting. Thanks for your insights.