[SPACES] WebDAV permissions

[jesmrec]

Every pair space-member is led by a permission. Three different permissions are available for a space:

• Viewer: Download and preview
• Editor: Upload, edit, delete, download and preview
• Manager: Upload, edit, delete, download, preview and share

Depending on the member permission, some actions will be allowed, other ones will be banned. Info fetched from the drives endpoint, permissions array:

"permissions" : [
               {
                  "grantedTo" : [
                     {
                        "user" : {
                           "id" : "52a81e9f-1c64-4384-8371-b1ebafd14d53"
                        }
                     }
                  ],
                  "roles" : [
                     "manager"
                  ]
               },
               {
                  "grantedTo" : [
                     {
                        "user" : {
                           "id" : "b7ea9393-fd39-4627-a3c7-11ad55cdcf11"
                        }
                     },
                     {
                        "user" : {
                           "id" : "f4cc5b14-7bf2-45c1-b470-e3d94969083e"
                        }
                     }
                  ],
                  "roles" : [
                     "editor"
                  ]
               },
               {
                  "grantedTo" : [
                     {
                        "user" : {
                           "id" : "2c487709-18db-4e48-8227-99af69274db6"
                        }
                     }
                  ],
                  "roles" : [
                     "viewer"
                  ]
               }
            ]

Depending on the permission level

	Viewer	Editor	Manager
Create folder	❌	✅	✅
Upload	❌	✅	✅
Download	✅	✅	✅
Preview	✅	✅	✅
Set as av. offline	✅	✅	✅
Open with	✅	✅	✅
Send	✅	✅	✅
Move	❌	✅	✅
Copy	**	✅	✅
Rename	❌	✅	✅
Remove	❌	✅	✅
Share	❌	❌	✅

** Only to other space with enough permission. Maybe it's OK as ❌

That means: inside a space there should be available only those actions that are allowed. It should be refreshed somehow, because the permission level is not static.

Extra ball, just an idea: in the sticky header, show with a small icon in the corner the permission level of the user in the space. F. ex:

• If it is viewer, show an eye icon
• If it is editor, a pencil icon
• If it is manager, a wrench or gear icon

TASKS

• Research (if needed)
• Create branch spaces/permissions_handling
• Development tasks
  • Save permissions for root folders (currently not saved)
  • Hide elements according to the different permissions in folders
  • Hide elements according to the different permissions in files
• Code review and apply changes requested
• Design test plan
• QA
• Merge branch spaces/permissions_handling into master

[jesmrec]

Using the WebDAV permissions for every item is the best approach

WebDAV Permissions cheatsheet:

https://github.com/owncloud/client/blob/cedf72825bc0db8e3c147958a9382ee5b411d9ea/src/common/remotepermissions.h#L42-L54

[JuancaG05]

Regarding the WebDAV permissions, some notes here:

• Permissions C and K only apply to folders and permission W only to files
• Permission W always appears in oC10 no matter if you have "change" permission or not. In oCIS, it appears only if you are allowed to edit the file
• Seems that permissions C and K always go together (no case found in which only one of these two appears)

So, we'll proceed in the following way:

• W: it's a file and user can edit it. If there is no W in the file, we'll send the file to the external apps via "Open with" in only-read mode. If the file gets to be edited anyway, we'll show an error when trying to upload it (server will reject it).
• C: it's a folder and user can add files to it. If there's no C in the current folder, we'll hide the "Upload" option in the FAB so that no uploads can be done (share with ownCloud and auto-uploads only point to Personal space, which are expected to always have the C and K permissions).
• K: it's a folder and user can add subfolders to it. If there's no K in the current folder, we'll hide the "New folder" option in the FAB so that no new folders can be created.
• When both C and K are simultaneously absent (expected case when user has no writing permissions), the whole FAB will be hidden.
• For copy and move options, "Copy here"/"Move here" button of the folder picker will be disabled if the current chosen folder in the picker has no C permission. When the current chosen folder in the picker lacks of K permission, the "New folder" icon button will be hidden as well.

[jesmrec]

W: it's a file and user can edit it. If there is no W in the file, we'll send the file to the external apps via "Open with" in only-read mode. If the file gets to be edited anyway, we'll show an error when trying to upload it (server will reject it).

Conflicts could happen in this case. A file is edited in the server and locally at the time, but local file is not pushed because not allowed. User will see the file as conflicted but only one option is feasible: "Keep server". What to do in this case? Removing local changes without asking seems to be intrusive. Showing the open with as open with (read only) and delegate responsibility to users could be another one. Making a more complex logic like asking the user if a local copy of the modified file will keep in local but not in server, in order not to lose the changes, could be also interesting but breaks sync. More ideas welcome.

For copy and move options, "Copy here"/"Move here" button of the folder picker will be disabled if the current chosen folder in the picker has no C permission. When the current chosen folder in the picker lacks of K permission, the "New folder" icon button will be hidden as well.

💯

[JuancaG05]

Since the roles may be dynamic in a future and we rely on permissions, we won't implement the role icon in the space sticky header for the moment