I have the following situation in my organization:
I have two groups: GroupA and GroupB. I created a “filesystem-manager”-user that owns the folders FolderA and FolderB and shares them with GroupA and GroupB.
Now the important part:
Group A should have full permissions on FolderA and GroupB should have full permissions on FolderB.
Also, GroupA should have read permissions on FolderB and GroupB should have read permissions on FolderA.
That’s no problem so far but now I have one UserX that is member of both groups, GroupA & GroupB. If I log into his account I see the following folders:
FolderA
FolderA(2)
FolderB
FolderB(2)
My request for this situation is to always use the highest permission level that a user can get from its group membership. So if GroupA has write permissions on FolderA and UserX is member of GroupA & GroupB, he should only see FolderA one time and FolderB one time and have write permissions on both of them.
All the other users of GroupA & GroupB only see the two folders, one of their group with write permissions and one of the other group with only read permissions.
I hope this is understandable… otherwise I could try to visualize my problem
this isn’t due to permissions. Folders get these kind of suffixes, if there’s already a folder with the same name, when the sync runs. Since one can never assume, that a folder named doesn’t already exist anywhere else, this is the way, this get’s solved. Your issue here is, that Folder A and Folder B got synchronized and then when the other shares “came along” their resp. names had already been taken and thus the “new” folders got suffixed. I take it, that The user has write permissions to FolderA and only read permissions to FolderB. Or vice-versa, depending on which folder had been actually shared first.
thanks for your explanation! I understand that it’s because of the same names for the folders but in my opinion it would be cool to “merge” these folders together and enable the user to access this merged folder with the highest permissions that he has…
I am no dev, but I do think that the potential issues with such a behaviour would be hugely complicated. It also won’t scale. And then, on what facts should the desicion been made, when to merge a folder or when not. This would only be feasible if two folders were shared from different sources, but the algorithm should be a generic one. So, at least, if one had a name already chosen for a local folder, you would end up with a suffixed folder again.
To me, a consistent user experience should be the highest priority. But then, I am not a dev…
I think it wouldn’t be such a huge problem?
Is there no unique ID for any shared folder? This could be used to identify that it’s the same shared folder.
I clearly also want an awesome user experience that is as simple as possible, but two shared folders that point to the same place also lead to confusion
I’m replying here because i think my question is close to this post.
If we share a folder1 with read only access containing 2 subfolders (1,2) . Then, we share subfolder1 with read/write access and we keep subfolder2 with read only inherited. The user concerned will have the folder1 with 2 subfolders (read only) AND the subfolder1 (read/write) in his root.
Here, the question is not about the name but the tree. Is there a way to keep the tree organisation ? meaning subfolder1 will stay under folder1 but will have different permission ?
I have exactly the same problem. It is pretty annoying and not very intuitive. I really hope devs are thinking about (maybe even working on) an option to keep the tree structure (sort of like a wiki) and allow better fine-grain permission control. A great orientation could be the pro version of Seafile: https://www.seafile.com/en/help/folder_permission/
We have exactly the same problem. One folder appears multiple times on a client, this is very confusing and users forget to which folder they can write and from which they can only read. It also looks messy.
Maybe the solution is not merging folders but allowing read-only permissions on subfolders.
There is file access control to limit access to subfolders, but it poses problems:
there is no read-only access
folders are still seen (again: confusing)
if the files have already been offline synced before the subfolder is tagged to deny access, the files and folders within the subfolder stay. Then there are sync error messages when syncing instead of a warning which could be similar when writing to a read-only shared folder.
The file access control is more a feature to automate workflow or serve as a “file/user/location firewall”.
Probably there could be another admin option (“folder permissions”) using the same technique as file access control (tagging a folder, limit by username(!) and group) but then giving read only access? It would solve the strange behaviour with offline sync and the issue that folders are still visible would not seem strange (as you have readonly access anyway).
