IssueTracker

Also asked on StackOverflow for help.

https://stackoverflow.com/questions/64338438/google-apps-script-scriptapp-getservice-geturl-always-returns-the-wrong-url

Hello there,

When following the steps you mentioned, the URL returned in my test environment is the /dev one and not the one you mention. Hence, I am not able to reproduce this behavior.

Would you mind providing more information regarding this and eventually a list of steps in order to investigate this further?

Moreover, did you notice this particular behavior only with this script or it has happened with others as well?

When executing ScriptApp.getService().getUrl() as a function directly it indeed works as you explained. We also receive the /dev url.

The way we deploy and test our add-on is on Google Calendar. We want to expose the Script URL through createSettingsUrlFunction for the calendar addon.

Attaching the manifest file and the function we use for the createSettingsUrlFunction function.

Attaching also a screenshot showing the mismatch between the Deployment ID and the URL generated in Google Calendar.

Attaching a screenshot taken from the script editor - showing the deployed version id.

Bottom line: I would expect the Google Calendar settings link to return the version deployed and not anything else.

Expected URL returned by ScriptApp.getService().getUrl(): https://script.google.com/a/gong.io/macros/s/AKfycbxbZEd8-MwPgnpi_OVQkOVsdVaBP4oS6MePaK_rOu4f6Rs_d8KmAdj8RVlsCd8IZ5zG/exec?settings 🙂

Actual URL returned by ScriptApp.getService().getUrl(): https://script.google.com/a/gong.io/macros/s/AKfycbzv1gX4eim1CzTjnFc4sFNvLMw9mXCfOv4laDu-_9AKefk5jXg/exec?settings  ☹️

To answer your last question - this happens consistently. I am able to reproduce this on a new project.

Thank you for all the details provided. However, I am still not able to reproduce the behavior you are mentioning as the URLs are returned correctly and match even after multiple changes and deployments.

Do you have any other information that might be of help?

You have to deploy the script at least once as webapp, and then continue deploying it from manifest.

Once you deploy as webapp - the webapp deployment URL will always be returned and not the URL for the manifest deployment.

Did you try reproducing this on a Calendar addon with the settings URL?

I have recorded a 10 minute video creating a project from scratch and was able to reproduce the issue.

Youtube is now processing the HD version. I will post the link when it's done processing.

Here it is:

Video demonstrating the issue: https://youtu.be/Poy92s5dfTM

Github repo with the code used for the project: https://github.com/yarinb/gapps-script-deployment-issue

This should be enough information to reproduce our issue :-)

So essentially, you don't want to deploy the add-on as a web app at all?

If so, why not remove this part from your manifest? Are you still experiencing the same behavior?

  "webapp": {
    "access": "ANYONE",
    "executeAs": "USER_ACCESSING"
  },

I don't think I can remove this part as we do want to serve SettingsPage.html from within the script (rather than hosting it on another server)

We followed this guide: https://developers.google.com/gsuite/add-ons/calendar/conferencing/add-settings#hosted_within_apps_script

And indeed it always worked as expected when deployed from the manifest.

I insist that there IS a bug here and would appreciate any sort of escalation on this matter. Right now we cannot fix any bugs on our calendar addon which is being used by thousands of users.

Thank you for the details provided.

I have forwarded them internally.

Best regards

Thanks!

Also experiencing the same issue on a first web app deployment.

The following code, if executed, produces https://script.google.com/macros/s/AKfycbxB92DN3YhFYwF5dY7qMN8OzDcUlw1d-QtS25DtPI8fnlo4i5CE/exec instead of the correct https://script.google.com/macros/s/AKfycbztKJrN9rDvWkE5t4wQkQbZrmrb0MGZx1Q4pgTM3w/exec (as provided by the GUI in manual deployment.

function setWebHook() {
  var hook = ScriptApp.getService().getUrl();
  Logger.log( hook );
  return;
}

These are also different from the dev URL https://script.google.com/macros/s/AKfycbx7FhrfLgItjJUMqaayswl_tTT439BdvbXLZmGEBmaC/dev

I have found a workaround that works for me. Using clasp, create a new version:

clasp version "new feature"

This will display the new version number in the terminal. Use that number to deploy the new version to the deployment ID being returned by ScriptApp.getService().getUrl():

clasp deploy -V <version> -d "new version with old ID" -i <deployment ID>

Few days ago Google make it possible to create and assign a version for an existing deployment. See Release Notes 2021-03-15

I too am having difficulty with ScriptApp.getService().getUrl()

But my problem is that I am getting different results for different users in the same google workspace

For my user account, it returns what I expect e.g. https://script.google.com/a/macros/{myWorkspaceDomain}/s/{appId}/exec

But for a different user account within our same workspace domain, it returns: https://script.google.com/macros/s/{appId}/exec <-- note the missing workspace domain!?

Both myself and the other user have Chrome logged into their Google account

My horrible workaround is to run the app in dev mode and hardcode the url, which also means I have to share the actual script code with non-dev users :(

Also have this issue and was able to workaround it by switching to legacy editor to deploy/redeploy.

Same issue of one of my newly created standalone apps script projects (V8 runtime).

Additionally, I can confirm that deploying a new version of the web app using the Legacy Editor circumvents this bug, as the user nicely suggested in #comment33

Every time you have to switch to legacy editor, please provide this issue as the feedback. Perhaps this will prompt some action?

I do like the new editor UI but, like others here, I have to switch back to legacy editor for new deployments for getUrl() to work as expected.

I have hit something similar. In my case, I ONLY deploy my application as a web app but have multiple active deployments and use getUrl() to try and distinguish between them.

For one of my projects, calling ScriptApp.getService().getUrl() returns the same URL every time regardless of which deployment it is actually being called from.

The URL that gets returned doesn't match ANY of the active deployments, but it does match the URL shown if you go into the legacy editor and open the dialog via Publish --> Deploy as web app.

I can't reproduce in a fresh project, but I also can't afford to re-create the project from scratch either.

If it's helpful at all, I can provide the URLs in question.

+1 on comments #46 & #47 above

In my case, when running in test mode, getUrl() returns a bogus url that renders a "Sorry, unable to open the file at present." page.

It would make more sense and be much more helpful if getUrl() returned the actual /dev url when running the web app in test mode

It's been a year and Google has not taken an action to fix this bug. It happens here in both old and new editor

Here is a simple recreation of the consistent failure of ScriptApp.getService().getUrl() to properly detect dev mode. This is 3 files, and I am accessing the dev link. DEV URL: https://script.google.com/a/redacted/dev

code.gs >>>>>

function doGet(e) {
    console.log(e.parameters)
    console.log(getAppUrl());

  var template = HtmlService.createTemplateFromFile("loading-html");
  if(e.parameter.test){
    var template = HtmlService.createTemplateFromFile("Test-html");
    template.url = getAppUrl();
  }

return template.evaluate();
}

function include(fileName){return HtmlService.createHtmlOutputFromFile(fileName).getContent()}

function getAppUrl() {return ScriptApp.getService().getUrl()}

Loading-html.html >>>>>

<!DOCTYPE html>
<html>
  <head>
    <base target="_self">
  </head>
  <body>

  <div class="container" id="loadingDiv">
  <h5>Loading CHP Test</h5>
  </div>  
     
     <script>
   document.addEventListener('DOMContentLoaded', function(){google.script.run.withSuccessHandler(function(appUrl){var link = appUrl + '?test'; window.open(link, '_self')}).getAppUrl()});
   </script>
   
  </body>
</html>

Test-html.html >>>>>

<!DOCTYPE html>
<html>
  <head>
    <base target="_top">
  </head>
  <body>
    <p>URL: <?!= url ?></p>
  </body>
</html>

console #1 >>> Nov 9, 2021, 9:37:59 AM Debug {} Nov 9, 2021, 9:37:59 AM Debug https://script.google.com/a/redeacted/exec

console. #2 >>> Nov 9, 2021, 9:38:00 AM Debug { test: [ '' ] } Nov 9, 2021, 9:38:00 AM Debug https://script.google.com/a/redacted/exec

This will return the exec url every single time, 100% broken

If that's too much, we can nail it home quicker:

doGet(e){console.log(ScriptApp.getService().getUrl())}

The end. The log will still never show the dev URL.

console >>> https://script.google.com/a/redacted/exec

This will prevent proper testing and development of any production web app, and should be a top priority to someone over there. I have easily proven that it essentially renders proper dev testing impossible. When can we expect you to make your service function again? This should be considered a complete failure / stoppage of basic functions, and should be addressed immediately.

Another issue tracker has marked this as completed as of yesterday: https://issuetracker.google.com/issues/193820645. Mine is actually working correctly today, give it a shot and report how it goes!

still an existing issue

From issue 230391950 on 26‏/4‏/2022:

1. Steps to reproduce the problem (including sample code if appropriate -> current APN settings in apns-full-conf.xml) : <apn carrier="Mobitel" carrier_id = "1931" mcc="413" mnc="01" apn="default" type="default,supl" />

2. What happened : As leading mobile service provider in Sri Lanka, we have partnered with SLT, and since most of the above APN settings were outdated, we are hoping to modify our APN settings as below.

3. What you think the correct behavior should be (Requesting to update to bellow settings) : <apn carrier=” SLTMobitel" mcc="413" mnc="01" apn="mobitel" mmsc="http://mmsc.mobitel.lk:8080" type="default,supl,mms" protocol="IPV4V6" roaming_protocol="IPV4" />

(4) Version of Android : all version

(5) Device (model and Android version) : all make and model

Thank you,

Jaque Perera Manager - Digital MediaConsumer Marketing Mobitel (PVT) Ltd jaquep@mobitel.lk +94 71 680 1728

Here is a basic test. To be clear, it isn't failing for all of our web apps. At this point, it is just one. However, we are going out of our way not to need to update, with the fear that deploying will break things again. It is working correctly in dev, but fails every time in exec. You can see that the structure of the URL changes as well.

https://script.google.com/a/macros/[redacted]/s/AKfycbxoe04IrfrToRZwma-gLA-IZeRNDBGY8rPucouMzvJ-tN4WDFIPidcDvVTlnd95mYWb/exec

function doGet(e) {
  return HtmlService.createTemplate("<html><body><p> The app has returned the URL of: " + ScriptApp.getService().getUrl() + "</p></body></html>").evaluate();
}

Outcome: The app has returned the URL of: https://script.google.com/a/[redacted]/macros/s/AKfycbyv_jygmRzzPFENjnyOQhaIiqzD4_0Mwgx8uNiqU73JCSsVu1c/exec

Hi,

an updates?

for now, I have managed to fix like this:

1. create a const

const  DEPLOYMENT_ID = 'YOUR-LAST-DEVELOPMENT-ID'

2. use this function

function get_webapp_url(){
  // getting WebAppURL based on deployment id provided
  var user = Session.getEffectiveUser();
  var email = user.getEmail();
  var domain = email.split("@")[1];

  var url = `https://script.google.com/a/${domain}/macros/s/${DEPLOYMENT_ID}/exec`;
  return url;
}

Yes, you need to create another deployment after your final deployment to make it work :)

The workaround with clasp as suggested by #19 worked in my case

We already had two active deployment IDs:

1. For the webapp which is referenced by ScriptApp.getService().getUrl()
2. For the add-on

I created a new version with clasp version "new feature"

Which returns the #new-version-number.

And then updated both deployments to the same version:

clasp deploy -V #new-version-number -d "new version with old ID" -i <webapp deployment ID>

clasp deploy -V #new-version-number -d "new version with old ID" -i <add-on deployment ID>