Infeasible
Status Update
Comments
sm...@gmail.com <sm...@gmail.com> #2
Kk, got a more contained example of the issue using a very small add-on.
source:
https://script.google.com/d/1o3AvP1zRrx7WnDEx_fV_IhS2fc3QstuKHvFaBsqjcffqxdhLNjC7j62S/edit?usp=sharing
add-on listing:
https://chrome.google.com/webstore/detail/dcpikpbagjcipkfmacefilfbkdjlfjmd
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
https://chrome.google.com/webstore/detail/auth-issue-tester/dcpikpbagjcipkfmacefilfbkdjlfjmd?authuser=1
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:https://cl.ly/0p0v080F2j1s
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:
ca...@gmail.com <ca...@gmail.com> #3
Thank you for your report. The Apps Script team is investigating.
se...@google.com <se...@google.com> #4
ki...@gmail.com <ki...@gmail.com> #5
I was the person who originally reported this issue to Streak.
se...@google.com <se...@google.com> #6
I am facing similar issue. Getting error "You do not have permission to call showSidebar" on Opening the file (Docs, Sheets etc..)
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.
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.
ki...@gmail.com <ki...@gmail.com> #7
We and our clients numbering around 100 with Google App Scripts attached to spreadsheets found around the 11th of Nov that they needed to re-authorise apps to run. Notification email have been sent to us and our clients. Example below.
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
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
ki...@gmail.com <ki...@gmail.com> #8
Comment has been deleted.
a....@journeyagency.ru <a....@journeyagency.ru> #9
I am getting the same "you do not have the permission to call..." on many of the scripts I have in place. This started on Nov 3rd. I also go the "you don't have permission to call showSidebar". If I just go in and manually run any of the functions, the script re-authorizes and starts running again.
ki...@gmail.com <ki...@gmail.com> #10
Folks how can we get this escalated for an action by Google team ? Its been close to 15 days since the issue started and there has been no action!!
d....@gmail.com <d....@gmail.com> #11
Thank you for your reports. The issue originally reported is due to recent improvements in Sheets' ability to handle multiple logged in accounts. These improvements expose limitations in Apps Script's ability to do the same. In particular, users may experience issues if they (1) are logged into more than one gmail.com account or more than one account belonging to the same G Suite domain, (2) have selected an account other than the default account while using Docs, Sheets, Slides, or Forms, and (3) use add-ons or the script editor.
ki...@gmail.com <ki...@gmail.com> #12
Thanks for the clarification of the issue - that matches what we've been seeing. Are you all actively working on a fix or is there a workaround? This is a pretty frustrating experience for our users.
os...@gmail.com <os...@gmail.com> #13
We're seeing the same. In addition, Session.getEffectiveUser().getEmail() is no longer reliable, if you're logged in with multiple gmail accounts it always returns the first one. Quite a serious problem, please fix this urgently.
so...@gmail.com <so...@gmail.com> #14
We have the same issue which is causing our Supermetrics Data Studio community connector to throw errors.
73...@gmail.com <73...@gmail.com> #15
We have the same issue which is causing all of our google sheet queries to break. Its broken our entire data pull that we use with DOMO.
ki...@gmail.com <ki...@gmail.com> #16
I can confirm that this issue exists for the Search Analytics for Sheets add-on as well.
er...@gmail.com <er...@gmail.com> #17
I have the same issue
ms...@costco.com <ms...@costco.com> #18
Same issue here, all of my reports are down.
rx...@gmail.com <rx...@gmail.com> #19
I have the same issue
ki...@gmail.com <ki...@gmail.com> #20
We have a very urgent problem. All our reports in Supermetrics with data from Analytics are failing. We get the message "Error: 403 The caller does not have permission (view ID: 12511297)" and the "view ID" number in the error message keeps changing. We have tried using the "Refresh account list " and sometimes it help, but when we run it again we get the same message "Error: 403 The caller does not have permission (view ID"
09...@gmail.com <09...@gmail.com> #21
Same problem - all our dashboards on data pulled by Supermetrics are broken - please fix!
su...@gmail.com <su...@gmail.com> #22
Any news on this?
er...@gmail.com <er...@gmail.com> #23
My script is also affected. Any news?
ki...@gmail.com <ki...@gmail.com> #24
Any news Google?
fu...@gmail.com <fu...@gmail.com> #25
Any news on this?
se...@google.com <se...@google.com> #26
Any new info?
tp...@igm.technology <tp...@igm.technology> #27
Any update regard this issue .
[Deleted User] <[Deleted User]> #28
Ya it's odd. I have been experiencing issues for awhile on this and never knew about this forum to track issues. So cool Goog!
me...@djis.edu.sa <me...@djis.edu.sa> #29
I'm starting to think Google team also don't know about this forum :/
jo...@truaxnw.com <jo...@truaxnw.com> #30
I wrote an article explaining how we are currently dealing with this issue in add-ons like Yet Another Mail Merge:
https://sites.google.com/site/scriptsexamples/home/announcements/multiple-accounts-issue-with-google-apps-script
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).
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).
tm...@themotorcyclecompany.com <tm...@themotorcyclecompany.com> #31
no response Google? I'm getting user emails about this all the time.
mb...@gmail.com <mb...@gmail.com> #32
This issue already obtained 90+ stars, why Google isn't taking any action on this?
bj...@valorcollegiate.org <bj...@valorcollegiate.org> #33
Are you realy surprized with it? I'm not :)
ma...@gmail.com <ma...@gmail.com> #34
A user can be logged into multiple Google accounts in the browser. But what account is your add-on or Apps Script code using? If your add-on or Apps Script code tries to use an account that it is not authorized to use, then there will be an authorization error.
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>
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>
[Deleted User] <[Deleted User]> #35
Issue resolved by opening form/data director in Incognito window.
me...@djis.edu.sa <me...@djis.edu.sa> #36
I can confirm the issue is not reproduced with Incognito window, however, this does not really mean it is resolved. Writing this in order to prevent this issue to be accidentally closed.
at...@gmail.com <at...@gmail.com> #37
+1 to "pa...@gmail.com"
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".
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".
ma...@planetcellinc.com <ma...@planetcellinc.com> #38
Are there any updates on this? I can see the last question to the team was asked on 22 Nov 2017 and was left without a reply. How come is priority 2 if it is a blocker and severity 2 when nowadays almost everyone is logged in into multiple accounts? Anyone from the team, please let us know if you are working on this and what is the status, our customers suffer.
ed...@tinuiti.com <ed...@tinuiti.com> #39
Any updates on this?
Posting mainly for the sake of not letting this ticket go completely inactive.
Posting mainly for the sake of not letting this ticket go completely inactive.
kw...@wvusd.org <kw...@wvusd.org> #40
I have the same issue in my add-on and the 'Incognito window' method doesn't work for me. But I fixed in another way.
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.
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.
mr...@gmail.com <mr...@gmail.com> #41
Very disgusting. Still no action being taken.
pf...@rosstech.ca <pf...@rosstech.ca> #42
I have issues with script errors, pls fix it .!!!
cu...@affectrix.org <cu...@affectrix.org> #43
'Incognito window' method doesn't work for me
ma...@planetcellinc.com <ma...@planetcellinc.com> #44
+1. Really inconvenient for users and kind of ridiculous. What sane developer would try to write plugins for Google Forms when the flagship example doesn't teach how to handle common use cases?
cu...@affectrix.org <cu...@affectrix.org> #45
Still no action?
ad...@arcosabroad.com <ad...@arcosabroad.com> #46
Tired of constantly needing to explain to your users why they are getting authorization errors, when they are logged into multiple accounts?
Implement some code to automatically explain it to them, so you won't need to.
Code posted at GitHub
https://github.com/Blueprinter/Authorization-Error-Multiple-Accounts
Implement some code to automatically explain it to them, so you won't need to.
Code posted at GitHub
ma...@telusinternational.com <ma...@telusinternational.com> #47
Comment has been deleted.
er...@gmail.com <er...@gmail.com> #48
supporting multiple accounts would be rather proper, compared to demanding workarounds; logged-in accounts have an index; that's also where the 0, 1, etc. in the G+ urls comes from. would assume, that in this case it's the account with index 1 trying to access - while the script wrongfully assumes account at index 0... logging out both accounts and the signing in in different order would also change their index... just as using an incognito window would use the account at index 0.
so...@mail.ru <so...@mail.ru> #49
Comment has been deleted.
re...@gmail.com <re...@gmail.com> #50
🎂 Celebrating the First Anniversary of this Issue
Still strong as New and Unassigned
Still strong as New and Unassigned
sa...@plugable.com <sa...@plugable.com> #51
🎂🎉🎁
Happy Birthday authorization issue!
It's been amazing watching how little you've grown or changed.
Happy Birthday authorization issue!
It's been amazing watching how little you've grown or changed.
sa...@plugable.com <sa...@plugable.com> #52
Congrats! Because it's not important it shouldn't been done! :D
sa...@plugable.com <sa...@plugable.com> #54
Happy Birthday! ..but nobody came to the party?.. I don't think any of the developers like you much!
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: "https://script.google.com/macros/s/xxx/exec ")
* the script is hosted on another domain (ex: "https://myapp.com ") and contained within an iframe element
* 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 'https://accounts.google.com/ServiceLogin?passive=xxx&continue=https://script.google.com/macros/s/xxx/exec&followup=https://script.google.com/macros/s/xxx/exec ' in a frame because it set 'X-Frame-Options' to 'deny'."
* 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!
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!
sa...@plugable.com <sa...@plugable.com> #55
Happy Belated Birthday!
er...@gmail.com <er...@gmail.com> #56
Having the same problem here!
sa...@plugable.com <sa...@plugable.com> #57
Why no action is taken?
ad...@aihti.com <ad...@aihti.com> #58
+1 please fix this issue.
er...@gmail.com <er...@gmail.com> #59
Same problem. Please fix ASAP!
ad...@aihti.com <ad...@aihti.com> #60
When are you going to fix this? It was reported back in November, 2017.
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!!
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!!
ni...@gmail.com <ni...@gmail.com> #61
+1 please fix this issue.
uk...@gmail.com <uk...@gmail.com> #62
+1 same problem
mb...@gmail.com <mb...@gmail.com> #63
+1 as well
ca...@gmail.com <ca...@gmail.com> #64
Really? Assigned?! Is supposed to be solved soon? :D Party day
tm...@themotorcyclecompany.com <tm...@themotorcyclecompany.com> #65
I apologize for the lack of a reply on this issue for so long. The bug was being tracked internally, but there hasn't been any progress to date.
The history here is that for a long time Google's multi-login feature only allowed you to be logged in to one @gmail.com account and one G Suite account (per-domain). Around the time this bug was filed, the multi-login system started permitting multiple @gmail.com accounts and multiple G Suite accounts from the same domain to be signed in at once. This broke some assumptions in the Apps Script code, leading to this behavior.
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.
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.
ay...@noon.com <ay...@noon.com> #66
Thank you for the explanation and status update!
[Deleted User] <[Deleted User]> #67
hope this will be fixed soon :D thanks!
ca...@gmail.com <ca...@gmail.com> #68
This has been a really challenging but for me and my add-on, so I've been tracking it closely, and it seems like since yesterday 3/26 it hasn't been an issue! Would someone at Google like to confirm if this has been resolved?
ca...@gmail.com <ca...@gmail.com> #69
This is really torturing developers. The users keep complaining... Eric Koleda, please help
ca...@gmail.com <ca...@gmail.com> #70
+1. I need this fixed ASAP
lo...@google.com <lo...@google.com>
dr...@gmail.com <dr...@gmail.com> #71
When will Google fix this major issue?
ja...@google.com <ja...@google.com>
lo...@google.com <lo...@google.com> #72
Adding my +1 that this issue affects me as well.
fi...@gmail.com <fi...@gmail.com> #73
This is one of the worst issues. Still no action is being taken by Google Engineers.
Kindly request to solve this issue.
Kindly request to solve this issue.
[Deleted User] <[Deleted User]> #74
Comment has been deleted.
er...@gmail.com <er...@gmail.com> #75
That's great news! Thank you.
Description
A short description of the issue:
For more than 10 days already people report frequent cases of getting error "Import Range internal error" while using
IMPORTRANGE()
function where it previously worked fine.What steps will reproduce the problem?
Not sure how to reproduce. I've seen this behavior within quite heavy spreadsheets as well as within newly created ones containing just a few cells of data.
What is the expected output? What do you see instead? If you see error messages, please provide them.
Data should be imported as usual, but often it is replaced with the error message "Import Range internal error".
Please provide any additional information below.
There is a SO question on the matter:https://stackoverflow.com/q/69593421/279806
Only dirty workarounds are known now.
One would be to change case of any letter in the second argument (range being imported) of
IMPORTRANGE()
.Another one is to repeat
IMPORTRANGE()
one original and another with some letter-case changes) inIFERROR()
like so: