I have multiple spreadsheet bound projects, and I want once in a while run all of them together. Is there a possibility to automate this, as I do not want open each project and run it manually. And as I understand I cannot create installable timed triggers, as I have more than 20, and I am not collaborating with anyone.
My vision - is to create a standalone project where I loop through all the projects using their project/script key(id)s. I only do not know if this is possible, and if yes how do I code this - a call of a script knowing its scriptid?
In order to provide a proper response to the question, I'm writing this answer as a community wiki, since the issue was resolved from the comments section.
Yes, it's possible to run several projects at once with Apps Script with method scripts.run
You can use this example to have an idea on how to do it with Apps Script.
The documentation that #Ruben shared above has specific details to accomplish what you're looking for. Make sure to check the requirements and also the limitations to check if the projects you're trying to run meet the requirements.
Related
I have about 700 Google sheets, running scripts.
For too many years now, I have to re-authorize these scripts indefinitely.
Of course, I searched the net, I simplified my scripts to minimize the number of services called. Recently, I was hoping that the Google Alpha V8 script could have helped me, but no, definitely no. Still no solution.
My hundreds of sheets are opened by the employees of my company, therefore hundreds of scripts linked to these sheets are automatically used thanks to triggers (simple and installable triger)
It seems obvious that there is a limitation on the number of scripts allowed at the same time. This limitation having been visibly reached for years, I have to re-authorize, every day, some scripts. But by doing this, I guess I am revoking so many other scripts. How Google decides to revoke this or that script, I don't know. I guess the least used.
Why this limitation? Is it possible to increase it?
If not, what is the solution?
I add I found this page https://developers.google.com/apps-script/guides/services/authorization , which is talking about OAuth application user limits (at the very bottom of the page) . I wonder if this could help me.
Thank you.
I worked on my topic, reading a lot of english docs... I painly read and slowly understood them. I hope so !
As I could expected, I hit on restrictions, placed by my organization, I imagine. I am unable to create project. See 1
In the same time, and strangely, I own several projects. 2. I don't know why they exist, even if I recognize their names which are those of several of my scripts.
Anyway if I want to publish my script as an Add-on, I have to "link" my script to a "standard GCP project".
As it is impossible to create specific projects, I tried to follow a google procedure, consisting to link my script to an existing project. But as it was expected, it does not work either 3
If someone had a good suggestion, it would be welcome.
Thx.
JM.
Convert your scripts to an add-on. Then these add-ons can be shared across users and spreadsheets, and you can actually reduce the number of places you need to maintain code. You can view the publishing guide here: https://developers.google.com/gsuite/add-ons/how-tos/publishing-editor-addons
A second solution is to create a standard Google Cloud Platform project and change (some/all of) your scripts to use it, rather than their own hidden GCP project. More info about this step: https://developers.google.com/apps-script/guides/cloud-platform-projects
Note that both of these solutions will result in sharing of certain quota limits, which may mean you need to redesign or update how you do things
However, both of these changes provide increased visibility into the errors that your scripts encounter, as you no longer have 700+ places to check for error reports, just a 1 or a handful.
I'm developing a Google Sheets add-on and I wonder what is the best strategy to test it with real users before submitting it to the add-on store. I have read the development checklist on this page:
https://developers.google.com/gsuite/add-ons/how-tos/publishing-editor-addons
And it says, among other things:
The editor add-on must be fully functional - it can't be a “work in progress.”
The script has been tested with multiple active users.
So the question is now, how can I share it with multiple real active users so that they can test it? The only real way to actually share it seems to be to publish it to the add-on store, so this seems like a bit of a catch 22.
The alternatives I have found so far:
I have been developing the add-on as a script (Using Tools -> Script Editor) in Google Sheets. This will cause the script to be attached to the spreadsheet. I can share this spreadsheet with other people, and when they open it they can run the script. However, they can only run the script in the particular spreadsheet I share with them. What if they want to test it on their own data?
I can share the actual script with other people. If I do this they can open the script and create a test configuration as explained here: https://developers.google.com/gsuite/add-ons/how-tos/testing-editor-addons. However, this is quite a technically involved process. Asking friends without programming experience to follow the steps seems like asking a bit much. If I only ask friends with programming experience, the tests will not really be representative for average users. And it says in the checklist that the add-on should be tested with "multiple active users", not "multiple active programmers".
Is there an alternative test method that I have missed? Anyone who has experience of this process and who has insights to share?
In our company we use Google spreadsheets heavily. I would like to automate some things, for instance every minute I would like to call our bank's API and save all the new transactions into a spreadsheet.
What I'm missing in the official documentation is some major architecture best practices.
First part of the question: Who should be the owner/runner of such user-neutral company-wide script? I would not like to bind it to my personal account. I want it to run seamlessly even after I leave the company some day. Is some artificial technical user needed?
If it makes any difference we plan on moving to team drives in future.
Second part of the question: I would like the scripts to have persistent storages (in the example above - for the record of transactions). I'm considering to be a rule that every script is bound to a spreadsheet which acts as its data store. Is it a good idea?
I generally recommend that clients provide me with an "artificial technical user", as you say, to keep that owner alive and away from my personal account. Which also avoids using up my daily quota especially for regular triggers.
I'd avoid binding the scripts to a GSheet as you'll then get issues with potentially using GitHub or creating add-ons in the future. I generally make all scripts in a separate library (Bruce McPherson did various tests and never found a performance hit) and then link them with a very small script to a script contained in a GSheet if needs be. This allow eases separate development whilst the script is being used live.
GSheets do provide a fair amount of storage (2 million cells) but if you reach that - and the sheets do tend to slow down - take a look at using Firebase for which you get 1GB free and there is a great Firebase library.
There are various general recommendations for Apps Script development. I link a few here.
Happy scripting!
I am going make some programs in Google Apps Script for a non-profit organization. I don't want give them my code. Is there any possible way to give them programs not code. Actually, I don't want anyone to see or change my code.
And I also don't want to use Web App. My script will access their contacts and Spreadsheets.
You may want to investigate Libraries. You can put the segments of the code you want to protect into a library, and then give them code (macros, scripts, whatever) that just calls that library - they will be able to see the code you gave, but not the library. However I don't know how "foolproof" this is if someone was really determined to dig.
https://developers.google.com/apps-script/guide_libraries?hl=en
I have been playing with this for days and no luck. One of the challenges is not being able to watch the network traffic of "UrlFetch" since it is on Googles wires.
Anyone interested in posting a detailed example of using "Digest Auth" and Google Apps Script?
It should be possible, but I'm not sure I've seen it done before. I looked into it briefly once but digest authentication is pretty complicated and it's a task to code it by hand. If you are looking for a server to test against I'd recommend test.webdav.org, and there are some existing JavaScript libraries like dijestj that you may be able to leverage or learn from.