Status Update
Comments
he...@streak.com <he...@streak.com> #2
source:
add-on listing:
Because I've made the add-on "unlisted" there are slightly different reproduction steps:
* Steps 1-4 are the same as in my original post
5. In the Incognito window that you're testing this in, open the following link
The "authouser=1" query parameter is very important in the above link as otherwise the add-on will be installed for the "default" account and the issue won't express.
6. Click the "+ Free" button on the above linked page to install the add-on
7. In the new Sheet you will be brought to after clicking "+ Free", wait a few seconds for prompt to appear. Click "continue" and then authorize the add-on
8. Open the Dev console
9. Go to "Add-Ons" => "Auth Issue Tester" => "Open Sidebar"
10. Note the error printed to the console and inserted into the sidebar
Demo of the above listed steps 5-10:
mc...@google.com <mc...@google.com> #3
am...@labnol.org <am...@labnol.org> #4
ma...@gmail.com <ma...@gmail.com> #5
al...@gmail.com <al...@gmail.com> #6
Since yesterday, I am getting an exception when calling showSidebar() function with in onOpen().
I am building custom menu onOpen and calling showSidebar() function with in onOpen(). I want run check a few things in a Google Sheet every time the file is open and display an alert and sidebar if certain condition is not met.
The functionality was working perfectly, until yesterday!!
Below is the error that I am getting onOpen()
"You do not have permission to call showSidebar"
I have been using the same script from beginning of this year and never had this issue. I started seeing it since yesterday. Just wondering recent changes to OAuth scope to include " container.ui " is causing the issue.
go...@adelaidehillsbc.com.au <go...@adelaidehillsbc.com.au> #7
We alone received over 1000 email in one day like this for our internal application triggered either by Time or Form Submit.
We have spend over 100 hours reauthorising Google App Scrips so far. Our concern is that will this happen again and why has it happened?
------ Email Message ------
Your script, Client List, has recently failed to finish successfully. A summary of the failure(s) is shown below. To configure the triggers for this script, or change your setting for receiving future failure notifications, click here.
The script is used by the document Client List - Do Not Remove.
Summary:
Error Message Count
You do not have permission to call showModalDialog (line 16, file "Menu") 4
Start Function Error Message Trigger End
11/14/17 10:55 AM onOpen You do not have permission to call showModalDialog (line 16, file "Menu") open 11/14/17 10:55 AM
11/14/17 12:56 PM onOpen You do not have permission to call showModalDialog (line 16, file "Menu") open 11/14/17 12:56 PM
11/14/17 1:02 PM onOpen You do not have permission to call showModalDialog (line 16, file "Menu") open 11/14/17 1:02 PM
11/14/17 1:15 PM onOpen You do not have permission to call showModalDialog (line 16, file "Menu") open 11/14/17 1:15 PM
Sincerely,
Google Apps Script
sr...@mecojax.com <sr...@mecojax.com> #9
al...@gmail.com <al...@gmail.com> #10
mc...@google.com <mc...@google.com> #11
fr...@streak.com <fr...@streak.com> #12
mi...@gmail.com <mi...@gmail.com> #13
al...@gmail.com <al...@gmail.com> #14
[Deleted User] <[Deleted User]> #15
mi...@vertify.ro <mi...@vertify.ro> #16
[Deleted User] <[Deleted User]> #17
ja...@voicemediagroup.com <ja...@voicemediagroup.com> #18
[Deleted User] <[Deleted User]> #19
[Deleted User] <[Deleted User]> #20
[Deleted User] <[Deleted User]> #21
su...@domodi.pl <su...@domodi.pl> #22
al...@10clouds.com <al...@10clouds.com> #23
es...@303mullenlowemediahub.com.au <es...@303mullenlowemediahub.com.au> #24
dr...@hotmail.com <dr...@hotmail.com> #25
mi...@vertify.ro <mi...@vertify.ro> #26
ej...@gmail.com <ej...@gmail.com> #27
da...@gmail.com <da...@gmail.com> #28
ma...@gmail.com <ma...@gmail.com> #29
ro...@gmail.com <ro...@gmail.com> #30
Note that there are 2 cases to handle. The "authorization is required" error is thrown when the other account has not granted permissions to your script. But if both accounts have granted permissions, then the script might run well with the permissions of the wrong account (which might be worse: eg: emails being sent from the wrong account).
wo...@gmail.com <wo...@gmail.com> #31
mi...@gmail.com <mi...@gmail.com> #32
oh...@gmail.com <oh...@gmail.com> #33
tr...@gmail.com <tr...@gmail.com> #34
How do you test for that?
If you want to "manually" verify that this is a problem, you can test for whether this is related to the multiple accounts issue, by either having the person log out of all accounts, and then log back into the account that installed the add-on, or have them open up the Chrome browser in incognito mode, and log into the account that installed the add-on.
The problem occurs when a google.script.run.FUNCTION() call is made from the HTML after the HTML in your Web App, sidebar, dialog box has loaded.
When the HTML first loads, you must run a scriptlet, which runs on the server, and get the effective user. That gives you the account name that the Apps Script code is running under. Then, as soon as the HTML loads, you immediately make a google.script.run.function() call to the server and get the user account name again. Then if the two are not the same, there is a problem.
function getAccountName_() {
//Put user email into html when it loads for determining whether user is the authorized user
return Session.getEffectiveUser().getEmail();
}
<input id="idAccountOfEffectiveUsr" type="text" style="display:none" <?!= getAccountName_() ?>/>
<script language="javascript">
//console.log('it ran on load one')
window.onload = function() {
google.script.run
.withFailureHandler(failedAcctTest)
.hazAcctConflict()
//console.log('it ran on load two')
//AlanWells.shwFirstTimeHlp();
};
window.failedAcctTest = function(rtrn) {
var usrWhoLoaded = document.getElementById('idAccountOfEffectiveUsr').value;
if (usrWhoLoaded !== rtrn) {
showErrMsg('The Add-on loaded under the account: \n\n' + usrWhoLoaded + '\n\nBut you are also logged into ' +
'account: ' + rtrn + "\n\nYou are logged into multiple accounts which has caused an authorization error. \n\n" +
"You must either log out of all accounts, and log back into the account that installed the add-on; or open " +
"an incognito window, log in and use the add-on from that window");
}
}
</script>
bp...@gmail.com <bp...@gmail.com> #35
pa...@gmail.com <pa...@gmail.com> #36
he...@streak.com <he...@streak.com> #37
Using a given Add-on in an Incognito window is an effective workaround for this issue as one usually only signs into a single Google account when using an Incognito window, which fundamentally sidesteps this issue.
Using an Incognito window effectively circumvents this issue, but is not a "solution" or "fix".
pa...@gmail.com <pa...@gmail.com> #38
he...@streak.com <he...@streak.com> #39
Posting mainly for the sake of not letting this ticket go completely inactive.
ga...@daksys.com <ga...@daksys.com> #40
Since I'm the developer of the add-on, I just remove the manifest file attached to the add-on, and rerun it. After authorizing with new permissions, it works.
mi...@gmail.com <mi...@gmail.com> #41
ph...@gmail.com <ph...@gmail.com> #42
de...@smashtech.com <de...@smashtech.com> #43
sk...@maplight.org <sk...@maplight.org> #44
mi...@gmail.com <mi...@gmail.com> #45
aj...@gmail.com <aj...@gmail.com> #46
Implement some code to automatically explain it to them, so you won't need to.
Code posted at GitHub
fa...@thexs.ca <fa...@thexs.ca> #47
This issue scares away most of new users using multiple accounts and consume a daily quota of time and effort from the developers
Could you please, fix this issue or at least tell us you are doing something about it?
Thanks
sy...@gmail.com <sy...@gmail.com> #48
kr...@gmail.com <kr...@gmail.com> #49
fa...@thexs.ca <fa...@thexs.ca> #50
Still strong as New and Unassigned
he...@streak.com <he...@streak.com> #51
Happy Birthday authorization issue!
It's been amazing watching how little you've grown or changed.
en...@gmail.com <en...@gmail.com> #52
kr...@gmail.com <kr...@gmail.com> #53
wa...@gmail.com <wa...@gmail.com> #54
on a related issue..
does anyone have a "best practice" for the following use case:
* a google apps script is deployed as a web app (ex: "
* the script is hosted on another domain (ex: "
* when a visitor loads the iframe but is not presently already logged into any Google account, the iframe contains an empty document
* console shows the error: "Refused to display '
* this is in contrast to what happens when the web app is loaded directly (outside of any iframe) and the window automatically redirects to a login screen
I tried using Google Sign-in for Websites, obtaining a clientID for the custom domain:
* when the visitor comes to the domain and is not presently already logged into any Google account, this will allow the visitor to log in (ex: account #0).. after which, the content in the iframe can load properly
* when the visitor is already logged into one single Google account (ie: #0), the visitor would still be required to click the "log in" button.. and then select the account (ie: #0).. in order to authorize the site
* when the visitor is already logged into multiple Google accounts (ie: #0, #1, #2, ...), the visitor would still be required to click the "log in" button.. and then select an account from a list.. however regardless of which account is selected.. the content that loads in the iframe will always see the "active" account (ie: #0)
I'm still trying to figure out an adequate workaround for this situation.. and haven't found any that would be satisfactory to visitors..
Google: please fix this issue on the backend.. and add support to Google Apps Script for selecting between multiple active user accounts.
Also, it would be VERY helpful if web apps loaded within an iframe could follow the same authorization workflow as occurs outside of an iframe.. which is to manage the login process when needed.
Thank you.. hope to see you again before next year's anniversary!
da...@gmail.com <da...@gmail.com> #55
[Deleted User] <[Deleted User]> #56
mi...@gmail.com <mi...@gmail.com> #57
[Deleted User] <[Deleted User]> #58
an...@gmail.com <an...@gmail.com> #59
sa...@gmail.com <sa...@gmail.com> #60
Either, Google is OK with multiple account sign-in on a single browser; or it is not.
Looks like Google wants us to continue to be able to use multiple accounts --- then PLEASE FIX this bug!!
ma...@gmail.com <ma...@gmail.com> #61
do...@gmail.com <do...@gmail.com> #62
kr...@gmail.com <kr...@gmail.com> #63
ek...@google.com <ek...@google.com>
en...@gmail.com <en...@gmail.com> #64
ek...@google.com <ek...@google.com> #65
The history here is that for a long time Google's multi-login feature only allowed you to be logged in to one @
As mentioned earlier in this issue, the best you can do at the moment it try to detect this behavior and show an appropriate warning to the user. I'll raise this issue again with the engineering team to see if we can get some traction.
he...@streak.com <he...@streak.com> #66
ha...@gmail.com <ha...@gmail.com> #67
ce...@gmail.com <ce...@gmail.com> #68
mi...@gmail.com <mi...@gmail.com> #69
sm...@gmail.com <sm...@gmail.com> #70
op...@gmail.com <op...@gmail.com> #71
bz...@gmail.com <bz...@gmail.com> #72
mi...@gmail.com <mi...@gmail.com> #73
Kindly request to solve this issue.
ek...@google.com <ek...@google.com> #74
sw...@gmail.com <sw...@gmail.com> #75
mi...@gmail.com <mi...@gmail.com> #76
he...@streak.com <he...@streak.com> #77
mi...@gmail.com <mi...@gmail.com> #78
This is a nightmare, Users are complaining severely.
jo...@b-advised.org <jo...@b-advised.org> #79
mi...@gmail.com <mi...@gmail.com> #80
ve...@gmail.com <ve...@gmail.com> #81
mi...@gmail.com <mi...@gmail.com> #82
The issue happens in all the add-ons, for Forms and Docs as well.
co...@gmail.com <co...@gmail.com> #83
vi...@tutteo.com <vi...@tutteo.com> #84
me...@gmail.com <me...@gmail.com> #85
ha...@gmail.com <ha...@gmail.com> #86
te...@supermetrics.com <te...@supermetrics.com> #87
ch...@gmail.com <ch...@gmail.com> #88
ki...@gmail.com <ki...@gmail.com> #89
um...@gmail.com <um...@gmail.com> #90
mi...@gmail.com <mi...@gmail.com> #91
On Tue, Oct 8, 2019, 1:23 AM <buganizer-system@google.com> wrote:
vn...@gmail.com <vn...@gmail.com> #92
ml...@click2mail.com <ml...@click2mail.com> #93
ek...@google.com <ek...@google.com>
fa...@thexs.ca <fa...@thexs.ca> #94
... just marking the date
🎂🎂
@google: any update or good news coming ??
hw...@gmail.com <hw...@gmail.com> #95
he...@streak.com <he...@streak.com> #96
Happy birthday issue #69270374!
I never would have guessed we'd make it this far together.
sw...@gmail.com <sw...@gmail.com> #97
too, that includes right-click Google Drive.
Steve Webster
On Wed, Nov 13, 2019 at 4:39 PM <buganizer-system@google.com> wrote:
ha...@gmail.com <ha...@gmail.com> #98
ch...@gmail.com <ch...@gmail.com> #99
I can imagine more users may encounter this same issue.
It's been two years. Will anyone please take care of this bug? Finger crossed.
[Deleted User] <[Deleted User]> #100
le...@google.com <le...@google.com> #101
Hi All, thanks for the diligent follow-ups! Want to rest assure you that while I can't comment on the status of this bug, the team is very much aware of it. I'll update this when a more substantial update is available.
dw...@gmail.com <dw...@gmail.com> #102
dj...@gmail.com <dj...@gmail.com> #103
No hard feelings, but 2 years for this?
[Deleted User] <[Deleted User]> #104
an...@balsamiq.com <an...@balsamiq.com> #105
dj...@gmail.com <dj...@gmail.com> #106
to...@tillerhq.com <to...@tillerhq.com> #107
sd...@family-support.org <sd...@family-support.org> #108
dj...@gmail.com <dj...@gmail.com> #109
wa...@gmail.com <wa...@gmail.com> #110
dj...@gmail.com <dj...@gmail.com> #111
ma...@gmail.com <ma...@gmail.com> #112
Do you guys need engineers?
I'm looking for a job.
ne...@gmail.com <ne...@gmail.com> #113
mi...@gmail.com <mi...@gmail.com> #114
No engineer is concerned about this issue so far.
I am already frustrated with this issue. Thanks to Romain Vialard for his
code snippet.
On Fri, Mar 20, 2020, 9:20 PM <buganizer-system@google.com> wrote:
dj...@gmail.com <dj...@gmail.com> #115
Could we get any answers?
ty...@ashleyvance.com <ty...@ashleyvance.com> #116
sa...@gmail.com <sa...@gmail.com> #117
To all subscribed to this issue:
There is a workaround, which I succesfully implemented in my addon 2 years ago, when developing it.
You probably just need to check if current user equals to document owner, and depending on that either use functions that require auth.FULL mode, or just show a sidebar with information for user, that he should log into document owner account.
var owner = Session.getEffectiveUser().getEmail();
var current = Session.getActiveUser().getEmail();
if (current == owner) {
//YOUR CODE FOR AUTH.FULL
} else {
//YOUR CODE FOR AUTH.NONE/LIMITED
}
dj...@gmail.com <dj...@gmail.com> #118
su...@childrenshome.us <su...@childrenshome.us> #119
The only way around this, without having the user sign out of the account, is to set the application as publicly accessible. Clearly I don't want the application to be public, or I wouldn't have put it on our G Suite site that's private, right? I don't have a choice there, so now that's done, I realize Google Sites doesn't allow the app to remain in it's ridiculous series of built-in iframes on the page, so when you change pages, it opens them on top(changes to the url of the application). Still works! Still Happy! ... wait... that means anyone and their brother can use my app if they have the link that's right there in plain sight in their search bar. (Yes, I know someone would essentially need to send it to them, but it's an unnecessary vulnerability now that the private information can be reached publicly.)
I'm trying really hard to be a nice admin and not make people log out of their accounts, so I use the Session.getActiveUser().getEmail(); and check if they're a part of my domain to grant access. Not a big deal right, they are on the site, it's working, and they are a part of my domain so, according to Google, it should work perfectly. (Just a reminder, they are logged in to a private Google Site that verifies they are using Google Suite Domain credentials to access a Google App Script.) Alright back on tra... WHAT!? If they are logged in to any other, non-my-domain account, it returns nothing. Zip, zero, nada, zilch. Great, can't fix it programmatically or by using all of the many broken Google settings, so let's tell the users to sign out of their secondary accounts.
I go click on the avatar, and go to sign out of the second account, and my only option is sign out all. OK, I'll sign everyone out, then sign just the good user back in. Everybody out, logged the good user back in... and there are still 2 accounts. I did a little digging and found out that the only option to log out of a secondary user account is to remove the account. OK, so keep reading, how do I do that... of COURSE YOU CAN'T! You have to essentially reset Chrome to log out of a second account. For multiple user stations, if you don't want to make them all sad, you can delete cache folders for just the effected users.
So, to recap. In an effort to increase your viewing pleasure Google has removed all app script security, and broken a great deal of their own services and functionality. Great job guys! I hope no one with protected data is still using app scripts and sites, because it's either not accessible, or publicly available. And it's been how many years now that you've known about ALL of these things that "mysteriously" happened right around the same time, and you've attempted to fix approximately 0 of them. Seriously, go look at the issues I just mentioned, open tickets for all of them, all of them being ignored.
What good are you guys, really, if nothing you do actually works the way you say it does and makes our data unsafe?
ma...@google.com <ma...@google.com> #120
We apologize for the delay. This issue is actively being looked at and we should have an approximate ETA for resolution by the end of the week.
Thank you for your patience.
lu...@gmail.com <lu...@gmail.com> #121
fa...@thexs.ca <fa...@thexs.ca> #122
- we haven't logged this error for 5 continuous days now
- that never happened before in the almost 2.5 years of this issue's life
ch...@gmail.com <ch...@gmail.com> #123
-------- Original message --------From: buganizer-system@google.com Date: 4/8/20 11:22 AM (GMT-05:00) To: b-system+741193042@google.com Cc: christianpaul5401@gmail.com Subject: Re:
Changed
fa...@thexs.ca added
A note of cautious optimism- we haven't logged this error for 5 continuous days now- that never happened before in the almost 2.5 years of this issue's life
_______________________________
Reference Info: 69270374 Unexpected "authorization is required" error from google.script.run after installing Sheets add-on while logged into multiple
component: Public Trackers > G Suite Developers > Apps Script
status: Assigned
reporter: he...@streak.com
assignee: ap...@google.com
cc: he...@streak.com, le...@google.com, mc...@google.com
type: Bug
priority: P1
severity: S2
blocked by: 132238897
hotlist: Google Domain
retention: Component default
Generated by Google IssueTracker notification system
You're receiving this email because you are subscribed to updates on Google IssueTracker
Unsubscribe from this issue.
ot...@gmail.com <ot...@gmail.com> #124
The error doesn't happen when the user is using his main google account to use the script. Closing all other accounts or using the main google account to use the script seems to work, but requiring users to log-out of their accounts to be able to use our scripts or using private mode is unreasonable (i.e. in my case only members of a business have access), they would prefer to not use our script at all.
100% of my users have to be logged in multiple google accounts for work reasons. This bug is a blocker for me. Come'on Google, you guys are super smart, please help us.
ch...@gmail.com <ch...@gmail.com> #125
-------- Original message --------From: buganizer-system@google.com Date: 4/8/20 12:14 PM (GMT-05:00) To: b-system+741193042@google.com Cc: christianpaul5401@gmail.com Subject: Re:
Changed
ot...@gmail.com added
Unfortunately the error is still there, experienced it yesterday, same as always.The error doesn't happen when the user is using his main google account to use the script. Closing all other accounts or using the main google account to use the script seems to work, but requiring users to log-out of their accounts to be able to use our scripts or using private mode is unreasonable (i.e. in my case only members of a business have access), they would prefer to not use our script at all.100% of my users have to be logged in multiple google accounts for work reasons. This bug is a blocker for me. Come'on Google, you guys are super smart, please help us.
_______________________________
Reference Info: 69270374 Unexpected "authorization is required" error from google.script.run after installing Sheets add-on while logged into multiple
component: Public Trackers > G Suite Developers > Apps Script
status: Assigned
reporter: he...@streak.com
assignee: ap...@google.com
cc: he...@streak.com, le...@google.com, mc...@google.com
type: Bug
priority: P1
severity: S2
blocked by: 132238897
hotlist: Google Domain
retention: Component default
Generated by Google IssueTracker notification system
You're receiving this email because you are subscribed to updates on Google IssueTracker
Unsubscribe from this issue.
ch...@gmail.com <ch...@gmail.com> #126
-------- Original message --------From: buganizer-system@google.com Date: 4/8/20 9:04 AM (GMT-05:00) To: b-system+741193042@google.com Cc: christianpaul5401@gmail.com Subject: Re:
Changed
lu...@gmail.com added
Experiencing the same issue. Any updates?
_______________________________
Reference Info: 69270374 Unexpected "authorization is required" error from google.script.run after installing Sheets add-on while logged into multiple
component: Public Trackers > G Suite Developers > Apps Script
status: Assigned
reporter: he...@streak.com
assignee: ap...@google.com
cc: he...@streak.com, le...@google.com, mc...@google.com
type: Bug
priority: P1
severity: S2
blocked by: 132238897
hotlist: Google Domain
retention: Component default
Generated by Google IssueTracker notification system
You're receiving this email because you are subscribed to updates on Google IssueTracker
Unsubscribe from this issue.
fa...@thexs.ca <fa...@thexs.ca> #127
"A note of cautious optimism
- we haven't logged this error for 5 continuous days now
- that never happened before in the almost 2.5 years of this issue's life"
Now it is MUCH WORST than before (the caps are intended)
- Now the error that Google add-on is throwing is not catch-able from the Script
- It simple crash the sidebar with a sad icon an a message "
- showing these messages at the console
"Refused to display '
I guess Google is working on fixing this very old issue and this might be an unintended consequence
I hope Google is monitoring this issue entry ...
ch...@gmail.com <ch...@gmail.com> #128
-------- Original message --------From: buganizer-system@google.com Date: 4/9/20 11:52 AM (GMT-05:00) To: b-system+741193042@google.com Cc: christianpaul5401@gmail.com Subject: Re:
Changed
fa...@thexs.ca added
A quick follow up on my comments on #122 where I said"A note of cautious optimism- we haven't logged this error for 5 continuous days now- that never happened before in the almost 2.5 years of this issue's life"Now it is MUCH WORST than before (the caps are intended)- Now the error that Google add-on is throwing is not catch-able from the Script- It simple crash the sidebar with a sad icon an a message "
_______________________________
Reference Info: 69270374 Unexpected "authorization is required" error from google.script.run after installing Sheets add-on while logged into multiple
component: Public Trackers > G Suite Developers > Apps Script
status: Assigned
reporter: he...@streak.com
assignee: ap...@google.com
cc: he...@streak.com, le...@google.com, mc...@google.com
type: Bug
priority: P1
severity: S2
blocked by: 132238897
hotlist: Google Domain
retention: Component default
Generated by Google IssueTracker notification system
You're receiving this email because you are subscribed to updates on Google IssueTracker
Unsubscribe from this issue.
sk...@gmail.com <sk...@gmail.com> #129
ty...@ashleyvance.com <ty...@ashleyvance.com> #130
dr...@gmail.com <dr...@gmail.com> #131
What is the best way to sound the alarm on this error? I'm receiving dozens of help requests from users of my add-on and have already seen many uninstall it.
Google team, can you please revert back to the way you were doing this before, so that for the time being the error can be handled while you are finding a long-term workaround?
fl...@gmail.com <fl...@gmail.com> #132
Users logged in to two+ accounts may receive a "
Not all users are effected interestingly; I haven't found a common denominator.
Not looking forward to the inevitable negative reviews.
an...@quicklution.com <an...@quicklution.com> #133
Dear Google,
On 1 April you told us the following in a comment above.
"This issue is actively being looked at and we should have an approximate ETA for resolution by the end of the week."
Was this an April's fool joke? Over two week later we still have no ETA and no fix. This is costing a lot of issue to our and your customers. You're making customers want to go back to Microsoft 365. Get your act together and save yourselves.
This bug has been going on for about 2.5 years!!!
dj...@gmail.com <dj...@gmail.com> #134
os...@gmail.com <os...@gmail.com> #135
I am also having a similar issue when calling a function on the server-side from an HTML-service page with google.script.run
it returns PERMISSION_DENIED because it is using the incorrect account...
Any workaround to call server-side functions?
lu...@gmail.com <lu...@gmail.com> #136
[Deleted User] <[Deleted User]> #137
error persists also on ES5_DEPRECATED runtime
+1 on keeping track of the issue
e....@gmail.com <e....@gmail.com> #138
Copying above note from Google team on April 1:
"This issue is actively being looked at and we should have an approximate ETA for resolution by the end of the week."
Any updates here, Google?
ho...@gmail.com <ho...@gmail.com> #139
Recently, I received lots of support queries from my users. There are 2 cases:
- Users didn't even see the Configuration from the add-on menu, they can only see Help.
=> For this case, the customer can only contact my live chat via Help menu, and I must spend some times answering them
- Users can select Configuration and open the add-on, but can't use its functionalities because of error
No item with the given ID could be found, or you do not have permission to access it.
orYou do not have access to perform that action. Please ask the owner of this item to grant access to you.
=> This is less critical than the above issue because in this case, I can show a warning message in the add-on UI that they are logging in with multiple Google accounts
=> But in both cases, I wasted my time answering my users if they asked about this problem (which should not be an issue)
So please release a fix ASAP. Thanks!
ri...@gmail.com <ri...@gmail.com> #140
this hasn't even being fixed yet?
co...@gmail.com <co...@gmail.com> #141
gn...@gmail.com <gn...@gmail.com> #142
+1, also there is an install issue
sc...@cofm.edu.in <sc...@cofm.edu.in> #143
e....@gmail.com <e....@gmail.com> #144
ty...@gmail.com <ty...@gmail.com> #145
fl...@gmail.com <fl...@gmail.com> #146
It looks like an update might've been put through quite recently.
I'm not getting "
google.script.run calls from the UI back to the script; that use methods requiring authorization (i.e. ...getId()); now fail. Authorization is already given and the add-on is installed of course.
Even when the methods are wrapped with try/catch in the script, catch isn't thrown, and the UI doesn't react.
.withSuccessHandler and/or .withFailureHandler are not triggered.
Console reports "Uncaught".
My advice to users is to log out of Google, then log back in with the single account. Or use an incognito window. Both methods are adequate.
I'd love some feedback about timeframes; if it'll be weeks for a fix, I'll need to wrap each google.script.run call in a timer or something to update the UI.
e....@gmail.com <e....@gmail.com> #147
fl...@gmail.com <fl...@gmail.com> #148
These are provided as modals with text like: "An unknown system error has occurred. If this issue persists please leave us feedback Error identifier: erroridentifier-2020-05-11T06:10:30.606Z"
The Google add-on dev team aren't immune from the auth problems.
Opening the same spreadsheet and add-on in a private window (logged-in with a single account) does not present any errors.
I've implemented a timer to alert users when google.script.run calls don't return. Try/catch does nothing.
e....@gmail.com <e....@gmail.com> #149
br...@msn.com <br...@msn.com> #150
fl...@gmail.com <fl...@gmail.com> #151
By chance I structured my add-on so it presents a sidebar without calling any functions that might require authorization (aside from opening a UI element). I then use google.script.run callbacks in the HTML to check the user (...getEmail()), and populate more content in the UI.
Possibly why some add-on's are getting "refused to connect" but mine's not.
Test for devs getting "refused to connect": Try just returning an HTML UI without any auth dependent functions. Watch for globals.
If that tests successfully, it probably confirms the above, and you can try something like the rough patch below - remembering the errors seem to be uncatchable.
I use google.script.run calls with a timer in the HTML's <script> to do the tasks that involve auth dependent functions:
// Show a loader so it doesn't look stagnant - they might be waiting a full 8s (or just set a lower time)
var authFailureTimer = setTimeout(alertAuthFailure, 8000);
google.script.run.withSuccessHandler(loaded).nameOfSomeFunctionServerSideThatUsesAuthDependentFunctions();
function loaded(e) {
clearTimeout(authFailureTimer);
// Hide the loader
// Make use of e; update the DOM or something using information you pass-in as e
}
function alertAuthFailure() {
// Timer finished before the script returned anything. 8 seconds is a lifetime, very likely it's this auth issue
// Hide the loader
// Have a hidden modal or something that can tell the user to try again in a single-account scenario, and make that visible now
}
It would be interesting to see if there are apps that already return a UI without auth dependent functions who also get refused to connect (breaking my theory). Or if the above test and solution changes the behaviour for the better.
Fingers crossed Google wind up this before its third birthday!
e....@gmail.com <e....@gmail.com> #152
I installed this Ignore X-Frame Headers chrome plugin:
This at least loads the content, so I can see what the iframe is trying to load. It's this screen:
Choose an account to use with Google Drive:
( ) [this is the gmail address of the account I'm trying to open the add-on in]@
(Unavailable unless you sign out of all other Google Accounts and then sign in to this one. Other options)
(•) [this is "default" account in my browser, i.e. the first one I logged into]@
Sign in to another account
In other words, it's Google's standard error/logout screen that shows up when you try to access an app that doesn't work with multiple accounts. I would even be okay with this option if this could actually be displayed to the user! At least then they'd know to log out of all accounts. Maybe this screen is Google's attempt to fix this ongoing authorization problem. I don't know. Maybe this page has the X-Frame headers issue / gray screen because
I appreciate you sharing the timer solution, but I've already recently refactored my app to finally handle this ongoing issue using the try/catch approach, and I'd love for Google to just solve this.
e....@gmail.com <e....@gmail.com> #153
gr...@tablet.academy <gr...@tablet.academy> #154
Adding to the quite extensive list of previous posts. I've also faced this issue, which took me a long time to diagnose. The only workaround I've managed is to show a message to the user to log out and back in.
sk...@gmail.com <sk...@gmail.com> #155
fa...@gmail.com <fa...@gmail.com> #156
pr...@madmagz.com <pr...@madmagz.com> #157
sk...@gmail.com <sk...@gmail.com> #158
You leave TONS of people here IN THE DARK, please at least show some more professionalism and report how the update is going forward or if You are not planning to do this!!!!!
fl...@gmail.com <fl...@gmail.com> #159
Still not firing in test mode for me (remains as the previous no error/no alert behaviour).
Timer-based catches are hopefully now irrelevant (though I'll keep mine in place, given that they're still needed in test mode and I imagine possibly for some other users).
It's tough trying to keep ahead of this. Can the Google team let us know when changes are going to be implemented so we can monitor actively?
It's embarrassing to have to hear about new errors from users - particularly when it's for something that has already been accounted for, but has changed.
ja...@jazzido.com <ja...@jazzido.com> #160
We're also affected by this issue. In our case, we can work around it by disabling the V8 runtime, but backend performance is DISMAL.
mi...@gmail.com <mi...@gmail.com> #161
The Response Editor for Forms Google not start in my form.
Details for the error to the initialization: "You do not have permission to access the requested document." Options to the message: Details or Exit
Help me please! Very thanks
sk...@gmail.com <sk...@gmail.com> #162
sk...@gmail.com <sk...@gmail.com> #163
To write an ticket in gsuit:
1. visit
2. open an ticket, best with email or chat.
3. and write something like:
If I am loged in more than one gmail at once and try to use any Spreadsheet plugin with sidebar, I get an error "
This google bug is very annoying.
To repodruce:
1. Log in into gmail A, install any plugin for Spreadhseet with Sidebar, FE:"grackle"
2. Do same steps for gmail B
3. Try to open in both Spreadsheet Grackle Plugin
Result: "
If they answer You that You can use profiles or incognito or similar, just anwser them that you are not intersted in "Trick" solutions
fr...@gmail.com <fr...@gmail.com> #164
Looks like the issue has disappeared in Rhino runtime. Can someone else confirm? Still able to easily reproduce the issue in v8 though...
ho...@gmail.com <ho...@gmail.com> #165
Hi Google team,
Recently (3-4 days), I got dozens of support requests about the issue
The add-on just stops working, not sure if it's related to the fix of this issue, but I think you broke something, very serious issue.
Please check it ASAP. Thanks
sk...@gmail.com <sk...@gmail.com> #166
ja...@checksheet.app <ja...@checksheet.app> #167
At minimum can you change how the error is returned so we don't have to try and match the message in multiple languages?
Ch...@hotmail.co.uk <Ch...@hotmail.co.uk> #168
fa...@gmail.com <fa...@gmail.com> #169
tp...@gmail.com <tp...@gmail.com> #170
sy...@gmail.com <sy...@gmail.com> #171
I even disabled V8, and it seems to me the issue still persists. Will monitor closely.
e....@gmail.com <e....@gmail.com> #172
fa...@thexs.ca <fa...@thexs.ca> #173
This issue that started back in Nov 13, 2017 is not related with using V8 or not
- It just changed for the worst in last April (see
) with that un-catch-able error "drive.google.com refused to connect."comment #127
However, I believe it might be registered at stackdrive error console in two kind of messages, both from a simple onOpen function
- Too many simultaneous invocations: Spreadsheets
- You do not have access to perform that action. Please ask the owner of this item to grant access to you.
Or are those two new errors from other causes ...?
gr...@gmail.com <gr...@gmail.com> #174
The actual problem is that, when logged in with multiple accounts, all google.script.run calls will, identify the "effectiveUser" as the Default account instead of the selected account (
So for example, when logged in with multiple accounts, you would think that "ScriptApp.getOAuthToken()" would get the oAuth token of the selected user, but it will actually get the oAuth token of the Default user.
Any updates on this? It's causing a lot of weird behavior in apps for users that are logged in with multiple accounts and going around it is not always that easy.
co...@shiftschedulerapp.com <co...@shiftschedulerapp.com> #175
ch...@gmail.com <ch...@gmail.com> #176
fr...@gmail.com <fr...@gmail.com> #177
Any updates on that one?
vl...@gmail.com <vl...@gmail.com> #178
so...@gmail.com <so...@gmail.com> #179
TEACHERS NEED TO USE ADDS ON FROM THEIR WORK ACCOUNTS AND KEEP HAVING THEIR PERSONAL ACCOUNTS WORKING
aa...@gmail.com <aa...@gmail.com> #180
ka...@gmail.com <ka...@gmail.com> #181
jo...@unicolmayor.edu.co <jo...@unicolmayor.edu.co> #182
[Deleted User] <[Deleted User]> #183
mn...@gmail.com <mn...@gmail.com> #184
mk...@gmail.com <mk...@gmail.com> #185
es...@panoramaed.com <es...@panoramaed.com> #186
ry...@usetopic.com <ry...@usetopic.com> #187
ty...@gmail.com <ty...@gmail.com> #188
On Tue, Sep 8, 2020 at 8:45 AM <buganizer-system@google.com> wrote:
ro...@gmail.com <ro...@gmail.com> #189
It would be great if you could prioritize this. A lot of lost opportunity for developers and a lot of headache explaining to the users that the fault does not lie with us.
Thank you for looking into this!
jv...@gmail.com <jv...@gmail.com> #190
pw...@grackledocs.com <pw...@grackledocs.com> #191
How is it possible that Google has not addressed this in 3 years??
kr...@gmail.com <kr...@gmail.com> #192
an...@gmail.com <an...@gmail.com> #193
di...@astro.com.my <di...@astro.com.my> #194
Am using only ONE single account to sign in to google, and open incognito mode to reauthenticate my Supermetrics account using the same goolge account signed in.
However the reauthentication is failed and shows message:
"This was a YouTube reauthorization request for user but you logged in as () instead. This authentication was not stored, please try again. If you have any questions, please contact support@supermetrics.com."
Supermetrics advised that this is caused by users sign in multiple google account at the same time, but i confirm that only ONE single account is signed in to Google and incognito mode is used when performing this.
Appreciate your great help to solve this scenario.
Thanks!
fr...@gmail.com <fr...@gmail.com> #195
We launched our add-on on 9/1/2020, and are getting very bad feedback from users because of this issue.
Not only can they not access our subscription side-bars, but secondary users cannot even install the add-on.
We had forecasted thousands of subscribers by EOY, however, this issue has caused immediate exposure to
that expected sales revenue. At this rate we have no choice but to begin an investigation into Google's liability
of this exposure.
The only work around suggested in this thread is a better method to inform the user that they must use the
default user. What's more frustrating then the fact we can't get secondary users to work in any capacity at all,
is the fact that only suggested (short cut) workaround doesn't work in any capacity at all either. We are left with
pissed off users, bad reviews, lost revenue, and wasted development cycles.
Some high level technical notes:
There are means to capture the generic OAuth exceptions, however, there are no means to inform
the user if an issue has occurred or will occur at all. Once the exceptions are hit, SlidesApp and Session no longer
responsive in respect to the initiating user, rendering the add-on non-functional in all aspects. There is no method to
obtain the default user or to confirm if the active user is secondary or not prior to any template evaluations.
PropertiesService.GetUserProperties() allows us to store the account prior to processing any html templates, however,
its pointer redirects to the default user during evaluation, so it completely loses track of the initiator.
I also tried moving some transactional processing to the onOpen method. This generally works, however, I can't trust
PropertiesService to ensure consistent account usage throughout a credit card transaction, so I scratched that Idea.
I guess the next best workaround to do would be to manage new accounts, exclusive to google. I suppose we could
accomplish this with a user login creation form, and a few database tables. I hate the idea of doing this though as users
would have to login to their add-on account in addition to their google account. But I suppose this is one of the only ways
to do it until a fix from Google.
no...@gmail.com <no...@gmail.com> #196
la...@sci.pdn.ac.lk <la...@sci.pdn.ac.lk> #197
Log into more than one GSuite account in same browser (first log into : user1@abc.com, 2nd log into : user2@abc.com)
1- Now execute a Google App Script (which deployed as "me" - deployed by any user within the domain).
2- You can see, app script always run as the first session (user1@abc.com)
Problem is , there is no way to run this script as user2@abc.com in the same browser.
This is a very critical requirement for our applications.
[Deleted User] <[Deleted User]> #198
dd...@slido.com <dd...@slido.com> #199
1) It damages the user experience of your own users
2) It damages the image of your partners
3) Renders the V8 engine in AppsScript useless. We'd like to migrate but we're stuck with Rhino because of this bug. The bug is also present in Rhino runtime, but on a smaller scale
sw...@gmail.com <sw...@gmail.com> #200
Who's there?
Not google's developers to fix this damn bug.
ja...@jazzido.com <ja...@jazzido.com> #201
Let's all get ready to celebrate this issue's 3rd birthday!
do...@gmail.com <do...@gmail.com> #202
e....@gmail.com <e....@gmail.com> #203
e....@gmail.com <e....@gmail.com> #204
ra...@nomad.systems <ra...@nomad.systems> #205
pa...@gmail.com <pa...@gmail.com> #206
no...@gmail.com <no...@gmail.com> #207
mi...@louhi.fi <mi...@louhi.fi> #208
I tried to setup a script to one of my Sheets, but for some reason it creates this script under another account of mine. And I cannot change it!
I removed the account from the device (by the way it did not even show up in my Chromebook managemetn console) and tried again. Now it took the next account (also wrong).
What the heck is happening?
ba...@cactusauto.com <ba...@cactusauto.com> #209
[Deleted User] <[Deleted User]> #210
gu...@gmail.com <gu...@gmail.com> #211
an...@google.com <an...@google.com> #212
Apologies for the lack of communication on this issue
As you know, Apps Script editor doesn't support multi-login at this moment, however, it is on the roadmap (no specific ETA at this point).
For now, there are a few workarounds:
1. Share the script to the default account (UserA); or
2. Sign out all accounts (or use an incognito tab) and sign in with the editor account of the script: or
3. Use
Hope this helps!
fl...@gmail.com <fl...@gmail.com> #213
This issue is not about the App Script editor, but about basically all G Suite applications like Slides.
The problem is that when a user has multiple accounts, one of them is the default account.
Every modern G Suite extension is communicating over iframe.
When a user switches to another account then the frontend (e.g. the Slides application) is switched to this account, but the backend (= the iframe used for communication) is not, so our application always sees this default user.
I added a safety check to at least warn users about this issue, but this is seriously a flaw in programming. The feature "Switch user account in G Suite application" is only half-way implemented because it doesn't work for add-ons.
You can it try with my Slides add-on:
(1) Have two accounts and make sure you are signed in with both of them (account A, which is the default; account B)
(2) Open Slides application and switch to account B (make sure that account A is indeed marked as "default" in the drop-down)
(3) Install add-on only for account B; Make sure that account A does not have the add-on installed.
(4) Start the add-on
(5) You will get an error because the iframe thinks you are using account A, which is not the case as you switched to account B in step (2)
Link to my add-on:
pw...@grackledocs.com <pw...@grackledocs.com> #214
Can you provide a sample code for that safety check? We were not even able to get any type of warning messages to users when this happens.
It would be greatly appreciated if you could provide some guidance here to at least warn users!
Thanks!
fl...@gmail.com <fl...@gmail.com> #215
I used this sample code:
It works because the Html template is generated using the correct account B.
So it is not only erroneous, but also inconsistent ;-)
no...@gmail.com <no...@gmail.com> #216
possible qith spreadsheet plugin?
pt., 27 lis 2020, 17:01 użytkownik <buganizer-system@google.com> napisał:
da...@markanddan.com <da...@markanddan.com> #217
ju...@gmail.com <ju...@gmail.com> #218
Calender ID not found. Error " Something went wrong. Please contact the author ScriptError: Authorization is required to perform that action." When I paste in the Calender ID (gmail address), it says "Calendar not found" and the error remains. I have already authorized this add on to access my Google Calender.
ak...@mixedanalytics.com <ak...@mixedanalytics.com> #219
ma...@gmail.com <ma...@gmail.com> #220
Instead of commenting here, I suggest we should create new issues explaining the problem again and again until they notice there is something happening.
fl...@gmail.com <fl...@gmail.com> #221
On Wed, Dec 2, 2020 at 12:48 PM <buganizer-system@google.com> wrote:
--
Florian Trippel
Rebstöcker Str. 60
60326 Frankfurt
Mobil: +49 176 98166486
Email: florian.trippel@gmail.com
sp...@gmail.com <sp...@gmail.com> #222
A user has two accounts, a gsuite work account and a personal Gmail account
both linked to a chrome profile. As a user of a script this user goes into
the baked in OAuth flow to authorize the script. The OAuth flow defaults to
the Gmail account even if you explicitly choose the gSuite account in the
OAuth dialog (and to add further confusion the user's chrome profile is
their GSuite account). This gets the OAuth flow stuck in a loop.
On Wed, Dec 2, 2020, 6:48 AM <buganizer-system@google.com> wrote:
ad...@igbis.edu.my <ad...@igbis.edu.my> #223
The people menu in Chrome solves this... if you can convince the user to
actually use it consistently.
But I work in a school where I constantly have some sort of auth flow and
they're confused by it all... not appscripts or add one just google
stuff...
So I kinda think the answer here was addressing the whole shebang.
On Wed, Dec 2, 2020 at 8:04 PM <buganizer-system@google.com> wrote:
*————————————————————————————*
*Adam Morris** | ICT Coordinator | IB DP Computer Science | **IGB*
* International School*Jalan Sierramas Utama, Sierramas,
47000 Sungai Buloh, Selangor DE, Malaysia
*t *+60 3 6145 4688
*f *+60 3 6145 4600
*w *
*e adam.morris@igbis.edu.my <adam.morris@igbis.edu.my>*
* Book Me! <
*————————————————————————————*
--
*DISCLAIMER:*
This e-mail and the attachment is intended solely for the
person to whom they are addressed and may be confidential and privileged.
If you are not the intended recipient, you are notified that disclosing,
distributing, copying or taking any action in reliance on the contents of
this information is strictly prohibited. Please notify the sender
immediately if you have received this email and delete it from your system.
The recipient should check the email and any attachments for the presence
of viruses that could be transmitted via email. Email transmission cannot
be guaranteed to be secure or error-free as information could be
intercepted, corrupted, lost, destroyed, incomplete or contain viruses.
Detik Harapan Sdn. Bhd. accepts no liability for any errors or omissions in
the contents of this message which arise as a result of email transmission.
Opinions, conclusions and other information in this email that does not
relate to Detik Harapan Sdn. Bhd.'s official business shall be understood
as neither given nor endorsed by Detik Harapan Sdn. Bhd.
ki...@edu.lomma.se <ki...@edu.lomma.se> #224
@Adam Morris,
what bugs me even more, are the multiple user settings which lead you to think you can also control whether you allow secondary logins into your Work profile or not, but the settings aren't enforced on non-ChromeOS, which makes it close to pointless.
These are the settings.
- Force user to sign-in. Windows, Mac & Linux, but it doesn't force, unless you also force it with GPO or Managed Browser token.
- Disallow adding external account for Android on ChromeOS. ChromeOS only
- Block Multiple Sign-in access. ChromeOS only.
- Block sign-in to Secondary Accounts - This is the kicker, as it is also only valid for ChromeOS!
So if all users were on Chromebooks, this wouldn't be such a problem, but that's not what most non-students are using. Super annoying.
pw...@grackledocs.com <pw...@grackledocs.com> #225
Seriously though, when the development community sees such blatant disregard for an issue like this how do you expect us to have high confidence in other products like GCP?
We don't care if these are separate divisions or whatever. You are Google and you make billions of dollars. Please fix!
ro...@gmail.com <ro...@gmail.com> #226
Now that new add-ons are available in Sheets, Docs & Slides, you could try to migrate your add-on to this new framework.
For example, Publigo is an add-on for Sheets relying on the CardService and it does work when connected to multiple accounts:
If you prefer to stick to the HTMLService, an alternative solution could be to replace all calls to google.script.run by calls to the Apps Script Execution API, in which you can manage the auth token yourself, making sure that you are making the call from the appropriate account.
sw...@gmail.com <sw...@gmail.com> #227
How-to video:
Slide deck:
Kind Regards,
Steve Webster
bs...@gmail.com <bs...@gmail.com> #228
ro...@gmail.com <ro...@gmail.com> #229
You can put the Google Picker inside a web app and display it when user clicks on a link / button in your UI built with the CardService.
Actually Publigo (mentioned in
do...@bi2vi.com <do...@bi2vi.com> #230
Are there anyone found the solution for this issue?
I got same issue with Email Studio and got the report email everyday even I deleted the extension or deleted the trigger or remove the permission of Email studio ....
If you know the solution to stop it, please help.
It is bad decision when chose to install this extension.
pe...@ecgc.org.hk <pe...@ecgc.org.hk> #231
bl...@portant.co <bl...@portant.co> #232
Our current workaround is to display an error message to the user informing them to set their default account to match that of the document. does anyone else have a solution
he...@techinasia.com <he...@techinasia.com> #233
no...@40shakes.com <no...@40shakes.com> #234
va...@gmail.com <va...@gmail.com> #235
dn...@gmail.com <dn...@gmail.com> #236
da...@gmail.com <da...@gmail.com> #237
Years later and Google still couldn't solve it.
Maybe communicating with the customers that they should not use Google Chrome for my application....
ad...@infisci.com <ad...@infisci.com> #238
this is a production block. Hello Google - wake yourself up. this is S1, not S2.
cr...@gmail.com <cr...@gmail.com> #239
he...@caritawaite.com <he...@caritawaite.com> #240
un...@hotmail.com <un...@hotmail.com> #241
da...@gmail.com <da...@gmail.com> #242
without add-ons, we are blocked from adopting it for managing our markdown documents
mi...@complypro.co.nz <mi...@complypro.co.nz> #243
su...@childrenshome.us <su...@childrenshome.us> #244
sa...@gmail.com <sa...@gmail.com> #245
rebrand this as a security issue and this probably raises chances it will get fixed!
li...@gmail.com <li...@gmail.com> #246
tr...@noaa.gov <tr...@noaa.gov> #247
bs...@gmail.com <bs...@gmail.com> #248
I am worried with this official response from Google that they do not understand this issue does not only affect developers--I need to tell my non-technical end-users to login with incognito mode.
As you know, Apps Script editor doesn't support multi-login at this moment, however, it is on the roadmap (no specific ETA at this point).
ph...@gmail.com <ph...@gmail.com> #249
pw...@grackledocs.com <pw...@grackledocs.com> #250
am...@gmail.com <am...@gmail.com> #251
Can we really get this fixed asap? we're losing users because of this.
cr...@gmail.com <cr...@gmail.com> #252
pa...@gmail.com <pa...@gmail.com> #253
am...@gmail.com <am...@gmail.com> #254
One of the best software companies and this issue has been open for more than 2 years now!
pw...@grackledocs.com <pw...@grackledocs.com> #255
fa...@thexs.ca <fa...@thexs.ca> #256
Just wanted to put a number on how is this issue affecting a single add-on.
In the whole year 2020
- the ratio between unique users affected and new user installs was 7.57%
- Even though we are providing support to each of the users affected, I believe many of them abandon the add-on
So it is a double loss for us, the cost of supporting this issue and the loss of clients due to it
ma...@gmail.com <ma...@gmail.com> #257
pw...@grackledocs.com <pw...@grackledocs.com> #258
I investigated where this error was coming from previously and I could recreate it under the scenario where a user is logged in to multiple gmail accounts.
The error is generated in the addon onOpen(e) function on the call menu.addToUi();
So assuming that this issue is causing these errors in 30 days we have 4531 potential lost addon users from this issue.
I found some other users that had workarounds to this to at least notify users that it's due to multiple accounts but I could not get any of them to work. If anyone has any code examples for addons that do work please let me know.
Come on Google!!
op...@adanto.com <op...@adanto.com> #259
de...@gmail.com <de...@gmail.com> #260
[Deleted User] <[Deleted User]> #261
[Deleted User] <[Deleted User]> #262
ud...@gmail.com <ud...@gmail.com> #263
hi
se...@gmail.com <se...@gmail.com> #264
bg...@gmail.com <bg...@gmail.com> #265
Hi Team, Please resolve this issue ASAP. I have lost almost 2K customers.
pw...@grackledocs.com <pw...@grackledocs.com> #266
I was reading the book "How Google Works" over the weekend. Clearly the book is not accurate!! Hearing stories of brilliant engineers fixing problems over a weekend because they wanted to?
This issue has been around for 3 YEARS!!!
How do we get someone to respond to us?
ja...@gmail.com <ja...@gmail.com> #267
I have the same issue, and I'd like to share my point of view on it...
THE PROBLEM: Identifying the user running the script (and choosing who they execute the web app as and the permissions we have to grant them on the data destination files).
I have to "Execute the app as user accessing the web app" to identify who is running my script but then I have to share the Sheet/Doc where my code writes data to with all the list of users filling forms or pushing buttons to provide content or they can't use the web app because they don't have permission to write to it (when it's me (on their behalf, if you wish), not them, who tries to write in that Sheet/Doc... They don't know what data or where it is being written but the permission has to be granted, or not, to them. Maybe it's a problem of the permissions' scopes... But the users don't have to have access to that Sheet/Doc, as I'm the one writing there the data they provide. Also they are not allowed to see the data other users provide, which they may see having those needed writing permissions granted.
SOLUTION 1: As Google knows which Google accounts are (and have been) open in the browser, when you log in the web app it could also link which account is executing that GAS web app or ask which account should execute it if no account has been associated to that script yet. When closing all open Google sessions, the link should be deleted, just like Gmail works in a browser.
SOLUTION 2: A different approach could be, when in doubt, to internally list all the open Google accounts in the browser and check them to see if the last user used to log in the script from that device (localStorage or cookies enter the game here) is in the list and use it as default one and if not, ask which one to use showing all the open accounts list as the Google does when asking from which account do you want to grant permissions to the script.
SOLUTION 3: "Execute the app as me" and have some sort of integrated login mechanism. (A list os user/password or emails in a domain or whatever), then both problems would be solved as the Sheets/Docs or wherever the scripts write data to would not have to be shared and also the real/actual/you-name-what user would also be properly identified.
We could somehow feed the valid users' list (or rules to verify them) to the Script Properties Service to check if the user trying to login is valid or not and then use the User Properties Service or a new "Real User Properties Service" to verify and keep him/her identified. If the device where the login takes place is to be remembered too, then localStorage could hold a key/value linked to the Script Properties Service to pair the web app with the desired login account, something like the actual TemporaryActiveUserKey in the Session, but maybe not that temporary...
Just my 5 cents! ;)
ir...@gmail.com <ir...@gmail.com> #268
Hi sir my name md irshad my address at chhoti ballia uper tola ballia begusarai bihar my pin code 851211 my account no 584010110011419 ifsc code BKID0005840 sir help please request for your help please argent payment find my bank account please find payment argent my problem my mother tetment DR and medesion give me so please help
mc...@gmail.com <mc...@gmail.com> #269
ja...@checksheet.app <ja...@checksheet.app> #270
Does anyone know if this issue also applies to the new workspace add-ons?
sw...@gmail.com <sw...@gmail.com> #271
Steve Webster
On Tue, Mar 16, 2021 at 4:43 AM <buganizer-system@google.com> wrote:
va...@actridge.com <va...@actridge.com> #272
I get CONSTANT support issues, emails, and 1-star reviews from this bug. I am trying to build a small business with an add-on (
[Deleted User] <[Deleted User]> #273
ro...@gmail.com <ro...@gmail.com> #274
ja...@gmail.com <ja...@gmail.com> #275
da...@millcreekveterinaryservices.com <da...@millcreekveterinaryservices.com> #276
I should have read this board closer before developing my webapps.
Please Google. We pay for GSuite. I don't to tell my employees that they must remove all their personal accounts to reliable access my Webapps.
EDIT: Looking through the Google Cloud App Engine documentation, it looks like that is the future. ....it appears Google Scripts is a VERY LOW priority for them.
je...@gmail.com <je...@gmail.com> #277
di...@gmail.com <di...@gmail.com> #278
Workspace Add-ons are constrained to using the built-in CardService to render UI elements (and don't suffer from the multiple login issue), whereas Editor Add-ons allow you to use custom HTML.CSS and Javascript.
I suspect that Google is quietly phasing out Editor Add-ons, hence the reason there has been no progress on this issue.
I'd recommend migrating your Editor-Addons to Workspace Add-ons if possible.
no...@gmail.com <no...@gmail.com> #279
"Google Workspace Add-ons don't yet support the use of document context in editors. That is, you can't use methods such as SpreadsheetApp.getActiveSpreadsheet() to acquire the current document."
These limitations, plus acknowledged and unresolved issues such as
mean that migrating an editor add-on is currently not an option for many people.
ja...@gmail.com <ja...@gmail.com> #280
It's not a problem related only to Sheets add-ons, that have restrictions on the permissions related to code implemented as a web App.
I have the same issue with code in a .gs file implemented as a web App when reloading the page: If the authorized account is not the first logged account, the primary one, the "u0" account when reading email or the "/drive/u/0/my-drive" one when accessing G-drive, then the app breaks with the "auth required" screen.
I require my users to either log out from all accounts and log in first in the account running the app or to use a different browser to run the app with only one Google account logged in and then, in both cases, the problem is gone.
pa...@outlook.fr <pa...@outlook.fr> #281
je...@gmail.com <je...@gmail.com> #282
ga...@gmail.com <ga...@gmail.com> #283
[Deleted User] <[Deleted User]> #284
ar...@gmail.com <ar...@gmail.com> #285
pa...@gmail.com <pa...@gmail.com> #286
tb...@melexis.com <tb...@melexis.com> #287
cr...@gmail.com <cr...@gmail.com> #288
pw...@grackledocs.com <pw...@grackledocs.com> #289
aj...@gmail.com <aj...@gmail.com> #290
What should the tag be?
#AppsScriptFails
cr...@gmail.com <cr...@gmail.com> #291
-------------------------
Hey @Google, this #GoogleAppScript issue is really hurting @googledevs and is over 3 years old.
Please help.
#GoogleWorkspace @Google #AppsScriptFails
----------------------
se...@google.com <se...@google.com> #292
Hello,
Multi-login has never been supported in Apps Script and given the vast number of features and services provided by Apps Script, multi-login becomes pretty significant change with a lot of risks involved.
Our team plans to begin to work on multi-login support for the new Apps Script IDE and container-bound scripts in Q3 ‘21.
For Google Add-ons, google.script.run, and Web Apps, existing workarounds include:
- Signing out of all accounts and using only 1 account: or
- Using an incognito tab to sign in
For both the new and legacy Apps Script IDE’s, as well as container-bound scripts, existing workarounds include:
- Signing out of all accounts and using only 1 account: or
- Using an incognito tab to sign in; or
- Sharing the script to the default account (UserA) of google.com; or
- Using
https://github.com/google/clasp to manage and edit the scripts locally
Regards.
je...@gmail.com <je...@gmail.com> #293
gr...@tablet.academy <gr...@tablet.academy> #294
no...@gmail.com <no...@gmail.com> #295
je...@gmail.com <je...@gmail.com> #296
ja...@jazzido.com <ja...@jazzido.com> #297
It's safe to assume that every developer affected by this issue is aware of the workarounds proposed by
As the previous two comments mentioned, the issue here is google.script.run
and other GAS services, not the IDE.
e....@gmail.com <e....@gmail.com> #298
A workaround would be a way to tell users what to do when they encounter this error. Instead, users simply think the app is broken and oftentimes they leave a bad rating/review due to this issue.
Curious to hear how you think developers should inform their users about this problem.
pw...@grackledocs.com <pw...@grackledocs.com> #299
As others have suggested at a minimum we have to be able to notify users when this error happens. We have tried to find ways to pop up error messages or warnings however none of them have worked. For the end-user, they launch an addon and just look like it's broken. We don't know about it and then they go away and leave a bad review and we lose a potential user and potential paying customer.
Has anyone been able to find a way to at least pop up a warning message? If so please provide details. I saw some links previously but our attempts to implement them all failed.
The way I see these errors come up in GCP Error reporting is with the message:
You do not have access to perform that action. Please ask the owner of this item to grant access to you.
onOpen (Code)
In the last 30 days we have received 4,539 times! That's 4,539 times a user tried to use one of our addons that failed due to this problem.
Please find someone at Google that can understand this issue and provide some real workarounds to this issue or better yet solve the problem.
ze...@gmail.com <ze...@gmail.com> #300
pa...@gmail.com <pa...@gmail.com> #301
Who would like to raise funds for a Kickstarter campaign?
If we raised X amount of money, we would start a Facebook campaign inside "Mountain View, California, United States" to raise awareness :-D
da...@gmail.com <da...@gmail.com> #302
We are much more concerned with communicating with our users rather than allowing multiple sign on.
If we could display a modal that showed them they were signed into multiple accounts, with instructions for the available workarounds, that would be excellent.
Even if your error message notified them it was due to multiple accounts - that would be huge.
It's simply that a generic error, completely out of our control, makes it look like our apps don't work.
sh...@gmail.com <sh...@gmail.com> #303
How difficult is it for you to use the current logged in user's (instead of the first user in the list) access token to access google.script.run functions?
Every method that starts with getActive** is useless because of this silly issue.
je...@soliddigital.com <je...@soliddigital.com> #304
ar...@gmail.com <ar...@gmail.com> #305
mz...@gmail.com <mz...@gmail.com> #306
p1
mz...@gmail.com <mz...@gmail.com> #307
69270374
ro...@gmail.com <ro...@gmail.com> #308
as...@oshmi.mn <as...@oshmi.mn> #309
se...@google.com <se...@google.com>
ti...@gmail.com <ti...@gmail.com> #310
tb...@melexis.com <tb...@melexis.com> #311
I't clear now that a corrective action is not easy, however please provide a containment action.
As stated above, such containment action could be a clear error-message to the end-users, or something that enables us to throw such clear message.
Now they get a scary and unclear error. As a result, they blame the quality of the apps.
Kind regards
al...@gmail.com <al...@gmail.com> #312
If the issue is not fixed, let's work around it with minimal code changes. Find below "copy and paste" code for 2 approaches
- only notifying the user about the problem;
- a complete workaround for when possible.
Approach 1 is the simplest: notifying the user about multiple sign-in and giving instructions to sign-out and sign into 1 account only. Much has been written about this in
Demo:
This approach is implemented in the Workspace Editor add-on
Step-by-step instructions:
Find
Approach 2 to provide complete workaround is recommended for developers with some background in Google apps script and Workspace Editor Add-ons.
Synopsis: In a browser window with multiple signed in Google accounts (u0, u1, ...), the apps script is running under the account (uN). Created in this application with the HtmlService sidebars and dialogs open under active default account (u0). All calls to application functions via google.script.run are also performed under the active default account (u0). This means that there are no mechanisms for communication between the HtmlService window (u0) and the application instance (uN). That is, the connection with app instance is lost.
Workaround: Let's use the opportunity to execute the application functions NOT through google.script.run, but using the Apps Script API and OAuthToken on behalf of the user (uN) running the application.
Limitations:
In the apps script functions called from the HtmlService window, you cannot use functions that refer to the current state of the document under the user's session:
getActiveDocument()/getActiveSpreadsheet()/getActivePresentation()/getActiveForm()
You should use
openById(id)/openByUrl(url))
The project OAuth scopes should be updated accordingly from .currentonly
document to all documents.
Demo:
This approach is implemented in the Workspace Editor add-on
cy...@gmail.com <cy...@gmail.com> #313
dr...@gmail.com <dr...@gmail.com> #314
[Deleted User] <[Deleted User]> #315
le...@gmail.com <le...@gmail.com> #316
1) "If I can help with some feedback, I'd say my biggest problem when I first started using your add on was that I had to open it in a private window. This was due to the fact that it seems to have issues if I'm logged into more than one google account.
Unfortunately I have 5 google accounts constantly open, (because of running several businesses and projects)
That has been my biggest pain point so far, hope that helps".
2) "Not working." And screenshot of the issue.
We expect much more from Google, having multiple accounts is very common and it is impossible to use HTML service to do anything useful is this problem persists. The workaround is not enough for the use cases that we have, in some cases the user directly sees this screen without anything being executed from the Apps Script side.
If Google wants to transition from HTML sidebars to CardService, then provide as a way of running intervals, or to reload the UI from a trigger somehow. And if that is not the plan, please finally fix this bug, the workarounds are not useful at all.
kh...@gmail.com <kh...@gmail.com> #317
ti...@gmail.com <ti...@gmail.com> #318
su...@childrenshome.us <su...@childrenshome.us> #319
jr...@saintpeters.edu <jr...@saintpeters.edu> #320
from it by being shelled in the old Google Sites. The forced migration to
the new Google Sites with their inability to appropriately select accounts
breaks this... Keeps getting worse folks. Just adding to the pile of
complaints on this issue...
On Wed, Aug 11, 2021, 9:42 AM <buganizer-system@google.com> wrote:
al...@gmail.com <al...@gmail.com> #321
ia...@google.com <ia...@google.com> #322
Thank you for your continued patience on this. Rest assured that we are actively working on it and it is an important issue for us, however, the scope of this issue is greater than it seems at first sight.
As a first step, we have updated the
As pointed out here, many end users of your addons run into this issue and don't know what it's about. So we plan to implement warnings that will draw attention to a possible multi-login issue while the main issue is worked on.
Seeing as most of the useful information about this issue has been said, and to prevent needless emails from being sent to everyone subscribed to this issue, this thread will be temporarily locked. If you want to let us know that this affects you too, please do “star” the issue, and in that way you will also be subscribed to the issue and we will have an indication of how many people are affected by it.
Once we have more news, we will post an update here.
Description
Unexpected/incorrect auth error if user is signed into multiple accounts, and is currently using a non-default account. Sheets add-on is throwing "authorization is required to perform this action" even though the user did authorize the add-on.
WHAT STEPS WILL REPRODUCE THE PROBLEM?
I'm working on putting together a add-on explicitly for the purposes of demonstrating the issue (and that I can share the source of), but the issue can be demonstrated using the Streak CRM Importer add-on (where the issue was first discovered). Full credit (and massive thanks!!!) to a user of our add-on for first figuring out the nature of the error and providing us with reproduction steps:
GET INTO THE CORRECT (ERROR CAUSING) LOGIN STATE
1. Open an Incognito window in Chrome (not strictly necessary, but is the easiest way to get to the correct initial state)
2. Go to
3. Log into a Google account, account1
4. In the top right, click the profile picture, select "Add Account", and log into a different Google account, account2.
> After logging into account 2, you can verify that you're in the correct login state by clicking your profile picture and checking that account2 is listed first and that account1 shows "(default)" next to it. It should look something like this (
5. As account2, create a new Sheet and open it
INDUCE THE ERROR
6. Open the Dev console
7. In the Sheet, select "Add-ons" => "Get add-ons..." => search "Streak"
8. Install and authorize "Streak CRM Importer"
9. Go to "Add-Ons" => "Streak CRM Importer" => "Start import"
10. Note the error (as console.logged from the withFailureHandler callback of an Execution API request made by the sidebar's js) in the console and how the add-on endlessly hangs.
You can see demonstration of steps 6-10 here:
A demo of steps 6-10 when account2 is the "default" account (i.e. the first account the user logged in to):
I'm reasonably confident in saying that this issue has not always been present, so I think this must be the result of recent changes to AppsScript or Add-ons in general.
Is anyone else seeing similar issues? I couldn't find any open issues that quite matched this, although there are a few other recently opened auth related issues that I suspect might be related.
Unexpected error of Authorization Required (
I'm working on a small add-on that explicitly demonstrates the issue and that I can share the source of. I'll post that here when I have it done.