File Permissions

Hi.

This sounds like a job for metadata-driven permissions and user groups. Using this approach would mean that the new user simply gets added to one or more user groups and they automatically get access to everything they need. 

I recall from previous posts that you are not engaged with your reseller. That is unfortunate, as your reseller should be best placed to consult with you about what you want to achieve and the best way to structure M-Files to achieve it. You would probably save yourself a lot of stress by being guided by a good consultant. 

That said, there is documentation on our user guide about how tk configure metadata driven permissions. What you effectively do is configure that certain elements of metadata (e.g. the object class) force a set of permissions onto the object; simply by selecting that this is an "HR Document", the document is automatically hidden from most users. 

You use this approach to build a set of permissions for each type of object in the vault. 

Regards,

Craig 

Dear Craig

Thanks for the response. The problem is that these are not department specific documents. These documents are random minutes of the meeting, presentations, some user guides and manuals, contracts and bunch of other stuff. Currently they are in a folder structure in windows. They want to migrate to M-Files with same folder permissions. For eg each minute of the meeting has a different user and it does not come from a user group. Hence making the minutes of the meeting object would make no sense as each meeting has different members. 

Thank you 

Hi YST,

The permissions can be driven directly from the metadata.

So, for example, you add your "Meeting Minutes" to the vault, supply metadata for the type of meeting it was and the people who were there, and then use that to drive the effective permissions on the object.

Regards,

Craig.

Dear Craig

Let say for eg, the class is meeting minutes and I add a property definition called "Type". This Type will be a text field, in which the user will type the meeting type. and then based on this type you want me to set the permission. Have I just confused you

Because I really confused right now

Hi YST,

I don't believe that a forum is the best place for this sort of discussion.  It's very difficult to get across what's possible and what's not via this sort of medium.

In general terms: metadata-driven permissions are driven from lookup-style properties, not text.  So you would choose "Meeting type" from a dropdown box and, depending on that, you add one layer of permissions (e.g. "Board meetings can only be seen by user group X).  You may also have an "attendee" dropdown where the user can select who was at the meeting, and use this to add another layer of permissions (e.g. "All employees who were at the meeting can see it, as can their managers").  Using this metadata-driven approach you can design a set of permissions that are applied automatically simply by describing the document, not by the user having to remember to save data in a specific location.

Note: you can still have a view that mimics that old location and, when items are created/dropped in it, will automatically apply the metadata you need.

We do have some pages on our user guide (M-Files User Guide (m-files.com)) and also via our Vimeo videos (M-Files Intelligent Information (vimeo.com)), but these are fairly simple in context and likely won't model exactly what you need.

If you need to go through this in significant detail then I strongly suggest that you reach out to your M-Files Reseller to discuss how best you can be supported.  If your Reseller cannot support you then please do let me know and I can speak to the Channel Account Manager for your region and ask them what other options are available.

Regards,

Craig.

Much appreciated Craig for the time taken to reply. I will try out what you have mentioned. But I do believe that M-Files should also include inheriting permissions like windows as an option. You might be able to drag in more customers that way. That being said this is just my feedback.  

Hi YST,

The core issue is that M-Files is not based on locations in the same way as other systems; there is nothing to "inherit" from in the same context.  One object may be surfaced in multiple views depending upon metadata and view configuration.

If you can switch your mental model across to the M-Files one then there is huge value to it, but it does operate fundamentally differently to a folder structure.  This is, honestly, one of the ways in which your reseller should be helping you.

Regards,

Craig.

Hi YST,

The core issue is that M-Files is not based on locations in the same way as other systems; there is nothing to "inherit" from in the same context.  One object may be surfaced in multiple views depending upon metadata and view configuration.

If you can switch your mental model across to the M-Files one then there is huge value to it, but it does operate fundamentally differently to a folder structure.  This is, honestly, one of the ways in which your reseller should be helping you.

Regards,

Craig.