Access control default ignoring specifics

[Peter Clough]

I have a node at the end of my workflows for access control. It sets the default action state to Locked, and then specifies Lock Link as No.

However, when the workflow runs, Link is being locked anyway. The info text on Default Lock Type specifically says that lock states on specific actions override the default, so I have to presume this is a fault. Please could this be confirmed, or am I doing something wrong? It shouldn't require two access control nodes in a row, I would have thought.

[Gareth Cantrell]

I've found this as well. The individual items don't actually override the default lock type.

In my case, I've resorted to adding a secondary node to lock or unlock specific items, after using the "default lock type" in the first node, in the hopes that one day it will be fixed and I can remove the 2nd node

[Berto2002]

Is it perhaps that the individual locks are inverted depending on the default lock type selected? e.g.:

Default Lock: Yes and Link Lock: Yes means link lock is NOT on because 'yes' overrides to the opposite of the default?

[Peter Clough]

An interesting idea, it would be pretty funny.

I've just tested this though, and it seems that is not the case, it still locks everything.

I'd guess it's an order-of-operations error, where it sets the default after the specifics or something. Only ways to correct would be to either add a follow-up node, as Gareth does, or to manually set everything to lock except the Link, which seems like a really unfun time.

[Gareth Cantrell]

@Peter Clough before the "default lock type" was introduced, I used to have each item manually toggled in the single automation; the only issue I had was getting cross-eyed trying to tell the "yes's" and "no's" apart.

Having the 2nd node (until the issue is fixed) makes it a little easier to see whats happening, for me at least.

[Peter Clough]

100%, it's at least readable that way.