Row Security


Author
Message
Larry Caylor
Larry Caylor
StrataFrame VIP (1.8K reputation)StrataFrame VIP (1.8K reputation)StrataFrame VIP (1.8K reputation)StrataFrame VIP (1.8K reputation)StrataFrame VIP (1.8K reputation)StrataFrame VIP (1.8K reputation)StrataFrame VIP (1.8K reputation)StrataFrame VIP (1.8K reputation)StrataFrame VIP (1.8K reputation)
Group: Awaiting Activation
Posts: 592, Visits: 3.7K

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.

 

-Larry

 

 

Reply
StrataFrame Team
S
StrataFrame Developer (6.5K reputation)StrataFrame Developer (6.5K reputation)StrataFrame Developer (6.5K reputation)StrataFrame Developer (6.5K reputation)StrataFrame Developer (6.5K reputation)StrataFrame Developer (6.5K reputation)StrataFrame Developer (6.5K reputation)StrataFrame Developer (6.5K reputation)StrataFrame Developer (6.5K reputation)
Group: StrataFrame Developers
Posts: 3K, Visits: 2.5K
We have thought of ways to implement this functionality... easliy configurable and implementable row-level security, however, we have held off of it for right now because the although we would be able to use it within the BrowseDialog and other places where the SELECT statements are generated programmatically within the framework, you would still have to implement the same WHERE clause on each of your fill methods that calls FillDataTable.  So, since we don't have any control over what queries you run, we're holding off until the next major version of SF.  We will be implementing LINQ functionality, and with the IQueriable interface, we will be able to programmatically add conditions to the WHERE clauses of every query executed within the framework.  So, then it will be easy to implement with a few simple properties on the business objects, but right now, it's just not feasible.

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.

GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...





Similar Topics

Reading This Topic

Login

Explore
Messages
Mentions
Search