Admin ServiceManager Further Details Roles and Permissions
- Matthew Wren
The ServiceManager authorisation model is a CRUD model, which stands for Create, Read, Update and Delete, these being the operations a user might be given permission to perform on a given object. Each user can be assigned one or more roles according to the type of access he or she is expected to need. A default set of Roles is provided by ServicePower (see Database sp808_role_definition)
Each role has been defined with a list of properties
| A property is a text string of the following form: |
| FRU means all FRUs, Team means all Teams, Oper means all Operatives and SA means all ‘Standard Activities’ (aka Unavailability Periods). |
| To restrict access to a specific entity, the model uses formal parameters as follows: |
| Where FRU_ID, TEAM_ID, OPER_ID and SACAT_ID are parameter types. The second part of the formal parameter- the part following the ‘.’ ( F, T, Op, Cat in this case) - is the parameter name. This name can have any value up to 20 characters. The properties in these examples mean: the named FRU, the named Team, the named Operative and the named Standard Activity Category. The actual names or IDs are supplied when the user and role are instantiated. |
Notes on Permissions
Use of Formal Parameters | When a permission entry contains one or more formal parameters it is recommended that that permission is assigned to only one role. If different role requires an entry specifying the same permission, then another permission entry should be set up unique to that role. Furthermore, it is recommended that the formal parameter names should be unique for each role. For instance,
 This allows the user to be assigned to multiple roles without any ambiguity over the formal parameter assignment Similarly if within a single role differing restricted levels of access are required then different formal parameter names must be used | ||||||
Permissions are Hierarchic | Permissions are hierarchic, applied top down. A higher level of access will override a more restricted level of access. A role containing the permission Notes
| ||||||
Objects Available to a Given Permission are Additive | Within the above the Formal Parameter
|
Â
Standard Activity Category Setup
ServiceManager has the concept of standard activity categories - the ability to aggregate a number of standard activity types within a grouping. This provides a means within ServiceManager and its authorisation framework to restrict access to groups (categories) of standard activity. For example a user might be allowed to create/manipulate team management activities (such as team meetings and training courses) but not be allowed to manipulate authorised absence activities (such as holidays, hospital visits and so forth). This could be achieved by defining categories of standard activity and associating specific types of activity with a given category (in the preceding example there might be two categories defined: "Team Management" and "Absence").
 As each customer may have different types of standard activity the definition of which activities belong in which category is not one that can be automated. As a consequence an amount of manual configuration is required.
The tables involved here are Database sp150_std_act_categories and Database sp151_std_act_cat_types . See the relevant pages for their detail. In order for ServiceManager to work correctly these two tables need to be populated appropriately.
Relationships between ServiceManager Roles and Standard Activities | There is no mandated rule for how standard activity categories, or types, should be named. However in order for them to be of use within ServiceManager it is necessary for those users requiring specific standard activity category/type interaction to have their role associations defined using the same activity category and type as those defined within and Database sp105_activity_types. ACTIVITY_TYPE and. Database sp150_std_act_categories.NAME. |
sp150_std_act_categories | This is a list of all the activity categories. Each category has a name and an identifier. The name is displayed within the ServiceManager user interface when displaying a list of categories. Also these values are used within the authorisation framework in those properties requiring actual parameters to be associated with a standard activity category. |
sp151_std_act_types | Activity types defined in and Database sp105_activity_types can be assigned to a standard activity category (Database sp150_std_act_categories) by adding entries to this table associating the Database sp105_activity_types's activity type with the desired Database sp150_std_act_categories category identifier. |
Â
An example of how it works
Given a role (5) containing the following SP802_PERMISSION entries:
 SP802_PERMISSION:
Permission Id | Property | Operation |
15 | FRU | R |
16 | FRU(FRU_ID.F).Team.Oper | ALL |
The user should have at least one entry in SP803_AUTH_ACTUAL_PARAMETERS and SP804_PERMISSION_PARAMETERS. If no entry exists then the permission with Id 16 is discarded from the user's authorisation policy. If an entry does exist but does not contain the correct data then it too would be discarded:
 SP803_AUTH_ACTUAL_PARAMETERS:
User Id | Role Id | Parameter Type | Parameter Name | Assignment Type | Value | Permission Parameter |
jodd | 5 | FRU_ID | F | = | ABC | 7 |
jodd | 5 | XXX | F | = | DEF | 7 |
jodd | 5 | FRU_ID | X | = | GHI | 7 |
jodd | 5 | FRU_ID | F | X | JKL | 7 |
jodd | 5 | FRU_ID | F | = | MNO | 8 |
Â
SP804_PERMISSION_PARAMETERS:
Permission Parameter | Permission Id |
7 | 16 |
8 | 29 |
Â
In the preceding example only the first row of SP803_AUTH_ACTUAL_PARAMETERS would be added to the user's authorisation policy because each of the following four rows contains a different invalid data element.