I know I can use Google Apps Script to send an email from the account that is currently logged in. I'm wondering, is it possible for a "master" Script on one account to push a trigger of some kind out to a series of other Google Accounts, telling them to run their scripts?
Essentially I need to send a bunch of emails from various different accounts, and the user who runs the script won't be able to log into all of them. I'm looking for a way to make all these accounts listen for a central signal to run their scripts.
Does this make sense? Any thoughts?
Thank you,
Pacific 231
The short answer is yes...
You will have to write one script for each account that will run as a service (deployed as webApp with its own url) and your master script will have to call each of them using an urlFetch with some parameters added to the url telling them what email to send. You'll have to add some security feature to these calls.
Every webApp service will run as the user who wrote the script and will be accessible to anyone (if in a Google Apps account you will be able to restrict the use to members of the Google Apps community).
This is not too hard to do but will require some work though...
We'll be glad to help you if you meet specific issues.
Related
Just trying to get the best method for testing adding/updating contacts via a cronjob without interfering with the current contacts list. Will I need to create a new account specifically for testing?
Twilio SendGrid developer evangelist here.
If you want to make requests to the API as part of your testing (which I normally advise against, as testing 3rd party services should be unnecessary), and you don't want to affect your data, then you don't need a completely new account, but you can use a Subuser account.
I am working on setting up a few new bots for Hangouts Chat. Part of the effort involves using Hubot, which is working well. Another use case requires posting to user spaces based on external functions, which is done via a python command script. I have a project and separate service account setup for each bot, and the permissions for the bot service account appear to be the same. None of the bots have corresponding domain-wide delegation at the GSuite Security level.
We obtain the spaceid for each user via one Hubot that saves their spaceid to a database, and the python script can then lookup the user and obtain that id.
However, only one of the 5 projects appears to be able to post a message to a user space. All others get a 403 error and fail to post. The same python script is used for any of the 'bots' with the only difference being the json file used for authentication.
Not sure this is enough information. But, I wonder what could be causing this problem if not permissions?
I figured it out. The spaceid I was registering via another bot is not the same as the spaceid associated with the bot/user communication for any other bot. In other words, it appears that the spaceid a bot sees for a user is unique to its communication with the user. I will need to have users register with the bot that needs to send the message instead of a common registration bot
We've written an application to replace a third party tool to download and print jobs through Google Cloud Print. For new customers this will work well. We create the printer in the cloud and download jobs. It works. Customers up and running with the third party tool are using a printer created with that tool. I thought I'd be able to access that printer's jobs by getting the user to go through oauth authentication to give our application the permission to manage the user's printers. However, having done this and all seeming to work when I fetch jobs from that printer the response is that there are no jobs. But there is a job. Is this behaviour to be expected. Is there any way around this? We'd just like to avoid our customers having to create new printers.
The question is a little unclear; feel free to edit your question and I'll edit this answer.
Being able to manage jobs is not the same as being able to download jobs. Each printer belongs to a user, and each has a robot account. Only those two accounts (I believe) can download the job ticket and payload.
After a job is marked as completed (through the /control API), the payload is deleted.
A third user account that can manage jobs is allowed to view information about the job, as well as cancel/delete the job, but can't (I believe) download the job payload.
I have built a Custom B2B app for one of our clients. My question is how to automate the distribution of the redemption codes.
I have already looked at some of the MDM providers. Their solutions are too expensive and all we really need is a way to distribute the app from a webserver, not manage a bunch of mobile devices.
As you probably already know, when a client buys a Custom B2B app through the Apple VPP program, they get a spreadsheet with valid redemption codes for the number of licenses they have built. This spreadsheet has 2 columns: 1) redemption code 2) URL to redeem the code
I want to provide my client with a URL where they can send their users to download the app. They just don't have the expertise/infrastructure to distribute the app themselves. And emailing clients is not going to work.
I'm not a web guy, but it seems to me that we could write a webpage that would look at the spreadsheet for the next available activation code and then redirect the user to the associated URL. I'm not concerned with the number of licenses they distribute since I have another way of auditing the real number of users (Flurry). So I want this to be as painless as possible.
In fact, I have multiple clients and want to provide them each with their own URL for their clients. It seems like this shouldn't be too difficult to code.
The problem is, I'm not the guy to write that code. Any ideas on how best to do this?
Assuming that you don't want to show the user a website you should be able to do this with an online service like parse.com and the features it offers.
From a user POV you would supply them with a link which directed them to parse.com with a path and parameters indicating the action to be taken (get app) and what account is associated. This would redirect the users browser to the appropriate destination.
The main issue (and this applies to any solution) is knowing if the user actually followed through and used the code. i.e. should it be removed from the DB so it isn't offered to another user in future. Then you would update the DB each time you get a new spreadsheet.
Anyway, this could be achieved with a little javascript in parse.com, specifically, by using cloud code which can interrogate and modify the DB and then redirect the user.
Obviously if you need user authentication of some kind or other restrictions then you would need to start adding some web interface on top of this in order to collect the details.
I am doing some dev work for a client. She has a Dev License should would like to put the app under but since she is non-technical it has been frustrating since she has to be the one to submit the final app.
Is there a way for a Dev License to have multiple Admins? I have it configured so I am a developer but as such I cannot do the Distribution License. Only she can do that. Is there a fix?
If you have a good relationship to your client, you might want to ask her for her login details so you can do it yourself.
There is one other possibility though: For a similar problem I was given the advice to build & archive my app and send the archive to the client. He could then resign the app using his certs, which would eliminate the need for him to do all the building stuff, not to mention it will spare you to surrender your source code. However, this will not eliminate the need for your client to enter all the meta information and so forth while uploading the app.
For the necessary steps to resign an app, see this answer.
To answer your original question: Each developer account has exactly one Team Agent. So you need some kind of workaround anyway.
There is only one administrative or Team leader per developer account. So you really need to plan on the policy for sharing use of that account from the beginning, if the required activities of the agent need to be split up among multiple parties, if you can't have one party capable of doing everything.
A shared account can be created from the beginning (either by the owner or the developer). I recommend an ADC account be created just for this purpose, instead of just using the owner's personal account and email address ( e.g. instead of mary.smith#sample.com, create and use iosdeveloper#sample.com for enrolling as an iOS developer. )
Account credentials can be "loaned" (perhaps with password changes after use).
You can be given remote access (VNC/RDP) into the owners PC or Mac (or more secure yet, a VM session) as or after they log in.
You can talk the owner though the process over the phone (or video chat, etc.).
Or, the owner can learn how to get certificates, and build or resign and submit apps themselves, perhaps using a comprehensive script.