Data-driven security
As stated before, Dime.Scheduler has a layered security mechanism, much of which can be managed by administrators. First, roles and user actions define what the user can do in Dime.Scheduler. This is also known as role-based access control (RBAC). Besides this, a second category can be identified: data-driven security. The data users can access depend on the results of a simple matching algorithm, which will be elaborated in this document.
Filter groups & filter values
Filter groups and values represent a mechanism to enforce data-driven security for the planner, tasks and resources. A filter value is a requirement or a restriction that can be set on the said entities, where a filter group is a mere logical grouping of filter values.
Here are some examples of filter groups and values:
- Region
- EMEA
- LATAM
- APAC
- Skill
- Servers and networks
- Basic PC knowledge
- Programming
- Department
- Administration
- Production
- Sales
When planning tasks in different geographical regions or across multiple companies, it may be possible that the customer assigns a dedicated planner for each region. Similarly, one could assign planners to certain types of tasks like room bookings, ship crews, product assembly, servicing, etc. Such scenarios make a very good case for filter values.
As mentioned earlier, filter values can be assigned to the following three entities:
- Users
- Tasks
- Resources
An assigned filter value to a task can be construed as an eligibility requirement for users and resources. This essentially means that the user needs to meet the requirements set on the task if he is allowed to plan it (or even see it for that matter). For resources, it is a matter of determining who is qualified to perform the task.
Dime.Scheduler will automatically perform the necessary calculations to enforce this data-driven authorization. In other words, the user will only see tasks and resources that he is allowed to plan. From this point, the user can plan his list of open tasks at will. However, there is still the issue of finding the right resource for the task that needs to be addressed. As explained in the resource filters section, Dime.Scheduler does not automatically enforce this but provides the tools to nudge the planner in the right direction.
An example will show the mechanism of this concept. Using the above filter groups and values, assume the following entity filter values:
| Type | Name | Regions | Skills | Departments |
|---|---|---|---|---|
| User | John Doe | EMEA | Basic PC knowledge, Programming | / |
| User | Jane Doe | LATAM | Basic PC knowledge | Sales |
| Resource | Hank Dover | LATAM | Basic PC knowledge, Servers and networks | / |
| Resource | Bill Jensen | EMEA, LATAM | Basic PC knowledge | / |
| Task | Install software | EMEA | Basic PC knowledge | Administration |
Suppose the time has come to plan the "Install software" task. There are two levels of data-driven security in play:
- Users must have authorization to plan the task and must be able to plan at least one resource. This behavior is out of reach for the user, which means there is nothing he can do.
- Next up is to let the planner decide which resource to assign to the task.
The user, and optionally the resource, need to meet the requirements set by the task. This check is done on filter group level. In this example, the task has requirements in three different filter groups:
- The task will be performed in the "EMEA" region
- The task requires a minimum knowledge (skill) of "Basic PC knowledge"
- The task will be done in the "administration" department
Looking at the users, it seems both John Doe and Jane Doe possess the required skill (Basic PC knowledge). However, Jane Doe can only schedule tasks for the "sales" department and the "LATAM" region, so she is out for this task. John Doe on the other hand passes the test with flying colors, even though he has no assigned department filter value. As will be explained in the management by exception principle section, a filter group can be ignored when a resource or user has no assigned filter values for that particular group. The result of this calculation will be that Jane Doe won't see the task in her open task list but John Doe will. The same exercise will be done for the resources. The user will only see the resources in the planning board that he is allowed to see, according to the filter value specifications of the user and the resources. John Doe will not see "Hank Dover" due to a different region (EMEA vs LATAM) whereas Jane Doe will see both resources.
It is up to the planner to decide how and when to plan the task, and to assign it to whom. Contrary to the connection between user filter values and task filter, the user can choose whether or not to comply with the requirements set on the task. It may be possible that the resource is not qualified for the task, so the onus is on the planner to create a realistic planning.
Categories and time markers
The data-driven security mechanism is not limited to filter values and filter groups. Categories and time markers indicate the status of an appointment, which can be useful to impose security rules on. One potential use case is to filter appointments with the category "Completed" to disallow users to modify the planning of something that's already been done.
Management by exception principle
The data-driven security algorithm of filter values, categories and time markers uses the management by exception principle. When no values are specified for a given filter group, then the user automatically has the permission to all values in that group. This makes it easier to maintain; when new values are added to a group, the user automatically has permission to these new values and no actions are necessary on managing these permissions. The same principle applies for categories and time markers.