Forum Discussion

bryan-riley's avatar
bryan-riley
Creator II
1 month ago

Extending Permissions to Item Properties

Has anyone successfully extended permissions to the item property level? 

I need to configure property‑level permissions in Aras Innovator so that modification and visibility of specific properties on an ItemType are controlled by user identity, beyond the standard item‑level permission and lifecycle security.

This cannot be a purely UI/visual restriction (e.g., hiding fields via Forms or client‑side methods only). It must be enforced as a true permission/authorization control so that users cannot modify restricted properties using AML, REST, external integrations, or custom clients.

Example Situation:

Starting with 3 ‘Property Permission’  sets, one for Electrical, Software, and Mechanical

Each Permission Set has 4 identities, one for Mechanical Engineers, Electrical Engineers, Software Engineers, and Non-Engineers. The permissions allow all of the engineers to Discover / get, but only one engineering group can update, and non-engineers have no access. 

 

Then modifying the 'Property' itemtype to have a lookup property to permissions

And creating an ItemType called ‘PropertyPermissionItemType’ with 3 properties 'owned' by the different engineering groups, linked to the previously created permissions

And the idea is that these property Level permissions would determine who could view and update these properties. 

It seems like theres a basic structure for it, but what would have to be done to actually implement the permissions at this level? 

6 Replies

  • Support filed a feature request for it, suggested UI-based restrictions using Javascript methods on the form to modify the visible/readonly form item options 

  • I haven't tried this myself, but have you considered an onvalueget method on the property to evaluate the permission you have in mind based on the property?

    • bryan-riley's avatar
      bryan-riley
      Creator II

      Seems like a really insightful idea. No idea how to execute that, I'll think on it. Thanks 

  • We have some of this configured in our solution, but it is quite difficult to manage within the Aras client. To achieve the stated requirements, you would need a few pieces:
    - Get/Discover: Implement a required method onAfterGet that removes the property value if the user cannot get/discover the property.
    - Update: This is the trickiest. In Innovator (even with xclass properties) you must have edit permission for the whole item in order to lock/update the item. We have implemented this, but do so by replacing 'update' calls to a custom method that performs the property-specific permissions checks, and escalates internally to allow edit.
    - Delete: You didn't mention delete, and I am not sure how that would apply, but that may not be applicable in this case. If it was, you would need to enforce that in a method onBeforeUpdate to prevent setting to null(??)

    Once the server-side is figured out, you would need to implement the same in the client forms and grids for the best user experience.

  • I didn´t have much time the past weeks, but I remember I have seen something like this presented at ACE 2019 or 2020 

    https://github.com/ArasLabs/lc-based-props-and-fields

    Or maybe this one?

    https://github.com/ArasLabs/property-advanced-validation

    There was also a TechTip back then with property based permission (Edit: It doesn´t fit the usecase).

     

    Based on Kentonvks input: Why not use an "onBeforeGet" (!!!!) Method that manipulates the SELECT attribute to only return the data where the user is in the correct identity group?

     

     

  • Saw at Ace '26 it looks like 'Edge API' would allow this level of control, but it would be outside of the Aras Interface

    and require an extra line item