feat: add option to resolve inherited option per-user instead of per-path

[icewind1991]

Instead of always have subfolder rules overwrite parent folder rules, first resolve the inherited rules for each user/group before combining the rules from the different users/groups.

With the default behavior, if any rule applicable to the user denies permission for a subfolder, the permission will be denied, even if the user is member of a group that has "allow" permissions.

With the new behavior, if any group the user is a member for has "allow" permissions, the user has access.

To test:

1. create groups group1 and group2
2. create user test in group1 and group2
3. create groupfolder gf accessible to group1 and group2 an ACLs enabled
4. create folder gf/a and create a rule on it for group1 giving full permissions
5. create folder gf/a/b and create a rule on it for group2, denying read permissions
6. with default behavior user won't have access to gf/a/b because of the rule from 5.
7. change to the new behavior with occ config:app:set groupfolders acl-inherit-per-user --value true
8. now user does have access to gf/a/b because group1 has access, users only in group2 won't have access

[artonge]

Can you confirm that the goal is to have a switch to toggle between:

1. Restrict down the user based on the rules
2. Give as many permissions to the user based on the rules.

[icewind1991]

Can you confirm that the goal is to have a switch to toggle between:

1. Restrict down the user based on the rules

2. Give as many permissions to the user based on the rules.

The difference is more complex than that.

The changes in how rules are inherited/merged will lead to more permissions in some setups but it's dependent on the specifics of the configured rules.

The main difference is that, with the new setup, if you're member of one group which has access to a folder and member of a group which has access blocked you will always have access.
With the previous setup whether or not you had access will depend on which "level" of folder the rules for the groups were configured on.

[artonge]

Approving to get it merged, but I would like to properly understand the logic:

Considering the following hierarchy: /a/b

Without inheritMergePerUser (old): merge(b/g1, b/g2)->apply(merge(a/g1, a/g2))
With inheritMergePerUser (new): merge(b/g1->apply(a/g1), b/g2->apply(a/g2))?

applyPermissions: if the rule does not have a value for a permission, use the provided one
mergeRules: do an "or" with both permissions set

Folder	Read	Update	Share	Delete
a/g1	1	1	1	1
a/g2	-	-	-	-
b/g1	-	-	-	-
b/g2	0	-	-	-
b/u1 (old)	0	1	1	1
b/u1 (new)	1	1	1	1

If that's correct, then perfect :).
Do you think it would make sense to add a comment with the above?

[icewind1991]

Yes, I've added a comment, please let me know if that explanation is clear enough

[icewind1991]

/backport to stable28

[icewind1991]

/backport to stable27

[icewind1991]

/backport to stable26

[fschrempf]

It looks like this would solve or at least affect a few open issues (#2812, #1212, #598, etc.). Are there any plans to reference this new feature there to let people know and maybe also have this mentioned in the README?