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
xClassification Insufficient permissions
I have created xClasssifications with set of xProperties and linked them to Part ItemType. When I tried to added xClassifications it give's an error as below " You have insufficient permissions to perform 'classify' operation for item id '29F57869D3E348FA92AB855F6A029EFE' by xClass id 'F1D35D96534B47BAB447134E6C309CC5'. "
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
Feature licenses error when activate
We are using a stand-alone server currently until we get ARAS fully stood up, then we will go live. We received the feature license keys and went to activate feature key but we keep receiving the pictured error below. It also pops up upon entering our database. Has anyone seen the below error before?
