Lead your team forward
OCT 24 / 9AM ET Register nowMDM 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"
orpublish="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'
andoverride='true'
, the attributewrite
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.
-
<!-- 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 < 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?