http://msdn2.microsoft.com/en-us/netframework/aa904594.aspx
-Larry
Thanks for info! While the current solution is pretty much what I expected, the future addition of the IQueriable interface gives us all something to look forward to
The way we have implemented the row-level security is exactly like you mentioned. We added a column to the necessary tables and stored an enumeration value within the field that tells the program which security key to check to determine whether the document can be viewed by the logged in user.
This is sort of a combination of ‘how to’ and a possible enhancement request. I have situation where I have client case files and some of those cases need to be marked as confidential. I’d like to be able to use Role Based Security at the row level to control who can view, add, modify, or delete confidential cases. Conceptually I can see how to do this by adding a column to the table that contains a security key. Where the possible enhancement request comes in it that it would be nice to be able to define in the object properties a security column similar to the concurrency column and have the data layer filter out rows that the user is not permitted to access. One of the reasons for the enhancement is that even if I implement my own security checking using the added column and security classes I can’t think of how I would enforce it in the BrowseDialog, unless you guys add some hooks or I build my own dialog. This probably raises other issues that I haven’t thought about but I’d like some input on how you might handle this. I’m thinking that you may have run into a similar requirement in your medical applications.