The Domain Management interface, built on top of the PRMS application, allows privileged users to create and manage their own categorization and assignment entries.
Top priorities in the design of the interface have been:
The form PRMS:DomainAdministration can be used as entry point to the Domain Management application. It shows the following buttons:
The domain in which the user has administrator privileges is shown. In case that the user can administer more than one domain, the domain will have to be selected in each particular form.
The form PRMS:DomainParametersView is a display-only form that shows the settings for the domain. That is, whether the categorisation tree for the domain includes the version level, and whether there is third level support. This properties cannot be changed by the Domain Administrator, and are managed by Remedy Support.
If the user is Administrator for just one domain, the properties for this domain are automatically shown, otherwise the domain has to be selected first from a list.
If the user have privileges to administer only one domain, it will be automatically selected when the form is opened. (Warning: Sometimes the domain is not automatically selected, but it doesn't matter; the field will be filled in with the correct domain name when the query is made or the entry saved.)
If the user can manage more than one domain, one of the available domains should be selected before submitting or searching.
A group has to be created before members can be added, or it can be used in any assignment in the Categories and Assignments form. To create a group, the form is opened in the New mode, and the name of the group is set (and optionally the GSM address).
The name of a group and the GSM address can be changed after creation, and the change is automatically propagated to all the tickets in PRMS assigned to that group, except those that are closed. The GSM address is entered without the final .gsm.cern.ch, which is automatically appended by the application.
Once the group has been created (by pressing the Save button), the window is automatically reopened in 'Modify' mode, allowing to set the members in the group.
Members can be added and removed from groups selecting the user to be added/removed from the tables and pressing the add or remove button. The changes are not applied until the entry is saved. A user cannot be removed from a group while it has cases assigned to him. Users listed in the Not in group table are those belonging to the domain. Creation of accounts and assignment of users to domains is managed by Remedy Support.
The status of groups is always active, unless we want to removed them from the system. If status is set to To Delete, the group is deleted by an escalation running hourly. Groups marked To Delete can no longer be modified. A group cannot be deleted if it is used in any assignment or appears in any non-closed ticket in PRMS:ProblemMgmt.
All modifications are logged in the History diary field, and the field Comments can be used to write notes regarding the group.
Apart from the Members page, which shows people in the group and allows adding and removing users from the group, the are two other pages in the form showing information related to the group. The Assignments page shows which assignments are made to this group in the PRMS:CategoriesAndAssignments form. Double-clicking a row in this table, the CategoriesAndAssignments entry is open. The Tickets page shows non-closed tickets in PRMS:ProblemMgmt assigned to this group, which can be open by double-clicking. This provides a fast way to reassign tickets before removing a user or group, for example.
If the user has privileges to administer only one domain, it's automatically selected. Otherwise the domain has to be selected from the menu (domain selection must be the first action performed for the menus to work properly).
The categorization forms a tree with three levels (Category / Type / Item), and a fourth level available in some domains (Version). [ categorisation tree currently active in PRMS:ProblemMgmt]
Entries in PRMS:CategoriesAndAssignments are of one of the types of object: Category, Type, or Item; assignments can be made at any level, and the one made at the lower level prevails (i.e., if a category is assigned to some group, this assignments applies to types and items under that category, unless an explicit assignment is made).
To create a given object, the higher nodes should exist already. That is, to create the categorization CAT/TYPE/ITEM, first of all the category object CAT has to be created. After that, a new object of type type is created. The category field is filled in selecting CAT in the menu, and the type field is written TYPE. The last object (of type item) is then created, category CAT and type TYPE are set using the menus and item ITEM is written directly in the field.
In the case of domains using versions, the list of versions for a given item is given in the entry corresponding to this item (assignments are not possible at the Version level). At least one version must exist, if no version is given when the item is created, the Default version is automatically added.
To avoid inconsistencies, a valid second level assignment should be present for every Category. For Types and Items, the assignment can be inherited from the level above (and shown in a display-only field) or can be set to any group defined in the domain.
For backwards compatibility with one domain, second level assignments can be made to individuals instead of groups, but assigning to groups is preferred.
Third level assignment (if available for the domain) is optional, so possible values for the assignment type field are none/inherited and group. In the first case, the assignment is inherited if it has been defined in a higher level, and it is shown in a display-only field.
The list of external analysts is optional as well, and the same rule applies for inheritance applies as for the third level assignment, if none/inherited is set it will be inherited if it has be defined at any higher level, or empty otherwise.
The status of each node of the tree can be active, inactive, or to delete. A node can be active only if all the nodes above are active as well. When a Category or Type is made inactive, all sub-tree below this node is made inactive automatically. If, on the other hand, the status of a Category or Type is changed from inactive to active the user is asked if the change should be propagated to every node below in the tree. When an Item object is activated, the parents (Category and Type) are automatically activated if necessary.
Only active Items are available in PRMS:ProblemMgmt, but the status of Category and Type objects has no effect from the point of view of PRMS users. The status can be changed to inactive only if there are no non-closed tickets in that category, type, or item.
Entries cannot be renamed, only the version list can be changed (when applicable). If an entry is marked to delete, it cannot be recuperated and is automatically deleted later by an escalation. Only inactive branches can be deleted, and only if there are no tickets belonging to that categorisation.
There are two other tabs apart from Assignments. Family Tree shows the ancestors and descendants of the object in the categorisation tree, and the corresponding entries can be opened double-clicking in the rows. Tickets lists the non-closed tickets that are categorised under this category, type, or item.
As SLA and Categorization are closely related, it has been chosen to reuse the PRMS:CategoriesAndAssignments form as the entry point for the SLA.
Service Level Agreements apply to domains. The Domain Manager will select the Domain then one type of object: Category, Type, or Item. The list of SLA escalations will show the existing SLA escalations for this given tree (at least 1 SLA entry per Priority [Low, Medium, High, Urgent] for the selected domain). The Domain Manager will click on the button NEW to create a new SLA entry. This will open a new form called PRMS:DomainSLA in NEW mode.
No SLA entry can be created for a given combination CAT/TYPE/ITEM if this combination does not exist yet.
SLA entries can be searched by selecting a combination of CAT/TYPE/ITEM then scrolling the SLA Escalations list or by opening directly the PRMS:DomainSLA form in SEARCH mode.
In order to set SLA entries, the Domain Manager will fill up at least all mandatory fields of the PRMS:DomainSLA new ticket. For details please refer to the SLA Design Document.
SLA entries are always set for a given categorization within a Domain and for a given Priority. It is the one with the lowest granularity that will be used to raise alarms (see algorithm below).
For each SLA entry, two types of Timers have been defined to enforce the SLA: Absolute Timers (never reset) and Relative State Timers (reset on change of domain). Three levels of alarms can be set, Escalation Level 1 being mandatory. Notifications are sent once per level of escalation [Reminder, Escalation Level 1, Escalation Level 2] for each Timer when the time spent has exceeded the value set for this Timer. When a Assignee is absent, notifications will be sent to the Assignee-Group instead.
For details about Timers and Alarms please refer to the SLA User Requirements Document.
