Folder Security Group permissions broken

[CraigNicholson]

Since upgrading from 4.1.2 to 4.1.4 I've noticed the following change in how folder security works, I think its a bug.

User X is a member of group G1 and group G2.
Group G1 has R access to folder F.
Group G2 has RCA access to folder F.

Previously user X would have the rights RCA. All of a sudden user X now only has R access. It seems like the rights are being AND'd not OR'd.

Is this a bug and if it is, when will it be fixed?

[CraigNicholson]

I've been exploring the problem a bit more and noticed that inherited folders are in effect.

User X is a member of group G1 and group G2.
Folder F2 is under folder F1.
Group G1 has R access to folder F2 (direct assignment).
Group G2 has RCA access to folder F1 (inherited assignment).

To workaround the issue I had to manually assigned group G2 to folder F1 with RCA access through direct assignment.

I still believe this is a bug though as access rights should be inherited correctly.

[Beth]

There's one caveat with what you described. I have a number of users who have a department that is only supposed to have access to one folder. Let's say it's QA. They would then deny QA access to $ and then give them only access to the $/QA folder. If inheritance could override, then they could never have access to $/QA unless the admin instead denied all items at the same level as $/QA so that $/QA had nothing it could potentially inherit. Also, that could be a lot of folders to have to configure.

You can do the same with just an individual. Directly assigned rights override inherited rights. That's by design.

I could take a feature request to give you an option to have inherited rights override directly assigned rights. Just let me know.

[CraigNicholson]

Logically I would directly assign the QA group rights to folder $/QA and there would be no reason to deny rights to anyone else unless you've assigned everyone rights to $/, which is illogical in the folder security enabled repository.

My question then is, when did this "by design" get implemented as it wasn't present in 2.0.6 through 4.1.2?

[Beth]

I'm sure that the explicit assignment has always overridden inherited. The one thing that changed is that an admin could set up default access to be Access or No Access. If the default is Access, then to prevent a user from seeing all but one folder takes removing that user's rights at $ and explicitly assigning them.

Rights aren't cumulative in this case. Removing a right in Vault has about the same effect as using a deny in Windows.

Again, I can always take a feature request to make the ability for inheritance to take precedence an option that an admin could change.