Scribd Logo
Upload

Welcome to Scribd!

  • Aveva E3d Access Control

    Uploaded by

    Shahfaraz Ahmad
    615 views5 pages
    This document provides an example of setting up Data Access Control (DAC) in the ADMIN module to lock specific IFC elements from modification by users. It describes: 1. Creating scopes, roles, and Access Control Rights (ACRs) to define which users have access to which elements and operations. 2. Allocating ACRs to users to control their permissions. 3. Activating the DAC across the project. 4. Demonstrating in the Design module how elements can be locked from modification by setting an attribute, and unlocked by unsetting that attribute.

    Original Description:

    AVEVA E3D ACCESS CONTROL

    Original Title

    AVEVA E3D ACCESS CONTROL

    Copyright

    © © All Rights Reserved

    Available Formats

    PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    Report this Document
    This document provides an example of setting up Data Access Control (DAC) in the ADMIN module to lock specific IFC elements from modification by users. It describes: 1. Creating scopes, roles, and Access Control Rights (ACRs) to define which users have access to which elements and operations. 2. Allocating ACRs to users to control their permissions. 3. Activating the DAC across the project. 4. Demonstrating in the Design module how elements can be locked from modification by setting an attribute, and unlocked by unsetting that attribute.

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd
    Flag for inappropriate content
    615 views5 pages

    Aveva E3d Access Control

    Uploaded by

    Shahfaraz Ahmad
    This document provides an example of setting up Data Access Control (DAC) in the ADMIN module to lock specific IFC elements from modification by users. It describes: 1. Creating scopes, roles, and Access Control Rights (ACRs) to define which users have access to which elements and operations. 2. Allocating ACRs to users to control their permissions. 3. Activating the DAC across the project. 4. Demonstrating in the Design module how elements can be locked from modification by setting an attribute, and unlocked by unsetting that attribute.

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd
    Flag for inappropriate content
    of 5

    Setting of DAC – a working example

    Objective
    In project scenario IFC elements needs to be locked for any known or unknown modifications

    Requirement
    ▲ Typically LOCK attribute at any element level can help you to restrict modification of such IFC elements
    until LOCK value is set TRUE, which otherwise, can be set to FALSE very easily by user who has
    access into that DB.

    ▲ To ensure IFC elements should be modified using selective methodology, one can use DAC (Data
    Access Control) setup in ADMIN module of project

    ▲ This document is an attempt to showcase a small example of DAC setup. Refer help maunal for more
    details, which supplied with software.

    (We are also supplying the Dblist files for all the necessary elements to test DAC)

    Procedure
    Admin Module

     Create Scopes, Roles, ACRs

    ▲ Scope: Scope can be applied to whole project (typically done) OR else it can be applied to selected
    elements (for e.g. SITE/DEPT etc.)

    ▲ Roles: Roles needs to be defined in-line with the requirement of allowing/dis-allowing access. Further to
    role, there are permissible operations (PEROPs) which hold the information like:

     Name of PEROP: Set unique and significant name for each PEROP

     Element Type: Set element and their hierarchy which you want to control. For e.g. PIPE PIPE HIER,
    includes both PIPE and all the child elements of that PIPE
    PAGE 2 OF 5

     Qualification Condition: Appropriate conditions needs to be defined to qualify of applying restriction.


    Typically, a PML 1 syntax should be used to set qualification condition. For e.g. PURP of PIPE eq ‘IFC’

     Operations: There are operations like Create, Modify, Delete, Claim, Issue, Drop, Output & Export
    which can be set with permissions like Ignore OR Allow OR Disallow.

     Attributes: You can select which all attributes of selected elements needs to be restricted. Typically,
    ALL attributes should be locked for such IFC elements

     Error Message: Key in appropriate error message that should be reflected when user tries to modify
    restricted elements. For e.g. “You are trying to modify IFC elements, access denied”
    PAGE 3 OF 5

    ▲ ACRs: Access Control Rights (ACR) is a combination of Roles and Scopes. Typically, ACRs are applied to
    USERs defined in Admin module.

     Allocate ACRs to USERs

    ACR needs to be applied to USERs defined in Admin module. Refer below image for steps.

     Activating DAC across the project:

    DAC can be activated by checking Project > Data Access Control...


    PAGE 4 OF 5

     Other Key Information:

    ▲ Once DAC is enabled all USER needs to have at least one ACR applied to
    them

    ▲ One or more ACR can be applied to USER based on the ROLEs defined

    ▲ There must be at least one ACR defined for all users which has access to
    all elements. Such ACR will allow creation and modification of elements when
    condition is not applied

    ▲ Sequence of ACR applied to USER are very much critical and has an impact
    on actions like creation/modification/deletion etc.

    ▲ In above example we have setup Negative DAC, which means after


    qualification condition fails, then application acts upon actions. Negative DAC is
    more effective in many cases.

    ▲ For each changes made in DAC related settings, don’t miss to savework and start new session of DESIGN
    or any other module where DAC needs to be tested.

    Design Module (for this DAC example only):

    In Design module, set value of IFC to PURP attribute of PIPE or EQUI and perform a savework action. This should
    now restrict further modification of such PIPE or EQUI by User Designer.

    In case there are mandatory changes in Design for e.g. revision in layout which will require re-routing of PIPE or
    re-positioning of EQUI, Lead User can unset such attribute (PURP in our case) and after savework and unclaim,
    Designer should get access to modify such elements.
    PAGE 5 OF 5

    In the first image above when PIPE has PURP as RFC all the fields are greyed out (non-editable), where as second
    image is having PURP unset and hence all the editable elements are open for any modification.

    You might also like