• State Not Answered
  • Replies 1 reply
  • Subscribers 13 subscribers
  • Views 2520 views
  • Users 0 members are here
Options
Related

Edit relationships outside the regular lifecycle - best practice tips?

AngelaIp
Hi, I have a few relationships that shall be editable outside the normal Part lifecycle from certain groups of the company. In our system, e.g. Parts can be added, edited and deleted by Identity Component Engineering. Members of this group have the permissions to get and change most of the data. But there are some properties, that shall not be set by this group. A simple example is maybe the 'Part Goal' relationship. Let´s assume only Purchasing shall have the unique right to change the Part_Goals when ever they want. Changes in the Goals shall be able outside the normal Part lifecycle, without changes in the Part revision. I deactivated the "Use Src Access" setting in Part Goal and assigned a custom Permission item. With this permission, Component Engineering has Get permission for the goals, but only Purchasing can update them. Problems that arise: - Goals cannot be added by Component Engineers, as they only have "get" permission. This leads to problems, when Parts are duplicated with Save As, as Aras will also try to copy the goals - Goals can be edited, but not added or deleted by Purchasing, as this would require a change of the Part. I have around 6 Relationships that shall be editable from various groups outside the normal lifecycle. Right now I use a veritable cornucopia of various Methods and Actions to handle these special use cases. Also I am not happy with them. I often directly manipulate relationships and have to use a lot of validation Methods to prevent unwanted writing to the db. Does anybody face a similar use case? Maybe there is a simpler solution possible for this use cases as my current one. Thanks! Angela
Parents
  • 0
    Some update: One additonal problem occures when versioning the Item. Here Component Engineering also needs the add access to add the new relationship. Lock and Unlock also needs special handling, as in my example the costs shall be completly separated from the Part. Null-relationships are not intended to support this behaviour. It really requires a lot of Methods to handle all possibly situations than can occur. But maybe I found the ultimate best solution: Federated relationship inside the Aras db. 1. Create a new Itemtype (e.g. MyGoals) for storing the costs. 2. This new ItemType must contain the same properties like Part Goal. So we have to add properties for "source_id", "actual_value", ... 3. Add an onGet Method in Part Goal that takes the values from MyGoals This way we can achieve a hard separation of Parts and Costs. Both can be added and edited separately. We can use complete different permissions models, without getting into trouble when version or copy an Item. I really like this soluton! But I would be happy to hear any second opinion when it comes to this use case.
Reply
  • 0
    Some update: One additonal problem occures when versioning the Item. Here Component Engineering also needs the add access to add the new relationship. Lock and Unlock also needs special handling, as in my example the costs shall be completly separated from the Part. Null-relationships are not intended to support this behaviour. It really requires a lot of Methods to handle all possibly situations than can occur. But maybe I found the ultimate best solution: Federated relationship inside the Aras db. 1. Create a new Itemtype (e.g. MyGoals) for storing the costs. 2. This new ItemType must contain the same properties like Part Goal. So we have to add properties for "source_id", "actual_value", ... 3. Add an onGet Method in Part Goal that takes the values from MyGoals This way we can achieve a hard separation of Parts and Costs. Both can be added and edited separately. We can use complete different permissions models, without getting into trouble when version or copy an Item. I really like this soluton! But I would be happy to hear any second opinion when it comes to this use case.
Children
No Data

Copyright © 2025 Aras. All rights reserved.