Options
  • State Verified Answer
  • Locked Locked
  • Replies 4 replies
  • Subscribers 7 subscribers
  • Views 905 views
  • Users 0 members are here
Related
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

Help with permission settings

Dominik

Hi,

I've been administrating our M-Files server for over a year now and thanks to it I usually set any permissions needed pretty easily. This time though, I can't seem to find the solution. Let me explain.

We have some private documents in a class that contains mainly (99,9%) public documents. This class was made for public documents, but it was the first class configured by our team and it was not really made with private documents in mind, so for those private docs specifically they set up permissions by hand on them. Fast forward to today, I am trying to improve this for the private documents to be private automatically, and not by hand, because users create them on a monthly/yearly basis. The idea is to make a lookup property on that class that would contain values "private" and "public". If public, then nothing happens (I did not set up any NACL permissions to that value), and if private, it gives the class one more NACL that specifies the group of people that can see the document. The group is taken from a property on that class and it's structure looks like this: GroupProp (MultiSelectLookup) > UserGroupProp (MultiSelectLookup containing employees) > EachEmployee (containing M-Files user).

Now my issues are these. I have:
- made the new NACL permission
- assigned the new NACL to the "private" value of a new property
- checked the "enable automatic permissions via this property" on the new property (and on all other properties like "GroupProp", "UserGroupProp", etc., even though I know this is not necessary)
- checked if other permissions work properly on the object that needs this NACL
- restarted M-Files, restarted computer, tried looking at the permissions on another computer, didn't restart the vault yet
- maybe some other things too

Here are some screenshots of the settings and how they look:

All users in M-Files:

All users + the new NACL group:



It says the there is nothing to take the permissions from:

But that doesn't make sense, because one of these displayed paths has to be correct. There is no other possible combination between "Skupina pro seznámení" (GroupProp) and "Uživatel M-Files" (M-Files user)



Sorry for the long post, I wanted to provide as much information about the problem as I could. Help would be much appreciated. I already spent about 3 hours on this problem trying many different solutions, but to no avail. Of course I am probably doing something wrong here, but I just need some guidance on what it is.

Thank you in advance for any idea.

Best regards
Dominik

Parents
  • 0

    The settings look fine to me on a quick review. The Skupina pro seznámení property is on the document metadata, right? Is it possible that you have two property definitions with the same name in the vault and your NACL is referencing a wrong property currently? This could be any of the three properties in the NACL reference (Skupina pro seznámení, Seznam zaměstnanců, Uživatel M-Files).

    Note that with this kind of a configuration whenever the list of employees is modified on any of the group objects, the permissions need to be recalculated for all documents which are referencing that group. If there are a lot of private documents referencing a lot of groups and there are frequent changes to those group memberships, the recalculations might start causing issues especially as the vault grows. It's recommended to refer to user groups in the NACLs whenever possible, so if you can find a solution where these users would be managed in M-Files user groups instead of employee lists in a property, that would be recommended to avoid problems in the future. See the tip in the user guide.

  • +1 in reply to Joonas Linkola

    Short answer: Hi, I didn't check in the object before looking at permissions, thanks for your time!

    Long answer:

    Hello Joonas,

    thank you for your reply. 5 minutes after reading your reply I have figured out the solution to my problem haha. Although it actually had nothing to do with what you mentioned in your reply, it gave me an idea, which turned out to be correct.

    Skupina pro seznámení property was on the document metadata, there was no second property named the same as any of the three mentioned properties and the settings were actually fine too, I didn't set them up wrong. What was wrong though was thinking that I can see the permissions before I even check in the document... Sweat smile 

    I always just changed the property in metadata dictating the permissions, then straight away looked at the permissions and saw that it didn't work. Only today have I actually checked in the document and of course it worked immediately. Tbh I don't really know why the permissions aren't seen before checking in, because everything else indicates that the permissions changed right away... Like this popup here, which pops up before check in:

    "Permissions of the object have changed due to the changes of object's metadata."

    Also just a note, thank you for your note about the recalculations. These groups are modified very very rarely and not that many documents use them. They are used mainly for generating tasks for users, and not for permissions, but this was somewhat of an exception. We know about this functionality and I always check "background tasks" in MF Admin when waiting for any permissions to apply, to know when they fully applied.

    Anyway, thank you again for your guidance and I wish you a nice day!

    Regards,
    Dominik

  • 0 in reply to Dominik

    Glad to hear it's working, it's often something simple like that for me too! Wink As you noticed, the permissions are calculated on the server so you cannot see them fully before the document has been checked in. The client can detect that there are automatic permissions in play already before check in but doesn't yet know who will have access for the metadata-based permissions.

  • 0 in reply to Joonas Linkola

    Ahhh, I seeee, thanks for clarification!

Reply Children
No Data




              

© M-Files Corporation 2024 | Privacy Policy