How does the permission system work on database level?
Hi Community, In Innovator, we can use permissions to specify which users are allowed to view, edit, or delete an item. I have a federated item type with a custom onGet method. Since SQL federation with onGet bypasses the standard permission system, any restrictions have to be implemented within the SQL query itself. I am wondering whether it is possible to customize my federation solution to support the existing permission framework. In my case, I would like to use the built-in identities such as "Creator", "Owner", and "Manager" to provide a more "natural and consistent permission experience". This leads to the question: How does Innovator actually enforce permissions? In the end, all regular data comes from SQL tables, so Aras must be applying some kind of security logic at the database level. I did some research and discovered the following: In SQL Server, there are "secured" versions of the regular tables that combine the underlying data with the results of the innovator.EvaluatePermissions function. My theory is that when a user requests data (for example, "Show me Parts"), the data is not retrieved directly from the innovator.Part table, but rather through the secured.Part function. Has anyone ever tried to replicate this mechanism in the context of federation? Any tips or ideas? Angela
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?
MAC Policy Issue in ARAS 31 – Need Help with Access Restrictions
Hi all, I’m working on implementing access restrictions for the a Itemtype in ARAS 31. There are around 46 records, and I want to group them into 5 categories. Each category will be assigned to specific identities, allowing controlled access based on the record's classification. To achieve this, I started configuring MAC policies. However, I’ve run into a few issues: The fields I need are disabled in the MAC Policy Condition Editor. User-defined properties are not accessible in the condition editor either. Has anyone faced similar challenges or found a workaround for this? Any help or guidance would be greatly appreciated! Thanks, Salini
Use Src Access on regular item type?
Hello Forums, I have a regular item type that is parent to some other regular item types. I.e. we have Item A that has a relationship to Item AB, and Item AB has a relationship to BB. A, AB, and BB are all regular items. I want A's permissions to cascade onto anything below, but it seems that 'Use Src Access' only goes as far as A to Ab (the relationship item), as opposed to also placing A's permissions onto AB. Can 'Use Src Access' reach AB and BB? Best Regards, Frank
Change permission for "view item" option(right click menu) of Documents under Operations
Under Process Plan(mpp_processPlans) --> Operations(mpp_operations) --> documents Some of these documents under an operation are "invalidated". The documents are assigned "invalidated" status from Document-->Part when the "valid" option is changed to "No"(screenshot below). The user has the ability to right click on the any of the documents and select "view item" (picture below) to open the document container (screenshot below). I need this "view item" functionality to work for a certain identity when the document is "invalid" Currently, if the document is "invalid" user can't open it from here but the document opens if one searched for it manually. I can't figure out where does this "view item" option come from and where and how was this right-click menu even generated. Can someone point me in the right direction, please. Thanks!changing permissions for existing Items (Documents)
We've a classification of Documents that we've setup to have a special set of permissions. We used the solution presented in the following topic to achieve that: SUPPORT Q&A - Permission based on Class Structure However, before we made this adjustment for the classification of documents, some documents we're already created. These documents still have the generic permissions set. Is there a way to change the permissions of these existing documents in such a way that they have the same permissions as any new document created under that classification?
