For the purpose of row level security I have an additional user table related to the SFSUsers table with several fields, one of them is a generated where statement. I use this where statement to perform custom fill-methods for forms and reports to control which domain of data the user have access to. This works ok.

Now – some of my users would like to do search/selection via a SF browsedialog, which they know from another application done with SF without this form for row level security. 

The problem is , that the browsedialog as I understand it talks directly to the table, and therefore I cannot use the where statement for the logged in user to do the search.

I thought about having two BO’s of the same type on the form, one to populate from the browsedialog and then in the BrowseDialogClosed event do some check before copying the data to the other BO which databinds to the controls.

Does any of you guys have any ideas on how to do this or maybe a better way over all to accomplish this?

Thanks.

Teddy

It sounds like you are going to want to handle the Searching event of the browsedialog.  The raw WHERE elements are given to you before the search is executed and you can add to, manipulate, etc. the browse.  So you could insert your secrity logic here to prevent any rows that are not allowed from coming back.  I have done this before and it works well.

Also, any field level security that you have associated with a BO will still be respected.  So if they are not allowed to see the social security number, for example, it will still show the replacement characters, etc.

I did read about the searching event in the documentation. And yes this might be the place to do it. But isn't it right that you have to do this for each field in your query that exist in the where clause?

Or is it possible to add a sql where clause as string to the wherestatementscollection?

The organization model that the where clause is generated from is six levels deep, and the different combinations of all levels makes it a little difficult to maintain. It would be nice to add the already generated sql where clause.

Well, I guess it depends on what you are trying to do here.  I made a change the other day to this event which allows you to add an inline query altogether (I will post that build later this week).  I had the need to do an LEFT JOIN but instead, added the ability to insert and inline query.  Now this doesn't have anything to do with the WHERE, but this collection is what ultimately provides access to the query taking place in regards to manipulating the search.

You mentioned row level security, but in order to have a row level secure, you have to identify the individual field elements that will secure that row....unless I am missing what you are getting at.

I have yet to find a scenario in which I could not secure a browse dialog query based on security credentials.  That is why I am slightly confused.

So I think the ability to add an inline query will be perfect for me. Then I can control the BD the same way as the fill-methods for the forms/reports.

This way is much better, because the user are not provided with data in the BD results that they don't have access to on the maintenance form.

Thanks.

/Teddy