[stable31] fix(sharing): Allow reasonable control for 'Hide download' on fed shares #56178
Conversation
|
@nfebe customer is asking about that, is there anything blocking the merge into 31 ? |
We have a large CI with hundreds of PRs and backports going on at once. Very often, jobs fail even though the failures are not related to the main PR this requires manual re-runs and follow up. There are also merge freezes which blocks PRs from being merged by non-admins. This PR is affected by both of those issues. (Merge freeze, flaky CI) If PR a is urgent then it has to be flagged to be given special attention also it is okay to re-run jobs and help request for force merges from those who can do it when you have an interest in the PR. This can help get the PRs through much faster. |
|
in any case, the fix has been tested and validated this morning on stable 31.0.11 |
nfebe
force-pushed
the
backport/55251/stable31
branch
from
eff66cd to
fe75d87
Compare
When creating public links from federated shares, users should be able to set the 'Hide download' option independently as long as they are more restrictive than the original share permissions. Previously, the `checkInheritedAttributes` method was ignoring user preferences and always overriding the hideDownload setting based solely on inherited permissions, preventing users from disabling downloads even when the parent share allowed them. This fix implements some sort of inheritance logic: - Users can only be MORE restrictive than parent shares, never LESS restrictive - If parent hides downloads -> child MUST hide downloads (enforced) - If parent allows downloads -> child can CHOOSE to hide or allow downloads - If parent forbids downloads entirely -> child cannot enable downloads Signed-off-by: nfebe <[email protected]>
nfebe
force-pushed
the
backport/55251/stable31
branch
from
fe75d87 to
8725129
Compare
Backport of PR #55251