In a regular development life-cycle case-tree, stages, steps, etc. are developed before Access Manager settings.
For example, we have a Parent-case and one Child-case. Child-case can be instantiated somehow, by smart-shape on the flow or automatically - it does not matter. Security context will be "current requestor".
When we use "Calculation" feature in the Parent-case in order to colect information from Child-cases, autogenerated DeclareTrigger for Child-case will be used. Security context for this DeclareTrigger will be "current requestor" of the Child-case. The same security context is used when we try to propagate some data to the Parent-case procedurally.
All things will works fine. But now we need to restrict an access to Child-case for operator who creates Parent-case. For example, Parent-case is the "Loan" and it can be created/processed by operator with "User Role", Child-case is the "Underwriting" and it can be processed by operator with "Underwriter Role". Operator without "Underwriter Role" should do not have an access to "Underwriting" case. Operator without "User Role" should do not have an access to "Loan" case.
So, we use Access Manager to set "no access" for corresponding roles against Open/Modify of corresponding case type. After that operator with "User Role" only cannot start "Loan" case, because "AthorizationException.createCannotOpenException" You are not authorized to open instance ...". Root cause is clear - Access Manager.
What should I do? Add some operations to change the security context before sub-case instantiation - looks strange.
The same is actual when we will try to propagate data to Parent-case under "Underwriter Role" security context.
Create Separate Access of Role to Object (ARO) Rule Instances for Each Case Type Class and then use Access When Rules to fine tune the desired permissions and Privileges. Be sure to associate each Access of Role to Object (ARO) to the Access Role Name referenced by the Access Group.
In that case Access When Rule should have some logic around current user operation. It should allow to Open/Modify corresponding case type class when WorkObject is created, but should disallow Open/Modify after that. It is difficult to implement.
Example with "Calculaton" feature is more complex. DeclareTrigger is defined in the Child-case type class. It runs implicitly. Is it possible to determine current action in run-time (I mean user 'click' to Parent-case in UI VS data propagation to Parent-case by DeclareTrigger)?