FilterByRole attribute is one of my little accomplishments. I apply it in real projects about two years. I am sure that it is able to solve this problem.
In this case, that's what I suggest. There are tables Clients,
Projects and ClientTypes. Projects table must have a foreign key columns
clientId and clientTypeId. To the tables
Clients and ClientTypes you must apply FilterByRole attribute. For example [FilterByRole("clnt", "clientId")] and
[FilterByRole("clntType", "clientTypeId")]. Add this roles to a specific client.
A small note. Since the FilterByRole attribute deletes the ALL item, you must supply an additional parameter - withAll.
Thus, the Projects table will have two filters: Client (with All), and
ClientType (without All). As a result, if the Client filter will be selected All, you can see all Projects of your clientType. Otherwise - only your own projects.
valZ
Member
128 Points
40 Posts
Re: Row level security
May 05, 2012 06:43 PM|LINK
Hi, BigA, Hi, Sjnaughton.
FilterByRole attribute is one of my little accomplishments. I apply it in real projects about two years. I am sure that it is able to solve this problem.
In this case, that's what I suggest. There are tables Clients, Projects and ClientTypes. Projects table must have a foreign key columns clientId and clientTypeId. To the tables Clients and ClientTypes you must apply FilterByRole attribute. For example [FilterByRole("clnt", "clientId")] and [FilterByRole("clntType", "clientTypeId")]. Add this roles to a specific client.
A small note. Since the FilterByRole attribute deletes the ALL item, you must supply an additional parameter - withAll.
Thus, the Projects table will have two filters: Client (with All), and ClientType (without All). As a result, if the Client filter will be selected All, you can see all Projects of your clientType. Otherwise - only your own projects.
Regards.