Google Drive subfolder permissions - need review

[camerojo]

OLD ISSUE NAME: Getting file permission error when sharing an attachment in Angular|Candidate|AdditionalInfo. Reusing ticket as it has all the information.

From Mariam See https://refugeejobsmarket.slack.com/archives/C42S4AJ73/p1712348835441979

[camerojo]

The exception is thrown from the publishDoc method in CandidateSavedListServiceImpl

It looks like google has failed to update the file permissions @cazcam34

[cazcam34]

ISSUES:

• It is a google error:

  403 Forbidden
  POST https://www.googleapis.com/drive/v3/files/1S3X4us9BHIpDgKm7fdn1CD1OnAsSnYIh/permissions?supportsAllDrives=true
  {
  "code" : 403,
  "errors" : [ {
  "domain" : "global",
  "message" : "The user does not have sufficient permissions for this file.",
  "reason" : "insufficientFilePermissions"
  } ],
  "message" : "The user does not have sufficient permissions for this file."
  }

• What caused this is Mariam manually moving the file from the candidate's base folder and into a subfolder (employer). The base folder has a restricted access with two accounts allowed with no general access. The subfolders have the same, however they have general access set to anyone with link.
• Permissions waterfall in the google drive, so by adding a file to a shared with anyone folder it will automatically update the permissions of that file.
• HOWEVER this is also resulting in the error, I can see that inherited permissions (which they all are when in the subfolder) cannot be revoked. But what is weird is that calling the create method to create the SAME permission as an inherited one is causing the error - the wording of the error could be confusing things more but essentially inherited methods cannot be changed or deleted (or in this example it appears cannot be created again).
• IF I change the subfolder to remove the general access "anyone with link" can view permission, I no longer get the error. So when trying to create the permission on a file that already inherits the permission it causes an error. I tried deleting the permission so that I can re-create it, but it won't let me as it's an inherited permission and those can't be deleted from the inherited object. When using the methods here to find out the sources of the permissions I found that files in the original base folder can have the 'anyone with link' permission created, as it is not already inherited. Whereas calling that method when it is in a folder which already has that permission, means it is inherited and cannot be created.

SOLUTIONS?:

• We could make all subfolders not generally accessibly by "anyone with link". Dont think we need publically viewable folders, only files which we can then manually make accessible like we currently do.
• If we are going to start organising folders for the team (e.g. all CVs will get put into the Employer folder) we will need to remove the general access anyways. Same with all subfolders, as they will all waterfall into the files in them. So there could be a privacy issue.
• Another problem, having folders as publicly accessible AND if we automate moving all CVs for example to that subfolder is that files that are removed by candidates do not get removed but just renamed 'removed' so those folders can't be shared as they will show deleted files by candidates.

My opinion: Change all subfolders permission to not accessible to anyone with link. This gives us greater control over what files we make publicly viewable, and it would stop the error occurring (it occurs by calling a create permission method on a permission that is already present through inheritance). Also by making a folder publicly viewable (and therefore all it's contents), it means files that are removed by candidates will still be viewable as they are not deleted but just renamed. So this is not something we want to be doing.

HOWEVER the reason we made these folders publicly viewable (anyone with link permission type) was that they were shared with fragomen. I think there may be examples of subfolders which could be publicly viewable, but we default to not and perhaps in the publicly viewable folder name we preface it with "PUBLIC: xxxx" so that it is clear to users that if they move files into that folder it will become also publicly viewable. Again though we want to avoid people moving things directly on the drive, and perhaps automating file uploads into the correct subfolder would resolve this. Eg. Automate all CVs to go into Employer folder. However as discussed above this folder would need to be not publicly viewable.

[samschlicht]

Just a quick note that this came up again — many thanks to @cazcam34 for already having put the work in! (See #1113)

[samschlicht]

Just adding that Mariam mentions in this thread that the team is reviewing their systems for filing attachments and has been using the base folder alone with good results.

I mention that it would be great to understand better what's creating the need to use Google Drive. For many reasons it'd be better if this weren't happening

• our source partners don't have Google Drive access
• we get bugs of this kind
• it's more efficient to work from one place
• we might be ditching Google Drive for candidate file storage anyway, and in the meantime there are operational processes being designed around it!

My message is tentative and doesn't promise or formally request anything, but I'd suggest this would be a worthwhile area for a bit of deliberate consultation.