The permission model is built on the fact that access should be given to each user for a particular object. This should ensure that noone is given access to something "by accident".
Permissions are objects tied to a process that gives access to other objects. A permission object (like most objects) has a list of categories. The categories list ties the users in this category to this permission. A permission contains a list of access levels (Access level and category combinations), a defaut level, and a list that determines in which category new objects are created.
Among the available permissions for user, the least restrictive will be chosen for the object. That is if two or more permissions gives the users different access to a object, write is prefered over read, etc.
A permission object not having any categories will be applied to all users in the process. For the simplest possible set up of the permissions, one permission object is created with no categories and only a default level of "Write". This permission will be available to all users and will ensure write access to every object in the system.
Using the permission model
In the webapp the permission model is used together with the currently logged in user. An object can be checked for read and write permission (for the current user) with readCheck/writeCheck. For example when the user is about to edit a case, it is tested if the logged in user has write permission for the edit form. If not, a view form will be returned:
"Check if the user has access to write in the form."
(form writeCheck) ifNil: [^self getViewer].