Folder permission inheritance - Vault 2015

[cvdcage]

Hi,

We're using Vault 2015 (not SP1 installed yet). Is it as designed that newly created folders that are created in a folder that has permissions set are not inheritting the permissions of the parent folder?

If it is working as designed, is there a way to automate this?

Kind regards,

Christiaan

[minkd]

Which "tier" of Vault are you using (Vault Basic, Vault Workgroup, or Vault Professional)?

If Vault Workgroup or Vault Professional, are the folders being created with a category which is applying a lifecycle, whose default state is setting an ACL?

-Dave

[cvdcage]

Hi Dave,

thanks for the response. We are using Vault 2015 Professional.

We have no category's for our folders. We do use categories for files but they don't have any security restrictions set on the files.

Kind regards,

Christiaan

[cvdcage]

I am shamelessy bumping this post. Would really like an answer from an Autodesk official. 🙂

[minkd]

All folders in Vault Workgroup and Vault Professional have categories. So I assume that in your case the category is the default "Folder" category.

As long as the Category does not have a Lifecycle Definition whose default state has an ACL, the created folder should inherit the ACL from the parent.

I just created a "Test" folder with the default Folder category under $, set it's security so that Administrators can read/write/delete and Everyone can read; and then created a "SubTest" folder with the default Folder category under the "Test" folder.  When I look at the security on the SubTest folder I see that the Administrator can read/write/delete and Everyone can Read - so it has inherited the security from the parent.

Select one your problematic folders and see what values it has for Category, Lifecycle Definition and State in the Property Grid. In my test above, the Category is "Folder", and the Lifecycle Definition and State are blank.

If you are getting different behavior, all I can suggest is opening a case with Product Support.

-Dave

[cvdcage]

Hi Dave,

Thanks! I've tested it on our test environment and can see that it is possible when we choose for "Object-based security" setting instead of "System or iverridden security".

Can you please explain the differences between those?

Thanks!

Christiaan

[minkd]

The security override is used by lifecycle to take over (override) the security as well as to revert back to the original security (remove the override) when the lifecycles state does not specify an ACL.  For example changing to a "Released" state may add a security override so that the file is readonly to most users, while changing to a "WIP" state may remove that security override.

The security override also allows an Administrator change the security for a specific entity when necessary. For example, even an Administrator cannot delete a file if the ACL would prevent the deletion. Instead the Administrator must first give themselves permission to do the delete by overridding the security on the file.

A search for "security" in the help will find a number of topics related to ACLs.

-Dave

[cvdcage]

Hi Dave,

Thanks, but what I mean is the difference between these 2 options on he security mode tab:

thanks!

Christiaan

[minkd]

That dialog is either setting an override or not.  See previous post for what is meant by override.  The role-based security option is to remove the override.

-Dave