Access Denied - Change Permissions required with User from Metadata

This is by design. The user needs the "Change permissions" rights to be able to perform any operation that affects the permissions of the object. This applies to both modifying them via the Permissions dialog or modifying a metadata value that is used in the object's access control lists.

Is there a way to formally disagree with this design.  If a class has properties that drive metadata, then an Admin created the class that way and people with edit access should be able to change property values - and let the admin decide what happens when those properties are changed.  The way it is now, I have to let someone be able to change the NACL to whatever they want just so they can add a user to a property that gives that other user read access.  That doesn't make sense to me.

As far as I know this is how M-Files has always worked so this design has been in the platform 10+ years. Someone more familiar with the origins of the permission model should comment on why it was decided that it should work like this. We can certainly record ideas on how to enhance the platform in the future, it seems there is already an improvement idea (ID 127025) on allowing metadata-based permission changes separately from the manual permission changes. I've added your company details to this request.

You can accommodate your requirements in the current design if I understand them. For example, you can have a Property "Security Owner" as a multi-list on Users. Then also have a NACL that grants the users in this metadata property "Change Permissions" (as well as Write to modify the property). When you are creating the first version of a document the Owner has full control so they can populate the Security Owner property with values. After the document is saved then assuming the automatic permissions are applied (not using Simple permissions) then the document will become locked down and only the users in the Security Owners property will be able to save versions where the Security Owners metadata field has been modified. I tried some basic tests and this seems to work. We use metadata driven properties to allow users to add and remove access as an easier way for them to understand permissions, but we don't want anyone with Write access to be able to alter the properties hence only some users with both the Write AND the Change Permissons access can make updates to the objects when those fields are changed.

You can accommodate your requirements in the current design if I understand them. For example, you can have a Property "Security Owner" as a multi-list on Users. Then also have a NACL that grants the users in this metadata property "Change Permissions" (as well as Write to modify the property). When you are creating the first version of a document the Owner has full control so they can populate the Security Owner property with values. After the document is saved then assuming the automatic permissions are applied (not using Simple permissions) then the document will become locked down and only the users in the Security Owners property will be able to save versions where the Security Owners metadata field has been modified. I tried some basic tests and this seems to work. We use metadata driven properties to allow users to add and remove access as an easier way for them to understand permissions, but we don't want anyone with Write access to be able to alter the properties hence only some users with both the Write AND the Change Permissons access can make updates to the objects when those fields are changed.