-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Alice can't restore files that Bob moved out of shared folder #24053
Comments
@MTRichards Could you please tell us if it works as the design? The only log I got in the server (Tested in 8.2.2 too):
|
What should happen is that Bob moves the folder or renames it, but Alice's files remain the same. This allows bob to organize the shared files wherever he wants, while Alice keeps the view she wants. What actually happens to Alice's files? Does Bob still have access? Can Bob edit the files? @janborchardt for ux to make certain I got that correct. |
@MTRichards Bob has edit permission of the share and moves only the subfolder, not the share itself. If Bob moved this subfolder outside the share (to account root for example), they are no longer available for Alice. Bob now can access those files. They are somewhere in his account, but not accessible for Alice. |
Ouch, ok. So Bob basically takes over those files and Alice loses them. But they were Alice's files...this is not ideal. This should not happen, or be allowed, or if allowed the link to Alice's files should be kept as we do with root shares. @jancborchardt your ux on what should happen here? |
Basically we should treat it similar to a deletion. Moving the files out should show as a activity and should be reversible for anyone having write access to the share. Most of the time it will probably have a reason (like a deletion), but sometimes it might be an error. |
While I understand, wouldn't a user dragging files around and having them deleted be confusing? Since that is what happened here, perhaps I am overthinking it. If we add the undo, how do we know? Is it just an undo in activity, or somewhere else? |
From the original sharers point of view, there is no difference between moving and deletion. So from their POV it should probably be in their trash for them to restore. And yes, a change action in Activity with the ability to restore. The other route is that we flat out restrict moving, but that would not make any sense since the sharee can also delete the files. It would be completely arbitrary. |
Ok, so a feature request to enhance the activity stream with an undo, and to put the files into the owners trash can as well as the person that moved it? Or all trash cans? |
The feature is way before activities or anything. |
I suspect this touches core sharing code, so while a higher priority it needs proper planning and qa. |
yes |
It's a cross storage move. That means a deletion in the one storage and a creation in another storage. cc @icewind1991 for the storage details. Maybe we could go into that direction. |
Nice use case. The sharing code actually does what we ask from it. A file is moved from storage We would need to keep track of moves in the trashbin. And if we move from a sharedStorage to also add the files in the trash of the owner. But we should really think and discuss how to do this. As this could get messy really quick.For example what happens if the recipient moves the files back? How do we handle versions? and all that. |
This should also apply if Bob is deleted by the administrator. It would make life much easier because it wouldn't make sharing a hell (analogous to the dependency hell) for the admin if he has to remove a user with loads of shared files. Also Alice wouldn't be in for a bad and nasty surprise if the shared files are suddenly gone. Restoring single files is extremely difficult if not outright impossible if encryption without recovery key is turned on and one has to rely on methods used to restore files encrypted by a cryptolocker to get them back. This shouldn't be something that a professional business grade software should do at any time! |
I think we should tee this up for design week, because it is unlikely to be fixed prior to 9.2 given the amount of thinking and impact on core. |
Let's make a feature request out of 00005262 with this. |
@MTRichards (another person) asked some similar as a feature request in 00005283. IMO I think that folders under the share should be kept as part of the share. The owner (Bob in this case) should be informed that a folder tried to be moved or removed and he has the possibility to recover it. And/or the other shared user (Alice in this case) that the folder can be moved only in inside the share or copied as a fork in another directory. |
All good input for a discussion. When we plan 9.2 we will need to normalize them and decide on a course of action. |
I'm not sure about how hard can it be the implementation: Any share (main folder (SharedwithBob) in this case) can be moved to different folder and can even be renamed. Could be the same behavior (moved and renamed) be followed for the sub-folders from the share? (Folder1 and Folder2) |
Well sometimes a move is a add, delete and move at the same time. So yes, that is really not that easy. |
@MTRichards design week sounds like a good idea! |
@nickvergessen probably vectoring the shares 😄 |
@MTRichards A solution that could be backported would be much appreciated. |
First question, backported to what version(s)? Still, earliest for both is 9.2. |
@michaelstingl this doesn't seem to represent the "restore a lost share" feature request? |
|
does it also appears in the activities? |
for federated shares, the activity will say "the file X was deleted" because the federated server doesn't know it was moved out since it received a DELETE command... Might need more special handling, passing hints to that server so it can detect it. |
The basic POC for rename activity seems to work without big blockers so far owncloud/activity#558. However I'm struggling with the formatter and there are many additional conditions that need to be checked against. I'm not sure there is enough time to finish this for 10.0. Additionally we'll need some special handling for the trashbin. Basically: if trashbin is enabled, don't say "moved out" but say "moved out and look at your trash the file is backed up there". Doing this without big hacks might be tough. |
Don't think there is a need for this special message. "moved out and look at your trash the file is backed up there" when a delete happens its no different. And yes, when somebody moves the file back and its restored we have it twice I think users will be able to handle this. |
@jochenwezel Great thought, but should be an app outside of core, IMHO. |
Still struggling with the PR. Writing a unit test for this case revealed a few potential bugs hidden in the platform code. It's the kind of bug that is not easy to fix because some other code might be relying on it returning the wrong value. (the "two bugs cancel each other" kind) |
@PVince81 This sounds difficult and to the same time it sounds as you are on the right way 👍 |
Yeah. Sometimes work takes much longer than originally expected due to these kind of findings. I hope I can iron all this out for 10.0 |
After a long and painful struggle with glitches in the architecture, the PR was finally merge: #27042 Enjoy your new (partial) feature: backup is now created. What's still missing: generating an activity. This is still WIP. |
Tested and works in 10.0 Alpha. |
not sure how important the activity is, setting to triage |
I see that there might be some more high priorities for 10.0 and to deliver 10.0 soon. |
Any ETA of a fix on this issue? |
@CorneelDragon which part of the issue ? The main part is already fixed in 10.0.3. |
okay, just saw it was still open en scrolled down, my bad. I will verify it on our test 10.0.x-environment. Thanks for the quick response! |
Raised #29473 for the remaining tasks as the main thing is done. |
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. |
Steps to reproduce
Expected behaviour
Alice expects a way to restore.
Actual behaviour
Server configuration
ownCloud version: (see ownCloud admin page)
9.0.1
Updated from an older ownCloud or fresh install:
fresh install
Signing status (ownCloud 9.0 and above):
Client configuration
Browser:
Chrome 50
Operating system:
Mac OS X 10.11.4
@MorrisJobke
00005262
The text was updated successfully, but these errors were encountered: