Skip to main content

Permissions

Three layer of permissions were developed for the scope of Oort:

  • Administrator permissions, directly added at the role level
  • Object permissions, added at the Resource, Form, Application, Page or Step level
  • Records permissions, added at the parent Form level

These permissions are defining which CRUD actions an user can perform on any object.

Location​

Permissions are accessible in different places in the back-office depending on the layer.

Administrator permissions in the global role page
Administrator permissions in an application role page
Object permissions on a Form
Records permissions
The UI is not developed yet, but explanations are here.

Basic usage​

Permissions are used to restrict people from some parts of Oort. If an user want to access a specific object, we will first check the administrator permissions, then if it doesn’t allow give him the access, we will check the Object permissions.

For Records it will be slightly different, we will first check the administrator permissions but then record’s specific permissions stored in the parent Form will be used.

Administrator permissions​

The following permissions can be added to a global role and have its own effect:

  • can_see_forms (authorize logged user to see forms tab)
  • can_see_resources (authorize logged user to see resources tab)
  • can_see_applications (authorize logged user to see applications)
  • can_see_users (authorize logged user to see and manage users)
  • can_see_roles (authorize logged user to see and manage roles)
  • can_manage_applications (authorize logged user to manage all applications)
  • can_manage_forms (authorize logged user to manage all forms)
  • can_manage_resources (authorize logged user to manage all resources)
caution

For an application role, only two administrator permissions are available:

  • can_see_users
  • can_see_roles

It authorizes logged user to see and manage users or roles for the application only.

These permissions are linked to a role and not an user, so you should configure them in the Role page (at the global or application’s level).

Object permissions​

Five types of objects currently have self-permissions:

Users who can update any of these object can grant permissions on the object per role, these permissions can then control which roles can execute CRUD actions on the objects.

info

Permissions can change the display of an application depending on the roles because some of them cannot see a page and some others can.

Record permissions​

In order to define record permissions, we added a new criteria, the PositionAttributes. You can then use roles and position attributes in order to define rules for each CRUD action. At the moment this rules will be applied everywhere for the read and create action. But only in the grid widget for delete and update actions.