Configure security - SmartPlant Foundation - IM Update 46 - Help - Hexagon

SmartPlant Foundation Web Client Help
Language
English
Product
SmartPlant Foundation
Search by Category
Help
SmartPlant Foundation / SDx Version
10

For more information about configuring security features such as access groups and domains, see How to Configure the Security Model.

Which security features determine what can be seen or done in the system?

What you can see or do is determined by which objects you need to see and which actions you need to perform to do your job.

Your administrator can use many different components of the security model to control what you can do or see in the system.

Security model feature

What it does

Role and role assignment

Determines your level of access to data and functionality in a specific plant or project configuration. You can belong to more than one role per configuration. Roles are associated with related access groups, domains, and owning groups.

Access group

Determines what actions you can perform in the system and which functional components you can access in your system. Users are related to roles, which are related to access groups.

Security rule

Limits the types of data that you can query in the system. Your associated access groups are used to determine which security rules are relevant.

Owning group

Sets up ownership of data, typically by department or discipline, as well as controls your access to an object or parts of an object based on its ownership. Objects can be owned by a user or by an owning group. Owning groups are associated to roles. The default owning group is engineering to which everyone has access.

Configuration

You can be assigned different roles in different plants and projects.

You can create and manipulate data in a single plant or projects. This is also known as the create scope. Objects created in projects are not visible from parallel projects and its parent plant.

You can query across multiple plants and projects. This is also known as the query scope.

Security is configured to ensure users see only the items to which they should have access. This access differs for internal and external organizations. Two access groups are used to define these rules:

  • SDACompanyFilter – This is used on internal company roles.

  • SDAContractorFilter – This is used on external contractor roles.

The central security rules are configured to access documents and comments. The SDACompanyFilter is used on rules that allow the users to see the documents from any organization as long as their security level permits it. The SDAContractorFilter is used on rules that allow the users to see the documents from their organization as long as their security level permits it.

The relationship between methods and access group conditions govern who can edit what and when.

  • The majority of roles have a relationship to the FDWDocEditByOrg access group. This is used in most of the conditions on updating methods; for example:

    • It is only possible to edit documents originating from their organization.

  • The global document control role also has the SDADocEditANYOrg access group.

    • The conditions on the updating methods also include a test of: OR Instr(Env.ACCESSGROUPSFORUSERINCREATECONFIG, 'SDADocEditANYOrg')>0.

    • This means that if the user is in a role that is related to the SDADocEditANYOrg access group, they can edit documents from other organizations.

  • The document, tag, work package, and communication forms have access control configured by access group with sections configured for different roles.

    • The majority of roles have a relationship to the SDAByMyOrgOnlyFormAccess access group that is related to sections in which the originating organization display items are read-only. This access control ensures that the users can create items only from their own organization.

    • The global document control role also has a relationship to the SDAProjComsEditANYOrg access group.

      • This gives access to editable display items for originating organizations on documents and tags.

      • This also gives access to editable display items for the From User on project communications. However, the From Organization is still read-only, because the role cannot create project communication items that come from other organizations. The only exception is an internal transmittal, which can be used to record the receipt of documentation when submittals are not used.

  • Markup access is governed in a different way. The LimitViewMarkup method has conditional access so the users can see only markup layers that are created by users of their organization.