Privileges Required to use Processes
To use processes, you need one of the following:
scheduler-administrator
orredwood-administrator
rolescheduler-job-administrator
role- object, system or partition-level permissions
Viewing Processes
To successfully view processes, you must have one of the following privileges:
- View Processes.
- Submit And View.
- Edit.
- Edit Processes.
- Delete.
note
The partition of the Job is inherited from the queue where the Job runs, not from the Process Definition!
Submitting and Restarting Processes
To successfully submit a Job, you must have one of the following privileges:
- Submit - privilege rank on the Process Definition of the Job, or on Process Definition in its partition or system-wide
- All - privilege rank on the Job of the Job, or on Process Definition in its partition or system-wide
As well as the following privileges
- View Processes - privilege rank on the queue where the Job is supposed to run, or on Queue in the queue's partition or on Queue system-wide
- View - privilege rank on the process server that serves the queue and where the Job is going to run as well as its partition, or on Process Server in the process server's partition or on Process Server system-wide
- View - privilege rank on the partitions of the process server, queue, and Process Definition where the Job has run and is going to run
Optionally, if you want to use a library, submit frame and/or time window, you will need View privileges on them and their partitions, as well. If the Job has a default submit frame, a default time window, or uses a library (in parameters or in the code) you will require View privileges on the objects or you will not be able to submit the Job or restart it.
Child-objects of a Job such as a Job File, for example, inherit the security from it.
Processes can reference the following objects, you need at least View privileges on these objects and their partition(s) when you want to submit a Job that references them:
Processes can reference the following objects, you need at least View privileges on these objects when you want to submit a Job that references them:
- Credential.
- Credential Protocol.
- Event.
- Library - if the Job uses code from the library.
- Lock.
Built-in Roles
- The
scheduler-administrator
orredwood-administrator
built-in role provides full access to Processes. - The
scheduler-viewer
built-in role provides read-only access to Processes.
Deleting Processes
All required privileges to see the Job as well as the following:
- Process Administrator (
JobAdministrator
) - privilege rank on Job in its partition or system-wide - Process Administrator (
JobAdministrator
) - privilege rank on the Queue, or on Queue in its partition or system-wide
Example
You have partitions named P1, P2, and P3; you want several users to be able to submit and monitor each other's processes. The process definitions are all located in the P1
partition, the process server P3_ProcessServer and queue P2_Queue are located in the P3 and P2 partitions, respectively, P3_ProcessServer serves P2_Queue. You do not want the users to see processes in any other partitions.
note
This example is an extreme case for illustration purposes; you would normally have the process server and the queue in the same partition.
You first create a group/role p_operators
for the users in your external authentication system and grant it to users. If you are running Net Weaver you also assign the action AccessScheduler on the role.
- Log in with a user who has the
p_operators
role so that it gets synchronized with Redwood Server. - Log in with a user that has scheduler-administrator privileges.
- Navigate to "Security > Partitions".
- Choose Edit Security from the context-menu of the P1 partition.
- Assign p_operators the Granted Rank View.
- Choose Save & Close.
- Choose Edit Security from the context-menu of the P2 partition.
- Assign p_operators the Granted Rank View.
- Choose Save & Close.
- Choose Edit Security from the context-menu of the P3 partition.
- Assign p_operators the Granted Rank View.
- Choose Save & Close.
- Navigate to "Security > Roles" and choose Edit from the context-menu of the role p_operators.
- On the Privileges tab, assign the privileges as the table indicates below.
- Choose Save & Close.
Object Definition | Level | Level Object | Exportable | Granted Rank | Grantable Rank |
---|---|---|---|---|---|
Job | Partition | P2 | View | None | |
Queue | Partition | P2 | JobAdministrator | None | |
Process Server | Partition | P3 | View | None | |
Process Definition | Partition | P1 | Submit | None |
note
Processes inherit their partition from the queue, so the privilege on Job must be in the same partition as the partition of the queue.
note
Operators will not be allowed to delete processes, if you want your operators to be able to delete processes, assign them the Process Administrator (JobAdministrator
) privilege in partition P2 on Job. The table above reads View only for Job in partition P2, however, processes can be restarted and resubmitted thanks to the JobAdministrator
privilege on the queue (which is required to submit processes).
note
You can also save the three object privilege grants on the partitions above by adding a system-wide View privilege rank for partitions. However, users will be able to see all partitions.
Owner
The process is owned by the user who submitted it. If the process has a recurrence, the process group will be owned by the initial submitter. When a user restarts or resubmits a process definition owned by another user, the owner changes to the user who restarted or resubmitted the process definition. You use the System_ChangeOwner process definition to switch owners of process definitions and process groups.
Best Practices
It is advised to use technical users to submit processes with a recurrence to avoid potential problems in the future due to changes in personnel. Ideally, technical users should not be allowed to log on to the Redwood Server. When normal users leave a team responsible for working with Redwood's product (or leave the company), their privileges are usually changed or revoked. If the user logs on to the Redwood Server after their privileges have changed, their accounts may potentially no longer be able to submit processes. The impact of the loss of privileges would be process groups with a recurrence owned by the user will no longer be able to be submitted since the user now has inadequate privileges. If a team member that owns processes with recurrences leaves the team, to prevent potential problems with recurrences, disable the user on to the Redwood Server. To do this navigate to Security>Users and choose Deactivating login for the user.
You use the System_ChangeOwner process definition to change owners.
See Also
- Privileges Required to use Event Definitions
- Privileges Required to use Credentials
- Privileges Required to use Credential Protocols
- Privileges Required to use Libraries
- Privileges Required to use Locks
- Privileges Required to use Process Servers
- Privileges Required to use Queues
- Privileges Required to use Resources
- Privileges Required to use Objects