GAS - Purchase Apps for business - google-apps-script

I'm trying to help a school move to 'Google Apps' but i have concern.
One of the features I need is to retrieve current user's email upon form submission..which is only available if i purchase 'Google Apps for Education'.
Another concern is that since they already have existing email accounts, wouldn't they be hesitant to use new email accounts created from 'Google Apps for Education'?
What are your experiences so far in helping clients or businesses with Google Apps?

If you are moving an organization over to Google Apps your will achieve the best results if they fully embrace the ecosystem, including migrating all their email accounts to Google Apps.
There should not be anything preventing users from keeping their existing email addresses, simply set up identical account names in Google Apps and adjust their DNS MX records to deliver mail to Google's servers once you are ready to go live.
You are correct that if you want to automatically obtain the account names of users submitting forms then you need to be on a paid Google Apps account. This also lets you use their own domain for their Google Accounts, hence the ability to keep the same email addresses. Attempting to move to the free consumer-level #gmail.com environment rather than a paid Google Apps environment is not advisable as you lose most of the functionality that makes Google Apps great for organisations.
In my experience, if the users are unhappy with their existing system and you can demonstrate the benefits of Google Apps to them (low costs, universal accessibility, and collaboration functionality) they will be enthusiastic about moving over. If they are not interested in the benefits Apps offers and do not embrace the change, then there will be conflict each step of the way as you attempt to have them embrace a new way of doing things.

Related

Google drive OR Google cloud storage for a business web app

I'm a voice-over artist. I am creating a web app in which the client can make orders & upload video/sound/image/text files, I download these files to edit them then i upload the edited files & allow the client to download them.
Which is better for this purpose?
Taking in consideration
I want to allow the client to preview the edited file (video) in the
browser
Security
File privacy [I mean no one can reach the file except the client who made the order]
Performance
Price
There is no definitive answer to your question.
It confuses many customers that two, such seemingly functionally similar services, are available.
That said -- generally -- for applications where a service (your web app) is the intermediary, Google Cloud Storage (GCS) is the more appropriate solution.
GCS is a lower-level service than Drive and so you'll have a little more work to do to integrate it but it provides richer functionality too particularly with regards authorization and being able to provide more specificity about who can do what. Lastly, GCS enables so-called "Signed URLs" that would e.g. permit you to provide your customers with a secure and time-bound URL where they may upload content.
One possibly determining feature is that a Google Drive account is oriented around an individual (generally human) user (e.g. you) and your Google Drive does not permit other users to upload files; only you can create files in your Drive account although you can then share these with others.
I hope this helps you decide which service is best-suited to your needs. GCS is a very widely used service and is well-documented. You should be able to find plenty of guidance to help you develop a solution using it.

Architecture of a company-wide Google Apps Scripts

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!

It is in regards to an email from google about migrating discontinued documents list API

I received this email and due to my lack of experience in google drive, I am unsure of how to go about troubleshooting this.
Google
IMPORTANT: Steps to migrate from discontinued Documents List API
Hello administrators,
We recently posted a reminder that Documents List API will be discontinued on April 20, 2015. This change means that service calls for this API will no longer be supported, and any Google Apps features that are implemented using this API will no longer function.
Our records indicate that you may have an application that uses Documents List API, and we recommend that you migrate to Drive API, which has comparable functionality, as soon as possible.
Here's what you need to do:
Determine if you have an application that makes requests to these types of URLs:
(took out urls since this format did not allow me to send more than two)
Migrate the applications to Drive API.
If you have questions about migration, please contact Google Apps for Work Support.
Sincerely,
The Google Apps for Work Team
How do I determine, which, if any, docs are going to cease to function post 4/20? Is there a way to organize my current list of docs (I have many) to see how many I need to pay attention to? In terms of migrating, is there a migrating tool available online?
From what I have read, I feel like this doesn't even pertain to my current drive. My understanding is that this is for developers not casual users such as myself. Am I wrong in that assumption?
Thank you for all your help in this matter. If I am not explaining everything to the level you need, please let me know. I am just confused by the email and want to make sure I stay ahead of this.
Best,
Nathan
The key part of the email is Our records indicate that you may have an application that uses Documents List API
If you have such an app (you should know since by implication, you wrote it), then you have a lot of work to do over the next two weeks. If you don't, then relax. Your documents are not affected by this announcement, only the app that Google thinks you once wrote.
It's possible it's referring to an app you have installed, in which case there is nothing you can do other than hope the developer has a new version.
In my case Google Apps Sync for Microsoft Outlook and Google Drive Windows seem to be the 2 applications that are requesting access to these depecrated scopes ... Come on Google, spread the word internally !

Google Drive SDK

I am developing an app in C++ which will run in a Windows desktop environment This will be distributed to a number of customers and I need to store log files from the customers in a central location where I can access them. Is Google drive a suitable platform for this and if so what is the best approach? Should I be looking at an Application Owned Account for example? Also I am concerned by the paragraph in the Google documentation:
"Note that there are limits on the number of refresh tokens that will be issued; one limit per client/user combination, and another per user across all clients. You should save refresh tokens in long-term storage and continue to use them as long as they remain valid. If your application requests too many refresh tokens, it may run into these limits, in which case older refresh tokens will stop working"
How long does a token remain valid for and what are the limits on refresh tokens?
Best regards
Trevor
You could use google drive for this, its not a bad idea really. But since its only log files you are storing and they are all owned by the application your not going to be needing to bother with user Oauth2. You could do it with a google drive service account. This way the application owns the account and they are just uploading data to it.
https://developers.google.com/drive/service-accounts

Is it possible to scale Google Apps Script?

If I write an entire web app in GAS and then it gets popular and it starts receiving a thousand requests per second. Is there any way to either pay Google to handle it, or host my GAS app on non-Google infrastructure, in the same way that here does for Google App Engine?
Your GAS script scales up automatically. The only thing that you should be worried about is your code where, if you have locks, thousands of users waiting for a lock will cause delays to the user. Other than that, scaling up shouldn't be a problem. After all, there are possibly millions of scripts being run by different users.
I've never seen Google suggest Apps Script is the tool for that kind of scale. Go to App Engine, do not pass Go, etc.
There is no third-party implementation of the Google Apps Script services. It is, however, a JavaScript implementation on Java (think Rhino) which you can run yourself - or you could run on App Engine and use the Java GData APIs to replace the Apps Script services.
if the App is running under the user account (execute the app as the user accessing the web app) it will consume each user's quotas and use their own account resources (docs, sheets, etc). This would allow for 'unlimited' scalability.
This is just my own view, am I right or totally wrong?