On This Page:

Notes on Permissions
Standard Activity Category Setup
An example of how it works

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)

This process may be achieved using ServiceManager.

Each role has been defined with a list of properties

A property is a text string of the following form:

FRU

FRU.Team

FRU.Team.Oper

FRU.Team.Oper.SA

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:

FRU(FRU_ID.F)

FRU.Team(TEAM_ID.T)

FRU.Team.Oper(OPER_ID.Op)

FRU.Team.Oper.SA(SACAT_ID.Cat)

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,

if both ‘Business Data Administrator (Business)’ and ‘Service Resource Manager (Permanent)’ roles requires permission FRU(FRU_ID).Team.Oper

then they should be set up with unique permission entries e.g

FRU(FRU_ID.BDAB_F).Team.Oper

FRU(FRU_ID.SRMP_F).Team.Oper

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 FRU(FRU_ID.F):R effectively says the user can view (Read) all the data associated with the defined FRU(s) FRU_ID.F. If FRU_ID.F were defined as FRU-1, then the user would be able to view all data relating to FRU-1 - including all its teams, and all the operatives within those teams.

Notes

One of the standard Roles within ServiceManager is the Planner Role which is defined containing only two SP802_PERMISSION entries:

FRU : R // the user can view everything

FRU(FRU_ID.F) : ALL // the user can update everything pertaining to FRU_ID.F

Note that where a role requires a more restrictive level of access to one of the subordinate node elements, a more verbose definition is required in which each of the individual node elements from FRU needs explicitly defining for those nodes that want a wider operational scope.

So for instance, in a role which requires Read access to all FRU attributes, Update access all but a few of the Operative, the opposite entries are required:

FRU : R // can read everything

FRU.Team.Oper.JobTitle : U

FRU.Team.Oper.Phone1 : U

FRU.Team.Oper.Phone2 : U ... // and all the other required SP210_EMPLOYEE attributes

In the above example, it is not sufficient to enter the opposite values since, in this case, the U access from FRU would mask the R access from the subordinate element.

FRU : U // can update everything within the FRU...

FRU.Team.Oper.Eff : R // except the efficiency which I want read-only access to

Objects Available to a Given Permission are Additive

Within the above the Formal Parameter FRU_ID.F would need to be specified for the permission FRU : ALL to take effect. By specifying the appropriate FRU reference results in all the objects specific to that FRU being considered. For example

If two FRUs were specified for the above:

FRU(FRU-1) : ALL

FRU(FRU-2) : ALL

Then the net effect would be all the operatives and teams within both FRU-1 and FRU-2 be considered

as objects relating to the FRU : ALL permission.

As a consequence, currently the != exclusive assignment type does not behave as might be initially expected.

Given the following where the assumption is that the user does not have access to either the operatives in FRU-1 or FRU-2:

FRU(!=FRU-1) : ALL

FRU(!=FRU-2) : ALL

The actual result is the inclusion of operatives within both FRUs, because !FRU-1 includes FRU-2 and !FRU-2 includes FRU-1.

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.

Browser not supported