Scheduler permissions are applied to a specific role, to delimit the tasks the users with that role can perform over data sources, jobs and the server configuration. Once a user is authenticated and his/her roles retrieved, Denodo Scheduler checks his/her permissions to decide whether he/she has the right privileges to perform an operation or not. When a user has several roles assigned, it can perform all the operations allowed by any of its roles.
By default, there exists a role with administration privileges called “scheduler_admin”. The Scheduler local user and every Virtual DataPort administrator user have this role assigned. It is a special role that cannot be deleted nor its permissions modified, and it has global administration permissions assigned to it, so users with this role can perform all operations in the server (see below).
Permissions can be applied globally to the server or specifically to a project or a job.
Scheduler supports the following types of global permissions, which affect the whole server:
Admin: users with this permission can perform any operation in the whole server. It affects to projects, jobs, data sources, permissions management, server configuration, import/export, uploading extensions, etc.
Create: users with this permission can create jobs in every project.
Write: users with this permission can update and delete jobs in every project (and their reports).
Execute: users with this permission can view and execute jobs in every project (and see their reports).
Read: users with this permission can view jobs in every project (and see their reports). They cannot execute them.
Scheduler also supports individual permissions to specific projects. These permissions can be applied to a specific project, and affect only to the elements contained in that project:
Admin: users with this permission can perform any operation in the project, such as creating, updating and deleting jobs and data sources, and changing the project name.
Create: users with this permission can create jobs in the scope of the project.
Write: users with this permission can update and delete every job in the project (and their reports).
Execute: users with this permission can view and execute every job in the project (and see their reports).
Read: users with this permission can view every job in the project (and see their reports). They cannot execute them.
Finally, Scheduler also supports individual permissions to specific jobs. These permissions can be applied to a specific job inside a project, and affect only to that job:
Write: users with this permission can update and delete that job (and its reports).
Execute: users with this permission can see and execute that job (and see its reports).
Read: users with this permission can see that job (and see its reports), but they cannot execute it.
Global permissions have preference over Project ones, and these over Job ones. It means that if, for instance, a role has been assigned a global privilege of Read, then it will have a privilege of Read for every project and, transitively, for every job.
Despite a user does not have privileges for creating, updating and deleting data sources (i.e. he/she does not have global or project Admin permissions), he/she can always see their configuration and use them when working with jobs.
The precedence of permissions is as follows:
Admin privilege implies Create, Write, Execute and Read ones.
Create privilege implies Write, Execute and Read ones.
Write privilege implies Execute and Read ones.
Execute privilege implies Read one.
When accessing the “Permissions” area, the Administration tool connects to the Virtual DataPort server to obtain the list of roles which currently exists in the server, and to the Scheduler server to obtain the permissions assigned to the roles. A table with the roles and the global permissions assigned to them is shown (Roles and global permissions screen). The appropriate check box can be used to give Admin, Create, Execute, Read or Write global permissions.
Note that two kinds of roles can be displayed in the table:
Roles which currently exist in Virtual DataPort. The description given by the Virtual DataPort administrator from the administration tool is shown for each of them. They can have permissions assigned in Scheduler (in previous sessions) or not.
Roles that have permissions assigned in Scheduler but they do not exist in Virtual DataPort anymore (they have been deleted). They are easily identified because their description is “Role not included in VDP”. In this case, you can also delete this role and its assigned permissions in Scheduler, as you can see for the role sched_user in the Roles and global permissions screen.
When accessing the permissions management section, if there is no connection with the Virtual DataPort server, the table will only show the roles already stored in Scheduler (i.e. those that have been retrieved from Virtual DataPort in previous sessions). In this case, the description of all these roles will be “VDP is offline. Description not available” but the user will be allowed to manage the permissions assigned to them.
Due to the precedence of the permissions explained previously, if for example, Admin permission is checked, then Create, Write, Execute and Read permissions are automatically checked and they cannot be unchecked.
As explained previously in this section, there exists a predefined role with administration privileges called “scheduler_admin” that is not editable (i.e. its permissions cannot be changed).
A vertical ellipsis appears in last column when hovering a role row of the table which contains a link Edit project permissions, which allows to access to the configuration of the permissions over each specific project. When one of these links is followed, a new table is shown listing all the projects and the permissions assigned over each one, to the corresponding role. The appropriate check boxes can be used to give the role permissions Admin, Create, Execute, Read or Write over each project. For instance, the figure Project permissions screen shows project permissions for the scheduler_user role.
Remember that Global permissions have preference over Project ones. It means that if, for instance, Read global permission has been assigned to a role, then it will have Read permission over every project and it will not be possible to clear the check boxes corresponding to that permission.
A vertical ellipsis appears in last column when hovering a role row of the table which contains a link Edit job permissions in each row, which allows to access to the configuration of the permissions over each specific job. When one of these links is followed, a new table is shown listing all the jobs of the corresponding project and the permissions assigned over each one to the corresponding role (as shown in Job permissions screen). The appropriate check boxes can be used to give the role permissions Execute, Read or Write over each job.
Remember that Project permissions have preference over Job ones. It means that if, for instance, Read permission over a project has been assigned to a role, then it will have Read permission over every project job and it will not be possible to clear the check boxes corresponding to that permission.
Denodo Scheduler lets you manage the extensions added to Scheduler via the “Plugins” and “Drivers” configuration areas. In the following sections, these configuration areas are described in detail.
Deleting extensions can cause parts of Scheduler that depend on them to cease functioning (for example, a JDBC data source that uses an adapter that has just been deleted).
The maximum allowed size for a file is 100 MB.
The sources of JDBC data defined using the JDBC data sources use drivers that need to be previously registered in Scheduler. In particular, Denodo Scheduler includes preinstalled drivers for some managers (see appendix JDBC Drivers).
It is possible to add drivers for new relational managers by specifying the following mandatory information:
Database adapter. The adapter name will be used, together with the version, to identify the adapter in Scheduler.
Database Version. Version of the database that the adapter applies to.
Class name. The JDBC adapter’s Java class.
Connection URI template. The sample connection URI for the manager to use the adapter.
JAR file to upload. JAR file containing the JDBC adapter classes. You can select several files if the classpath to connect to the data source needs them.
Once a new driver has been added, it can be deleted. However, it is not possible to delete drivers included in the product distribution.
Denodo Scheduler allows the user to create their own exporters or handlers for those functionalities not supported by the server or that are specific to a particular project.
The administration tool shows a table with the extensions registered in
Scheduler. For each extension it shows its name, the name of the
implementation class, its type (
handler), the name of the JAR file that it contains, and a link to
delete the extension from the system.
To create a new extension, certain Java interfaces need to be implemented (according to the extension type), a configuration file created, and everything packed together in a JAR file (see section Extensions (Plugins)).
To register a new extension in Scheduler, the JAR that contains it needs
to be selected to upload it to the server. Scheduler analyzes the JAR
and, based on the metadata contained in the file
detects the type of extension and the implementation class.
There are two ways of releasing space from the metadata database of Scheduler:
Delete all reports. Releases space by recreating the entire reports table in the database. All the reports will be deleted.
Compact reports. Releases space by compressing the reports table in the database. This option is longer than the previous one, but it does not need to delete the reports. The more fragmented the table is, the more space it will release.
This option is only available when using Derby as database.