You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
OneDrive (personal account): You can access shared folders. If you're unable to access a shared folder that was shared with you (i.e., you are not the owner), you have to add the shared folder to your OneDrive.
OneDrive for Business (work/school account): You can only access shared folders that you own. Even if you add a shortcut to "My Files", you cannot access the shared folder.
Technical Details
To make this point clear: Shortcuts are not part of the directory listing. It seems that there is no way to implement this feature transparently. So there is no way to "merge" shared files with your own files. That's actually what the shortcuts are for (in my opinion) but they're missing.
There is an API to list all shared items (not being the owner) via GET /me/drive/sharedWithMe. With these identifiers, you can access the shared folders.
Proposed Solution
Since personal accounts are not affected by this issue, the driveType should be retrieved and persisted after a successful authentication. You can get it via GET /me/drive.
When adding a vault in OneDrive: If the driveType is business (and maybe documentLibrary?!), we need to present a choice between the user's own files and shared items. An optimization could be to detect if there are any shared items at all so that the choice can be skipped. In case of shared items, we need a new screen that lists all available shared folders (shared files don't make any sense here). If one of the folder is selected, the "new" root identifier is the one from the selection (incl. drive identifier).
Caveat: If we set the selected folder as root, there will be the problem that the root folder doesn't have a name (classic example if the vault is the root folder itself). When implementing this feature, we should experiment with setting the parent reference as root but still showing the shared folder directly.
The text was updated successfully, but these errors were encountered:
I'm running in the same issue with the iOS OneDrive app (personal?). I cannot access the shared folders, where all the faults are placed. I remember it worked some time ago, maybe on Cryptomator App 1.x. Any plans for this issue?
Original issue from the old app: cryptomator/cryptomator-ios#139
Status Quo
OneDrive (personal account): You can access shared folders. If you're unable to access a shared folder that was shared with you (i.e., you are not the owner), you have to add the shared folder to your OneDrive.
OneDrive for Business (work/school account): You can only access shared folders that you own. Even if you add a shortcut to "My Files", you cannot access the shared folder.
Technical Details
To make this point clear: Shortcuts are not part of the directory listing. It seems that there is no way to implement this feature transparently. So there is no way to "merge" shared files with your own files. That's actually what the shortcuts are for (in my opinion) but they're missing.
There is an API to list all shared items (not being the owner) via
GET /me/drive/sharedWithMe
. With these identifiers, you can access the shared folders.Proposed Solution
Since personal accounts are not affected by this issue, the
driveType
should be retrieved and persisted after a successful authentication. You can get it viaGET /me/drive
.When adding a vault in OneDrive: If the
driveType
isbusiness
(and maybedocumentLibrary
?!), we need to present a choice between the user's own files and shared items. An optimization could be to detect if there are any shared items at all so that the choice can be skipped. In case of shared items, we need a new screen that lists all available shared folders (shared files don't make any sense here). If one of the folder is selected, the "new" root identifier is the one from the selection (incl. drive identifier).Caveat: If we set the selected folder as root, there will be the problem that the root folder doesn't have a name (classic example if the vault is the root folder itself). When implementing this feature, we should experiment with setting the parent reference as root but still showing the shared folder directly.
The text was updated successfully, but these errors were encountered: