Status Update
Comments
se...@google.com <se...@google.com>
se...@google.com <se...@google.com> #2
ka...@gmail.com <ka...@gmail.com> #3
Hello there,
Thank you for reporting this! However, it seems that this is the expected behavior as the method will return the valid named ranges. Would you be interested in turning this into a feature request instead? If yes, how would it impact your organization in terms of costs and productivity?
nu...@gmail.com <nu...@gmail.com> #4
bs...@ntsd.org <bs...@ntsd.org> #5
Named ranges help a lot to write dynamic scripts that do not require static range references. And it is crucial to have a good way to define, delete and manage named ranges within app scripts. Especially manage invalid named ranges.
gr...@edmonton.ca <gr...@edmonton.ca> #6
Thank you for the details provided! I have forwarded them internally.
Best regards
[Deleted User] <[Deleted User]> #7
da...@pvusd.net <da...@pvusd.net> #8
I haven't found a way to delete them in bulk via the Sheets UI either. In fact, it's a surprisingly tedious process because the UI resets the viewport to the very top list item after each deletion, forcing the user to manually perform O(n-squared) scroll wheel rotations.
I would be really grateful if this were fixed / added.
Thank you
jo...@gmail.com <jo...@gmail.com> #9
as...@nisseiasb.com <as...@nisseiasb.com> #10
as...@nisseiasb.com <as...@nisseiasb.com> #11
ad...@intellicommht.com <ad...@intellicommht.com> #12
This request would break many of my scripts as we are relying on the broken named ranges not being found and we would otherwise often have duplicate named ranges with the same name. Please make it an option to also select the broken named ranges which is off by default
ma...@gmail.com <ma...@gmail.com> #13
li...@gmail.com <li...@gmail.com> #14
Having no more options but manual deletion...
I hope NamedRanges methods get improved soon.
tw...@gmail.com <tw...@gmail.com> #15
tw...@gmail.com <tw...@gmail.com> #16
is...@google.com <is...@google.com>
ce...@najeebmedia.com <ce...@najeebmedia.com> #17
I am also facing same issue, please update on this issue?
[Deleted User] <[Deleted User]> #18
em...@gmail.com <em...@gmail.com> #19
pa...@section6.nz <pa...@section6.nz> #20
I'd like to add my voice to this. Is there an ETA? Thank you
qu...@airbus.com <qu...@airbus.com> #21
go...@entrenoaldia.com <go...@entrenoaldia.com> #22
Same issue here, please update on this issue?
jp...@google.com <jp...@google.com>
sa...@unimib.it <sa...@unimib.it> #23
jp...@google.com <jp...@google.com> #24
I am marking this issue as FIXED
as the internally reported issue has been marked as FIXED
. Please note that there may be a delay in rolling this out to production. Thank you for your patience and please comment here if the issue remains.
ap...@colo-sport.com <ap...@colo-sport.com> #25
Please fix this Google.
sa...@unimib.it <sa...@unimib.it> #26
jp...@google.com <jp...@google.com>
es...@gmail.com <es...@gmail.com> #27
ti...@gmail.com <ti...@gmail.com> #28
jp...@google.com <jp...@google.com>
th...@nephosec.com <th...@nephosec.com> #29
jp...@google.com <jp...@google.com> #30
Please open a new issue with a reproducible example.
Description
A short description of the issue:
There is a method of
ScriptApp.getService().getUrl()
for obtaining the Web Apps URL in Google Apps Script. It was confirmed that recently,ScriptApp.getService().getUrl()
returns invalid URL.What steps will reproduce the problem?
There is a method of
ScriptApp.getService().getUrl()
for obtaining the Web Apps URL in Google Apps Script.Before the V8 runtime is released, this method had returned the endpoint like
https://script.google.com/macros/s/{deploymentId}/exec
.After the V8 runtime was released, the endpoint of
https://script.google.com/macros/s/{deploymentId}/dev
was returned.Now, it seems that this returns
https://script.google.com/macros/s/###/exec
.But, in the current stage, when I access this endpoint, the message of
Sorry, unable to open the file at this time. Please check the address and try again.
is returned. So, I tried to search the deployment ID of###
fromhttps://script.google.com/macros/s/###/exec
returned with currentScriptApp.getService().getUrl()
. But, unfortunately, I cannot find the deployment ID. I'm worried that this might be related to the error.In order to test this situation, I used the following sample script to the standalone script.
When this is deployed as Web Apps, the URL of
https://script.google.com/macros/s/{deploymentId1}/exec
is obtained. This can be found with "projects.deployments.list" of Apps Script API. And, when I access this URL,Done
is shown.On the other hand, when
getUrl()
is run,https://script.google.com/macros/s/{deploymentId2 ?}/exec
is obtained. But, this deployment ID cannot be found with "projects.deployments.list" of Apps Script API. And, when I access this URL,Sorry, unable to open the file at this time. Please check the address and try again.
is shown.Affecttion
I think that when
ScriptApp.getService().getUrl()
cannot be used, the Web Apps URL is required to be a hard copy. And, in the current stage, when the Web Apps is redeployed as a new version, the Web Apps URL is changed. WhenScriptApp.getService().getUrl()
is a valid URL for the deployed Web Apps, this will be useful for a lot of developers of Google Apps Script and will lead to the reduction of process costs for developing applications.