We're in the process of upgrading/improving our application framework, and we're currently looking into (application) user groups and roles. We want to implement CRUD rights to our screens. What's in place is a kind of ORM, so there's a class for each table already. Am just looking for ideas on how to get this built as generic as possible.
A general, generic system would have you define a table to store your groups, a table to store what permissions that group has and a table to assign users to groups.
I would then translate that into C# and assign roles to your screens.
The other option is to be more database driven and record the permissions for each screen as a table. Personally, if you're doing simple CRUD permissions I would use interfaces and mark your screens.
ie. MyScreen : IRequiresWrite, IRequiresRead
Otherwise if you need to make it more complicated;
MyScreen : IRequiresPermissions
And then load the permissions required from the DB
You would need to write your own middleware for the permissions authentication. I'm not sure of anything out of the box.
You would need to write your own middleware for the permissions authentication.
No problem, they want control anyway.
I would use interfaces and mark your screens
All screens would need all four (CRUD), it depends on the role a user's in whether he's allowed. So how would you map a role to a screen. Using database is fine. Are you thinking about storing the screen class name mapped against one or more roles?
Suppose a screen shows a master detail relation. Would it make sense to connect a screen's right to rights on the underlying tables? Company and contact relation for example: I define that the screen uses both classes (tables). Using such a setup I can extrapolate that logic to buttons for example. A button can be visible for the aforementioned screen, but it's action may need rights to something else entirely (create an invoice for that contact for example).
If you interfaced it out, you could easily check the permissions of screens below the parent. Alternatively you could go action based and link your roles to actions rather than screens. This would probably require more maintenance but give you more flexibility.
Action based sounds like a good start, so if anybody knows of some interesting samples please let me know.
In addition, we probably want to define visibility of specific properties, for example to hide financial information. Not sure yet if we'll define that in the database, or categorize them by using attributes. Any samples on this appreciated too.