The feature is planed to be added in 6.1. We’ve finished some work.
You will have a new “invisible” permission along side the current read-only and write permissions. You can set this permission to a sub-folder under a shared folder, for a person or a group. The person or group cannot see this sub-folder, but other files or sub-folders are unaffected.
I have a use case where a certain group should only access a subset of the libraries top-level folders.
Is it possible to share a library “invisible”/inaccessible and grant explicit access to some folders?
Maybe it would be a good idea to call it “inaccessible”.
On sharing a library you select the default-behaviour for folder permssions in that “share”. e.g inaccessible, read, read-write. Then I would be able to set read or read-write to certain folders, since default is inaccessible. It is not a problem if everyone sees those folders, they should just be inaccessible.
Completely hiding those folders would possibly also cause confusion. The standard paradigm in this case is to see inaccessible folders and present a message of “missing” access permissions. Therefore someone could request access.
I could vote for this solution, except that some users may be confused of seeing a folder they do not have access to and may complain about it ("tell my why i don’t have the right to access this ??!!!)
Imagine this: Another team member tells you the path to a folder. You “just” don’t see it, you would assume a failure/corruption in seafile or a selective sync issue. If it IS there and tells you don’t have access, you know what is going on!
If you don’t want others to access the top level shared folder by default, you can just share the sub-folders under it to specific users/groups. Allowing “inaccessible” permission in the default share seems unnecessary to me.
I think both invisible and inaccessible permissions have their own use cases. In some cases the share owner just don’t want some users to know there is such a sub-folder. But it looks over complex and confusing to allow users to choose both permissions. So we’ll go for the invisible way first and see how users react.
I don’t think this kind of usage can be satisfied even in Windows network share.
In your description, if Projects is shared as invisible while “Project A/Costs” is set to visible. There is no easy way to determine whether the folder list (“Project A, Project B, …”) in Projects and folder list in “Projects/Project A” can be visited by a user.
When you share Projects to a user as invisible, the user should not be able to see the folder list in Projects. Later, you set “Project A/Costs” to be visible to the user. Then the user will be able to see the folder list in Projects, otherwise the user can’t navigate to “Project A/Costs”. This makes the system has to check whether there is a sub-folder or sub-sub-sub-folder in a folder set to visible before determining whether the current folder is visible the user, which is quite complicated.
After thinking it for a while and looking into other systems, I propose a simple solution, that is you can set a share name when share a folder. So you can share project A/costs, project B/costs to the account team as project A-costs, project B-costs.
In this way, the accounts can access to the folders without confusion and the desktop clients can be used.
Ok, and this will look like sub-libraries to the clients or how can we imagine this? I just think of having twenty or hundreds of sub-folders and i want to manage them easily. Maybe i didn’t understand your idea, can you describe it a litte bit more for us?
Almost any filesystem used on client-side uses a hierarchy, even seafile based libraries.
Your suggestion strips away the hierarchy. We wanted to restricted access, as in “fine-grained” permission on sub-directory level.
Your suggestion would generate a flat view on our document structure, loosing any project/department information. Having them all renamed on a flat hierarchy, causes our employees to scroll down 100 or more libraries, to find the e.g “costs” folder for departmentA/projectG/costs.
I liked the previous invisible approach of yours better. Your latest approach however would be unusable for this use case.
What if it followed the ABE service like in Windows Server? Where maybe the emphasis isn’t that the share is invisible, but skipped over due to not having permission and thus looks like it is invisible to the user? (just bumped into a case where we need a shared library, but a folder in there is meant to only be seen by a couple of people instead of the entire team)
Nextcloud has it implemented - you can set Tags on any folder or file and based on rules, users or groups simply have access or not. The Desktop client then simply does not sync these files/folders as it can not access them.
I’d love to see read-only / read-write / no-access settings for at least folders.
Having a very clear notification to the user if a content can not be synced (for different reasons, access rights, etc) would help the user to see if all is working (100% synced) or if he needs to take action.