What @Michael_Ruhnke has described is correct. However, all workflow ACLs persist from when they are set to either the end of the workflow or until another ACL is set. Good practice is to to set the write access ACL and then on the task after this set another ACL that sets simple read access for a user or group. For example, owning user or world read access.
Never add any rule directly in the "In Job(true)"-branch of the rule tree!
Workflow ACL must be added to desired tasks within the workflow designer only.
Ok... But at workflow ACL I can't use Has Type or something like that, right?
So your suggestion is put the others objects at References and let with Targets only what I want to grant access... that's it?
@Michael_Ruhnke I wouldnt say never add to main rule tree... There are scenarios where this is necessary...
@mundim Workflow ACLs are the usual place to control access in a workflow, rather than the main rule tree. Shuffle your attachments from Target to Reference using condition task with -reference option, or depending on what version of TC you have you can use the handler epm-move-attached-objects.
The downside of workflow ACL is that it only applies to Targets, so when you move objects to the references folder they are no longer flagged as being In Process, so if they are WIP they can be put into other workflows or modfified as per the access granted in the main rule tree. A workaround is to apply a temporary status to objects when entering the workflow, and then applying an ACL in the main rule tree for that status.
Well, I think that's part correct and part incorrect. This is based on my understanding (I have not verified it)
InJob(true) branch is simply a place holder. This is the location where Workflow ACL (applied using ootb handler) is evaluated
If you add any entries under this branch, then those entries will not be evaluated.