Hi all,
we are using Seafile CE Version 7.1.5
I resynced a shared library that had syncing issues. As this caused unwanted conflicts, I wanted to reset the library to the revision before. As written in the article below, this should work by visiting the history, selecting a revision and clicking “restore”. This does not seem to be possible in 7.1.5. The only possibility is to Restore (sub)folders and files, which causes them to be restored as <OriginalName (1)>, so the folder is there twice. What happened to the revision restore?
History revision I wanted to go back to: No “Restore” Button
One reason for the absence of the “Restore” button may be a custom css that does not work properly for your version of Seafile. Have you upgrade to 7.1.5 and forgot adjusting your css?
Alternatively, have you checked the browser console or checked the server logs?
Hi @rdb, thanks for the quick answer!
I might have forgotten the css update after the last minor update. Let me check css & logs, will report back here.
The current css is from datamate for version CE 7.1.4. I completely disabled custom css, still the same.
The library is not mine, it’s share to a group where I have read-write access. I shared a test-lib to the group - seems that only the lib owner can restore snapshots, regardless of share permissions given.
Is this by design/written somewhere?
— edit / edited title
as a reverted revision also appears in the history, nothing can be broken by reverting. All people with read-write access should be able to revert revisions
I disagree. The is a distinction betweeen read-write and admin permissions.
The owner has, obviously, admin permissions for a library. Another user posses admin permissions only when the library is shared with admin permissions.
The admin permission level exists in Seafile Professional. It does not exist in Seafile CE.
Thanks for the link, this cleared up the permission scheme for me as a “non-pro user”.
What I understand is that someone with read-write premissions should not have the power to share the lib to other people/groups.
But: restoring a history version is something that’s not breaking anything (b/c the history revision is threated as a new commit in the history. So the restoring itself is reversible).
In my opinion restoring falls in the read-write category rather than admin. I also don’t want to give people library admin rights just to enable them to restore history snapshots
Hi Leo,
I hear you. I don’t agree 100% though. Restoring a snapshot is not necessarily reversible. Imagine a user restores a snapshot and then empties the trash bin. Then gone are all the snapshots.
Sure, you can also prevent users from emptying the trash bin.
I think there is no solution that satisfies everybody. It is the way it is.
Glad we could solve your problem. (Please mark as solved.)
