CDP 4 User Manual

Typical Role Setup

Plugin:

Introduction

As described in the section on the purpose of roles in the CDP™4, following ECSS-E-TM-10-25, a user needs to be created as a Person in the CDP™ and has to be assigned to a Person Role to be able to open the CDP™ and login, i.e. connecting to a data source. In this section, a brief overview is given of the interactions between the classes in the role assignments and the corresponding permissions on these classes with several illustrative examples.

An indicative overview of typical or advisable role setups with corresponding permissions is provided as well.

Combinations of Roles and Permissions

The CDP™ uses the combinations of the Person Role and Participant Role of a person to define in the CDP™ Web Services what a user is allowed to do and what not. There are various relationships between required function assignments with corresponding editing rights that have an influence on which data the user sees and the actions the user is allowed to perform on the data. If a user is not able to perform a certain action, this will most likely be caused by the definition of the roles and permissions resulting in the fact that the person does not have sufficient rights. Feedback is provided to the user if he tries to perform an action that is not defined within this role assignment.

To allow a person to connect to a data source in the CDP™4, in principle only having a Read access right on the class SiteDirectory is already sufficient. This does not allow any useful actions or any actual data to be visible however. All browsers are available, but will be shown without any data.

The advisable or required settings for the permissions on any additional classes for person and participant roles may depend highly on the organization and associated requirements for access to the CDP™4 in general and engineering models specifically. In that sense it is not really possible to provide a real minimum role setup. The setup of the required person and participant roles requires a representative build-up of permissions on the available classes to a sufficient level, based on the allowed or required actions for these envisaged users.

Example for Roles and Permissions

As an example to illustrate the effects of assignments of classes, and the difference between settings for permissions, consider a user with a person role that includes the class Person. If the access right is set to Read if Participant, when a user (as a Person himself) is connected to a data source, he will see only a subset of all Persons in the list of persons, e.g. in the Person Browser, namely those Persons that are included as participants in any of the engineering models in which the person is a participant himself. If the access right is set to Read, the user will see the full list of all Persons on that data source. If the access right is set to Modify, the user will be able to perform all actions on all Persons, e.g. create or edit persons.

To allow a user to connect to a data source, and open an engineering model, the setup should have at least the following permissions on the given classes:

If this user as a person does not need to perform any further (administrative) actions on SiteDirectory level (see the description of levels in the RDL), this Person Role is sufficient. For the Participant Role, access rights on additional classes are needed to actually view the design data in the CDP™ for this engineering model and to perform all required actions on it that e.g. a Domain Expert or System Engineer will need to be able to perform.

Main Roles

An indication for various roles is given in the setup overview below. These are given for the following roles, that are available when installing an OCDT Server:

With these as a reference, it will be possible to setup additional roles required for your organization or Concurrent Design centre, e.g. for CD team members from external partners, or CDP™ Database administrators without full administrative permissions on all classes. Note that to achieve successful access and perform allowed actions for a user as a person in the CDP™, for a particular role it may be sufficient for the user to have only a Person with more extensive Person Role permissions and not requiring any access to engineering models, while for other roles it may be required to have a minimum Person Role while the focus will be on having specific permissions in the Participant Role within an engineering model. For the result, the Person Role by itself determines the allowed actions on concepts at the level of the Site Directory, while it is always the combination of the Person Role of a Person and the Participant Role for this person as a Participant within a specific engineering model that determines what is allowed on the Iteration level in that engineering model.

Overview of Advisable Roles Setup

As an indication or guideline, an overview is given here for the required roles setup for participants and supporting roles for a typical Concurrent Design team. This indication is based on the role setup of roles with access rights on each applicable class as this is done in the OCDT implementation of ECSS-E-TM-10-25, as managed and distributed by ESA. This set of permissions can be always be adapted, limited or extended.

An indicative setup of permissions for Person Roles is given by:

Class Site Administrator Concurrent Design Team Member Line Manager
Domain of Expertise MODIFY READ READ
Domain of Expertise Group MODIFY READ READ
Engineering Model Setup MODIFY READ_IF_PARTICIPANT READ
Iteration Setup MODIFY READ_IF_PARTICIPANT READ
Model Reference Data Library MODIFY MODIFY_IF_PARTICIPANT READ
Organization MODIFY READ READ
Participant MODIFY READ_IF_PARTICIPANT READ
Participant Permission MODIFY READ READ
Participant Role MODIFY READ READ
Person MODIFY MODIFY_OWN_PERSON MODIFY_OWN_PERSON
Person Permission MODIFY READ READ
Person Role MODIFY READ READ
Site Directory MODIFY READ READ
Site Log Entry MODIFY MODIFY MODIFY
Site Reference Data Library MODIFY READ_IF_PARTICIPANT READ

An indicative setup of permissions for Participant Roles is given by:

Class Model Administrator Customer Team Leader Design Authority Domain Expert Technical Author Observer
Actual Finite State List MODIFY READ MODIFY MODIFY MODIFY_IF_OWNER READ READ
Common File Store MODIFY MODIFY MODIFY MODIFY MODIFY MODIFY READ
Domain File Store MODIFY READ MODIFY MODIFY MODIFY_IF_OWNER MODIFY_IF_OWNER READ
Element Definition MODIFY READ MODIFY MODIFY MODIFY_IF_OWNER READ READ
Element Usage MODIFY READ MODIFY MODIFY MODIFY_IF_OWNER READ READ
Engineering Model MODIFY READ MODIFY MODIFY MODIFY_IF_OWNER READ READ
External Identifier Map MODIFY READ MODIFY MODIFY MODIFY_IF_OWNER READ READ
File MODIFY READ MODIFY MODIFY MODIFY_IF_OWNER READ READ
Folder MODIFY READ MODIFY MODIFY MODIFY_IF_OWNER READ READ
Iteration MODIFY READ MODIFY MODIFY READ READ READ
Model Log Entry MODIFY READ MODIFY MODIFY MODIFY MODIFY_IF_OWNER READ
Nested Element MODIFY READ MODIFY MODIFY MODIFY_IF_OWNER READ READ
Nested Parameter MODIFY READ MODIFY MODIFY MODIFY_IF_OWNER READ READ
Parameter MODIFY READ MODIFY MODIFY MODIFY_IF_OWNER READ READ
Parameter Group MODIFY READ MODIFY MODIFY MODIFY READ READ
Parameter Override MODIFY READ MODIFY MODIFY MODIFY_IF_OWNER READ READ
Parameter Subscription MODIFY READ MODIFY MODIFY MODIFY_IF_OWNER READ READ
Possible Finite State List MODIFY READ MODIFY MODIFY MODIFY_IF_OWNER READ READ
Publication MODIFY READ MODIFY MODIFY READ READ READ
Relationship MODIFY NONE NONE NONE NONE NONE NONE
Requirement MODIFY MODIFY MODIFY MODIFY MODIFY_IF_OWNER MODIFY_IF_OWNER READ
Requirements Group MODIFY MODIFY MODIFY MODIFY MODIFY MODIFY_IF_OWNER READ
Requirement Specification MODIFY MODIFY MODIFY MODIFY MODIFY_IF_OWNER MODIFY_IF_OWNER READ
Rule Verification List MODIFY NONE NONE NONE NONE NONE NONE

Related Topics

Last modified 1 year ago.

^ Top