Terminology
| Term | What it means |
|---|---|
| sharer | The user that shares content |
| sharee | The user whose content is shared with |
| assign permissions | same as "share content" |
| disinheritance | to override the parent folder's permissions |
| explicit sharing | to add permissions using the sharee's account directly |
| implicit sharing | to share folder to the enterprise using a link or create content within a shared folder |
On Sharing
SkySync transfers content and migrates permissions in that sequence. This is mainly because platforms expose shared content differently. In other words, we transfer content first, then apply permissions after the content is transferred. Applying permissions can have unintended consequences at the destination depending on how the destination exposes shared content after the destinations are applied. This is why we have the ability to exclude shared content from the source so that content is not duplicated on the destination after permissions are applied.
Let me give you some background on Box and Google folder sharing before diving into how SkySync interprets and transfe.
Box
In Box, when a sharer shares a folder with someone, the folder appears on the sharee's Box root (once the invite is accepted manually or automatically). Subfolders within that folder is owned by the sharer. You can add new sharees to other subfolders but cannot modify the permissions that are already there. This is called "disinheritance"; the ability to override the parent folder's permissions. In other words, Box does NOT support disinheritance.
G Suite
In G Suite, when a sharer shares a folder with someone, the sharee will either have a link to access the content with or, if explicitly shared, shows up in their "Shared With Me" bucket. The sharee can then choose to "Add to My Drive". The shared folder can be dragged to any folder within the sharee's "My Drive", including both private or other shared folders. The sharee can even move the shared folder to a folder they are sharing with the sharer. This means that the sharer can then have the folder they shared in their "My Drive" in multiple places. Content created on a shared folder is, unlike Box, owned by the creator and considered shared to the sharer of the folder. The sharer of the parent folder can also move the subfolder created by the sharee out of the folder into a private folder in their drive. This will cause the subfolder to be orphaned on the sharee's side. Since the sharee owns the subfolder he can search for it but it is no longer in his "My Drive". Confused yet?
G Suite, unlike Box, supports full disinheritance. This means that the sharee can create a subfolder on a shared folder then remove the sharer from its permission list. The sharer will no longer see that subfolder in his folder. The sharee will.
How SkySync Interprets Shared Folders
Box
In Box, since sharing is limited to the root and all content within a shared folder is owned by the sharer, SkySync behaves as expected; the sharer DOES NOT see the folder and its content as shared, the sharee DOES see the folder and its content as shared.
G Suite
In G Suite, things are not as straightforward. Shared behavior is driven by an application setting called GoogleDrive.AllowSharedWithMe (set to false by default) and based on how the folder was shared in the first place and whether it is already inheriting its parent folder's sharing.
Lets walk through by using an example.
We have two users, Juan and Lynn. In SkySync, we open two connections, one for each account, respectively.
Juan has two folders in his "My Drive": JuanFolder1 and JuanFolder2.
Lynn has one folder in her "My Drive": LynnFolder1
Juan shares JuanFolder1 with Lynn explicitly and shares JuanFolder2 as a link to the entire enterprise. Lynn adds the two shared folder into her "My Drive"
Lynn shares LynnFolder1 with Juan explicitly. Juan adds LynnFolder1 into his "My Drive".
In SkySync, using Juan's account, JuanFolder1, JuanFolder2 are not considered shared and LynnFolder1 is considered shared. Using Lynn's account, JuanFolder1, JuanFolder2 are considered shared and LynnFolder1 is not considered shared.
So far so good...
Lynn creates a subfolder: JuanFolder1/SubfolderByLynn and moves JuanFolder2 to JuanFolder1.
Juan moves LynnFolder1 to JuanFolder1.
In SkySync, using Lynn's account, regardless of GoogleDrive.AllowSharedWithMe setting, JuanFolder1, JuanFolder1/JuanFolder2, JuanFolder1/SubfolderByLynn and JuanFolder1/LynnFolder1 are all considered shared. LynnFolder1 also shows up in her root drive as not shared.
In SkySync, using Juan's account:
- When GoogleDrive.AllowSharedWithMe is false, JuanFolder1, JuanFolder1/SubfolderByLynn are not considered shared, JuanFolder1/LynnFolder1 and JuanFolder1/JuanFolder2 are considered shared. JuanFolder2 also shows up in his root drive as not shared.
- When GoogleDrive.AllowSharedWithMe is true, JuanFolder1, JuanFolder1/JuanFolder2, JuanFolder1/SubfolderByLynn and JuanFolder1/LynnFolder1 are not considered shared. JuanFolder2 also shows up in his root drive as not shared.
LynnFolder1 is considered a "shared with me" container thus its share state is on the sharer's side is driven by GoogleDrive.AllowSharedWithMe. The issue is, from Juan's standpoint, we cannot determine whether LynnFolder1 is also located somewhere else on Lynn's drive. The flag gives you the opportunity to decide whether to consider it shared or not so that it can be included or excluded on Juan's transfer job.
JuanFolder2 is also considered "shared with me" even though Juan owns it and it is not shared with him. The folder has two parents, one of which is a folder Juan shares. So we consider it a "shared with me" within the shared folder to give you the opportunity to decide whether to consider it shared or not so that it can be included or excluded on Juan's transfer job.
The risk with using GoogleDrive.AllowSharedWithMe is you can either end up with skipped transfers or duplicate transfers because "shared with me" items most likely have multiple parents within the scope of the sharer's account.