"The OAuth identity of this script has been deleted or disabled. This may be due to a Terms of Service violation."
I run a google script on a google sheet which notifies other users at my organization that I have uploaded the google sheet information to our database. This script suddenly stopped working and threw up the error quoted at the top of this post. As far as I know, there were no recent changes to the ownership of relevant files/folders. Please help! I need this script in my everday work.
This seems to fix the problem, but in fact, it does not.
The problem is related to the cloud project bound to the script, The reason turned out to be that the Terms of Service (TOS) for Cloud projects changed and that the user has to acknowledge this. If that does not happen then after some time, the whole shebang is disabled and you get the error message.
(This is why a copy seems to work: it works until some Google bot notices that it is bound to a project without TOS acknowledgment, and then it disables it.)
The solution:
open the script
click Resources > Cloud Platform project
click on the bound project
This will open up the Cloud console and also show the popup for you to acknowledge the new TOS. If you agree to this, you're set, and your script works again.
Note: it seems that you need to do this only once for the Cloud environment. So if you have several scripts, then you need to do this for one script only. Or access the Cloud environment directly and acknowledge the new TOS.
Note: even if you thought your script is not bound to a Cloud project, trust me... it is. If you do not bind it yourself, then it is bound to a default project specific to that script.
Hope this helps.
Had the same issue, the fix is :
Copy your script locally to some temporary file.
Delete the old project in Google script editor.
Reload script editor and create a new project.
Create new script and copy from the local backup.
You are all set to ok. I changed function and script name before executing, not sure if that was needed.
I had faced the same issue recently and solved the same as follows -
Go to https://console.cloud.google.com.
Create a new project (or select an existing one) and note the "Project number".
Open the Script > Click Resources > Cloud Platform project
Change Project using the "Project number" noted above.
Related
In a .NET project, select Build -> Publish -> and see the default "No profiles created, select a method" screen. Choose Folder and complete the wizard. Click Finish. Receive the following Microsoftian error:
"One or more errors occured"
With no other information.
Having already solved this, I'm posting to share the answer and publicly shame Microsoft for these lame error messages. Visual Studio is a program only used by developers: we can handle a little more information, and in fact need it to solve these minor, job-derailing errors in a timely way and hold onto some sanity while the rest of the program is locking up and spewing errors all day.
Navigate to [Your project's directory] -> Properties -> Publish Profiles and delete the contents (or move to another location if you might want these back later). Then, in VS, click Finish in the publish profile wizard again.
It didn't work for me with removing Properties.
On this link, Microsoft explains, that they have made a fix and advices instaling preview-version of Visual Studio 2019. Didn't work for me either.
I created a brand new MVC-project and tried to import publish profile, and it worked, so it looks like I have a problem in my original project.
Then I copied [Properties]>[PublishProfile] from new- to original project and th profile now works in original project.
After this copy, I then tried to make a new import in my original project, and that works too.
Not pretty at all, but I'm up and running again.
long time listener, first time caller!
I've spent two days searching for an answer to this so hopefully someone here may be able to help.
I've set up a personal/free VSTS instance and created a project.
One of the first tasks I want to do is setup the build pipeline, so create a new pipeline, define the agent pool as VS2017, connect to my Github repo etc, all of which is fine.
Next I try to add an Agent Job, again choosing VS2017 as the agent. With no other options chosen, if I try to save the build definition I get the following error message (and cannot save it);
The AllowScriptsAuthAccess build option is not supported in API versions greater than 4.0.
Allow scripts to access the OAuth token is unchecked on the Agent job configuration under phases and on the Build/Options tab (slider set to disabled)
I've googled and searched for all sorts of stuff to try and find someone with the same problem but it's almost like I'm the first to discover this - which is highly unlikely!! It has almost driven me to using Bing to search for a solution, but let's not get carried away.
Any ideas or suggestions would be greatly appreciated!
So it turns out that turning off the "New YAML pipeline creation experience" and "New Navigation" under preview features fixes the problem, insofar as I can now create and save a build pipeline without the error.
Also, if you have "Build YAML Pipelines" enabled under preview features for the Organisation, you get the "View YAML" link that I was missing also.
Thanks all for your help. I'd be interested to know the root cause of this still. I'll update the Microsoft support ticket with the same and post back here if they have any insights.
There's an similar issue here:https://developercommunity.visualstudio.com/content/problem/123012/getting-multiconfiguration-build-option-not-suppor.html
Seems the build template was broken. So, you can try with other build templates or starting over with an empty template, then add the needed tasks manually to check if that works.
Besides, you can try below things:
Clean the caches on your client machine, also clean the browser
caches, then check it again. See How to clear the TFS cache on
client machines.
Create a new team project and create a new build pipeline within the
new team project to check if that works
I am assuming this is a bug in the VSTS system and it will likely be fixed soon. But for the time being, I found a workaround:
I was also getting the AllowScriptsAuthAccess error and struggled with it for hours. I don't think any of the configuration settings you mentioned have anything to do with it (free account, GitHub, OAuth token unchecked).
To solve it, I converted the Agent Job to YAML (which is as easy as clicking "View YAML" in the upper right). Save the code to a file named .vsts-ci.yml, and save this in the root folder of your solution. Commit/push the new file, then queue the build. (Note that the conversion to YAML is one-way, so you may want to Clone your build.)
That should get rid of the AllowScriptsAuthAccess error. After that I had to add a few variables, but then it's just a matter of following the error messages.
I hope this helps. Sorry I can't answer this more authoritatively. Please post a comment if I am missing any steps.
I had this issue and it turned out that I didn't have Build Admin permissions in VSTS for the project. Not a very helpful error message for this.
I am creating a web app in Erlang with n2o. My current dilemma is the automatic syncing of changes i make to the app's source code to that with the accommodating release.
For example, I startup my app release in the erlang console, go to specific localhost:? address and see index.erl being reflected in the page with <span>Hello</span> shown. I then go back to modify the index.erl file to say Hello World instead. The changes are not reflected. So i end up regenerating a release to see the new changes.
I guess I could write a bash script to synchronize changes between the app source files and the release libraries, but I imagine there must be better ways of doing this.
What is the appropriate way of doing this?
The synchronization capability you're looking for is explained in the n2o README.
Clone the git-repo 5HT/n2o and follow the instructions in the samples section of that repository. Make a change to one of the source files and once they are saved, you can see the updated changes in the erlang shell as well the web site itself.
Background
I am developing an iOS app that connects to a server. We have a team of developers who run their own server with unique addresses for debugging. Our rule for source control is to only checkin the "production url".
In Android we have a solution that works really well. This solution won't work in iOS.
What I've Tried
Set a "Command line argument" or "Environment variable" in the Build Scheme. The problem with this is those are put into the "*.xcproject" file which get's checked in and causes merge conflicts. If it could be set at the user level it would be fine because we .gitignore xcuserdata.
I also tried referencing a "MyConfig.h" file that does not get checked in. But if it does not exist the project won't build.
What I want to do
If a developer wants to point at a different server they would set an environment variable on their mac. Something like "export MY_SERVER="http://domain.com/api/". In the project file we would add and environment or command line argument that is basically "MY_SERVER=$(MY_SERVER)".
Unfortunately I can't figure out how to get XCode to resolve the variable on my OSX machine. It seems environment variables are resolved on the device only. Command line arguments seem to be taken literally.
Research I've done
http://qualitycoding.org/production-url/ - does not really address the real issue
http://nshipster.com/launch-arguments-and-environment-variables/
Google, Apples developer forum and Stackoverflow post.
How do you do this in your projects ?
Is the only solution to use a backdoor or some file folks change and just try not to accidentally checkin?
As an update I found the solution that solves the problem for me. I am using https://github.com/xslim/mobileDeviceManager and a script that is checked in. The developer can create their custom configuration and copy it to the documents directory. Now we keep production checked in and have a runtime check for our custum configuration file.
Here is an example of the tools usage:
$ mobileDeviceManager -o copy -app "com.domain.MyApp" -from ~/.myAppConfig/app_override.plist
This way the developer can keep their custom configuration in their home directory (out of source control) without fear of accidental checkin. We already use process like this for other desktop and android apps so this fits our process really well. This has the added benefit that if a testers device is failing we can point it at a custom debug server with extra logging to simplify the debug process and not need to deploy a new binary to that device during internal testing.
I hope this can help someone else.
I'm just getting started with the team build functionality and I'm finding the sheer amount of things required to do something pretty simple a bit overwhelming. My setup at the moment is a solution with a web app, an assembly app and a test app. The web app has a PublishProfile set up which publishes via the filesystem.
I have a TFS build definition set up which currently builds the entire solution nightly and drops it onto a network share as a backup of old builds. All I want to do now is have the PublishProfile I've already setup publish the web app for me. I'm sure this is really simple but I've been playing with MSBuild commands for a full day now with no luck. Help!
Unfortunately sharing of the Publish Profile is not supported or implemented in MSBuild. The logic to publish from the profile is contained in VS itself. Fortunately the profile doesn't contain much information so there are ways to achieve what you are looking for. Our targets do not specifically support the exact same steps as followed by the publish dialog, but to achieve the same result from team build you have two choices, I will outline both here.
When you setup your Team Build definition in order to deploy you need to pass in some values for the MSBuild Arguments for the build process. See image below where I have highlighted this.
Option 1:
Pass in the following arguments:
/p:DeployOnBuild=true;DeployTarget=PipelinePreDeployCopyAllFilesToOneFolder;PackageTempRootDir="\\sayedha-w500\BuildDrops\Publish";AutoParameterizationWebConfigConnectionStrings=false
Let me explain these parameters a bit, show you the result then explain the next option.
DeployOnBuild=true:This tells the project to execute the target(s) defined in the DeployTarget property.
DeployTarget=PipelinePreDeployCopyAllFilesToOneFolder: This specifies the DeployTarget target.
PackageTempRootDir="\\sayedha-w500\BuildDrops\Publish": This specifies the location where the package files will be written. This is the location where the files are written before they are packaged.
AutoParameterizationWebConfigConnectionStrings=false: This tells the Web Publishing Pipeline (WPP) to not parameterize the connection strings in the web.config file. If you do not specify this then your connection string values will be replaced with placeholders like $(ReplacableToken_dummyConStr-Web.config Connection String_0)
After you do this you can kick off a build then inside of the PackageTempRootDir location you will find a PackageTmp folder and this contains the content that you are looking for.
Option 2:
So for the previous option you probably noticed that it creates a folder named PackageTmp and if you do not want that then you can use the following options instead.
/p:DeployOnBuild=true;DeployTarget=PipelinePreDeployCopyAllFilesToOneFolder;_PackageTempDir="\\sayedha-w500\BuildDrops\Publish";AutoParameterizationWebConfigConnectionStrings=false
The difference here is that instead of PackageTempRootDir you would pass in _PackageTempDir. The reason why I don't suggest that to begin with is because MSBuild properties that start with _ signify that the property in essentially "internal" in the sense that in a future version it may mean something else or not exist at all. So use at your own risk.
Option 3
With all that said, you could just use the build to package your web. If you want to do this then use the following arguments.
/p:DeployOnBuild=true;DeployTarget=Package
When you do this in the drop folder for your build you will find the _PublishedWebsites folder as you normally would, then inside of that there will be a folder {ProjectName}_Package where {ProjectName} is the name of the project. This folder will contain the package, the .cmd file, the parameters file and a couple others. You can use these files to deploy your web.
I hope that wasn't information over load.
The ability to publish web sites, configure IIS and push schema changes for the DEV->QA->RELEASE cycle has required either custom configuration to imitate publish or custom code where IIS settings are involved.
As of Visual Studio 2013.2 Microsoft has added a third party product that manages deployment of web sites, configuration changes and database deployment with windows workflow and would be the recommended solution for automating deployment from TFS build.
More information can be found here:
http://www.visualstudio.com/en-us/explore/release-management-vs.aspx
You can use the Publish/Deploy in Visual Studio 2010.
See http://www.ewaldhofman.nl/post/2010/04/12/Auto-deployment-of-my-web-application-with-Team-Build-2010-to-add-Interactive-Testing.aspx for more information