If you can't find the product or version you're looking for, visit support.ataccama.com/downloads

MDM Web App Permissions

Permissions (or roles) for the MDM Web App are defined in Files/etc/mda-permissions.gen.xml and referenced in MDM Web App Backend. Keep in mind that for a new role to be able to work with tasks in the MDM Web App, the role also needs to be defined in metadata.xml and workflow.xml.

mda-permissions.gen.xml overview

The mda-permissions.gen.xml configuration file has the following structure:

<?xml version='1.0' encoding='utf-8'?>
<permissions>
    <taskRoles>
        <role name="MDM_viewer"/>
        <role name="MDM_user"/>
        <role name="MDM_admin"/>
    </taskRoles>
    <securityProviders>
        <securityProvider class="com.ataccama.mda.core.config.security.MdaPermissionsProvider">
            <rolesBean class="com.ataccama.mda.core.config.security.MdaXmlRolesProviderConfig">
                <roles>
                ...
                </roles>
            </rolesBean>
        </securityProvider>
    </securityProviders>
</permissions>

loggedUsername: Allows to skip the login screen and log in as the specified user (development mode only).
securityProviders: This section defines actual permissions to the entities and related attributes.
- MdaAllPermissionsProvider: Grants permission for all entities and columns including all actions (development mode only).
- MdaDefaultPermissionsProvider: Role types are hardcoded, and consist of:
  - viewRoles: User can see entity, workflow, and create tasks.
  - userRoles: All the previous permissions plus the ability to edit records, create, discard and delete tasks, and export data.
  - adminRoles: All the previous permissions plus the ability to publish tasks and create automatic tasks.
- MdaPermissionsProvider: For custom definition of permissions for entities and their columns, and definition of transition permissions.
  
  Two security providers can be used, but one role should not be defined in both. Otherwise, permissions for that role can not be determined correctly.

rolesBean: The container node for definition of role. Currently, there is only one role provider available: RolesBean.

...
            <rolesBean class="com.ataccama.mda.core.config.security.MdaXmlRolesProviderConfig">
                <roles>
                    <role name="MDM_user">
...

taskRoles: Users listed here are users to whom tasks can be assigned.

Role definition

Here is an example of actual role definition:

mda-permissions.gen.xml example

 <role aiMatching="true" createTask="true" name="MDM_user">
                        <description/>
                        <workflows>
                            <workflow name="consolidation">
                                <steps>
                                    <step delete="true" discard="true" name="draft" publish="false"/>
                                    <step delete="true" discard="false" name="waiting_for_publish" publish="false"/>
                                </steps>
                                <transitions>
                                    <transition name="move_publish"/>
                                </transitions>
                            </workflow>
                        </workflows>
                        <instanceLayer>
                            <entities>
                                <entity export="true" name="party">
                                    <steps>
                                        <step name="draft" override="true" ovrActive="true" ovrMatch="true" workflow="consolidation" />
                                    </steps>
                                    <columns>
                                        <column name="id" write="true"/>
                                        <column name="src_first_name" write="true"/>
                                        <column name="cio_gender"/>
                                    </columns>
                                    <row>cio_gender IN ('F', 'M')</row>
                                </entity>
                            </entities>
                        </instanceLayer>
                        <masterLayers>
                            <masterLayer name="masters">
                                <entities>
                                    <entity export="false" name="party">
                                        <steps>
                                            <step masterCreate="false" masterDelete="true" masterEdit="true" name="draft" override="true" ovrActive="false" ovrMatch="true" workflow="consolidation"/>
                                        </steps>
                                        <columns>
                                            <column name="id" write="true"/>
                                            <column name="cmo_first_name" write="true"/>
                                            <column name="cmo_gender"/>
                                            <column name="cmo_type"/>
                                        </columns>
                                        <row>cmo_gender = 'F'</row>
                                    </entity>
                                    <entity name="party_instance">
                                        <steps>
                                            <step masterCreate="false" masterDelete="true" masterEdit="true" name="draft" override="true" ovrActive="true" ovrMatch="true" workflow="consolidation"/>
                                        </steps>
                                        <columns>
                                            <column name="id" write="true"/>
                                            <column name="src_first_name" write="true"/>
                                            <column name="cio_gender" write="true"/>
                                            <column name="cio_type" write="true"/>
                                        </columns>
                                        <row>cio_type = 'P'</row>
                                    </entity>
                                </entities>
                            </masterLayer>
                        </masterLayers>
                        <datasetLayer>
                            <entities>
                                <entity export="true" name="party_contact_inst">
                                    <columns>
                                        <column name="id" write="true"/>
                                        <column name="party_instance_std_first_name" write="true"/>
                                    </columns>
                                    <row>party_instance_std_first_name NOT IN ('John', 'Jordan')</row>
                                </entity>
                            </entities>
                        </datasetLayer>
                        <proposalLayer>
                            <entities>
                                <entity name="party_proposal_k" reject="true"/>
                            </entities>
                        </proposalLayer>
                    </role>

role

name: Name of the role.
createTask: Specifies if the role can create a task (for more information, see Manual Task Creation).

aiMatching: Specifies if the role can use AI Matching (for more information, see AI Matching Overview).

Users that train AI or review training must have full view permissions on the training entity both for columns and rows. The absence of column permissions can cause inadequate matching decisions, and the absence of row permissions can result in an error.

automatedTaskCreation: Specifies if the role can create automatic tasks (for more information, see Automatic Task Configuration).

Users with automatic task creation permissions must also have view permissions for all entities and columns that are used in the automatic tasks they created. Otherwise, it is not possible to see the task detail.

workflows/workflow

workflow name: Name of the workflow.
If a role contains a workflow step, the role can view tasks in this state.
If a role contains a workflow transition, the role can execute this transition (move tasks to another state).
If a step contains the attributes discard="true", publish="true", or delete="true", the role can discard, publish, or delete tasks in this state (for more information, see Publishing Workflow).

entities/entity

entity name: Name of the entity.
If a role contains an entity, the role can view the entity.
export: Specifies if the role can export.
reject (only for proposalLayer): Specifies if the role can reject matching proposals.

steps/step

If an entity contains a step (identified by the step name and the workflow name), the role can execute actions. The following actions can be specified (Boolean):
- override: The role can set and remove overrides on attributes (see Editing Values, section Override consolidated values).
- ovrActive: The role can override the activity status of the record: set as active or inactive and remove activity overrides (see Activating and Deactivating Records).
- ovrMatch: The role can merge master records, merge and split instances (see Merging and Splitting Records).
- masterEdit, masterCreate, masterDelete: The role can execute these actions on the master layer (see Editing Values, Creating and Deleting Records).

columns/column

column name: Name of the column.
If an entity contains columns, the role can view these columns.
If a column contains the attribute write="true", the role can override or edit this value if the workflow state allows this action.
If a column contains the attribute `edit="true’ (authored records only), the role can edit this value if the workflow state allows this action.
If a column contains the attribute override='true' (consolidated records only), the role can override this value if the workflow state allows this action.
If a column contains both edit='true' and override='true', the attribute write is generated, and works as previously described.

row

If a role does not contain a row permission, it can see all rows.
If an entity contains a row permission, the role can view only what is defined in the permission.
Row permissions are defined using SQL WHERE conditions (supported operators and syntax are dependent on the database).
If a user has more than one role, they have the row permissions of all assigned roles.

Row permission examples

    <!-- Role has permission to view column cio_gender if the values are 'M' or 'F' -->
<row>cio_gender IN ('F', 'M')</row>


    <!-- Role has permission to view records that have a first name column containing the letter 'a', gender column containing the value 'M' or an ID value less than 2000.  -->
<row>(first_name LIKE '%a%' AND gender = 'M') OR id &lt; 2000</row>

For example, to see only gender = M records in Party entity, the mda-permissions.gen.xml would look as follows:

                               <entity name="party" >
                                    <columns>
                                        <column name="src_first_name" write="true"/>
                                        <column name="src_last_name" write="true"/>
                                        <column name="src_gender" write="true"/>
                                    </columns>
                                 <row> src_gender = 'M' </row>
                                </entity>

Was this page useful?