Examples of rules to control access to incremental changes

Learn how to control access to incremental changes in Teamcenter using examples. You can place the In IC Context rule at the top level of the rule tree as follows: Copy Has Bypass In IC Context (true) → IC ACL Has Status Has Object In this example, if there is an active incremental change and the operation performed by the user is tracked by incremental change, the In IC Context rule applies and its associated named ACL applies to objects affected by the operation. However, if there is no active incremental change, the subsequent rules apply. You typically use this rule to relax a restriction, such as only allowing edits to a released structure for a specific status. For example: Copy Has Status () → Vault Has Status (Pre-Released) → () (No ACL) In IC Context (true) → Incremental Change Access In addition, the user requires write access to the incremental change itself.

Note There is no mechanism of enforcing that an incremental change is used when making structure edits. You can also configure the In IC Context access rule as follows to allow write access to released structures at a specified status. This allows incremental change to track changes at prereleased stages of the structure (BOM view revision). Copy Has Status () → Vault Has Status (Pending IC) → Incremental Change Access (or Working) Has Status (Pre-Released) → () (No ACL) In IC Context (true) → Incremental Change Access (or Working) The purpose of these rules follows: Has Status ()→Vault This standard rule ensures released parts cannot be modified. Has Status (Pending IC)→Incremental Change Access (or Working) This rule allows you to apply a status of Pending IC to an incremental change so that you can apply effectivity. This allows changes to be configured for the incremental change. However, designers still require write access to the incremental change to add changes. It may be sufficient to use the general working access control list (ACL). Alternatively, you may want to restrict editing of incremental changes to certain roles, in which case you should use a different ACL (for example, Incremental Change Access). When an incremental change is finally released (for example with Released status), it can no longer be modified due to the Has Status ()→Vault rule. Has Status (Pre-Released) In IC Context (true)→ Incremental Change Access (or Working) These rules ensure that when a status of Pre-Released is applied to an item revision, changes can only be made to the structure or the item revision with an incremental change. Prior to this, there is no status and the structure or item revision (attachments) can be edited by any user with suitable access permissions. When an item revision and the BOM view revision are finally released, for example, with a Released status, the structure can no longer be modified due to the Has Status ()→Vault rule.