This page last changed on Apr 20, 2010 by mmcgarry.
Available only in HQ Enterprise
Feedback is welcome. Click Add Comment at the bottom of the page.
Before You Start
If you are new to HQ Enterprise roles, see Understanding Roles in HQ Enterprise.
Create a New Role
The sections below provide instructions for creating and editing roles.
Step 1 - Define Role Permission Matrix
In this step you create a permissions matrix for the role.
Note: If you are creating a role purely for the purpose of role-based alert notification, skip to Step 2 - Assign Users to the Role.
 | Popup Help Click below to view helpful topics in a popup window side-by-side with these instructions. (The topics are also at the bottom of this page, in About Permission Levels.)
|
- Click New Role on the Administration page (or navigate to an existing role to edit).
- In the "Properties" section of the New Role page, enter:
- Name
- Description, if desired.
- In the Permissions section, select select a permission level - Full, Read-Write, Read-Only, or None for each type:
- Users
- Grant Full to enable role users to create and delete HQ user accounts.
- Grant Read-Write to enable role users to edit HQ users accounts.
- Roles
- If you select Full, which enables role users to create roles, HQ will ensure that the role's permission level to Users and Groups is at least Read-Only, because to create a role, you need to view users and groups.
- Groups
- Grant Full to enable role users to delete groups created by others.
- Grant Read-Write to enable role users to modify groups created by others.
- Note that regardless of the permission level you select, any user can create groups, and as the owner of such groups, delete them.
- Platforms
- If you select Full, which enables role users to delete platforms and their child resources, HQ will require that the role's permission level to Servers and Services is also Full.
- If you select Full or Read-Write, HQ will automatically checkmark the Can Fix/Ack Alerts? and Can Control? capabilities.
- If you select Read-Only, you have the option to grant alert management or resource control capabilities by clicking Can Fix/Ack Alerts? or Can Control? respectively.
- If you select None, you cannot grant alert management or resource control permissions.
- Servers
- If you select Full, which enables role users to delete servers and child services, HQ will require that the role's permission level to Platforms is at least Read-Write, and its permission level to Services is Full.
- If you select Full or Read-Write, HQ will automatically checkmark the Can Fix/Ack Alerts? and Can Control? capabilities.
- If you select Read-Only, you have the option to grant alert management or resource control capabilities by clicking Can Fix/Ack Alerts? or Can Control? respectively.
- If you select None, you cannot grant alert management or resource control permissions.
- Services
- If you select Full, HQ will require that the role's permission level to Servers is at least Read-Write.
- Grant at least Read-Only if you are going to grant the role Full permission to Applications.
- If you select Full or Read-Write, HQ will automatically checkmark the Can Fix/Ack Alerts? and Can Control? capabilities.
- If you select Read-Only, you have the option to grant alert management or resource control capabilities by clicking Can Fix/Ack Alerts? or Can Control? respectively.
- If you select None, you cannot grant alert management or resource control permissions.
- Applications
- Grant Full if you want role users to be able to create and delete applications.
- Grant Read-Write if you want role users to be able to modify change applications created by others.
- Escalations
- Grant Full if you want role users to be able to create and delete escalations groups
- Grant Read-Write if you want role users to be able to modify escalations.
- The role is saved, and the refreshed role page will have three new sections: "Assigned Users", "Assigned Groups", and "Alert Calendar".
- Proceed to Step 2 - Assign Users to the Role.
Step 2 - Assign Users to the Role
- Click Add to List in the "Assigned Users" section.
- On the "Users" panel on the left side of the *Assign Users to Role" page, checkmark each HQ user you wish to add to the role, and click the blue arrow to move the users to the "Assign To Role" panel.
- Click OK when you are done adding users to the role.
- If you are creating a role purely for the purpose of role-based alert notification, skip to Step 4 - Define Alert Calendar for Role. Otherwise proceed to Step 2 - Assign Groups to the Role.
Step 3 - Assign Groups to the Role
In this step, you assign resource groups to the role. A resource in a group assigned to the role will be available to role users, to the extent that the permission matrix enables. (For example, if the role's permission level to Platforms is None, role users will not have access to platforms in groups assigned to the role.
- Click Add to List in the "Assigned Groups" section.
- On the "Groups" panel on the left side of the *Assign Groups to Role" page, checkmark each resource group you wish to add to the role, and click the blue arrow to move the groups to the "Assign To Role" panel.
- Click OK when you are done adding groups to the role.
- Proceed to Step 4 - Define Alert Calendar, as desired.
Step 4 - Define Alert Calendar (for Follow-the-Sun Role-based Notifications)
An alert calendar defines the availability calendar during which role users are available for alert notfications. You should define an alert calendar if:
- You are creating a role that will be a recipient of alert notifications, and
- The users assigned to the role users are available only during specific intervals only.
By default, a role's alert calendar settings specify that role users are available for notifications 24 hours a day, 7 days a week, with no exceptions. To define a narrower availability calendar:
- For each day in the week,
- Use the first set of From and To pull-downs to specify a start time and an end time that role users are availability for notifications.
- If there is a period of time within the availability period specified in the previous step, during which role users should not receive notifications, click Except, and use the From and To pull-downs on the right to specify that period of time.
- Click Save after defining the alert calendar.
 | You must define additional role or roles with complementary alert calendars to ensure that there is a role whose users are available during periods of time that the current role's alert calendar does not include. |
Step 5: (Optionally) Customize Role-Specific Dashboard
When you create a role, HQ Enterprise creates a Dashboard with the same name as the role, which is HQ users that have been added to the role can select from the Select a Dashboard pull-down in the upper left corner of the HQ Dashboard.
As desired, you can add, remove, or reconfigure the portlets on the role dashboard to meet the needs of role users. For more information see Role Based Dashboards in HQ Enterprise.
About Permission Levels
The following sections summarize tips and facts about permission levels.
Permission Tips
 | Defining a Role's Permission Matrix For roles that:
- Add resources to inventory and create alert definitions - use Full or Read-Write permission levels. These permission levels enable a role to also process fired alerts and control resources.
- Monitor resources, respond to alerts and control resources - use the Read permission level, and then grant Fix/Ack and Control capability, or both. This allows operations staff to respond to alerts, see the details of alert definitions, and perform routine or as-needed resource control tasks but not create/modify/delete resources and alert definitions.
- Need visibility only - Use Read permission level for roles that view and monitor resources, but do not (1) create/modify/delete resources and alert definitions, or (2) response to alerts.
|
Permission Level Definitions
- None - No access at all to instances of the type.
- Read-Only - Allows role users to view instances of the type, but not create, edit, or delete them. For Platforms, Servers, Services, Groups, also enables:
- Read-Only access to alert definitions for the inventory type.
A role with Read-Only permission level does not have permissions to enable/disable/fix/ack alerts or control resources - these capabilities must be explicitly granted.
- Read-Write - Allows role users to view and edit instances of the type, but not create or delete them. For Platforms, Servers, Services, Groups, also gives:
- Read-Write access to alert definitions for the inventory type,
- Permission to manage alerts (enable/disable, fix, acknowledge) for the inventory type.
- Permission to perform supported control operations on resources of the inventory type.
- Full - Allows role users to create, edit, delete, and view instance of the type. For Platforms, Servers, Services, Groups, also gives:
- Full access to alert definitions for the inventory type.
- Permission to manage alerts (enable/disable, fix, acknowledge) for the inventory type.
- Permission to perform supported control operations on resources of the inventory type.
How HQ Validates Platform-Server-Service Permission Level Assignments
HQ Enterprise 4.3 does a bottom-up validation of the permission levels a role grants to Platforms, Servers, and Services.
A role with Full access (which enables resource deletion) to an inventory type must have at least Read-Only access to the parent type (if there is one) and Full to the child type (if there is one).
For example, Full access to Servers requires at least Read access to Platforms and Full access to Services.
|