Admin User Management

User management can be accessed by Admin users from the primary navigation sidebar. The current user may view their rights and/or change their password by using the user name drop-down in the top right corner of the screen.

All users may see their current rights. In addition, if native authentication is used, all users may change their password. Admin users may also view and manage users when native authentication is used.

Viewing Rights & Changing Your Password

Selecting My User from the user name dropdown in the top right of the screen will bring you to the page which lists your user rights. If native authentication is used, you may also change your password from this page.

Listing Users

Admin users may view current users, add users, and update settings and passwords of existing users.

Exporting Results

The current contents of the table can be exported to Excel, CSV or XML by clicking on export icon displayed at the far right of the table header. The download will automatically begin and will include all pages of the current table of results.

Changing or Adding Users

Clicking the (+) button in the table header will bring you to the New User screen. Clicking a user in the table will allow you to edit or view a user. For security reasons, you must always enter your current user password to make user changes.

Note: The question mark icon that appears next to the form title indicates inline help. Click on the icon to see help related to the current page.

When saving changes, you may receive error notifications. In this case, no changes were saved and you may correct your user setup and resubmit.

Note: When editing existing users, you may change their password by entering the new password and confirmation. If you leave both blank, the password will remain unchanged.

Deleting Users

You can also delete users from the edit page. For security reasons, you must always enter your current user password before deleting a user. You will be prompted to confirm the delete action.

Note: Deleting users can make tracking down who made changes more difficult. Consider making a user inactive instead.

User Rights

Rights are broken out into these categories: Default (read), Write, Admin, API Access, Author and Operator. In addition, as starting with Obsidian 2.0, Default read access can be limited using the Limited Read Access setting.

• Default rights allow you read access to most parts of the application, with the exception of user lists and the Scheduler Settings screen.

• Write rights allow you perform most operations, with the exception of viewing and changing users, and the Scheduler Settings screen.

• Admin rights allow you access to view and change Scheduler Settings, pause/resume scheduler hosts and manage users.

• API Access grants the user the ability to use the full REST API. In addition, this role grants the Default read access to the admin application.

• Limited Read Access prevents the user from seeing potentially sensitive job configuration parameters. If you wish to hide these values from a user, grant them this right, otherwise leave it unselected. Note that if a user has Write or API Access, this setting has no effect.

• Author rights allow you to create and modify jobs, job chains and conflicts. As of Obsidian 5.0.0

• Operator rights allow a user to resubmit failed jobs, submit ad-hoc jobs, interrupt running jobs and pause/resume scheduling hosts. As of Obsidian 5.0.0

Job Folder Rights

Understand the job folder feature.

As of Obsidian 5.0.0, more granular rights can be assigned to users that are based on the root job folder specified on a job. Any job that doesn't have a job folder specified will require the standard rights listed in User Rights above. For example, if a job has the folder Maintenance or Maintenance/BackOffice, a user with the role Maintenance-Author has the Author permissions as noted below.

For rights that allow creation/modification of jobs, the job folder can only be set/changed by the user if it continues to respect the user's job folder authoring permissions. This also implies the job folder cannot be cleared by this user. For example, if a user has the roles Maintenance-Write and DevOps-Write, they can create a job that has a root folder Maintenance or DevOps, optionally with any subpath. The user cannot create a job with no job folder, nor can they change a job's folder to something other than a root of Maintenance or DevOps.

The 3 permissions supported by folder convention roles are similar, but not identical to the broader roles listed in User Rights above.

• Write access by root job folder allows a user to create/modify, submit for ad-hoc and resubmit failed jobs that have a matching root job folder.

• Author access by root job folder allows a user to create and modify jobs that have a matching root job folder.

• Operator access by root job folder allows a user to resubmit, interrupt and submit ad-hocs that have a matching root job folder.