Define your permissions
In this section, we will illustrate some examples of how to set up your permissions
Last updated
Was this helpful?
In this section, we will illustrate some examples of how to set up your permissions
Last updated
Was this helpful?
An important aspect of developing a medical application, is making sure that your user has access to only the information which they are authorised to see. Until now we've assumed that everybody can see all information, but that is rarely the case in an actual application. As the application progresses, you're more likely to segment the users into different roles such as patients, doctors, administrators, ...
The Extra Horizon backend has a couple of mechanisms to enable these roles & restrict permissions to certain users, classes of users or groups of users. Depending on the specific use-case of your medical device, you'll most likely need a combination of these.
These permissions are called as such because they are not restricted to a specific instance of a resource like a specific document or a specific group. They apply to the whole 'environment' and are the most extensive set of permissions.
Examples: VIEW_TEMPLATES, DELETE_REPORTS, CREATE_PROFILES,...
These global permissions are assigned to users through a role, which is a container for a set of permissions. Once you've created a role with a set of permissions, you can assign that role to the users that need to perform them.
To get an overview of the current roles & possible permissions in your environment, open your Control Center at . There you'll see a list of global roles and their associated permissions. The admin
role typically has the most permissions associated with it. This part of the UI also allows you to create new roles and manage existing roles.
Note that it is also possible to add your own custom permissions to a role. The Extra Horizon backend ignores them, but you can leverage them within your own backend functions.
What is a group? Fundamentally, a group is just a 24 character hex string identifier such as 654cf5b4c14e6e67bd3a8bfd
. This identifier is used to link users together in a group. What this identifier references to, is entirely up to the developer. For example, this identifier can be the id
of a document in a MyGroups
schema. Or it is simply an identifier which is generated by a developer and stored somewhere else. Extra Horizon provides the means to conceptually link users together in a group, but gives developers the freedom to fill in themselves what this grouping means.
There are 2 ways that a user can be linked to a group: as a patient or as staff. You can interpret this as a classification within the group membership. The distinction between these two will be more important when talking about schema permissions but intuitively, staff membership is more permissive than patient membership. Patients have no permissions other than being member of the group and do not have the ability to get more permissions through group membership. Staff users on the other hand, can have more permissions assigned through a group role.
The group concept provides a means to link different users together in a group, either as a patient or as staff. In itself, this doesn't determine whether somebody has access to a certain document or not. But this concept is leveraged to its full potential in the next section on schema permissions.
Within a data schema, there are a two mechanisms which are important in deciding who has access to the documents of that schema
Access modes: setting that controls which class of users gets to do what operations.
Actions: transition actions can grant permissions to users by manipulating the userIds
& groupIds
fields of a document.
All schemas contain the following properties: createMode
, readMode
, updateMode
& deleteMode
. Each of these modes have different settings which specify who will be able to perform the respective operation on the documents of the schema.
Next to this, it's important to know that every document in the Extra Horizon data service has the following array properties: userIds
& groupIds
. As the name implies, userIds
is an array containing user ID's and groupIds
is an array containing group ID's. By default these arrays are empty and you can't manipulate them directly as you would with the data contained in them, but there are API & SDK calls to add & remove users/groups to & from these arrays.
Combined with the schema access modes, the contents of these arrays in a document unambiguously determine if a user has the permission to perform a create, read, update or delete operation.
Important to note here is that global permissions take precedence over everything.
Example: a user who has the VIEW_DOCUMENTS:my-schema
permission, will be able to read all documents of schema my-schema
, even if the readMode
of that schema is set to default
and his user ID is not present in userIds
and his group ID's aren't present in groupIds
.
Imagine the following problem: a patient member in a group creates a document. Unless the readMode
is set to allUsers
, nobody can see the document. But we don't want to set it to allUsers
because that means that everybody will be able to see the document. Likewise we don't want to give people global permissions either because that means they can see all documents. So how do we make this document available to the right people?
In the users UI at , you see the different roles which are assigned to users. After clicking on a user, you'll be able to change their role (provided you have the proper permission to do so).
For more information, see .
Group roles give staff members extra permissions compared to patient members. They consist of a set of permissions which will only apply to the group. This set of permissions is a specific subset of the global permissions. You can find the list . As you can see, they are mostly related to managing the group itself. While you can technically include other global permissions in your role role (or your own custom permissions), they will be ignored by the Extra Horizon backend.
For more information, see .
For an explanation of all modes, please see .
This is where actions come in handy. A particular set of these actions, described , are used to modify document access.