Forum Discussion
6 Replies
- Former Member[deleted]
- SuhasIdeator I
Hello
, Is this post is related to DAC Policies?
Regards,
Suhas
- gdelabrouIdeator I
Hello,
Yes, you can insert in your Query Definition (QD) used by the DAC, an additional step after your current Item (i.e Part) with a Join Condition like part.config_id = part_1.config.id.
Thus, the QD will extract all the revisions of the Part. You can then map Part_1 in order to give access to all the Item Revision.
Moreover, if you want to filter them out (i.e only the Released Part), you just add also a Where Condition such as Part_1.Released = '1'
Hope this helps. - ScriptSet6Ideator I
The AI App I'm workig on returns the following. Is it useful, ? Any feedback welcome.
Your observation that you can only see the latest version (is_current=1) of an item in the "Versions" menu when it's shared via DAC policies is likely related to how permissions, particularly Discretionary Access Control (DAC) implemented through Private Permissions, interact with item versioning and life cycle states.
Here's a breakdown drawing from the sources:
- Versioning and the "Versions" Menu:
- Versionable Items in Aras Innovator keep a history of changes by storing a new generation each time a change is saved after claiming. Items in the Product Engineering application are versionable.
- When a versionable Item reaches the Released state, further changes require creating a new revision, which typically starts in the Preliminary state.
- The "Item versions" dialog is the standard feature designed to display all versions of an Item. You can access this dialog via the "Navigate" menu on the Item toolbar or by right-clicking the Item in the Search Grid and selecting "Navigate → Versions".
- Previous versions of Items viewed through this dialog are read-only.
- There are client-side methods to get all versions (getItemAllVersions) and the last version (getItemLastVersion). The property is_current=1 is standard for the latest version.
- Permissions and Access Control (including DAC):
- Permissions define access rights for users or groups (Identities). Key rights include Get (to retrieve items for viewing), Update (to edit), Delete (to delete), and Can Discover (to search).
- Permissions are assigned to an ItemType to provide default security for all items of that type, and they can also be assigned to Life Cycle states to change security over an Item's existence.
- Private Permissions (DAC) can be set specifically for a given Item, overriding its current Item Permission. This is how you "share" a specific item with users who wouldn't normally have access via ItemType or Life Cycle permissions. An Identity needs the "Can Change Access" grant on the Item's current Permission to create Private Permissions. The Item Creator and Assigned Creator have this right by default.
- To create a Private Permission for an Item, you open the Item in edit mode, and use the "More → Permissions → Create Private" action. A new Private Permission is created, initially pre-populated with grants from the default Permission. You can then add Identities and set their specific access rights (Get, Update, etc.) using the Access accordion on the Private Permission view. Once the Private Permission is saved and assigned to the Item, it takes control of access rights to that Item.
- Access rights are enforced when querying or retrieving data. Query results are limited by the User's standard "Get" permissions. Restricted properties (without "Get" permission) are not returned.
- Why You Might Only See the Latest Version via DAC:
- The "Versions" dialog works by retrieving all versions of a specific Item instance (identified by its config_id).
- Each version exists in a specific Life Cycle State (e.g., Preliminary, Released, Superseded, Obsolete). Standard permissions are tied to these states.
- When you apply a Private Permission to an Item, it's applied to that specific instance of the Item (the one with the particular config_id). While this Private Permission overrides the Item's current permission, the sources do not explicitly state that a Private Permission automatically grants access rights to all previous versions of that item, particularly if those previous versions are in states for which the user's Identity doesn't have "Get" permissions according to the original (non-private) Life Cycle state permissions.
- Your observation suggests that the Private Permission, as configured, might only be granting "Get" access for the Life Cycle State(s) that the latest version is currently in, or perhaps that the underlying query for the "Versions" dialog defaults to only showing versions for which the user explicitly has permission via the DAC policy.
- How to Give Access to All Versions via DAC:
- To ensure an end user can see all versions of an item through the "Versions" menu after setting a Private Permission, the Private Permission itself needs to explicitly grant the user's Identity "Get" access to all the relevant Life Cycle States that the item's versions might be in (Preliminary, Released, Superseded, Obsolete, etc.).
- When you create or edit the Private Permission for the Item, you must add the user's Identity (or a group they belong to) and ensure the "Get" checkbox is selected for them. The Private Permission dialog allows configuring these access rights. While the image provided shows setting Get/Update/Delete/etc. rights per Identity, the full configuration would likely involve ensuring these rights apply correctly across the relevant Life Cycle States of the Item's versions.
- By default, the Private Permission is pre-populated with grants from the default Permission. If the default permission structure ties Get access to specific Life Cycle states (which is common), the Private Permission needs to replicate or extend these grants for the user's Identity to cover the states of all versions you want them to see.
- In summary, the administrator configuring the Private Permission must ensure that the Identity receiving access has the "Get" permission explicitly granted within that Private Permission for all the Life Cycle states where the various versions of the item reside. Setting the Private Permission on the latest version does not automatically grant access to older versions if the permission configuration or life cycle state permissions prevent it.
To recap: The "Versions" dialog is designed to show all versions. The limitation you're seeing is likely due to the Private Permission (DAC) applied to the item not granting sufficient "Get" access to the Life Cycle States of the older versions. The solution involves editing the Private Permission to grant "Get" access for the user's Identity across the relevant Life Cycle states.
- PaulwoodIdeator I
To show all versions of an item shared via DAC policies, you need to change the filtering or querying logic. Instead of only retrieving the version where is_current=1, you need to retrieve all versions associated with that item, regardless of their is_current status. The application or system displaying the data needs to be modified to present these multiple versions to the end user through the version menu. papa's games
- PaulwoodIdeator I
thank you