My company uses Google Suite and there are a handful of engineers who develop projects within Sheets (often for use by others with less technical backgrounds).
Some of these projects have involved creation of Triggers (e.g. "save the contents of this Sheet every day at midnight").
What I've discovered is that when one of those engineers leaves the company and their account is disabled, triggers written by that user become disabled and remaining users can neither view nor edit their contents. Nor can they see details of triggers created by a different (active) user.
Are there known workarounds to get the contents of this type of trigger? Or is there a better practice to employ that doesn't tie status of a trigger to the status of a user?
Google has a guide for scripts collaboration : Collaborating with Other Developers . Briefly, they suggest to save scripts in a Shared Drive as this will allow several users to do the same than the owner of a script stored in their "My Drive", but this requires the use of Google Workspace account having access to Share Drives.
If the script creators don't have access to a Shared Drive then ask them to transfer the ownership of the scripts to be used by others to a more stable user account. IMHO the best is to have a generic user account not tied to a specific person, i.e. scripts#example.com., one additional advantage is that it might help to differentiate on the version history if the changes made where done "by a real person" or by a trigger.
Another option is that the domain admin could transfer the files ownership from the disabled account to another user account, either to a real person account or to a generic account, i.e. archivist#example.com, then someone having access to that account could do find the corresponding script and do the required adjustments.
Depending on the number of engineers and size of the company you might also want to keep an inventory of all the scripts used by others and implement some sort or pair-review focused on script ownership succession.
Related
I would like to inquire for best practices in storing keys within the Google AppScript environment.
Currently, while I am prototyping, I just store the keys as local variables in the file where it is used. This key is used by all users of my App Script regardless of their domains.
Moving forward however I would like to safekeep this key in a more reliable storage. And would like to ask for advice on how to best safekeep these keys.
Currently, I am thinking of :
Using PropertiesService.getUserScriptProperties().setProperty(key,value) as this is shared by all users.
as part of the manifest? Is there a way to add userData in the contextual and homepage triggers?
Or just keep using local variables as the code is not visible to the users anyway?
Thank you all in advance.
I understand that you ask about the best way to store a static key that would be retrieved by anybody who runs your Apps Script project, being indifferent to its domain. I also assume that the script is being run as the owner (you) and that the final users shouldn't be able to read the key, please leave a comment if that isn't the case. With this situation you have the following approaches:
The straightmost approach would be to use the Properties Service. In this particular scenario the key should be accessible to anyone executing the script, therefore PropertiesService.getScriptProperties() is the way to go (you can learn more about other scenarios here).
As an alternative you could store the key in your own database and use the JDBC Service to access it. This method is compatible with Google Cloud, MySQL, Microsoft SQL Server and Oracle databases. Here you can learn more about reading from a database.
Another possible choice is the Drive API. You could take advantage of the application data folder since it is intended to store any files that the user shouldn't directly interact with. For this option you would need to use the Advanced Drive Service on Apps Script.
Please be aware that an admin from your domain could access (or gain access) to the stored key. Also please check the quota limits to see if it fits your usage.
As you may have noticed, the PropertiesService provides several methods for storing key/value at the document's level, user's level or script level:
getDocumentProperties()
getUserProperties()
getScriptProperties()
I'd recommend to store a property based on who needs access to it. If only the authenticated user should have access to a property (such as for example a setting relevant only to its accounts, like it's locale language), go with the UserProperties. Contrary, if the property is relevant to a document (Google Docs, Google Sheets, etc.) go with the DocumentProperties.
With this said, I wouldn't recommend using the ScriptProperties in general. The main reason being that quota applies to the PropertiesService (see table below). This means that as your add-on gets more and more users, you will hit the quota limit quite rapidly.
| Service | Consumer accounts (e.g. #gmail.com) | Google Workspace accounts |
|--|--|--|
|Properties read/write | 50,000 / day | 500,000 / day |
Source: https://developers.google.com/apps-script/guides/services/quotas
Depending on your use case, you might also be tempted by alternatives to the PropertiesService:
using local variables in your code - as you mentionned
using the CacheService - which store data for a limited period of time.
making request to a distant server where you could query your own database.
We heavily rely on the latest at my company, thanks to the UrlFetchApp service. The main reason being that it allows us to pull a user profile from our database without making updates to the codebase.
I think I made a big mistake.
I was asked to investigate Office 365 vs workspace and took out a workspace trial. In hindsight, I probably should have created a new workspace account to try this.
To be clear for a long time we have had access to and used the "Google Workspace Admin console" purely to setup our organisation and adminster users for compute engine projects. I am not sure why we would have had access to this without a paid account. (possibly we used g-suite before. It's not clear to me whether companies are able normally able to access this without a paid account.) I assumed this was akin to the free azure organisation/user setup. Nowadays, I believe we would possibly be advised to use Google Identity in this situation.
Having taken out the trial I understand from workspace support that at the end they will delete my existing organisation and users; they cannot not switch me back to an "identity only" version of workspace we seemed to have before, and are therefore forcing me to sign every user up to workspace even though we don't need it at this point. Is this the case or are they advising me incorrectly?
Assuming they are correct, I cannot sign our company up to google identity, since our domain is owned by the soon to be deleted workspace account.
Therefore my worry is that my business is about to lose access to our compute engine organisation and associated logins, as well as google domains.
The only options I can see are to pay for workspace for our users every month, or create a new organisation in cloud identity, transfer the compute engine projects, wait for the workspace account to be removed, then reclaim our main domain and recreate all the admin users. (I am not sure whether we can move a project out of an organisation once there.)
Is this even possible, and what are the dangers? Are there any other options?
If you have a GCP organization and access to the Admin Console, you must have some subscription. You can see your subscription(s) in the Admin Console under Billing > Subscriptions.
It's possible to add or change subscriptions, but there are some restrictions: For example, if you currently have a G Suite Legacy subscription, you might not be offered the ability to add a Cloud Identity Free subscription. But there are ways to deal with this -- for example, by temporarily upgrading to a paid plan, and then switching to Cloud Identity Free.
Support should be able to help you find a way that doesn't require deleting and re-creating your account/org.
Johannes Passing is correct.
admin.google.com on the home page says "Welcome to the Google Workspace Admin console" - this is confusing since the portal is also about administering organisation and users through cloud identity as well (it could be better named for example "Organisation Admin console")
In addition, there are actually different answers from google:-
This one (which I originally read) says "If your trial period ends and you haven’t set up billing or verified your domain, your account will be automatically deleted" and also "You won’t be able to access Google Workspace after completing the steps."
https://support.google.com/a/answer/6388094
...but this one correctly says "Note that cancelling Google Workspace doesn’t remove user accounts, groups, or your organizational structure"
https://support.google.com/a/answer/1257646
Together this gave the impression that access to admin.google.com may be completely removed, if a subscription is removed. I can clearly see that I also have a subscription to Cloud Identity Free.
I programmed a web app and now i need to deploy it for my organization. There are 500 potential users. What factors i need to consider before the deploy? There's an easy way to deploy it? there are limitations to consider? what risks there are? there are a model or can you give tips or experiences for the deployment?
There are no definable risks or dangers, it all depends on what your application does.
When you choose who are the users authorized to access, you will inevitably have to select anyone within your organization, otherwise only you (or the account with which the script was created) will be able to access. While as for the execution mode, you will have to choose how you or the user who accesses the application. This is important because if the application accesses an external service, such as Google Analytics, it can do so as the user with whom the application was generated or as the user who is accessing the application. Based on that selection you will see the Analytics data of one or the other Account.
So it all depends on what your application does and how it is to be used.
Let's say I want to build a simple register:
There are Persons Informations and Relationships.
Each Person has a name and a variable amount of Information attached to it.
Each Information has a label and a description.
Each Relationship has two Persons and a description.
As for views, when I click on a Person, it should give me all the information I have about that Person and provide links to all other people this Person is in one way or another connected to.
(probably) simplest design: relational database backend
So the way it's in my head, right now, a user would log in to the app with his google account. The app then creates the database(s) it needs in the user's drive and allows the user to add and delete Persons and Informations as well as connect two Persons with a description of their Relationship.
I'm kind of surprised Google still hasn't added a database application to its rooster.
And since basically everything I found that uses Google Drive as a "database" makes use of its Spreadsheets, I kind of wonder whether it's even supported or if I'm not better off thinking about a file-based approach.
So can you add a database to Google Drive at all? And if you can, where would I find more information about the how?
With thanks to Andrew Roberts, commenting on my question Library function accessed as timed trigger DriveApp I now understand that triggers are visible only to the user who created them. Two users (User A and User B) have split the task of adding the same timed trigger scripts to a large number of spreadsheet objects. Users A and B are interchangeable members of a team. Unfortunately User A can't see triggers established by User B and vice versa. This makes management of triggers somewhat challenging. My questions are:
Is there really no way that users in a multi-user team can see all
triggers created by all other users in the team?
What happens when User A leaves the organisation? Will the
spreadsheets that received User A's triggers just lose the
functionality provided by those triggers?
Short answer
If you need that your team manages installable triggers collaboratively then create an account specifically to manage them an other project assets that could not be transferred between accounts.
Extended answer
Is there really no way that users in a multi-user team can see all
triggers created by all other users in the team?
Unfortunately there is no way.
What happens when User A leaves the organisation? Will the spreadsheets that received User A's triggers just lose the functionality provided by those triggers?
It depends on the account type and the leaving user goodwill.
The triggers will work until someone using the account who created the installable triggers delete them and if this account is the spreadsheet owner they could be the only one able to transfer its ownership to another user from the same domain.
If you are using consumer accounts the only way to transfer one account from one user to another is by given knowing the password and "being nice". If the other developer knows all the account information they could reset the password.
If you are using G Suite accounts ask the G Suite Administrator to reset the password.
References
From https://developers.google.com/apps-script/guides/collaborating#collaborating_with_team_drives
Collaborating and triggers
When you collaborate on a project, any installable triggers that you create are not shared with those who
have access to your project. If you need to have a consistent trigger
setup for all collaborators, you can use the Script service to create
triggers programmatically, at run time. For more information, see
Managing Triggers Programmatically.