Table Permissions¶
Table permissions allow users to view, edit or delete data into the tables directly (without using a process).
You can set the following table permissions for each app role you have defined in your app:
create
delete
view
edit
Permissions on all fields, all rows¶
true
grants permissions on any field, any row. false
does exactly the opposite of course.
# myTable.yml
permissions:
recruiter:
create: true
delete: true
view: true
edit: true
Permissions on specific fields¶
For the create
, view
and edit
options you can grant permissions to specific fields. For example:
# myTable.yml
permissions:
interviewer:
view: [firstName, lastName, email, resume] # will be able to view only these fields
edit: [interviewerComments, score] # will be able to edit only these fields
# won't be able to create or delete
You can use the "*"
wildcard to include all fields, and "!"
to exclude a specific field. For example:
# myTable.yml
permissions:
recruiter:
create: ["*", "!salary"] # when creating an entry, it will be able to set every field except salary
view: ["*"] # will be able to view all fields. It's the same as "view: true"
# won't be able to edit or delete
Permissions on specific rows¶
For the view
, edit
and delete
options, you can limit which rows can be modified, by using the following filters:
own
: Allows to view/edit/delete rows that have been created by the user. (Directly or through a process).assigned
: Allows to view/edit/delete rows that are connected to a task that is assigned to the user. After the task is completed or reassigned, the user won’t be able to modify the row data anymore.any
: Allows to view/edit/delete any rows.
Note
You can combine the own
and assigned
filters, but not the any
filter.
You can also combine these filters with the permissions on specific fields, that were described before.
For example:
permissions:
recruiter:
view:
any: true # can view all fields in all rows. It's the same as view: true
delete:
own: true # can delete rows created by themselves
assigned: true # can delete rows of processes currently assigned to them
edit:
any: ['*', '!address'] # can edit all fields, except address, on any row
interviewer:
view:
assigned: ["*", "!salary"] # can view all the fields, except salary, for the rows that are assigned to them
Important
You don’t need to grant create
or edit
permissions when you want the user to modify fields through a process.
This is because the process is the one that will be modifying the data, not the user.
Anyways, you might want to give them access to view
fields that the user needs in the forms for completing their tasks. If they don’t have permissions to view those fields, those fields will appear empty.
If you want them to view only the data of tasks assigned to them (not all the data), make sure to use the assigned
option.
Guest User Permissions¶
Guest users are not able to create, view, edit or delete any data by default.
If you have processes with tasks that will be assigned to guest users, you might want to grant them access to view the specific data they need to complete the tasks they’re assigned.
Important
It’s important to keep permissions for guest users as limited as possible. We recommend to only give them view access to specific fields, filtering with the assigned
property.
For example, in the following code, a guest user will only be able to view officeName
and phoneNumber
of the data connected to a task assigned to the user.
permissions:
guest:
view:
assigned: [officeName, phoneNumber]
Warning
As stated before, if you need a user to modify data through a process, you don’t need to give them create
or edit
permissions. If you grant create
, edit
or delete
permissions to the guest
role, any guest user will be able to modify the data directly through the GraphQL Endpoints.