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

Metadata card configuration: Filter option using permission settings

Some properties should be hidded within metadata card configuration. That works fine and it is possible to hide properties in the initial phase of a document by selecting a special workflow state as filter.

In some use cases it would make sense to hide e.g. special financial information from users except of financial department. This is only possible by hiding the property value generally - but then the property is still visible with "value not available" message but not hidden.

Idea: Add a filter option specifying a NACL where all with read rights see the property and set it hidden for the others. The same with editable,

Also: Add an option that the property should be hidden if the user has no permission for viewing the value.

Parents
  • I think that this is possible right now with the permissions of the metadata properties. I am attaching here a few basic screenshots I just made from a simple test. This "hiding" can apply to the entire metadata property, not just to certain values, so that the user without access won't see that property at all. In this situation they won't see it in the filter settings either - effectively the user without rights will not even know this property exists.
  • That's what I've meant by

    "In some use cases it would make sense to hide e.g. special financial information from users except of financial department. This is only possible by hiding the property value generally - but then the property is still visible with "value not available" message but not hidden." ...

  • I'd say from security point of view, using permissions on the field itself in m-files admin is the best option, as it ensures that everyone who reads that object will have the permissions evaluated properly.

    Using metadata card customizations to hide or validate values is something I would strongly advise against, because it can be circumvented by the client and they can still see the data or submit unexpected data. This is also noted in the user guide and in the customization settings document.

    That said, you can control the visibility of items in a Value List in a very granular manner. If you have the metadata property to prevent desired users from editing, they can't change its value which is a good step 1. The next step can be to set the permissions of individual items in the value list it points to so that the restricted users can't see them. Then they will see "(hidden)" in place of the actual value.

    I can see how that can be limiting, though (it takes effort to set up, and cannot work for free input like texts or numbers, but only for value lists). So, I would think that a new feature might, indeed, suit your needs, something like a third row of settings in the property definition - in addition to "edit" and "see" the property, a new setting like "can see the value of the property" is what I feel like you want to have. With the expected result like hiding a value list item from the user - so they'd see "(hidden)". Am I understanding you correctly? If yes, what is the behavior you expect from such a field when the user puts it in a filter? Since they can see it, they can filter by it, but that means that the server needs to compare the field values with the actual object data, and now that the user does not have permissions for that, this can result in confusing UX or even errors. Or, worse, it can 1) expose sensitive information (such as value lists) and 2) cause serious performance issues.

Reply
  • I'd say from security point of view, using permissions on the field itself in m-files admin is the best option, as it ensures that everyone who reads that object will have the permissions evaluated properly.

    Using metadata card customizations to hide or validate values is something I would strongly advise against, because it can be circumvented by the client and they can still see the data or submit unexpected data. This is also noted in the user guide and in the customization settings document.

    That said, you can control the visibility of items in a Value List in a very granular manner. If you have the metadata property to prevent desired users from editing, they can't change its value which is a good step 1. The next step can be to set the permissions of individual items in the value list it points to so that the restricted users can't see them. Then they will see "(hidden)" in place of the actual value.

    I can see how that can be limiting, though (it takes effort to set up, and cannot work for free input like texts or numbers, but only for value lists). So, I would think that a new feature might, indeed, suit your needs, something like a third row of settings in the property definition - in addition to "edit" and "see" the property, a new setting like "can see the value of the property" is what I feel like you want to have. With the expected result like hiding a value list item from the user - so they'd see "(hidden)". Am I understanding you correctly? If yes, what is the behavior you expect from such a field when the user puts it in a filter? Since they can see it, they can filter by it, but that means that the server needs to compare the field values with the actual object data, and now that the user does not have permissions for that, this can result in confusing UX or even errors. Or, worse, it can 1) expose sensitive information (such as value lists) and 2) cause serious performance issues.

Children
  • Ok you are right - from security view it is safe. That's the same with readonly properties where you have to ensure it on server-side in addition to the metadatacard settings to be sure that no one ships around it.

    But for UA-criteria it should be also possible to hide the property in addition to the security settings. Would be good to have this as a new feature in future. Hiding properties is not only because of security reasons but also for focussing people on a set of fields they have to input.

    Btw. thank you for your good advises. They are also very helpful. My wishes are only meant in addition to it.

  • For focusing the users, I'd suggest the "Is Hidden" option for the metadata card customization, in case security is not the issue. It is easier to setup than permissions, and still lets them use it for filtering.

    Another approach would be to put that property in a group that is initially collapsed, but still available (e.g., something like "Non-essential settings" or "Additional data" or something that suits the desired UX).

    I've shown this thread to product management as well so they can review the idea and concept and gauge whether and how it could fit the product. If it makes it in the product, it will be in the release notes.

  • Ok, I guess now we have all aspects :)