Extending Permissions to Item Properties in Aras Innovator

The Challenge: Granular Permission Control in Aras Innovator

Aras Innovator’s native permission system operates primarily at the item level, which can be limiting when organizations require finer-grained security controls. A common challenge arises when different engineering disciplines (Electrical, Software, Mechanical) need distinct access rights to specific properties of the same item.

Why Property-Level Permissions Matter

Traditional item-level permissions mean that if a user has access to an item, they typically have access to all its properties. This becomes problematic when:

• Sensitive data exists in specific fields
• Different teams require access to different subsets of data
• Compliance requirements demand strict property-level controls

Solution Architecture: Implementing Property Permissions

We’ll implement a custom solution with these components:

1. PropertyPermission ItemTypes: Create dedicated permission items for each discipline
2. Extended Property Definitions: Enhance the Property ItemType with permission references
3. Server-Side Enforcement: Add validation logic for all data access methods

Step 1: Create PropertyPermission Structure

<Item type="ItemType" action="add" id="PropertyPermission">
  <name>PropertyPermission</name>
  <is_versionable>0</is_versionable>
  <Relationships>
    <Item type="Property" action="add">
      <name>applies_to_property</name>
      <data_type>item</data_type>
      <source_id>Property</source_id>
    </Item>
    <Item type="Property" action="add">
      <name>granted_group</name>
      <data_type>item</data_type>
      <source_id>Identity</source_id>
    </Item>
    <Item type="Property" action="add">
      <name>permission_type</name>
      <data_type>list</data_type>
      <data_source>read|write</data_source>
    </Item>
  </Relationships>
</Item>

Step 2: Extend Property Definitions

Add a relationship to PropertyPermission items on the standard Property ItemType:

<Item type="Property" action="merge" where="name='permission_rules'">
  <source_id>Property</source_id>
  <data_type>relationship</data_type>
  <related_id>
    <Item type="RelationshipType">
      <name>PropertyPermissionRules</name>
      <relationship_id>PropertyPermission</relationship_id>
    </Item>
  </related_id>
</Item>

Step 3: Implement Server-Side Validation

Create a server method that checks permissions before property access:

function checkPropertyPermission(itemId, propertyName, permissionType) {
    var property = aras.getItemProperty(itemId, propertyName);
    var permissionRules = property.getItemsByXPath("//Relationships/Item[@type='PropertyPermission']");
    
    var userGroups = aras.getUserIdentities();
    var hasPermission = false;
    
    for (var i = 0; i < permissionRules.getItemCount(); i++) {
        var rule = permissionRules.getItemByIndex(i);
        var requiredGroup = rule.getProperty("granted_group");
        var permission = rule.getProperty("permission_type");
        
        if (userGroups.indexOf(requiredGroup) !== -1 && 
            permission === permissionType) {
            hasPermission = true;
            break;
        }
    }
    
    return hasPermission || aras.isSuperUser();
}

Implementation Considerations

1. Performance Impact: Cache permission rules where possible
2. Administration: Create UI forms for managing property permissions
3. Testing: Verify enforcement works across all access methods (AML, REST, UI)
4. Documentation: Train administrators on the new permission model

Conclusion

By extending Aras Innovator’s permission system to the property level, organizations can achieve much finer-grained security controls that align with their operational requirements. This solution maintains Aras’ flexibility while adding critical security capabilities for complex engineering environments.

For production implementations, consider:

• Adding permission inheritance rules
• Creating bulk permission management tools
• Integrating with existing identity providers