I have a table called "contracts" and different roles of user types which log into my system. A user of the role "admin" shall be able to edit MORE rows of the table than a user of the role "guest" can. A "guest" might only be able to edit 2 rows, while an "admin" will be able to edit ALL rows.
Can guests edit up to 2 rows at any given time, or can they modify 2 rows in total?
I suppose you should implement this restriction in the business rule anyway. Having the amount of edited contracts stored in a cookie or in a database, you easily can compare the value against the limited quantity.
I guess I kindoff put myself wrong. I want the "admin" role to be able to edit ALL Columns/Attributes of a selected row/data-set. The "guest" role shall only be able to edit SOME columns of the specific data-set/row in the table.
Any ideas?
How about roles in general? What is a good way to implement them?
I can think of handling this permission case with form model scenarios instead of pure role-based authentication.
Of course you still have to determine what a given user can do - so you you may want to assign admin, guest or additional roles to users as you might already have.
I’m grateful because your question is like an answer to one of my topics.
Once I questioned the usefulness of scenarios, now I can provide you a working example.
When editing contracts, set up your form model with different scenarios.
Let each scenario be responsible for one role (you may prepare the model in a more elegant way, so common fields are shared across scenarios, more information regarding this is in the official documentation).
Validation rules apply to fields you allow to be edited in each scenario, others are ignored (unless you specifically enable them via safeAttributes() method). In this way, guests cannot hack your site by modifying the HTTP request.
Of course you have to edit the views accordingly, so only legitimate fields appear in editing mode.