The Authorization Concept for Working with Records Management 

The authorization concept for working with Records Management has three levels. Level 1 is checked first, then level 2, and finally level 3.

·        Level 1: Authorization restrictions for defining views.

·        Level 2: Authorization check using the Records Management authorization object.

·        Level 3: Authorization check using the authorization objects of a Service Provider (as long as this has implemented an authorization check)

As a general rule, an authorization check for an element in its own repository is only successful if these authorization checks have been passed.

Level 1: Authorization Restrictions for Defining Views

Prerequisite: User roles have been defined. The views are each assigned to one or more users.

Creating Views in Records Organizer

The administrator can create a role-based view and assign it to a user role. The role-based view contains element types and elements that users with that role need in their everyday work.

The role-based view is designed to simplify navigation from the initial screen for the user. If no role-based view is created, the user will see all the element types that exist in the current RMS. To display individual elements, the user would then have to use the Search activity.

Creating Views in Records Modeler

When creating a record model, the administrator can determine for which roles each node is visible. When users create a record using a record model, structure nodes, model nodes, and instance nodes are only displayed if they have been defined as visible for their role. The user can therefore only create elements for element types that are assigned to the visible nodes.

Controlling Views in Records Browser

In a record, a user can determine which nodes are visible for which roles. This is valid for model nodes that do not yet have any elements, as well as for nodes that have elements assigned to them, and structure nodes.

Level 2: Authorization Check Using the Records Management Authorization Object

The general authorization object for Records Management is called S_SRMSY_CL. This applies to all elements within Records Management, It has the following authorization fields:

 

You can use the fields to restrict the authorizations within an authorization object. If you enter a value here, the authorization is restricted to this value. If you do not want to set any restrictions, enter ‘*’. You can enter more than one value for each field.

·         RMSID: ID of an RMS

·         SPSID: ID of an element type

·         ACTVT: Number of an activity. The following values are permitted:

o         33 Read (execute non-change activities)

o         34 Write (execute change activities)

o         35 Output (list display)

This authorization check is carried out before the user performs the following actions:

·         Displaying element types and elements as nodes in a list (for example, when calling a record)

For every element type and every element that is displayed as a node in the list, the system checks whether the user has authorization for the current RMS, the element type (SPS ID), and the Output activity.

If the check fails for an element or an element type, the node for the corresponding element/type is not displayed in the list.

·         Calling activities for an element

For the activities Search, Display, Information, and Log, the system checks whether the user has Read authorization for the RMS and the element type of the element.

For the activities Create, Edit, and Delete, the system checks whether the user has Write authorization for the RMS and the element type of the element.

If this check fails, a message is displayed stating that the user does not have authorization to execute this activity.

Level 3: Authorization Check Using Authorization Objects of the Individual Service Providers

Service providers can implement their own authorization checks. This authorization check is called in connection with the authorization check of the general Records Management authorization object. For service providers that do not implement their own authorization check, level 3 is omitted.

The following service providers supplied by SAP have an implemented authorization check:

·         SP for records

·         SP for record models

·         SP for documents

·         SP for document templates

·         SP for notes

·         SP for administration data of paper documents

·         SP for file plans

The service providers named above are all based on the same back end; the generic service provider. The authorization check for all these service providers is therefore identical. For more information, see The Authorization Concept of the Generic Service Provider. The SP for records offers one other authorization check. For more information, see Authorization Check for the Service Provider for Records.

·         SP for circulars and process routes

For more information, see The Authorization Concept for Circulars and Process Routes.