Open butonic opened 2 years ago
cc @micbar @aduffeck @pmaier1 This is what we are seeing. I hope the steps are clear. For OCIS we agreed to implement this properly, as in auto accepting subsequent shares on the same resource for the same recipient.
@phil-davis this is related to https://github.com/owncloud/core/issues/38851 AFAICT
It seems strange the Alice would share folder
with Brian read-only, then make another read-write share of folder
with Brian.
IMO Alice would edit the existing share to Brian and add write permission.
For each resource that Alice has, she should only be able to share the resource once to each sharee (user or group).
But maybe that restriction causes problems if Alice wants to give the extra write permission to Brian only for a specified time-period. In that case, Alice shares the resource read-only to Brian with no expiration. Then Alice also shares the resource read-write to Brian with an expiration date. Brian should see a single view of the resource, and lose write access after the expiration date. I Anyway, Alice could share read-only to Brian, and read-write to "Group1", at different times. If Brian is a member of "Group1", and Brian has already accepted the first read-only share from Alice, then "something reasonable" has to happen when Brian "suddenly" gains an extra way of seeing the resources from Alice. "something reasonable" is probably that it "just happens" and Brian does not have to accept the "new share", and it works even if Brian had renamed the original share.
The test expectations have been adjusted a bit in #39917
Expected:
Actual:
After demo creates the second share User admin has to accept the new share before he can write to
/foo from demo
Furthermore, when he accepts the new share, the mount point is renamed to
/foo
(/foo from demo
no longer exists)Finally, if admin declines the new share the original share is declined as well and
/foo
vanishes.Explanation
There is a mixup between resource based and share based share management: when demo creates the two shares before admin accepts either of them, the accept action actually accepts both shares. The concept here is resource based sharing. That is the reason why the 'list shares with me' UI only shows a single entry (in oc10 classic). AFAICT ocis web not merging two shares for the same resource is a bug.
When the user has accepted (aka mounted) a resource any subsequent shares on the same resource for the same recipient should be effective immediately. No additional accept needed, no additional mounting needed.
In contrast to a resource based share management share based share management would allow creating two distinct mount points for the two shares. One would be read only, the other would be read write. They would have different names and the desktop client would duplicate the resources. This is undesired, as it causes confusion for end users, which is why the classic ui merges all shares for the same resource into one.
AFAICT we need to fix the above corner cases to properly have resource based share management in ownCloud 10 and OCIS.