I have published a Google Apps Script as a web app (Let's say it's Version 1 in 'Manage Versions'), I am now working on code for a new version. The issue I have is any changes to the GUI Builder UI for the new version are immediately applied to the published web app version, which naturally causes a lot of problems for current active users as they have Version 1 code (good) mixed with yet-to-be-published GUI Builder components (not good). How do I get GUI Builder to align with the Google Apps Script version control? Thanks, John
Hmm, I think there is something missing in the gas version-managment regarding the things built with gui-builder, maybe you should file an issue for that (google-apps-script-issues), seems to be not yet reported.
As a workaround 1 (as there seems to be no way to copy a gui inside the gui-builder), you could just make a copy of the project when you are ready to publish a new version and just publish the copy to your users (drawback: key changes, so you have to update your users with a new link to the app)
Workaround 2 could be to copy your guis into a separate library and have as code a single function like
function getComponent (app, guiName) {
return app.loadComponent(guiName);
}
which you then use from your project to load the gui. This means each time you want to create a new release, you copy your project, replace all the source-code in this copy with the above function and reference that copy as library from your project.
This library then has to reference the original project as library too and you have to update the event-handlers inside the gui builder to point to that original handlers in your project. Made a short test and it seems to work, but what a mess...
Related
When I deployed a new version of a script using the legacy editor, the "web app meta-version" was set to that version number and the link that my users have will execute the new version.
When I use the new editor the "web app meta-version" is not updated but a new "default meta-version" is created instead and a new ID/url is generated for it with the new version number shown there. The "web app meta-version" is left with the older numbered version of the code.
I do not want to update the links that the users have. Is there no way with the new editor to update the "web app meta-version" version number? An alternative would be to be able to set the required ID/url for the "default meta-version".
This is a known issue
And it seems that Google have recognized it.
Go give this issue a ☆:
https://issuetracker.google.com/175944464
Please don't commment with "+1", if you just click the star you will be subscribed and functions as a "+1"
I can now see (and have "starred") the issue number shown in iansedano's answer. However, that is a duplicate issue and the original issue to which it refers (https://issuetracker.google.com/issues/175811864) is inaccessible. I cannot imagine that having "starred" duplicates makes much difference to anyone responsible for resolving the original.
I've an question about libraries usage within Google Sheets.
I developed a standalone Apps Script published as Library. This library is used by 150 Google Sheets files (I did that to centralize and hide some code from users).
Today, I need to update the library code to add some functionalities.
I'd like to know if you know a solution to remotely update the 150 Sheets Clients to match the new Library version on client side (I don't use the "dev" mode).
It seems that the Apps Script API can change do changes on the library itself but not on the client side (sheets).
Has someone else had this issue and how did you deal with it ?
Nope. You'll have to do it yourself. Libraries not in dev mode never auto-update, and can't be updated to the latest version by the library developer, because they are libraries -- it is expected that there is code in the destination that uses it, and thus it is not guaranteed that changing the version does not break the interface code.
If you want your deployed code to be auto-updated to the latest version, you should be using the add-on model, or (when you know that you will have backwards compatibility for your library interface) accessing your libraries from your scripts in dev mode.
You can collect the requisite Script IDs (File -> Project Properties) that need to have the library updated, and you can update the Script Project contents (including the appsscript.json manifest file that specifies the library version) via the Apps Script API. You may find clasp helpful for this.
I am developing a one of those bulk delete script for gmail. I want to create a front end for the script so I can easily modify my settings on a per-label basis to specify how many emails I want to delete during a trigger event and how old they have to be for a particular label. I want to be able to test the interface similar to testing a script.....just hit the run button. However, google's script engine tells me I need to deploy the script and it's HTML files as a web app to test the interface.
Is there anyway to test the the interface and its interaction with my backend google script without deploying as a web app?
The answer is no, unless you "deploy" your code through a Spreadsheet. In fact, it's fairly well-documented.
See Serve HTML as a Google Docs, Sheets, or Forms user interface on that page for a "workaround" to testing your app without actually deploying it.
However, there is no harm in deploying it as a webapp. And as a matter of fact, you can see changes instantly after refreshing your app that you have deployed (published), using the dev macro you're given when you deploy it. This is the most useful tool for UiApp and HTMLService:
Edit: After you're done testing and you've "finalized" your code, you can disable the webapp, meaning that nobody can accidentally access it, you don't post the macro link to it, etc. It's a one-click process. Again, this is really the only way to test the code in my opinion, as it's most succinct for a real "development process". See image below:
I would like to make a copy of a Google Spreadsheet file between users that are not on the same domain. The source file has a sharing setting of Anyone with the link can edit.
I created a Web App (with execution permissions set to User accessing the web app) that call an install function:
I was hoping the code would read the source file which is open to everybody and make a local copy to the Google Drive of the user running the Web App (of course assuming the user accept to run the script). The behavior works when it's me running it (because I am the owner of the source) but do not work if the user is from another domain.
Any suggestions on how to achieve this?
function doInstall() {
// The source file is readable by everybody with the link;
var file = DocsList.getFileById('0AlVPTKz1xoevdHc1ZTQ2OGFMXXXXXXXYYYYZZZZ');
file.makeCopy('Test Copy Spreadsheet');
}
I had a different but similar use case and problem. Like you, my source file was accessible to anyone with the link and my domain settings allowed users to share content outside my domain. It worked for me but not for them.
This might work for you, it has for me (so far):
Assuming you have your original script...
Create a separate script for 'Script as web app'.
Write a function (e.g. loadFileIds()) to store the necessary fileIds using ScriptDb. Run the loadFileIds() function.
Write another function (e.g. getFileId()) in the same project that returns your desired file Id from ScriptDb.getMyDb when called. Avoid using DocsList in this function. I originally thought that because getFileId() would 'run as me' that it would be OK but it was always the DocsList line that caused failures when other users triggered the script.
In File > Manage Versions: Save a version of the project.
Under Publish: Deploy that version of your project as a web app. Choose Execute the app as "me(me#mydomain.com)" and set Who has access to the web app to "Anyone".
In your original project go to Manage Resources and enter the Project Key of the web app, choose a version and copy the identifier.
Write a function that calls yourIdentifier.getFileId() and - hopefully - returns the fileId.
In my experience so far external users have been able to access files that they could not when DocsList methods returned null. But there is one more thing to add... You might find you have to share your web app script with your users. I haven't quite made certain that's necessary but I've encountered bugs when I don't. I untick the option to email them the link.
I learned how to do this from examples in the documentation, this video and of course StackOverflow.
As you can see, I'm still working this out myself and testing of the system has so far been just me simulating other users. So no promises. Good luck! I'll star your issue.
When I published an app to the google app script gallery for spreadsheet tools, it failed to upload the GUI builder components as well. Do you know how I should go about remedying this?
I just get this:
Invalid argument: resourceName (line 37)
When trying to execute the code. Line 37 corresponds to where the code exists which loads the GUI builder component in to the UI app. I was going to rewrite the code and programmatically create the visual elements, but it seems like that would defeat the purpose!
Many thanks,
Eamonn
You're right, the GUI Builder falls short when you try to share it. Being through the Script Gallery or as a library. There's no way at all to export it and import in another script.
And that the reason why I never use it. Sometimes I play with it just to make fast mock ups to see if how an idea will actually look on Apps Script, but never as the real thing I'm going to develop.
You should open an issue report on the tracker, since publishing on the Gallery should really work out-of-the-box.