Full support for team based permissions in Ataccama ONE is coming in v14. However, you may need to implement team based permissions sooner than v14. This document is a guide to how you could achieve this in v13.8.
 

Background

Permissions in ONE can be configured as role based or user based. In most cases, configuration by role is preferred as it will usually be a one-time set up, where the role only needs to be configured once in the beginning, then any users allocated to that role will inherit all permissions on role.

The out of the box roles in ONE have some capabilities already allocated. These are auto-sharing permissions, which allows the role to have access to all items of that entity. E.g. Your role could have the capability of Rule Owner. This means the user will be automatically be owner of all rules that would ever be created on the platform.

But what if your user should only be owner to rules (or any other entities) within their team / division / domain?

As it stands in v13.8, these are the supported scenarios:

• user cannot create new rules, has access only to its rules
  • Admin has to create the new rules, and assign permission for that role under specific rule
• user can create new rules, and see all rules in the whole platform
  • Role is given rule-admin capability
• user cannot create new rules, but see all rules from all teams
  • Role is given rule-editor or rule-viewer capability

In this article, we will explore the implementation for this case:

• user creates new rules, and has access to the team’s rules
  • user creates a record in a new entity called newRuleRequest and publishes it
  • notification handler picks that up and creates new rule, allocating specific roles as owners and editors

I have an example configuration here. These were my conditions:

• I have 2 departments: HR and Finance
• They have access to their own rules and own terms.
• There are 4 roles: MMM_hr_lead, MMM_hr_user, MMM_finance_lead, MMM_finance_user

1. New entities / properties in metadata model

You will need to create some new entities in ONE:

• To hold list of your departments

  

   

  • Each department should specify Owner roles and Editor roles
  • The ownerRole and editorRole are Single Reference Entity on role. If you have a requirement, you can always set this as Array Embedded Entity.

• To hold list of requests

  

   

  

   

  

   

  • Each request should specify which department it is for
  • You may need to add extra SRE property for sub types, e.g. for terms
  • Hint: You could have created a newRequest entity with the common properties between the 2 entities, then create newRuleRequest which extends newRequest, and also newTermRequest which extends newRequest but with extra termType property
  • termType here is extra custom entity also

• Add department and termType to valueLists entity as AEE

  

   

  • This allows the department and term type list to be visible in List Of Values menu in Global Settings

• Add newRuleRequest / newTermRequest / newRequest (which ever you have chosen to implement) to metadata node

  

   

  • This allows us to then put them in the navigation
• Optionally, you can also add new SRE property of department, on your actual rule and term for easy reference, so it’s clear to the users which department the rule / term belongs to. It is not configured in this example.
   

2. Navigation

Once you have created the entities and properties in the metadata model, tidy up the navigation. Here, both of the requests were put into a Requests menu. A new section group navigation of Requests was created as a child of Middle, and then the new requests were created as children items inside of Requests. You can of course organise this according to your needs.

3. Permissions.json

Permissions.json is in use for v13.8. This is the example that was implemented in this model. Do this only after all metadata model changes have been made because the permissions.json references the new entities. 
 

Operation sets

• Set core:createNewDraft operations for newRuleRequest` and newTermRequest entities
  • line 1522: rule-requester
  • line 1539: term-requester

Capabilities

• line 1718, 1719: Add nodePaths of "newRuleReuqest/**" and "newTermRequest/** as owner for application-user capability
• line 1723 - 1731: Add nothPath of "" and operationSet of "rule-requester","term-requester" to application-user capability
   

4. Create users and roles, and allocate users to roles

The 4 new roles need to be created. Remember to create them in Keycloak, not in ONE directly. Remember they need to start with MMM_.

5. Sync user and role

Go to ONE and sync user

6. Populate List of Values

Next, populate the Department and term types list.

When creating the department, allocate the roles who will get owner or editor access.
 

7. Orchestration project

The orchestration project consists of:

• notification handler
  • This listens for all creations of newTermRequest and newRuleRequest, and triggers defined .ewf, with the event details in a json string
• workflow
  • The workflow will pass that json string into defined .comp
• component
  • The component takes the json message, and queries the newRequest entity for its details
  • Also queries the associated department and roles
  • Check that the person who created the rule / term request has one of either the owner or editor role. If the person does have the role(s)…
  • Write the rule or term. This is possible because it is now MMM_admin doing the write rule. Rule could be written by MMM Metadata Writer, but term need to be written by Graphql
  • More Graphql queries to set the ownerRole and editorRole
  • Delete the initial newRequest record, as it’s already been created
  • If the person does not have the role(s), the request would be updated with a timestamp and a message, notifying them that they do not have permissions and so need to delete the request and try again when they have the correct rights.
• runtime config. The connection details to ONE platform are defined as https://one.your.ataccama.domain. Adjust all the urls and credentials as required for your environments.

8. Tweak notification handler

The rule_creation.noth notification handler file has this in line 11:

<subscription ackLimit="100" chunkMaxDelay="250" chunkSize="100" entityType="newRuleRequest" excludeOwnModifications="false" subscriptionId="896a55cf-0b3c-412e-b062-86351bca8b15"/>

You need to adjust it, so that there is no subscriptionId tag. This tag needs to be generated specifically for your ONE instance. ONE runtime server will generate it when it starts up:

<subscription ackLimit="100" chunkMaxDelay="250" chunkSize="100" entityType="newRuleRequest" excludeOwnModifications="false"/>

9. Ensure notification handler component is enabled in serverConfig

Ensure you have enabled the notification handler component in your serverConfig file. More docs here.

Deploy to your project to your runtime server and start it.

10. Test!

All configuration is now done!

To start with:

• admin user should see everything
• hr_user1 should see nothing
• Both admin and hr_user1 should see the new request menus

As hr_user1:

• Create a new rule request
• Give it some description
• Indicate it should be for HR team
• Publish the rule
• Refresh the page, the new rule request should disappear
• Go to rule listing
• Should see your new rule there
• New rule should be allocated to MMM_hr_lead for Owner and MMM_hr_user for Editor

As finance_user1:

• Create a new rule request
• Give it some description
• Indicate it should be for HR team
• Publish the rule
• Refresh the page, the new rule request should be populated with log message and timestamp
• Go to rule listing
• New rule should not be there