flat federated re-share #24603

schiessle · 2016-05-12T14:35:16Z

This PR introduces flat federated re-shares. This means that if userA@serverA share a file with userB@serverB and userB decided to reshare the file with userC@serverC the share will be created directly between userA and userC. Still both userA and userB will see the share and will be able to manipulate it, unshare it etc.

This should be a nice performance boost for federated re-shares. Because now everyone is directly connected to the source of the file instead of going through multiple ownClouds.

Further this brings the same behavior we already have for internal shares to federated shares.

reshare gets created directly by the owner
unshare from self gets propagated to both the owner and the initiator of the share
unshare form the owner/initiator gets propagated to the recipient and the initiator/owner
notification says "you received fileX from userA@serverA on behalf of userB@serverB" so that you know who shared the file with you
propagate permission changes
fall-back for federated re-shares with older ownClouds
adjust unit tests

mention-bot · 2016-05-12T14:35:18Z

By analyzing the blame information on this pull request, we identified @nickvergessen, @icewind1991 and @LukasReschke to be potential reviewers

schiessle · 2016-05-17T13:06:14Z

This pull request is feature complete. Please start to test it and review it... Ignore the failing tests for now. I will fix them.

Basically you can test every cracy re-share activity of federated shares you can think of 😉

Also enable the activity and notification app to check their output.

cc @PVince81 @nickvergessen @rullzer

rperezb · 2016-05-18T12:58:55Z

@SergioBertolinSG can you please create a issue on the qa repo so that we track the qa process for thix, thx

rullzer · 2016-05-18T13:19:55Z

AWESOME stuff @schiesbn!
Looks good so far. Will have more in depth look later!

SergioBertolinSG · 2016-05-19T12:13:28Z

A question, is this expected or not?:
steps (in all the steps the fed shares are accepted):

Having three servers, A, B and C with three users, userA, userB and userC each.
userA shares a file to userB and userB to userC.
userB deletes the file. (userC is still seeing the share).
userA shares again the same file with userB.
userB shares again that file with userC.

Observed: userC has now the file twice, second one with (2). Shouldn't him have only one file?

SergioBertolinSG · 2016-05-19T12:30:06Z

Having a middle server with an old version makes shares not flat. Is this ok? Only flat shares when all server involved have this patch?

schiessle · 2016-05-19T12:42:21Z

Having a middle server with an old version makes shares not flat. Is this ok? Only flat shares when all server involved have this patch?

Yes, for old servers (or servers who also implement federated shares but not the flat re-shares) we fall back to the old behavior.

schiessle · 2016-05-19T12:45:00Z

Having three servers, A, B and C with three users, userA, userB and userC each.

userA shares a file to userB and userB to userC.

userB deletes the file. (userC is still seeing the share).

correct, because the file is still shared from userA to userC. Same as for local re-shares.

userA shares again the same file with userB.

userB shares again that file with userC.

This should probably fail because the file is already with userC... I will have a look

SergioBertolinSG · 2016-05-19T12:50:53Z

A problem found:

steps (in all the steps the fed shares are accepted):

Having three servers, A, B and C with three users, userA, userB and userC each.
userA shares a file to userB and userB to userC.
userB unshares the file (click on the trashbin in sharing list.
Using userB refresh browser, in the sidebar click on sharing.

Observed: File is still appears as shared (but it was unshared, it doesn't appear in server C).

schiessle · 2016-05-19T13:50:07Z

userA shares again the same file with userB.
userB shares again that file with userC.

This should probably fail because the file is already with userC... I will have a look

Should be fixed now.

schiessle · 2016-05-19T15:28:14Z

Observed: File is still appears as shared (but it was unshared, it doesn't appear in server C).

should be fixed... @SergioBertolinSG please re-try, thanks!

SergioBertolinSG · 2016-05-20T09:08:43Z

userA shares again the same file with userB.
userB shares again that file with userC.
This should probably fail because the file is already with userC... I will have a look
Should be fixed now.

I'm seeing the same behaviour, file added again with (2).

SergioBertolinSG · 2016-05-20T09:14:56Z

Observed: File is still appears as shared (but it was unshared, it doesn't appear in server C).
should be fixed... @SergioBertolinSG please re-try, thanks!

Still happening, userB unshares, but it comes back to the list.

schiessle · 2016-05-20T09:21:33Z

I'm seeing the same behaviour, file added again with (2).

Just tried it again and can no longer re-produce it. Are you sure that you updated all three servers to the latest version of this branch? The last commit should be c8c213a

This is how it looks for me if userB tries to share the file again with userC:

SergioBertolinSG · 2016-05-20T09:28:09Z

Yes, three servers are in the last commit. Do they need to be fresh installations?

schiessle · 2016-05-20T09:28:50Z

Yes, three servers are in the last commit. Do they need to be fresh installations?

I would try to make sure that no broken db entries or something similar is in the way

schiessle · 2016-05-20T09:29:42Z

Still happening, userB unshares, but it comes back to the list.

I can reproduce it... Will look into it. Seems that I misunderstood your steps yesterday and fixed something different 😉

SergioBertolinSG · 2016-05-20T11:50:59Z

Mm not sure why it failed last time. After retesting it works fine. ✅

SergioBertolinSG · 2016-05-20T11:54:20Z

I've found another problem.

Having two servers, A and B with two users, userA and userB each.
userA shares a file to userB.
userB accepts the share and shares it back with userA.
userA accepts the share.

Observed: File is not detected as the same file. It is duplicated.

schiessle · 2016-05-20T12:17:18Z

Having two servers, A and B with two users, userA and userB each.

userA shares a file to userB.

userB accepts the share and shares it back with userA.

userA accepts the share.

Observed: File is not detected as the same file. It is duplicated.

fixed, please try again... Thanks!

SergioBertolinSG · 2016-05-20T12:40:47Z

Works now 👍

schiessle · 2016-05-20T12:48:38Z

PVince81 · 2016-05-20T12:51:02Z

We already went through the code together yesterday, so I only reviewed the additional commits. All looks good 👍

PVince81 · 2016-05-20T12:51:16Z

@schiesbn ah, can you rebase and solve the conflicts ?

schiessle · 2016-05-20T12:55:06Z

rebased, but I didn't had any merge conflicts...

PVince81 · 2016-05-20T12:58:32Z

Yeah, local git is sometimes more clever/efficient than Github. Probably Github is more cautious.

…request correctly accross share owner and share initiator

in case of federated re-shares the owner can be a remote user. Therefore we can't always use to owner to access the local file

…'t support flat-reshares

… app

…share from self

lock · 2019-08-05T20:01:55Z

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

schiessle added 2 - Developing feature:federated-cloud-sharing labels May 12, 2016

schiessle added this to the 9.1-current milestone May 12, 2016

schiessle force-pushed the federated_reshare branch 2 times, most recently from 83ebc1f to c21ad0a Compare May 17, 2016 10:22

schiessle added 3 - To Review and removed 2 - Developing labels May 17, 2016

schiessle force-pushed the federated_reshare branch 2 times, most recently from 30a1bc7 to 77f2775 Compare May 18, 2016 12:09

SergioBertolinSG mentioned this pull request May 18, 2016

Test improvements in federated sharing. owncloud/QA#238

Closed

schiessle force-pushed the federated_reshare branch from 7cd1c75 to c0b416c Compare May 18, 2016 14:31

schiessle force-pushed the federated_reshare branch from c0b416c to f339729 Compare May 19, 2016 12:39

schiessle force-pushed the federated_reshare branch from ad1f1a7 to 5c38b45 Compare May 19, 2016 13:49

schiessle force-pushed the federated_reshare branch from 752b6a1 to ca47555 Compare May 20, 2016 12:54

Björn Schießle added 11 commits May 20, 2016 21:15

move request handler for federated shares to the federated sharing app

5a1641b

use query builder for getShare and add tests

8f87e11

create re-share by owner and propagate unshare and unshare-from self …

d23df4c

…request correctly accross share owner and share initiator

close cursor after select to avoid db lock

81e3787

use share initiator as fall back to access the file

7b25839

in case of federated re-shares the owner can be a remote user. Therefore we can't always use to owner to access the local file

update share permissions

2dc26aa

fall back to old re-sharing behaviour in case the remote server doesn…

92fa0c7

…'t support flat-reshares

move motifier from the files_sharing app to the federatedfilessharing…

e25fbaf

… app

improved error messages

06b6e2b

add missung return value

bc8f659

remove reshares and the mapping in the federated_reshares table on un…

20852fd

…share from self

schiessle force-pushed the federated_reshare branch from ca47555 to 20852fd Compare May 20, 2016 19:15

schiessle added 4 - To release and removed 3 - To Review labels May 23, 2016

PVince81 merged commit 5ba1add into master May 23, 2016

PVince81 deleted the federated_reshare branch May 23, 2016 07:52

PVince81 mentioned this pull request Aug 15, 2016

Federated reshare regression on single server #25807

Closed

PVince81 mentioned this pull request Oct 10, 2016

Federation resharing concept ideas #16601

Closed

lock bot locked as resolved and limited conversation to collaborators Aug 5, 2019

flat federated re-share #24603

flat federated re-share #24603

Uh oh!

Conversation

schiessle commented May 12, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mention-bot commented May 12, 2016

Uh oh!

schiessle commented May 17, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rperezb commented May 18, 2016

Uh oh!

rullzer commented May 18, 2016

Uh oh!

SergioBertolinSG commented May 19, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

SergioBertolinSG commented May 19, 2016

Uh oh!

schiessle commented May 19, 2016

Uh oh!

schiessle commented May 19, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

SergioBertolinSG commented May 19, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

schiessle commented May 19, 2016

Uh oh!

schiessle commented May 19, 2016

Uh oh!

SergioBertolinSG commented May 20, 2016

Uh oh!

SergioBertolinSG commented May 20, 2016

Uh oh!

schiessle commented May 20, 2016

Uh oh!

SergioBertolinSG commented May 20, 2016

Uh oh!

schiessle commented May 20, 2016

Uh oh!

schiessle commented May 20, 2016

Uh oh!

SergioBertolinSG commented May 20, 2016

Uh oh!

SergioBertolinSG commented May 20, 2016

Uh oh!

schiessle commented May 20, 2016

Uh oh!

SergioBertolinSG commented May 20, 2016

Uh oh!

schiessle commented May 20, 2016

Uh oh!

PVince81 commented May 20, 2016

Uh oh!

PVince81 commented May 20, 2016

Uh oh!

schiessle commented May 20, 2016

Uh oh!

PVince81 commented May 20, 2016

Uh oh!

lock bot commented Aug 5, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

schiessle commented May 12, 2016 •

edited

Loading

schiessle commented May 17, 2016 •

edited

Loading

SergioBertolinSG commented May 19, 2016 •

edited

Loading

schiessle commented May 19, 2016 •

edited

Loading

SergioBertolinSG commented May 19, 2016 •

edited

Loading