Try arranging your Add Attachments task so that the EPM-set-rule-based-protection is on Start, and the PS-attach-assembly-components is on Complete.
Make sure that your ACL is granting change to whoever is running the workflow.
I tried it as you said and sending to an another user where the accessor was the system administrator and made the ACL changes as per that, but i still get the same error.
But I did try another way of changing the ownership where I add the change ownership handler to the Complete action of the Perform Signoffs subtask of the Review task and it works perfectly for the entire structure. But this is not what i am looking for though.
I created a workflow to mimic your example;
On the Add Attachments task I set an ACL to grant Change access to the responsible party;
And for handlers I have the following on Start (by assigning the ACL);
Then the following 3 handlers on Complete to add the assembly children, their Items, and their BOMViews.
You will probably have different objects depending on your use case;
Then on the Change Ownership task I set an ACL to grant Change Ownership to the responsible party.
The the handlers on the task have the following on Start;
Then the actual change of ownership on Complete;
When I run this workflow on an assembly that is fully owned by a normal user (including children) then it works, and changes the ownership correctly on the specified objects.
If however the assembly (or I guess any of its children, or attached objects) is owned by infodba then I get the following error;
This is because of the following entries in the Access Manager rule tree;
This is explicitly denying Change and Change Ownership permission to general users (World) for objects that are owned by infodba. These are considered system objects, and the rules are there for a good reason.
This is why you shouldn't have real product data owned by infodba.
So to end a fairly long post the workflow should work where objects are owned by a normal user, but if you have objects owned by infodba then you are probably going to have the sort of access problem you are seeing.
Thanks a lot for the very detailed description and I understand the error, but i was wondering as to how it works when I use the workflow with the review task. Does it bypass the access when I assign the signoff user.
There could be a few reasons depending on the exact setup.
When a user completes the review task the workflow is then running as that user, and the handlers will run with their privileges. If this user has the necessary privileges to perform the action by virtue of who they are then they may complete without error.
To attach to the target you need to have change privileges. The Workflow ACL works only on the objects in the target. So you need to define the change privileges in the ruletree instead as a wfl ACL