Google Spreadsheet Addon - unsubmit pending version - google-apps-script

I have a Google Spreadsheet addon that has been running for a while now.
A few days ago, due to to a change that happened on my company's server side, I submitted a new version to be published. Usually, this takes about 30 minutes. However, this time I got a notice that my update should be reviewed.
I've got 2 issues:
1. It has been days, and the item is still pending review
2. Another back-end change caused my first fix to be insufficient; however, I cannot push a newer version while the current is under review.
My addon is currently not functional, so I'm hoping to get a quick resolution.
How can I unsubmit the existing published version?

You can fill this form, so your issue can be attended by Google: https://support.google.com/chrome_webstore/contact/developer_support/?hl=en

Related

Suddenly: Service using too much computer time for one day

I have been putting out fires all day. Can't seem to make heads or tails of this error...
Today I started for the first time after months of using the same script. It is triggered when a new record is added to a google sheet.
It seems to work on and off but every few minutes I am getting a failure notice indicating "Service using too much computer time for one day".
Looking through the documentation and the post on Stack, it is clear I am not the first to deal with this issue, but there does not seem to be any concise answer to how to resolve. I looked for some way to reach some type of google assistance but am always directed back to stack overflow to submit my issue for consideration. Understand this could be an issue with my script, but cant seem to find what might be causing this issue. Also confusing the matter is that the script does seem to be firing 90% of the time.
My questions:
How do I check the "computer time" quota?
Should I turn off that script/trigger until 24 hours have passed?
Does anyone know how to get a hold of Google support directly?
I don't know of any way that the total script run time can be seen in a dashboard.
You can see duration times of individual script executions at:
https://script.google.com/home/executions
You could scroll through your executions to look for long durations times. That might indicate an endless loop in your code.
To calculate the total run time of all your running scripts, you'd need to use the Apps Script API.
https://developers.google.com/apps-script/api/how-tos/view-processes
https://developers.google.com/apps-script/api/concepts/processes
I don't have any code to list and compile all the durations.
If anyone does, that would be very interesting.
I don't know if deleting the trigger until the next day would gain you anything. I'm guessing that it shouldn't.
Google does not provide "on demand" support people to answer questions about Apps Script. Even G Suite customers don't get "on demand" support contacts for Apps Script. You can report bugs and request features through the Google Issue Tracker, but that won't get you direct contact with a Google support person. Even if you purchase a support plan, Google doesn't have people who are designated to support Apps Script. If you purchased a support plan, they might try to help you with an Apps Script question, but officially they aren't qualified to help, or obligated to provide Apps Script support. And even if a support person tries to help you with an Apps Script problem, the first thing they'll do is a search of Stack Overflow, and give you links to SO posts.
So, it's extremely unlikely that you're going to be able to talk with someone directly at Google.
The best thing to do is to review your code for performance issues. Avoid reading the writing data often. The ideal situation is to get all the data that you need just once, process it, and write it back once. Cache data if you can. Avoid lots of calls to Properties Service. Find what part of your code is taking the longest time, and try to improve it.

Google Chrome Extension Review Time process

How much time will it take for Google to finish its review for a extension before it gets published to the Chrome Web Store?
Review times vary; some reviews complete in a few hours, others take many days, and in some cases a review can take several weeks
https://developer.chrome.com/webstore/faq#faq-listing-108
Long time no review, many days, few weeks. Our users can't wait. This is reason why we moved almost feature of extension from Chrome Extension to our own app
So it's weird. The review now take 10 days because they review all versions like its new. So if you make a push and have a small fix it's another 10 days. And sometimes it is more than 10 days.
This means a different strategy towards trying to get your extension deployed. First we are setting up a testing item in the Chrome Store Dev Section so that we can test our extension extensively in Chrome.
Second we are looking at using eval() in order to put our code in a wrapper. We already do this for FF and Safari. The real goal is to move more and more of the processing to the back end so that the need for a deployment becomes rarer.
This sounds like a lot of hoops but if you look at it from Chrome's end and the issues they have had around people doing bad things with extensions this is the price that has to be paid in order to be able to make extensions from their point of view.

Why is the OneNote API lagging by roughly 3 days on my account?

In short, getting page information for my notes through the OneNote API has data that lags by about 3 days. Why is this the case (I assume only for me) and how can this be fixed?
I'm working on a personal R program to read my OneNote Notes. Got it up and running about a week ago. Authentication works fine and I can use GET requests to get information from the OneNote API. However, the information that is returned about my OneNote pages (using GET https://graph.microsoft.com/v1.0/me/onenote/pages) is about 3 days old. New notes from the past 3 days and changes made in the last 3 days are not reflected in this data. It is not frozen in time, i.e. checking tomorrow will give me information that is 3 days behind tomorrow. This is not solely an issue with my application, as the same behavior/results are produced through the Microsoft Graph Explorer. Does anyone have insight on how to fix this?
I can confirm this behavior is still true as of Jan. 30. Calls to get the pages of a section, or pages in general return indexes of very stale information. To test, delete or create a bunch of pages in your OneNote account, then call in the API Explorer:
GET https://graph.microsoft.com/v1.0/me/onenote/pages
You will be given information about deleted pages, and no new information for at least days after these changes have been made. If you follow the returned 'contentUrl' properties for deleted pages, the content does not exist.
It seems other endpoints in the OneNote API are not subject to this same problem. Adding/removing/updating sections, for example, results in immediate changes to the results from the API.
Sorry to hear that. Just to clarify, are you using your personal account or work account for auth?

Google Apps Script close spreadsheets programmatically

Google lists a maximum of 50 concurrent users allowed edit permission at once in a shared spreadsheet
https://support.google.com/docs/answer/2494827?hl=en&rd=1
I've got a Google Spreadsheet that will have a large number of potential editors at any moment and am concerned about idle users filling up the 50 cap and blocking edits from fresh logons. There's a lot of interaction with the data that discourages me from using Forms submissions, and there would be a large bound script to the document.
Is there an idle timeout function that can be called through the spreadsheet's bound script that will close the document or set an idle user to view only status? This is in a Google Apps for Business domain.
This is a question that was asked very often 6 years ago on the old Google product forum when I began to work with Google spreadsheets.
Strangely the question disappeared after a while and never came back (until today !)
There are two main reasons for this question to disappear :
Since Google spreadsheets are a representation of a documents hosted on a distant server, we can not interact with what happens in another user browser from a script that runs on this distant server
I suppose this is rarely an issue and that in most case it was mainly a theoretical question that vanished in real use. (but that is really a supposition, I admit...)
As far as I know there is no practical solution to avoid that situation.

How do I track users and installations on the Chrome Web Store?

I developed a Chrome extension called TabCarousel to help monitor information like our NewRelic graphs. After realizing other people might find it useful, I decided to open source it and then release it on the Chrome Web Store.
I'm really impressed with how easy it is to release code on the Web Store, but... even a couple days after the extension has been released, I still show " users" and " weekly installs" rather than something like "7 users" and "10 weekly installs". I know I've set my extension up on a few computers, and I've helped others set it up as well. A few friends have installed it too.
Why doesn't the Chrome Web Store show any users or installations? It's not showing any data at all -- that is, " users" instead of "0 users".
Am I just missing something? I've read through the FAQ, some blog posts, and even set up a Google Analytics account and entered it in the Developer Dashboard entry for my extension. I just want to get an idea of how many downloads I'm getting so I can gauge interest like I can on other projects.
This is actually a bug, and the team are in the process of preparing a fix and getting it pushed live. I don't have an exact ETA, but it should be pretty soon.
On another note, you can still use your Google Analytics accounts to detect traffic to your landing page and in your app. And if you look for the referrer chrome://newtab you will get a very good indication of all the users who are launching your app.
Just give it few days, they don't update counters in WebStore too often. Currently it doesn't show users for any extension submitted after June 15, and yours was submitted on June 19.