We'd like to extend our quota limit from 1kk to around 20kk. We were already hitting limits, so we lowered frequency of our requests, and submitted https://services.google.com/fb/forms/ytapiquotarequest/. We have filled the from thoroughly and sent it three times, always with negative response from google:
Your quota extension application cannot be processed at this time
because of the following reasons:
Bad data (invalid project number)
As it says in the form:
The project number is a series of digits that can be found alongside
the Project ID in your Google Cloud Console. Please comma separate
the project numbers without additional spaces
There is only one numeric Project ID we have. When I tried fill in the alphabetic one, we received :
Project ID supplied does not exist.
When contacted Google Cloud Support, they told us that it is probably some bot who is answering this request, hence the generic answer. As well they directed us here: maybe someone of you had similar problem?
Perhaps they wish you to use the item the arrow is pointing at in the image below.
Go to Iam & Admin >> Settings
Related
I wrote two small Google Scripts that present simple forms to fill in. Most of my user community has no trouble using them. A small minority of users can never open the forms, instead they get "Sorry, unable to open the file at this time" error page for both forms. I can't find any common thread for why only some users fail. I've tested on multiple browsers on multiple machines, even on android devices, it never fails for me.
A couple of things I've noted:
when it fails for them the URL is re-written. The proper url starts with https://script.google.com/macros/s/... but for broken users when they paste that in they instead get https://script.google.com/macros/u/3/s/... (notice the "u/3" at the end)
There is no execution log created when they try to access the site, so I have no way to debug what's going on.
The app is permissioned so "Anyone" can access it, and it runs as my account
Sorry, I realize this problem description is impossibly vague. Any debug suggestions would be extremely welcome. I'm not a regular Google App Script developer, so I'm kinda stumbling in the dark with this one. Thanks in advance.
/u/3 means that the user have signed-in into multiple Google accounts, the number correspond to the zero-based index of the account in the order that the user followed to sign-in, 0 is for the default account, 1 is to de second account, 2 is for the thirds account and so on.
So, on your test include this use case, a user signed-in into multiple Google accounts.
NOTE: It's known that the HTML Service do not handle as expected this use case.
Related
AuthMode gets confused w/ multiple logged in users
We're sorry, a server error occurred while reading from storage. Error code PERMISSION_DENIED
Why is my script pushing an incorrect URL? [/u/2 inserted into script URL] (possible duplicate)
The new platform API at Clickatell seems to not allow you to add "from" to the JSON payload, complaining that it not a 2 way integration, but the is no possibility to add a text moniker to the short codes so that instead of the number "COMPANY" would appear
This is possible with the older api. Clickatell endpoints, and wondering if anyone can confirm that this functionality is actually removed, but better still suggest a workaround if it is
They used to allow this a long time ago (TPOA - transmission path originating address)... looks like the API's haven't been updated to reflect that now it's not a free-for-all, but restricted to short or long codes you have purchased via them.
The Platform account doesn't have the sender ID feature - however, the FROM parameter is still available for any two-way integration with an active two-way subscription. The subscription can either be for a short code or a long number, if specified in the message submission. If the feature is supported by suppliers and network operators, these messages will deliver with the short code or long number specified.
When I make an API request to Google places API one of the fields I get back is "reference".
It is not documented in the API documents. The value appears like a long hash code.
Is this versioning for the places details? For instance, does this reference stay the same until something like phone number or name is changed?
I am looking for a way to cache results. I was going to do it by date of request but if this value is for versioning of the record then it will be ideal to check against the cache.
I can't find any mention of it on developer site but value appears to be consistent so I figured this might be the case.
Does anyone know for sure one way or the other?
From the web service documentation (same is true for the Google Maps Javascript API v3):
Note: The id and reference fields are deprecated as of June 24, 2014. They are replaced by the new place ID, a textual identifier that uniquely identifies a place and can be used to retrieve information about the place. The usual deprecation period of one year has been extended, as we’re looking into ways of ensuring this change will not break existing code. We’ll update this page with a final notice at least 90 days before we change the way the API handles the id and reference fields. We recommend that you update your code to use the new place ID instead of id and reference as soon as possible.
I'm following the Quick Start Guide, as I've just received my credentials. I went through the coblogin and user (consumer) creation successfully. For test purposes, I was able to search and list sites and infos.
When I try to invoke addSiteAccount1 using the user session token for the consumer that I create, I get an HTTP 200 response and no apparent error, no exceptions or messages. The JSON response is basically the same as the one listed in the API documentation page, however there's no ID I can use to list transactions. I'm using a real login/password account information on Chase (site ID 643).
By the way, if I use random strings for credentialFields[0].value (username) and credentialFields[1].value (password), I get the same JSON response.
Please help me clarify what is not working here.
addSiteAccount1 API will give you a response which should contain "siteAccountId" field this is the identifier for that particular user's Chase bank site.
This siteAccountId will have itemIDs which resembles different 'container'(in Yodlee terminology) like, all saving and checking accounts comes under bank container,while credit card comes under credit's container similarly loan and mortgages are other containers.
Now even under a specific container you might have multiple accounts for e.g., Chase Bank container you might have 1 saving's account and 1 checking account, for each there will be an itemAccountId available. This uniquely identifies that specific account and you can pass this itemAccountId (which you can get from getItemSummariesForSite API) in executeUserSearchRequest API to get the transactions belongs to this specific account.
For further help here is the link for the API flow which will give you an idea about how and when to use different APIs.
OK, I think I got it working, but maybe some documentation clarification is needed. Provided that all mandatory parameters in the addSiteAccount1 are present and contain no errors, the method call will be successful for a given consumer.
I then visited the getAllSiteAccounts method, which would show me all account aggregation for that user/consumer. I was able to see all accounts added, some had a message like "REFRESH_COMPLETE" and others would have "AUTH_FAILED". It seems that once one adds an account, the Yodlee robots will try to login and then synchronize the data for a given account. Makes sense?
I was only able to verify if the bank credentials were OK by calling another method.
I'm facing an issue with an application I'm developing using Google Drive.
I have a Google group with some users inside, and I share a collection with this group.
When I try to find this collection using Google Drive API (files().list()), as one of the users of this group, the collection shows up properly.
However, if I add another user to the group (either using API or Google CPanel), and try to find the collection using Google Drive API as this user, the collection doesn't show up, as if the user is not able to see it even though he is in a group allowed to see the collection.
If I manually open once the collection through my browser, then the collection is showing through Drive API.
Is this a normal behaviour ? In my use case I cannot expect from the users to open in their browser each and every collection shared with them in order for the application to work.
Any insight?
I opened a Google Support case about this and apparently this behavior is "expected". Here are some excerpts from my exchange with "Angel" from
Google Enterprise Support (typos corrected and emphasis mine):
After reviewing the stackoverflow question, we need to clarify to you that the behavior shown is expected. When adding a user to a group, this group must be added again for any files that it has been shared with.
and
All information previously provided is from internal documentation for Drive UI; however the functionality is the same for SDK, therefore, group must be deleted and added back to the list of users that have access to files/folders after adding a new member.
So, there you have it. Not sure if #Burcu will ever come back and confirm.
<EDIT> It gets worse. According to this Google document, groups with more than 200 members will never see files shared with them, even if you delete and add the group back. </EDIT>
Useless post-answer rant follows:
This behavior, even if it is "expected" by Google, does not seem to be properly documented, and it is neither expected nor usable by clients of the service. How are we supposed to know when a user has been added to a group that has items shared with it? Are we supposed to constantly monitor group memberships as well as maintain a list of all things shared with the group and then *re*share them with the group when the membership changes, just to get consistent behavior? It makes me wonder why Google doesn't already do this on the back end; it can't be that expensive to register a list of callbacks with a group that are triggered upon membership changes. And the requirement that we actually unshare is even more bizarre, since it necessitates a short period of time during which nobody in the group can access the resource.