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.
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.
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
For the Participant Role
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.
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:
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
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.
A role with full administrator rights on the Iteration level, i.e. all allowed actions within an engineering model.
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.
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.
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.
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.
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.
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.
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|
|Model Reference Data Library||MODIFY||MODIFY_IF_PARTICIPANT||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|
|External Identifier Map||MODIFY||READ||MODIFY||MODIFY||MODIFY_IF_OWNER||READ||READ|
|Model Log Entry||MODIFY||READ||MODIFY||MODIFY||MODIFY||MODIFY_IF_OWNER||READ|
|Possible Finite State List||MODIFY||READ||MODIFY||MODIFY||MODIFY_IF_OWNER||READ||READ|
|Rule Verification List||MODIFY||NONE||NONE||NONE||NONE||NONE||NONE|
Last modified 3 years ago.