I'm working in a Google Script that runs on a a Google Spreadsheet and creates an onEdit() trigger on it.
I would like to know if this script is somehow visible (through Google's interface or any kind of source code inspection) to the users that access the table with readonly permissions.
From my understanding users would not be able to access such a script, since they are suppose to run on Google's server side and not on the client browser. I couldn't find anything about that on App Scripts documentation.
Regarding the use of a web browser developers tools (like right click and selecting Inspect) over a spreadsheet they will not the script code if you do right clic over an spreadsheet but it might show the name of functions called by a custom menu or image with an assigned function, not the code of the onEdit function.
User with view access can't view the code but, if you didn't disable disabled make a copy, they see the code if they made a copy of the spreadsheet.
An alternative to limit users to make a copy of the spreadsheet is to publish your script as an add-on.
Related
How to protect the Apps Script code in a Google spreadsheet?
Related
How can I allow users with permissions of "View Only" the ability to execute an apps script in a spreadsheet?
I've created a custom menu choice triggered by onOpen() that launches the script fine for anyone with edit permissions. However, onOpen() does not run for anyone with only view/comment permissions (consistent with the documentation) and thus the menu is not created and there is no way to launch the script.
Ideally, I would like view only users to view and execute the script, but not modify it.
If executing the script results in modifying any content of the sheet then I think it's reasonable to expect only those users with edit rights will be able to run the script. In view of this I am not sure I understand the question at all.
Ideally, I would like view only users to view and execute the script, but not modify it.
Simple triggers and installable triggers that are able to use SpreadsheetApp.getUi like onOpen and onEdit are executed only for users with edit permissions.
Instead of using a custom menu you could add a link to script published as web app allowed to be accessed by anyone and run. The link could be added to a cell or to an image.
Related
Threads with answers with score > 0
Google App Script - allowing access for anonymous users
Threads with one answer with 0 score
Extend Google Spreadsheets UI with a Google Web App
Google Spreadsheet - Custom menu won't load because onOpen won't fire
I just spend a few days on this and don't believe you can! In order to let an anonymous user execute a web app google app script, you have to set it to "Anyone on the internet with this link can edit" in the app script sharing options. Plus you have to make the sheets the script touches editable by anyone. Plus you have to deploy it as executed by you and everyone has access.
No sir, I don't like it. The app script should be executable without being editable. Google's choice makes no sense, especially considering how difficult they've made it to share content with anonymous users. You'd think they would allow an execute privilege without a modify privilege. (Are opinions allowed in answers?)
I wrote a google spreadsheet script incl. html service. Now I like to publish the html service as a survey. Everbody shall see it without registration at google but it should be not allowed to see the results of all participants.
Have you an idea how can I reach this?
I tryed a lot of publish options but I didn't reach my goal. Do you?
Right now, your Apps Script Project is probably bound to the spreadsheet. If the users who are submitting the form, never need to see the spreadsheet, then create an Apps Script file that is not bound to anything, it's "Stand Alone". Then do NOT share the spreadsheet. If you share the spreadsheet, then people who the file is shared with can VIEW the spreadsheet. It is possible to hide and protect sheets and ranges. And of course you can make settings for some users to be able to VIEW the spreadsheet, and others to EDIT.
If you share the spreadsheet file, then everyone it's shared with has VIEW permissions. You can't share a spreadsheet file and not give VIEW permissions. But, if you want some users to be able to see just some sheets in the spreadsheet, and not all the sheets, then you would need to write some code that ran when the Spreadsheet opened, and that code would be hiding and unhiding sheets depending on who opened the spreadsheet. Only users with EDIT permission can unhide a hidden sheet. So, that's an option. You can hide a sheet from anyone. But a user with EDIT permission can unhide the sheet. If you want to hide a sheet from someone with only VIEW permission, (They can't unhide it) then have code run onOpen() that checks the user, checks their permissions and either hides or unhides the sheet.
If the people submitting the form, never need to view the spreadsheet file, then don't even share the spreadsheet URL with those users. Just use the Stand Alone HTML Service as your "front end", "User Interface" with the users who never need to view the spreadsheet.
So, if the people who are using the HTML don't need to ever view the spreadsheet, then don't give those people the URL to the spreadsheet. Give them the URL to the published app. In that scenario, the users of the published app will never see the spreadsheet. The published app is essentially a website, with no real domain name.
The solution for you, depends on how simple or complicated the sharing, editing and viewing settings need to be.
When opening the script file, you need to use the Publish >> Deploy as web app option.
Then, choose the version you want to deploy as webapp or create a new one, set the app to execute as you, and add access to anyone (even anonymous). Like this:
The important thing is that the function that's called when someone access the URL that's shown for your web app, is a function called doGet(). So you must rename the function you use to display the UI and Form to doGet(). This function should return a valid HTML Output (normally using the HTMLService or the deprecated UiApp service).
So this:
Gets you this:
I have a seemingly simple problem that seems to get more complicated the more I get into it.
I have one spreadsheet document.
This spreadsheet utilizes a google apps script, that in turn utilizes various APIs: Domains, Sites, Spreadsheets...
To use this spreadsheet I have to take a few steps -
Authorize the spreadsheets. This dialog only comes up if I use the
script editor, otherwise the Spreadsheet fails silently.
Enable Domain API in Editor -> Resources -> Advanced Google Services
Enable Domain API in Google Developer Console to a seemingly hidden
project that is attached to my spreadsheet. The only way I can access this secret page is through the Advanced Google Services menu in step #2.
After getting through these hurdles, the spreadsheet now functions correctly without having to use the Script Editor.
Now I want to share this spreadsheet with other users in my company's domain.
Is there any easy way to do this, or will every single user I share it to have to jump through these hurdles as well?
Am I thinking about this wrong? The documentation states the script is 'attached' to the spreadsheet. But the more I get into it, the more separate these two things seem to be. I can share a spreadsheet - but the script won't function properly. I can publish a 'web app' with the script editor - but it won't come with the spreadsheet.
Any help appreciated
Frusteratingly yours...
Other users will have to have the same domain permissions as you do.
An approach you could take is have all the permissions related work done on a script that is published as a web app that will take url parameters (to trigger tasks), which is run as you and accessible to others.
From there, your original script can call the published url and send instructions via parameters.
https://developers.google.com/apps-script/guides/content
I have a Google App spreadsheet that I would like to make available to anyone with the link. It uses a custom gui to edit the cells of the spreadsheet. The custom gui is a html file launched using the HtmlService class in the Google Apps Script file.
How can I adjust the settings of the sheet so that anyone can open the spreadsheet and use the custom gui to make changes to the spreadsheet, but not make changes through any other means?
Here are the results I've had under various scenarios.
The gui works as expected but the sheet can be modified without it:
Anyone with link can edit
Gui launched via custom menu (App script runs as user)
The gui works as expected but the sheet can still be modified without it:
Anyone with link can edit
Gui launched via installable trigger (App script runs as trigger owner, which is also the document owner)
The gui cannot edit the sheet and neither can users otherwise:
Anyone with link can comment
Gui launched via installable trigger (App script runs as trigger owner, which is also the document owner)
My thought was that since the installable trigger is running as a user with permissions to change the sheet, that would work. Does that trigger's permissions not extend to a HTML Service gui that it opens?
Its not related to htmlServices. Simply any gui that you launch by any means from the spreadsheet will run as the user using the spreadsheet.
You need to publish the service (to run as the script owner) and use that gui through its service url, NOT launching it from the spreadsheet (menu etc).
I have a Google Apps script (written in a Google Spreadsheet) that creates a separate calendar and events for it with respect to a university course and the university calendar. The GUI is a Spreadsheet form, which triggers the execution of my script. The script gets its input from the spreadsheet form entry.
The trouble I have is that I can't easily deploy my solution to other users. Yes, they can make a copy of my sheet/form/scripts, so that they can run it on their account. Several problems, however, result from this approach:
triggers don't get copied - this is because authorization to access local info (calendars, contacts, etc.) must be given by the users before a trigger is enabled. So users have to re-connect the form submission trigger to the Apps Script for it to work (this is not user friendly).
if I change the code of my apps script, the users are using a copy and won't see the changes.
The solution seems to be Google Web Apps, but from what I've read, I can't re-use the form-based GUI of my approach. Or can I?
Google Spreadsheet Forms have the advantage that they are very easy to create, and you can already specify what fields are mandatory, etc. I don't want to have to re-write all of this in a complicated GUI front-end to my Google Apps Script (Edit: even the GUI builder tool seems way more complicated than a Spreadsheet Form), yet I want other users to be able to create the calendars and events in their own Google accounts. Is there a way to keep my form, but have it hooked to a Web App version of my code?
Try adding the form on a google sites (intranet). This way, any user having access, will be able to use the form as it is. All logic you created will remain the same.
Creating a script however will allow the user to execute the script "under their login", thus enabling access to calendars, contacts......