Controlling Editability
Sometimes it is useful to disable editing of certain entities or fields. This is possible by specifying the editability using the 'Permissions' tab in the schema editor.
-
Locate the entity of field in the Entities tab of the schema editor.
-
Select the Permissions tab of the entity or field editor.
-
Specify the settings you need by checking/unchecking the checkboxes.
-
Click the 'Apply' button.
Entity permissions
Permissions for entities allow you to control:
-
Edit values allowed: whether any values in the entity can be edited. Deselecting this check box makes the entity and all its fields read-only.
-
Delete rows allowed: whether existing rows can be deleted from the entity. Deselecting this check box disables deletion of rows.
-
Insert rows allowed: whether new rows can be added to the entity. Deselecting this check box disables insertion of new rows.
Field permissions
Permissions for fields allows you to control:
-
Edit values allowed: whether any values for this field can be edited. Deselecting this check box makes just this field read-only.
The 'Edit values allowed' permission for an entity takes precedence over the same setting for any of its fields. If editing of values in the entity is disabled this setting for all the entity's fields will be disabled.
Interaction of permissions and security
Securing settings provide an alternative approach to controlling the editability of data in IJC. The security settings take precedence over the individual entity and field permissions, so that if the user only has read-only access to the schema they will not be albe to modify any data even if the permissions on the individual entity or field are set to allow this. e.g. the permissions only apply to users who have read-write access to the IJC schema.
Setting permissions is only permitted by a user who has the security role ROLE_EDIT_SCHEMA.
Security settings also allow provision of 'row level security' that can be used to filter the rows that each user can see. Please see the Row level security documentation for more details.
Future plans
We plan to extend the permisions to be role based in the future. This will allow you to define two groups of users (let's say ROLE_CHEMIST and ROLE_BIOLOGIST) and to give each group a different set of permissions.