0
votes

I have had some inconsistent results using GAS to set sharing for files created in the script, from an uploaded blob. Gobally, the GAS script serves an Html form, collects the uploaded file, and makes some logging and processing. It is a heavily modified version of this https://ctrlq.org/code/19747-google-forms-upload-files adapted for report submissions from students.

The only clues I have so far are related to the position of the line that sets the sharing, relative to the lines in which the file is created:

var folder = DriveApp.getFolderById(dropbox);

// Get the blob
var contentType = data.substring(5,data.indexOf(';'))
var bytes = Utilities.base64Decode(data.substr(data.indexOf('base64,')+7))
var blob = Utilities.newBlob(bytes, contentType, filename)

// Create a folder for the file if it does not exist
try{
  var subFolder =  folder.getFolder(tp);
}
catch(e) {
  var subFolder =  folder.createFolder(tp);
}
var file = subFolder.createFile(blob) // Create the file

From this point on, strange things happen. I have narrowed down the problem to the actual line that sets the sharing:

file.setSharing(DriveApp.Access.ANYONE_WITH_LINK, DriveApp.Permission.VIEW)

If this is immediately after the file creation, it works only some times. Over 200 reports have been submitted, and ~50% of them are visible to anyone with the link, while the rest are only shared privately.

Whether these permissions are set or not, everything else completes successfully. So i have no error log to know for sure what is going on.

By moving this line to the end of the function, subsequent submissions have properly set the permissions:

// .... processing lines that include logging to a spreadsheet, sending emails, and setting other permissions.

file.setSharing(DriveApp.Access.ANYONE_WITH_LINK, DriveApp.Permission.VIEW)

return "OK";

My guess is that, for some reason, the time between file creation and permission modification affects the effectivenes of the .setSharing() line.

One hypothesis is that the file may be inheriting the parent folder's permissions (which is not public) with "lag". In other words, the permissions set by the .setSharing() function would be overwritten by some obsecure inheritance function behind file creation line:

 var file = subFolder.createFile(blob) // Create the file

The "default" permissions must surely be set at some point, but there is no "flush" function, that I know of, to force or wait for this to happen (such as the one used in Google Spreadsheets).

EDIT: i have found a thread where similar "non determinism" occurs, involving permission inheritance from the parent folder (see this issue).

I would like to know how to make sure that permissions are always set correctly.

Cheers :)

For your situation, how about using Drive API? By using Drive API, when the file is created, the permission can be also included.Tanaike
Hi, thank you for your comment Tanaike. I have followed the link, but it is not clear to me how to use the Drive API in my script. ¿Could you provide an example? RegardsLabo QG Unsam
Yes. You can see the sample for using Drive API from here.Tanaike
Thanks! I have tried the following, and the file is created correctly, but permissions are once again not set on file creation. I have used this files resource with Drive.Files.insert: ` var filesResource = { 'title': fileName, 'mimeType': contentType, 'description': 'lab report', 'shared': true, 'permissions': [{"role": "reader", "type": "anyone", "withLink": true }]};`Labo QG Unsam
I noticed that I misunderstand about the method of Drive.Files.Insert. Although The setting of permission is included in the request body, the permission can install for only the created files. When I tried it using Drive API v3, the error of The resource body includes fields which are not directly writable. occurs. Namely, this indicates that it is required to create files before give the permissions. I'm really sorry.Tanaike