Bob,
The Grant, Deny and Readonly aren't actually permissions, they are actions allowed for a permission. You create the permissions needed for you're app in the security maintenance form. An example might help to clarify this.
Lets say you have a table that stores employee information with fields such as name, address, phone and some more confidential information like SSN and salary. You need to control access to this information. Most users won't have access to this info at all. Of those who can see it, most only can see the non-confidential information. A few in HR have full access. Of the users who can access employee information, there are variations in how the can access (CRUD).
Lets see how we might handle this using RBS (for now I'm going to just assume that the app will be able to use this info to control access...more on that later). First pass is to simply create a key to provide access to employee data:
Employee: permission to access to employee information
With this, we can now assign a user the Employee permission, with the appropriate action:
Grant - full access to emloyee data.
ReadOnly - they can view employee data
Deny - they can't access the data at all.
This is a step in the right direction, but it doesn't handle the confidential information. To handle that, add another permission:
Employee: permission to access non-confidential information of an employee
EmployeeConfidential: permission to access confidential information of an employee
Now we'd have more options. Here is a partial list to get you thinking:
Employee EmployeeConfidential Access
-------- -------------------- --------------------------------------------
Deny Deny No access to employee data
Grant Deny Access to non-confidential data only
Grant Readonly Full access to non-confidential, read to confidential
Grant Grant Full access to all data
Getting closer. What about differential access based on CRUD? Just add permissions specific to the type of access required. I.e. rather than permission to the Employee data (or confidential employee data), the permission is now to
update the employee data, etc.
Employee: permission to view non-confidential employee data
EmployeeConfidential: permission to view confidential information of an employee
EmployeeUpdate: permission to edit employee data
EmployeeAdd: permission to add employee data
EmployeeDelete: permission to delete an employee record.
Now, a user can be assigned the correct combination of permissions to control access in a very fine tuned manner. Essentially, the Employee and EmployeeConfidential permissions control what they can view. The EmployeeUpdate, EmployeeAdd and EmployeeDelete keys control what they can do to the data.
Note that the names of the permission are completely under your control. I've named them this way so that they sort together and I can see all Employee permissions together in the security maintenance form. Also note that you can create folders to organize permission too.
Of course, it could be a real pain to manage this for the users, which is were roles come in. A role is a set of permissions with associated actions that can be assigned to a user. Thus, I might have a "manager" role that has the Readonly action for the Employee permission, and a "HR" role that has Employee and EmployeeConfidential with Grant actions, plus the update/add/delete permission with Grant action for employees.
To implement this, you need to setup the permission/roles and assign those to users. Then you need to setup your BO to have the appropriate permissions. In this case, we need to setup field level permission (to handle confidential info) and the security keys Bill was talking about. The field level permission are setup in the BO Mapper (rebuild it after setting them up). If you didn't have the need for field level security, there is a security key at the form level which can be used (or alternatively, you could have two form, on with and one without the confidential info). Again, see the help file for details.
Hopefully this helps you see how you can manage very, very complex security requirements with the RBS module. I've been very please with it. I'll be happy to attempt to help more if needed.
