The M-Files Community will be updated on Tuesday, April 2, 2024 at 10:00 AM EST / 2:00 PM GMT and the update is expected to last for several hours. The site will be unavailable during this time.

This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Access Denied - Change Permissions required with User from Metadata

Dear all,

We've noticed that when we're using "User from Metadata" to give that specific user some permissions, if this metadata is changed, the other users need to have the "Change Permissions"  Allowed otherwise they get an access denied error message.

Is that a normal behaviour ? We find that kinda weird, because we want to give them the rights to change a M-Files user through the Metadata card but deny them to change all the objects permissions. 

Thanks for your replies
Claudio

  • That message appears when there are permissions being handled using metadata card properties. It is to notify the users that the permissions are changing and it is a possibility that they may lose access. I did find it to be a bit annoying as well, and users found it confusing. Luckily there is a setting to disable that additional dialog from the admin client, if you want to . Here is a screen shot of where you can find that setting under the vault configurations:

  • Thanks for your reply, however you might have misunderstood the "Error Message".
    I was not talking about the Warning message but more about an "Access Denied Error Message"



    The problem we're having is if you don't give the "Change Permissions" to a user or a group, they don't have the permission to change specfic property. 

    Here goes an explicit example :

    We have a Project property in a report object.
    The report's accessible with r/w permissions by the mentioned project's technician only.
    Alice is trying to change the Project Prop in the metadata card of the report.
    If Alice doesn't have "Change Permissions", she can't change the project and save the modifications.

    Hope it's clearer now.

  • Hi,

    Floating this as we have the same issue. We want to have documents with a "Document Owner" property (choose from People objects linked to user accounts) and use pseudo-permissions so that the document owner can edit and delete the document, while others can only view. But the owner should also be able to assign ownership to someone else, which means granting the new owner additional permissions and removing some from the original owner.

    M-Files sees this as a permissions change and blocks it. However we don't want to give everyone "Change Permissions" rights, as that allows them to undo many other permission settings.

  • This makes sense as your project property is driving permission on specific report object (using pseudo users or metadata-based security). In that case, your user effectively change permission on report when he/she assign new project. For that project's technician must have change permission rights.

    We have similar case with drafters who need to add/remove certain approvers who are used to be assigned to have permissions on documents, so if drafter change approvers he/she effectively provides access to different users. For this change permissions rights are needed.

  • 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.