• Typical Role Setup
• Introduction
• Combinations of Roles and Permissions
• Example for Roles and Permissions
• Main Roles
• Overview of Advisable Roles Setup
• Related Topics

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:

• For the Person Role

  • Domain of Expertise - Read
  • Domain of Expertise Group - Read
  • Engineering Model Setup - Read If Participant
  • Iteration Setup - Read If Participant
  • Model Reference Data Library - Read If Participant
  • Organization - None
  • Participant - Read If Participant
  • Participant Permission - Read
  • Participant Role - Read
  • Person - Read If Participant
  • Person Permission - Read
  • Person Role - Read
  • Site Directory - Read
  • Site Log Entry - None
  • Site Reference Data Library - Read If Participant

• For the Participant Role

  • Engineering Model - Read
  • Iteration - Read

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:

• Person Roles

  • Site Administrator

    A role with full administrator rights on the Site Directory level.

    Note that this does not automatically provide a person with administrative permissions on an engineering model, these are determined by the assigned participant role.

  • Concurrent Design Team Member

    A role with sufficient permissions on the Site Directory level to successfully access any assigned engineering model

  • Line Manager

    A role with READ permissions on all concepts on Site Directory level.

    This allows e.g. to inspect the available engineering models, persons, roles, etc. Note that an assignment to an engineering model as a participant with an associated Participant Role with sufficient permissions is required to actually open an engineering model and inspect the actual design data.

• Participant Roles

  • Model Administrator

    A role with full administrator rights on the Iteration level, i.e. all allowed actions within an engineering model.

  • Customer

    A role with READ permission on most concepts in the engineering model, to allow the customer to see the design and trace the design evolution.

    For the requirements, this role has MODIFY permissions, to allow the customer to create, check and update requirements during a Concurrent Design activity.

  • Team Leader

    A role with MODIFY permissions on almost all classes, except for Relationship and Rule Verification List.

    Note that this role has the same permissions as the design authority.

  • Design Authority

    A role with MODIFY permissions on almost all classes, except for Relationship and Rule Verification List. Note that this role has the same permissions as the Team Leader.

  • Domain Expert

    A role with READ permissions on classes that are more related to overall process management of an engineering model, such as iterations and publications, and usually MODIFY_IF_OWNER permissions on the various classes related to the actual design within the engineering models, e.g. the element definitions and element usages, classes related to the parameters, and for requirements.

  • Technical Author

    A role with mostly READ permissions to allow a participant to inspect the actual design data in an engineering model to retrieve valuable information for reporting purposes.

    This role has MODIFY_IF_OWNER permissions on classes related to requirements, e.g. to allow managing requirements within the engineering model that have a direct relations with reporting or retrieving final results.

  • Observer

    A role with READ permission on most concepts in the engineering model, to allow the observer to see the design and trace the design evolution.

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:

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

Related Topics

• Create a Team
• Purpose of Roles
• Manage Person Roles
• Manage Participant Roles
• Manage Persons
• Typical Role Setup
• Create a Team
• Login
• Manage RDL

Last modified 3 years ago.