I need to delete permanently a Google Workspace Organization (for a final customer). This organization have an active project in Google Cloud that definitevely locks deletation of Workspace Organization. The project has been created by the system called "apps-scripts".
The "apps-scripts" project was a container for scipts.google.com, that hosted a gsheet macro.
I cannot delete or leave this project on my own. It's system-wide impossible due to limitation on the right 'manage.resource.folderdelete' has been set to false by the old GSuite system. It protects well macro againts container deletation. It protects so well !
My question is ...
The Google Worskpace support (paid) team say that the problem is out of there scope.
The Google Cloud Commercial support said that only the (paid) Google Cloud Support can operate manually on project deletation.
The Google Cloud Customer Care support that only the (paid) Google Workspace support can operate on Gsuite locked project.
I tried to tell to each support, what the others said. Many screenshot. It seems, Google Workspace support and GCP Customer Care agreed, that i'm stuck in an abnormal and rare loop.
But (here comes my question ...) : Do the hell i have the only google account that :
once a Google Gsuite organization has been corretly migrated to Google Workspace
once migrated, a user generated a macro on gsheeet that needed the GCP apps-scripts in order to create a single script on script.google.com
once has decided to leave
just can not ?
GCP finally answer.
The "Folder Editor" IAM has not been replicated while GSuite/Workspace replication.
Done manually with the set-iam-policy on the organization wide folders.
In fact, the inherited Owner and Editor, doesn't allow ... folder deletion.
Related
I have an existing Google Docs add-on (with a G Suite Marketplace listing) with thousands of users, and I've made a development version of it for Google Slides that I'm ready to publish. I realized now I can bundle them together (which makes a lot of sense).
However, the instructions on how to bundle multiple add-ons seem to imply that neither one exists with a GCP project:
It is possible to bundle add-ons of different types together. This requires them to share a GCP project and G Suite Marketplace listing, as described above. Choose a standard GCP project to use for the bundled add-ons, and switch each add-on to use that GCP project.
Since I already have the Docs add-on in a standard GCP project (at least I think I do since it's available in G Suite Marketplace), can I just switch the new Slides add-on to point to it?
My goal is to minimize re-authorization of existing users as much as possible.
Also, would this approach simplify having to get my add-on re-approved? It took 6 months the first time, but that was years ago...
You can link your new Slides add-on to your existing GCP project and resubmit it for approval.
Having your users reauthorize your application will happen only if you are accessing different scopes than the last time they authorized.
In regards to the time taken for approving an add-on, there is no guarantees on time.
Before I start, I'm having the same issue as this question and this question. Unfortunately, neither of those solutions is working for me.
I have an add-on in the G Suite Marketplace. There are two separate entries, one for a Docs version and one for a Slides version. Now that the Chrome web store is being phased out for add-ons, I want to combine them into the same listing (afaik, that wasn't possible in the web store, only G Suite Marketplace).
Because of this, I now need to associate the Apps Script projects for both the Docs and Slides version with the same Cloud project. I'm hoping to migrate both to the Docs version because that has more users so hopefully fewer people will be impacted by the move.
I've taken the following steps:
Duplicate the Slides Apps Script project (to avoid messing with the original Marketplace listing until everything is set)
Go into the Cloud Platform settings for the new Slides App Script project
Enter the Cloud Platform project number for the Docs add-on
When I do this, I get an error that says "Project does not exist or you need edit access to it."
The weird thing is that if I try these steps to switch both projects to the Slides version in the Marketplace, it works. Because of this, I'm assuming there's some issue with the Cloud Platform project for the Docs version, but I can't seem to figure out what it is. Does anyone have any tips for common settings that could cause this error?
I was having the same problem and found out that it has something to do with the Shared Drive you have for a team.
Using the answer found by Ian: Google Apps Script cannot convert from GAS managed to specific Cloud Project
If the project is in a Shared Google Drive, like a team drive, you are no longer the owner (even if it says you are).
I couldn't create a new project in a shared drive and convert it to a Cloud Managed Project.
The only way I could do it was to create a new project on my account, in My Drive, and convert that to a Cloud Managed Project, THEN move it to the shared drive. (Once it is in a shared drive, you can't MOVE it back out.) However, if it is a Cloud Managed Project, you can add more scopes to the project after it is in the shared drive. - Once this new project is setup, then copy over your code for your old copy, and point all links to the new one.
I am not able to switch google cloud platform project in GAS editor.
What I am doing is…
Open the google sheet GAS editor
Open Resource --> Cloud Platform Project
Enter project number that I want to connect
With the process above, I was able to switch a cloud platform project but now it returns an error
‘Project does not exist, or you need edit access to it.’
I am using the same cloud project and same account(editor) that I used before and properly worked. I tried do the same with a owner account, but it didn’t work, either.
Also, this cloud project is not a default project nor a hidden project. (If it does, I guess it should not be able to access through GAS editor from the beginning)
I have checked documentation below, but it tells me only case when switching to a hidden project.
https://developers.google.com/apps-script/guides/cloud-platform-projects
Does anyone have a solution or suggestion??
Thank you for the help in advance.
Problem Solved.
I figured out that OAuth IDs which are generated when make connection docs to the cloud project are not be deleted even though delete actual document files.
What I have done is...
Login Google Cloud Platform
Go to APIs&Services --> Credentials
On OAuth 2.0 client IDs, delete unnecessary contents from the list
Back to your docs and switch the cloud project.
We are no longer able to associate our Apps Script projects with our Cloud platform project. When going to Resources: Cloud platform project in the GAS editor, and entering the project ID, it says "Project doesn't exist or you need Edit access to it.". The project definitely exists and the same Google account is an owner of it. With the same workflow, we previously managed to associate many projects.
Is there maybe a limit on how many GAS projects can be associated with one Cloud project? We've associated about two dozen recently, and then it started to produce this error. Or what could be going on?
This is explained in details here:
https://developers.google.com/apps-script/guides/cloud-platform-projects
Specifically, quoting:
"There may be cases in which you want multiple Apps Script projects to share the same Google Cloud Platform project. Since these default Cloud Platform projects for Apps Scripts are hidden, they cannot be used as the destination projects for a switch. If you see a "Project does not exist or you need edit access to it" error when attempting to switch a script's project, that usually means you are attempting to move it to one of these default projects.
To get around this restriction, create a new, blank Cloud Platform project, and use the steps above to add each script to that."
I was able to solve this by switching from the Classic Editor to the New Editor, adding the Cloud Project, then reverting back to the Classic Editor (if needed).
I want to develop a comercial App that works in connection with gmail, Google calendar and other Google products. For what I see, Google Apps Script would give me the required functionality but I cant seem to find the answer to a couple of deployment issues. In the Google Apps Marketplace article on Wikipedia I read this:
Google Apps Marketplace is a product of Google Inc. It is an online store designed to help people and organizations to discover, purchase, and deploy integrated cloud web applications that work with Google Apps (Gmail, Google Docs, Google Sites, Google Calendar, Google Contacts, etc.) and with third party software. Some apps are free, some are paid for. Apps are based on Google APIs or on Google Apps Script.
But then, looking into the Google Apps documentation, the only distribution mechanisms I find are the "Script Gallery" which implies access to the source code by the end user and no comercial transaction or Chrome Web Store which is bound to Chrome Browser, while what I intend to do is aimed at Google Sites or Google Apps users and perfectly Browser Agnostic. My questions are:
Can I bundle a Google Apps Script based App for sell in the Google Apps Marketplace ?
Can I deploy it without the end users having access to the source code?
The short answer is no. Google Apps Script imposes daily quotas on all of their GAS APIs. These quotas cannot be extended in any way, so it is not feasible to deploy this on a commercial scale. You should take a look at Google Apps Engine which gives much more flexibility for what you want to do.
There is a workaround that I did in the past. I had an installation script (that ran as me) that collected user properties and the actual app script that ran as the individual user and referenced the user properties collected. At the time I didn't set user script properties but you could do that to bypass the first install script I would think. When the user installed they would get an email with the user script link and then they would authorize it separately. Install link was distributed through Google Checkout (deprecated now) but you could do electronic distribution through another venue. Not a traditional app distribution process by any means but maybe it will spark an idea for your specific case.
#Javier - we too arrived at the same conclusion. Google Apps Marketplace (GAM) deployment is just one of the channels to reach businesses but its the un-extendable Google Apps quotas that cripples a commercial deployment of a Google Apps Scripts (GAS) based WebApp.
We tried listing our webapp based on GAS directly into GAM but it failed their SSO requirements as there was no way to use domain-wide delegation to authorize the GAS permissions for the end users if the webapp ran as "user accessing the web app".
While we migrate to a fully stand-alone application, we have managed to deploy a restricted version of the app to GAM indirectly using a GAE instance as a proxy.
Here is how its deployed.
The GAM listing links to a GAE proxy app.
GAE proxy does GAM compliant SSO and redirects all subsequent access to our publicly accessible webapp in "run as me" mode.
GAE proxy passes on any domain data authorized by the GAM client to the webapp.
Implement security mechanism to block unauthorized access to the public webapp and accept calls ONLY from the GAE proxy.
Our current customers (very small businesses/startups) are fine with this security model, but I am afraid this will not scale for larger commercial deployment.
#mrschwen: we too are considering your exactly approach in mind to mitigate quota issues in case our app gets wider adoption until we are forced to move out of the GAS space, even though the end users will be forced to authorize our scripts which will run as 'user accessing the web app'