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.xml and referenced in MDM Web App Backend. Keep in mind that for a new role to be able to work with drafts in the MDM Web App, the role also needs to be defined in metadata.xml and workflow.xml.

mda-permissions.xml overview

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

<?xml version='1.0' encoding='utf-8'?>
<permissions>
    <issueRoles>
        <role name="MDA_viewer"/>
        <role name="MDA_user"/>
        <role name="MDA_superuser"/>
        <role name="MDA_im_steward"/>
    </issueRoles>
    <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 issues.
  - userRoles: All the previous permissions plus the ability to edit records, create, discard drafts, and export data.
  - adminRoles: All the previous permissions plus the ability to publish drafts.
- 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="MDA_user">
...

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

Role definition

Here is an example of actual role definition:

mda-permissions.gen.xml example

<role name="MDA_user">
                       <workflows>
                           <workflow name="consolidation">
                               <steps>
                                   <step name="draft" discard="true"/>
                                   <step name="waiting_for_publish"/>
                               </steps>
                               <transitions>
                                   <transition name="move_publish"/>
                               </transitions>
                           </workflow>
                       </workflows>
                       <instanceLayer>
                           <entities>
                               <entity name="party">
                                   <steps>
                                       <step name="draft" workflow="consolidation" override="true"/>
                                   </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 name="party" export="false">
                                       <steps>
                                           <step name="draft" workflow="consolidation" ovrMatch="false"/>
                                       </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" createIssue="true">
                                       <steps>
                                           <step name="draft" workflow="consolidation" ovrMatch="true"/>
                                           <step name="waiting_for_publish" workflow="consolidation" ovrMatch="true"/>
                                       </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 name="party_contact_inst" createIssue="true">
                                   <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>
                   </role>

role

name: Name of the role.

workflows/workflow

workflow name: Name of the workflow.
If a role contains a workflow step, the role can view drafts in this state.
If a role contains a workflow transition, the role can execute this transition (move drafts to another state).
If a step contains the attributes discard="true" or publish="true", the role can discard or publish drafts 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 issues.
createIssue: Specifies if the role can create an issue on the entity (see creating-data-issues.adoc).

createIssue attribute will only work if createIssue and seeOthersIssues permissions are assigned for the role in metadata.xml.

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 depend 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.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?