Permissions

Permission in term of Codejig application is a set of rights for a number of predefined permissible actions, such as create, update, delete, view and others. You may define a number of permissions and apply them for any entity types except primitive, embedded and transient. Permission can be applied to one or many data types (one to many relationship; only one permission applies to a particular data type). The first created permission is automatically applied as default. You can change the default permission on the Settings page. The default permission applies to data types that do not have a permission applied to them in an explicit way.

All permissions are enforced on server. Once server-side code (as specified by developer during compilation) got permission to run, it has unrestricted access to all the data and it raises no further "chained" permission checks.

Permission mechanism allows for fine-grained tuning of security policy in your app. For example, it is possible to have some pages available only to authenticated users and some for everyone or anonymous users only.

Note: Permissions are checked on the type level and not on the field level. For example, we can easily define the policy that will allow only users belonging to groups "Employees" or "Managers" to view (read, fetch data) instances of data type "Sales order" and allow only "Managers" to update those instances. It will work just fine. However, there is no permission-based mechanism that would reliably prohibit users belonging to "Employees" from accessing the data stored in the field "Sales order.Comment" and provide such an access only to "Managers". It is certainly possible to use a UI based workaround by hiding Comment field depending on user role or by using two different web page for employees and managers. However, while this would work in low-risk scenarios it can not be guaranteed that data from "Sales order.Comment" can not be accessed by forging URL and fetching it with "employee" credentials or by using API with corresponding credentials. If the security were a real concern, it would be necessary to define the data type "Sales order 1" without "Comment" field and let employees access it while removing access to original "Sales order". "Sales order 1" might have all the fields marked as transient and data could still be read from and stored to original "Sales order" on server by using explicitly defined server-side "Load" and "Save" actions in "Sales order 1". "Load" and "Save" could implement corresponding logic to check if a particular field should be copied or not between "Sales order" and "Sales order 1" depending on user role.

Permissions can be managed on the Permissions page available through the left sidebar menu in Builder.