workflow permissions are not applied to all users

Do the other internal suppliers have user accounts?  Do you have any other permissions being applied to the object (e.g. via metadata-driven-permissions, e.g. from the class?

Hi Craig, apologies for not responding before, I was on annual leave.  The other accounts have M-Files accounts and there are no other special permissions from the class.  It appears like, it reads one of the supplier internal contacts, applies the permissions and then it stops reading the other ones.

And these are tied together as per the ACL configuration (e.g. the document points to the internal supplier contact object for each of these which points to the user?

There shouldn't be a way for it to only take one of them into account and not others.  These things can be difficult to diagnose asynchronously via a forum though.  We'll try.  Let's go through some points:

• What you should do is start at the object itself (e.g. the document in your screenshot).
• The effective permissions (the list on your screenshot) on an object are a combination of the ACL on the object itself (what you see when you click on the permissions in the lower-left) and any automatic components.
• If you have metadata-driven permissions then the user must exist in *all* of the components (automatic and custom) to be effective.
• When looking at the ACL on the object look at the "path" from the current object.  It'll say something like "Internal Supplier Contact.M-Files User".  This means that the document must have an "Internal Supplier Contact" property, and the object(s) it points to must have "M-Files User" properties.  If any/all of that isn't the case for one of the contacts (e.g. the users are invalid) then they won't work.

Hi Craig, 

I am using a workflow to apply custom permissions.  The class, "Contract" does not have any special permission settings.  See screenshots below

The class has the property "Internal Supplier Contact" that is a list of all our users

In the workflow, at the stage were the Contract sets the workflow state to Active, these permissions are applied:

If the object in question has three people listed as "Internal Supplier Contract" why is it that only Sarah Staite is displayed as having edit rights.   The workflow also sets the Hubshare account as having edit rights and those permissions are working fine.

As far as I know I am not using an ACL

The ACL ("access control list") is simply what you've shown in the final screenshot (the "permissions").  I think the confusion here is around "NACL" (a "named access control list") which is what is shown in the upper part of that final screenshot; you're right that you don't seem to be using one.

Can you check one of the other People objects (e.g. Doreen Gravestock) to see whether it's associated with an active user account?

Hi Craig, thanks for the clarification.  Doreen's account is active.  This is her person card (what we call our users)

Here is the card for Sarah Staite, is not different

Thanks for helping me with this

Do both Sarah and Doreen's "Person card" have a property called "User Account" and is it set to their respective users?

Yes, they do.

In that case I am running out of ideas via the forum.

There is some reason why these permissions aren't effective.  It's either to do with the path to the user record from the ACL on the object, or it's to do with the users themselves.

My next step, honestly, would be to say it's worth getting someone to sit and work through this logically with you.  If you have a services agreement with us then maybe getting someone to spend 30m on a Teams call will solve you a lot of headache.

I don't like giving that answer, but I am running out of ideas to do this remotely.

Thanks Craig.  I personally think it is a bug.  I will create a support ticket.

I guess it could be.  Metadata-driven permissions are a core part of our product and I'm not aware of anyone reporting odd issues like this at the moment, so I'd be surprised, but it could be.

Certainly - in support of the bug hypothesis - I'm struggling to think of more questions to ask to drill into what's going on.

I guess it could be.  Metadata-driven permissions are a core part of our product and I'm not aware of anyone reporting odd issues like this at the moment, so I'd be surprised, but it could be.

Certainly - in support of the bug hypothesis - I'm struggling to think of more questions to ask to drill into what's going on.