Permissions

This page explains how to manage permissions in Yesplan.

Tip

Discover the specific steps to establish permissions in the guide for setting permissions.

Attention

The general set-up of permissions that is described below doesn’t apply to reports (templates and generated documents) and dataviews. Discover the permission system for these elements in Sharing Reports and Sharing Dataviews.

Concepts§

Managing permissions in Yesplan is broken down into the various actions that a user can execute (their so-called capabilities) and managing which users have access to which events, resources, prices, contacts and tasks.

Below, we briefly explain a few basic concepts related to permissions in Yesplan.

User Capabilities§

It isn’t always advisable for a user to be allowed to execute every action or view all screens. In Yesplan, you can set who has the capability to perform various actions and to see certain screens and who does not.

You set this by means of capabilities. If a user has a certain capability, then they can execute the corresponding action.

Granting Permissions§

Every Yesplan element (events, resources, contacts etc.) has an owner. This owner is a Yesplan user. Initially, the owner of an element will be the user that created this element. You can also modify the owner of an element.

Every Yesplan user grants permissions to other users regarding what can happen to the elements that they own. These permissions determine who can read, write, delete, use… this element. In other words, the owner of a certain element decides what can happen to that element in Yesplan.

Remark

Suspended users retain ownership of elements, and they continue to grant permissions as a consequence. To prevent this from happening, you can transfer ownership to other users. See Suspending a User and Transferring Ownership and Deleting for more information.

Permission Templates§

A permission template is a set of capabilities and a description of the granted permissions.

You use these templates to describe the permissions of a certain group of users (such as ‘Administrators’) or a certain function within an organization (such as ‘Planner’).

You can award one or multiple permission templates to a user. If you award multiple templates to a user, then their capabilities will be the union of all capabilities in these templates, and the granted permissions (for elements owned by the user) will also be the union of permissions determined by these templates.

Managing Permissions§

Managing Permission Templates§

You can manage permission templates in “System Settings” > “Users” > “Permission Templates”. You can create, delete, duplicate and rename templates there.

If you click “Show Permissions”, a new screen will open where you can manage the capabilities and permissions for this template.

This screen consists of two parts:

At the top of the screen, there is a list of capabilities for the template.
At the bottom of the screen, you see the permissions that are granted by users that were assigned this template.

Tip

We strongly recommend using our guide to building permissions via templates. If you do so, a template will either define capabilities or grant permissions, but never both.

See the Permissions Guide for more information.

Managing Capabilities§

Options are managed in a separate window:

Click “Edit Capabilities…”.
These capabilities can be selected and deselected in the window that pops up.
Next, click “Apply” to save the changes.

Capabilities are divided into three groups:

The types of elements that a user can create and the actions that can be executed on certain elements.
The tabs of various inspectors and modules that are visible.
The statuses that a user can award to an event.

We will discuss the capabilities in detail below.

Creating Elements§

The left column shows the capabilities that a user receives to create elements or to execute certain actions. More specifically, you can set the following capabilities here:

Events: Creating events.
Resources: Creating resources.
Contacts: Creating contacts.
Tasks: Creating tasks.
Report templates: Creating report templates.
Prices: Creating price definitions for resources.
Mute Conflicts: The capability to hide conflicts in the event calendar and the Teamplanner.
Unlock Events: Capability to unlock events of type “Locked”.

Remark

You can mark certain statuses as “Locked” in Yesplan. As soon as an event has this status, its name, date or location can no longer change, to prevent accidental changes. Changes are only possible by clicking the padlock on the event. In order to open this padlock, the user must have the capability to “Unlock Events”.

Visibility of Tabs and Teamplanner§

The middle column shows a list of tabs classified per inspector. If you click “Open” next to the name of the inspector, then all the tabs of that inspector will appear.

For each tab, you can determine whether it’s visible for the user using the checkbox. If desired, you can change the visibility of all tabs of an inspector at once by clicking the checkbox next to the name of the inspector.

In this column, you can also determine whether the Teamplanner is visible in the navigation menu.

Attention

When you add new tabs to Yesplan, they aren’t visible for users by default. You must select these tabs in the capabilities of templates that are applicable to the users that must be able to view these tabs.

Using Statuses§

The right column shows a list of statuses that were created in Yesplan for events. If a status isn’t selected, a user won’t be able to award that status to an event.

Attention

The order of the statuses has a meaning. An event will often evolve from an option request to a fully scheduled and concluded event. You can determine the order of statuses via System Settings.

To move to the next status (a status that is lower in the list), a user must have the capability to use that status. However, to return to a previous status, the user must have the capability to use that previous status and to use all the intermediate statuses.

This functionality enables you to determine that a user can place an event in a later status (and possibly skip certain statuses) but he/she can’t switch a planned event back to an option, for instance.

Granting Permissions§

Under “Permissions for Template” you will find the permissions that are granted to other users (or user groups) according to that template.

The table with the permissions works according to the following logic:

Each row corresponds to a user or a user group to whom permissions are granted.
The columns of the table correspond to the elements for which permissions are granted.

Permissions are managed in a separate window:

Click “Edit Permissions…”.
These permissions can be selected and deselected in the window that pops up.
Next, click “Apply” to save the changes.

You can also change the structure of the table in this window:

Add users (or user groups) by clicking “Add User Group or User” below the table.
Do you want to edit who the permissions apply to in an existing row? Then double-click the name of the user or user group in the leftmost column of this row and select the desired value from the drop-down menu.
You can add additional columns for events to manage permissions by status. See Permissions per Status for more information.

Remark

The name of a user appears in red in the table when he or she is deleted from Yesplan. This indicates that permissions are granted to this user even though he or she is no longer in the system.
Managing permissions for locations, placeholders and reports isn’t done via a template, but per element (so per location, placeholder or report).

Determining Permissions§

Permissions are assigned on the basis of the owner of an element. For example:

We assign the template ‘Common A’ above to Jean.
Jean is the owner of the event ‘Hamlet’.
He grants permissions for this event to other users (or user groups). In the screenshot above, people from the administration will only be able to view and edit ‘Hamlet’, as only these permissions are selected.

The permissions you see in the table follow the logic below:

The owner is the user (or user group) to whom the template is assigned.
This owner grants permissions to themselves and/or other users or user groups.
These permissions are granted for elements (e.g. resources, events) of the owner.

In other words, the owner of a certain element decides what can happen to that element in Yesplan.

In the window in which you can change the permissions, you’ll find the actions you can perform on rows in the column on the far right:

Select all: Select all permissions in a row at once.
Deselect all: Deselect all permissions in a row at once.
Delete: Delete a row from the table.

Permissions per Status§

For events, you can manage permissions per status. To add specific permissions for a certain status, click “Add Status” in the header of the “Events” column.

If no specific permissions are determined for a status, then the general permissions for an event are applicable as defined in the “Events” column.

Determining Permissions§

You can set the following permissions:

View: The user (or user group) can see the element in question.
Edit: The user (or user group) can edit the element in question.
Delete: The user (or user group) can delete the element in question.
Edit Permissions: The user (or user group) can edit the permissions for the element in question.
Book: This only appears for resources. The user (or user group) can book resources.

Remark

In order to book a resource on an event, you must meet two conditions:
1. You must have the permission “Edit” for the event in question.
2. You must have the permission “Book” for the resource in question.
The permission “Book” also impacts the Teamplanner. If you may book a resource, then you may also:
- Create bookings, shifts and breaks for that resource in the Teamplanner.
- Edit and delete existing bookings, shifts and breaks for that resource.

You can choose how the permissions of resource bookings are determined. You can do this via “System Settings” > “System Preferences”, with the option “The permission to edit a resource booking is set using the”:

Separate “Edit booking” and “Delete booking” permissions on the resource booking:
- These permissions appear in templates (in the column for resources) and in the tab “Permissions” of the inspector for resource bookings. They determine whether the user (or user group) in question can edit or delete a resource booking.
- These permissions are granted by the owner of the booking.
- The permissions “Edit” and “Delete” in the “Prices” column determine whether a user (or user group) can edit or delete the prices of resources, including the prices of their bookings.
“Edit” permission on the event:
- If a user (or user group) has permission to edit an event, they can also edit the resource bookings on that event.
- To edit the prices of resource bookings, the user (or user group) also needs the “Edit” permission in the “Prices” column of the permissions.
- The permissions “Edit booking” and “Delete booking” no longer appear in Yesplan.

Remark

The first option allows you to define the permissions for resource bookings in detail, but you have less control over them. For example, a user may not be able to edit an event, but may be able to edit resource bookings and their prices on that event. Of course, this isn’t always desirable.
The second option is more straightforward: if a user can’t edit an event, he/she can’t edit the resource bookings on that event. This comes in handy when, for example, you’re closing an event financially: then you don’t want others to change anything, including bookings and their prices.

Permissions for Unavailabilities§

It’s possible to indicate that a resource or location is unavailable during certain periods via the event calendar, the Teamplanner or the resource inspector. Unavailabilities don’t have separate permissions in Yesplan, but they follow the permissions of that resource. In other words, if a user can book a certain resource, then this user can also mark the resource as unavailable and delete unavailabilities.

A user can mark a human resource as unavailable in the Teamplanner, for a certain day or period, if the user has permission to book the human resource.

A user can mark a location as unavailable in the event calendar for a certain day or period, if the user has permission to book in that location.

Granting Permissions to Different Users§

You can grant permissions to different users or user groups. We will run through the capabilities from most general to most specific:

Everyone Else: This row contains the permissions of all users for whom no other, more specific row has been defined. This row is always present and you can’t delete it.
Permissions for a certain user group: It is possible to grant permissions to a certain user group. These permissions are applicable to all users that are member of the user group. If you add a user to the group, this user will receive the same permissions. If you remove a user from the group, the permissions are no longer applicable to this user.
Permissions for a certain user: It’s possible to grant permissions to a specific user.

Granting Permissions Dynamically§

In addition to these explicit users or groups of users, Yesplan also supports dynamic permissions. These are useful because you don’t have to name or repeat all users or user groups within Yesplan on each of the templates. However, we recommend that you only use these options in cases where a complex implementation of permissions is necessary, since they make it harder for an administrator to discover precisely which permissions are applicable.

Owner: These permissions are applicable to the owner of an element.

This allows us to express that a certain user receives permissions for an element, as soon as this user becomes the owner of that element (the user who creates an element is, by default, the owner).

For example:
- In the ‘General’ template, we add a row for “Owner” in which the owner receives permission to view, edit and delete events. For “Everyone Else”, these permissions aren’t selected.
- Jean and Rhea were both assigned the ‘General’ template.
- Jean will be able to view, edit and delete all events that he owns, but not events that Rhea owns.
- Rhea will be able to view, edit and delete all events that she owns, but not events that Jean owns.
Primary group of owner: This allows you to distribute permissions to users who are members of the owner’s primary group. These permissions are inherited by child groups (below them), but not by parent groups (above them).

For example:
- In the ‘General’ template, we add a row for “Primary Group of Owner”, in which the owner receives the permission to view and edit events. For “Everyone Else”, these permissions aren’t selected.
- Jean’s primary group is ‘Planning Theater’, but he is not a member of the ‘Planning Dance’ user group.
- Rhea’s primary group is ‘Planning Dance’ and she’s also a member of the ‘Planning Theater’ user group.
- Thomas’ primary group is the parent ‘Planning’ group, which includes both ‘Planning Theater’ and ‘Planning Dance’.
- Jean, Rhea and Thomas were assigned the ‘General’ template.
- If Jean is the owner of an event, then Rhea can view and edit it, because she is a member of Jean’s primary group (Planning Theater). Thomas can’t view or edit that event, because the permissions aren’t inherited by the parent group (Planning).
- If Rhea is the owner of an event, then Jean can’t view or edit it, because he is not a member of Rhea’s primary group (Planning Dance). Thomas can’t view or edit this event either, because the permissions aren’t inherited by the parent group (Planning).
- If Thomas is the owner of an event, then both Jean and Rhea can view or edit that event, since permissions are inherited by the underlying groups (Planning Theater and Planning Dance).
Remark

If you edit the primary group of a user, this also influences the permissions.

Applying Multiple Rows§

Since a user can belong to multiple user groups, and since Yesplan supports dynamic permissions for the owner and the primary group, it’s possible that multiple rows within one permission template are applicable to a certain user. Yesplan will use the most specific permissions that are applicable when determining permissions for a user for a certain element.

The following rules are applied when doing so:

The most specific level is that of the user. This means that if there are permissions for the user, they will be applied, and the permissions for user groups and for “Everyone Else” will be ignored.

For example, as soon as you include a row with explicit permissions for a user in the template, this row is always applied. Moreover, if the user is also the owner of the element and you determined dynamic permissions for the owner, then the combination of these owner permissions and any explicit permissions for the user is applied.
If you didn’t include any explicit permissions for the user, and the owner permissions aren’t applicable, then Yesplan will look at the level of the user group. In this case, it’s the combination of permissions for each of the users’ user groups that’s applied. Moreover, if you also set permissions for the primary group and the user belongs to the primary group of the owner of this element, then these permissions will also be applied, in combination with the other user group-specific permissions that apply.
If permissions at the user level and at the user group level don’t apply, then the permissions for “Everyone Else” apply.

Awarding Permission Templates to Users§

You can award permission templates to users in “System Settings” > “Users” > “Users”. You can read how this works in the page about the system settings.

It’s possible to award multiple permission templates to a user. In that case, the union of capabilities and granted permissions of all awarded templates will be applied. In other words, as soon as one of the templates awards a certain capability or grants a permission, it will be applicable. When taking the union, the least strict permissions are granted.

Editing User Permissions§

There are other ways to manage permissions and capabilities, apart from allocating permission templates. You can adapt these for each user individually. To do so, go to “System Settings” > “Users” > “Users” and click the action “Show Permission Settings” in a user’s row.

Remark

In order not to complicate the management of permissions in Yesplan unnecessarily, we advise against using this option. Only use templates, this makes it easier to check where permissions are granted exactly. You will find simple step-by-step instructions for configuring permissions in the guide for configuring permissions.

After clicking “Show Permission Settings”, a screen will appear that is very similar to the one for managing permissions on a permission template:

At the top of this screen, you see the permission templates that are applied to the user.
The user’s capabilities and the permissions allocated to him or her can be seen just below the list of templates.
These capabilities and permissions are the result of merging the capabilities and permissions that the user was assigned via permission templates.

You can further edit capabilities and permissions at user level by clicking “Edit Capabilities…” and “Edit Permissions…”:

Changes that deviate from templates appear with an asterisk after the capability or the permissions that were granted and edited.
Deviations with regard to templates can be reversed by clicking “Reset”.

Viewing the Permissions that Were Granted to a User§

In Yesplan, permissions are based on the concept that a user grants permissions to other users either explicitly or via permission templates. To know which permissions were granted to a specific user—what the acquired permissions are—you can click “Show Permission Settings” in the far-right column in the list of users (found in “System Settings” > “Users” > “Users”).

At the bottom of the screen that opens, you see a list of permissions that were granted to that user.

Each record shows a specific permission and the columns show the various types of Yesplan elements. Each cell in this table contains a list of users that grant the corresponding permission for the corresponding element. For example, we see that Planner can view events owned by himself or by Administrator, and can only delete prices owned by Administrator.

Editing Element Permissions§

Element permissions can be edited through the “Permissions” tab on the inspector of that element. This is possible for events, resources, locations, contacts and tasks. These edited permissions will replace the permissions granted by the owner of the element.

Remark

Locations and placeholders aren’t granted permissions through a permission template: manage their permissions through the inspector.
You can share reports and dataviews with other users, and when sharing you determine what other users can do with the report (view, edit or delete). Discover the permission system for these elements in Sharing Reports and Sharing Dataviews.
An administrator always sees all elements, even if he/she doesn’t have permission to view them.

Permissions for an individual element are managed as follows:

At the top you see the element’s owner. You can change this owner by clicking “Change Owner”. This can be handy if the owner changes function or leaves the organization.
Below the owner, you see a table of various user groups and users who received permissions for this element. You can edit the permissions for the different users of this element using checkboxes.
This table will always contain a row “Me”. These are the permissions of the user who is signed in. To avoid inadvertent changes to this row, you must click the padlock before making changes.
You can add specific permissions for other user groups or users by clicking “Add User Group or User” below the table.
You can delete added rows again. It isn’t possible to delete existing rows with permissions for a certain user group or user, but you can change their permissions if you have permission to do so.

Permissions for Events and Event Groups§

Events and event groups have a central role in Yesplan. There are, however, a few things to bear in mind when managing their permissions through the inspector:

The permissions for events and event groups are managed for every element separately, since every event can have a different owner.
If you deselect a person’s permissions to “View” an event, that person will be able to see the event in the event calendar, but it will be shown with the name “[Undisclosed]”. The tabs for that event will appear empty for that user.
If you deselect a person’s permissions to “View” an event group, the group will be shown with the name “[Undisclosed]” for that user. In the inspector, the tabs will appear empty at the level the event group in question. However, events in that group will remain visible in the calendar, and all tabs in the inspector will be accessible for those events.

Attention

The inheritance of custom data is an important principle in event groups, but this doesn’t apply for the management of their permissions. If, for example, you change the permissions for an event group under the “Permissions” tab, the events in that group won’t adopt the changes automatically: in other words, you’ll have to change the permissions for every event separately.

Permissions for Locations and Placeholders§

Both locations and placeholders are special resources: permissions for locations and placeholders are determined per element, in the inspector.

Permissions for Locations§

Manage the permissions of locations in “System Settings” > “Resources” > “Locations”. You then open the location’s inspector by clicking “Inspect” in the “Edit” column. You can manage permissions in the “Permissions” tab of this inspector. Managing the permissions for a location is similar to managing element permissions, with the exception that a location has a user group as an owner rather than a user. This makes it easier to link locations to certain user groups.

Remark

You can also open the location inspector from the event calendar by clicking the name of the location (in the header of the column).

Permissions for Placeholders§

Placeholders don’t have an owner and can be read and booked by every user. Only administrators can create, edit and delete placeholders.

Permissions are applied to the prices of placeholders:

You can manage the permissions of placeholders in “System Settings” > “Resources” > “Groups & Roles”.
Open the placeholder inspector by clicking “Inspect” in the row of a certain role.
Go to the tab “Permissions for Prices” of this inspector to edit the permissions.

Remark

You can also open the placeholder inspector from an event inspector if it has a booking for that placeholder. Open the booking inspector for that placeholder first (by clicking its name), then open the placeholder inspector (by clicking the button at the bottom of the booking inspector).