Can I give another person publishing rights to my deployment? If so, how?
I tried adding the other person to 'Admins' of that deployment, but at least the rights haven't updated, as I did it approx. 30 minutes ago. I also just published it, and the rights have not updated.
Of course, they could make their own deployment, but then the URL would change. Is there a way to solve this?
This appears to be a bug -- Google's documentation about App Maker describes the ability to do this in detail, but there are no such actions visible in the app.
That documentation says "A project owner also has full access to the data in all deployments of the app, even if the project or deployments restrict the owner from having that access (because the project owner can give themself access)." and "An app owner can take ownership of a deployment." and even has a section "Take ownership of a deployment" saying "If the owner of a deployment edits or republishes a deployment that an editor originally published, this takes ownership of the deployment."
We can report this to google.
Related
We initially worked with Google to setup a POC firebase account for us to test out. We ended up continuing with this project and turning it into our production project. Later on down the road, we are now trying to migrate this project to our enterprise organization within GCP so we can configure the correct billing.
However every time we try to migrate the project we get a permissions error.
ERROR: (gcloud.alpha.projects.move) User [email] does not have permission to access projects instance [PROJECT_ID] (or it may not exist): The caller does not have permission
Steps we've taken so far (basically followed this):
We've added the user who is migrating the project into the target organization- giving him the 'Project Creator' role
In the source organization ("No Organization"), we added the same user and gave him the role "Project Mover"
Then in the GCP cloud console, we used this command:
gcloud alpha projects move PROJECT_ID --organization ORGANIZATION_ID
We then select y to confirm our change and then get the permissions issue again
We've verified that the user has all of the correct permissions across projects, so we're really unsure how to proceed with this migration right now. We've also given the user the roles Organization Policy Administrator and Owner within IAM with no luck.
If anyone has experienced a similar issue, any guidance would be very appreciated!
Thanks!
The user must be a project owner of the project being moved - Project Mover is not enough. The user must also be a Project Creator at the Organization level - adding this role at the project level will not work.
If you are using Folders in the organization, the user will also need either the Folder Admin or Folder Mover role at the Organization level.
I have been using Azure DevOps for a project for quite some time, but suddenly publishing to my own organisation/collection feed results in a 403.
I created a feed and I can select it on the nuget push build step, but it does not work. I created a new feed to publish the NuGet packages to and this works perfectly again. It seems to me like a token expired, but I never created one or used it to authenticate. I also do not want to change my NuGet feed to the new one, as I want to use older packages as well.
This is the buildpipeline:
And this is the stack trace:
Active code page: 65001 SYSTEMVSSCONNECTION exists true
SYSTEMVSSCONNECTION exists true SYSTEMVSSCONNECTION exists true
[warning]Could not create provenance session: {"statusCode":500,"result":{"$id":"1","innerException":null,"message":"User
'a831bb9f-aef5-4b63-91cd-4027b16710cf' lacks permission to complete
this action. You need to have
'ReadPackages'.","typeName":"Microsoft.VisualStudio.Services.Feed.WebApi.FeedNeedsPermissionsException,
Microsoft.VisualStudio.Services.Feed.WebApi","typeKey":"FeedNeedsPermissionsException","errorCode":0,"eventId":3000}}
Saving NuGet.config to a temporary config file. Saving NuGet.config to
a temporary config file. [command]"C:\Program Files\dotnet\dotnet.exe"
nuget push d:\a\1\a\Microwave.0.13.3.2019072215-beta.nupkg --source
https://simonheiss87.pkgs.visualstudio.com/_packaging/5f0802e1-99c5-450f-b02d-6d5f1c946cff/nuget/v3/index.json
--api-key VSTS error: Unable to load the service index for source https://simonheiss87.pkgs.visualstudio.com/_packaging/5f0802e1-99c5-450f-b02d-6d5f1c946cff/nuget/v3/index.json.
error: Response status code does not indicate success: 403
(Forbidden - User 'a831bb9f-aef5-4b63-91cd-4027b16710cf' lacks
permission to complete this action. You need to have 'ReadPackages'.
(DevOps Activity ID: 2D81C262-96A3-457B-B792-0B73514AAB5E)).
[error]Error: The process 'C:\Program Files\dotnet\dotnet.exe' failed with exit code 1
[error]Packages failed to publish
[section]Finishing: dotnet push to own feed
Is there an option I am overlooking where I have to authenticate myself somehow? It is just so weird.
"message":"User 'a831bb9f-aef5-4b63-91cd-4027b16710cf' lacks
permission to complete this action. You need to have 'ReadPackages'.
According to this error message, the error you received caused by the user(a831bb9f-aef5-4b63-91cd-4027b16710cf) does not have the access permission to your feed.
And also, as I checked from backend, a831bb9f-aef5-4b63-91cd-4027b16710cf is the VSID of your Build Service account. So, please try with adding this user(Micxxxave Build Service (sixxxxss87)) into your target feed, and assign this user the role of Contributor or higher permissions on the feed.
In addition, here has the doc you can refer:
There is a new UI in the Feed Permissions:
To further expand on Merlin's solution & related links (specifically this one about scope), if your solution has only ONE project within it, Azure Pipelines seems to automatically restrict the scope of the job agent to the agent itself. As a result, it has no visibility of any services outside of it, including your own private NuGet repos held in Pipelines.
Solutions with multiple projects automatically have their scope unlocked, giving build agents visibility of your private NuGet feeds held in Pipelines.
I've found the easiest way to remove the scope restrictions on single project builds is to:
In the pipelines project, click the "Settings" cog at the bottom left of the screen.
Go to Pipelines > Settings
Uncheck "Limit job authorization scope to current project"
Hey presto, your 403 error during your builds involving private NuGet feeds should now disappear!
I want to add a bit more information just in case somebody ends up having the same kind of problem. All information shared by the other users is correct, there is one more caveat to keep into consideration.
The policies settings are superseded by the organization settings. If you find yourself unable to modify the settings or they are grayed out click on "Azure DevOps" logo at the left top of the screen.
Click on Organization Settings at the bottom left.
Go to Pipeline --> Settings and verify the current configuration.
When I created my organization it was limiting the scope at the organization level. It took me a while to realize it was superseding the project.
Still wondering where that "Limit job authorization scope to current project" setting is, took me a while to find it, its in the project settings, below screenshot should help
It may not be immediately obvious or intuitive, but this error will also occur when the project your pipeline is running under is public, but the feed it is accessing is not. That might be the case, for instance, when accessing an organization-level feed.
In that scenario, there are three possible resolutions:
Make the feed public, in which case authentication isn't required; or
Make the project private, thus forcing the service to authenticate; or
Include the Allow project-scoped builds under your feed permissions.
The instructions for the last option are included in #Merlin Liang - MSFT's excellent answer, but the other options might be preferable depending on your requirements.
At minimum, this hopefully provides additional insight into the types of circumstances that can lead to this error.
Another thing to check, if using a yaml file for the Pipelines, is if the feed name is correct.
I know this might seem like a moot point, but I spent a long time debugging the ..lacks permission to complete this action. You need to have 'AddPackage'. error only to find I had referenced the wrong feed in my azure-pipelines.yaml file.
If you don't want to/cannot change Project-level settings like here
You can set this per feed by clicking 'Allow Project-scoped builds' (for me greyed out as it's already enabled).
That's different from the accepted answer, as you don't have to explicitly add the user and set the permissions.
Adding these two permissions solved my issue.
Project Collection Build Service (PROJECT_NAME)
[PROJECT_NAME]\Project Collection Build Service Accounts
https://learn.microsoft.com/en-us/answers/questions/723164/granting-read-privileges-to-azure-artifact-feed.html
If I clone an existing pipeline that works and modify it for a new project the build works fine.
But if I try to create a new pipeline I get the 403 forbidden error.
This may not be a solution but I have tried everything else suggest here and elsewhere but I still cannot get it to work.
Cloning worked for me.
Background:
I'm quite new to App Maker, but have been involved in programming/IT for over 2 decades.
I have created an App Maker app, which works fine. It is deployed, and functions internally in our organization.
It accesses a Team Drive spreadsheet, makes modifications to it based on input criteria, and sends an email out to a hardcoded user. It uses no external GCP database or other resource.
The OAuth scopes it requires are:
admin.directory.user.readonly
drive.readonly
script.send_mail
spreadsheets
userinfo.email
Problem:
I can no longer preview the app.
When I click on "Preview" at the top right, a new tab opens and a spinning wheels seems to indicate that the preview is loading. Within about 4 seconds, the tab closes and the original tab (with the scripts, UI etc) gives a "Previewing failed. Dismiss" error in the bottom centre.
I am both able to deploy the exact same code/UI/etc, as well as run it without issue.
I do not know what I changed, since being able to preview the app, but cannot seem to regress to that state.
What I've tried:
Admittedly not much, as I don't know where to look. I'm rather certain that there must be some setting somewhere, but for all my googling, I've come up empty.
This can't be a client/server script or other syntax issue, as otherwise the deployment also wouldn't work.
With a more meaningful error, I would know where to look.
Expected Result:
Obviously, I should be able to preview the app if it is deployable.
Following #Morfinismo's comment, I contacted G Suite Support; my matter was escalated to the API Team.
I was asked by Google Cloud Support ("Support") to provide network traffic info using FiddlerCap. As I am on a linux machine and FiddlerCap is a windows application, I suggested alternatives (eg:Wireshark). It was eventually not required and never provided.
I noticed that on the Google scripts page, when accessing the project in question selecting "Preview", it was missing the following OAuth:
https://www.googleapis.com/auth/admin.directory.user.readonly
The functioning deployed version did not have this missing.
Still in the Preview, I selected "Stackdriver (logs)", which gave me an error that the project had been deleted. The actual wording was:
Access forbidden
Project XXXX is shut down and scheduled to be deleted. A project owner can cancel the shutdown on the projects list page.
Clicking on the link in the error "Go to projects list page" brought me to a page with the title "Resources pending deletion", which did not load a list of projects (but otherwise fully loaded) and would display the spinning wheel in perpetuity. I attempted this multiple times, including leaving it overnight once.
Support presumed that I had deleted the GCP project, although I honestly don't/didn't think I had. I also confirmed that creating new previews did not work, but creating new deployments did. I also confirm(ed) that this particular App Maker app did not require (eg) a GCP SQL database.
Support pointed me toward the following website: Google undelete project and I was asked to follow these steps (copy-pasted here):
a. For projectId, enter your project ID. From the screenshot you provided, this is "XXX (redacted)" (the quotes are just to emphasise the project ID, you shouldn't enter them.
b. Click EXECUTE.
c. You'll be prompted to grant authorisation, which may be preceded by a prompt to choose your admin account. Please do so.
d. You should receive a 200 response, with an empty body, that is {}.
e. Attempt to access the project via Project link (with the actual project id redacted here).
The above yielded some strange behaviour:
a. undeleteing the project gave it a different name that the App Maker app;
b. I notice that I had 3 other projects all called correctly (the App Maker app name).
c. When asked to reauthorize, I was provided with yet another project name ("Untitled project"), which was different from the correct one and different from the one in para. 7a, above.
d. I then also obtained another error in a new window which read:
That's an error
Request Details
(a bunch of stuff)
That's all we know.
Support advised that there may be a propagation issue, and that I should wait up to 30 minutes. I did, and it then worked! The only weird thing was the project name was wrong, but it was only for the preview, so I didn't really care.
If anyone needs additional information, I can PM screenshots I took along the way.
Hope this helps someone!
SJL
I had an app created for me--Demeter's Harvest (iOS). The company that built it has dropped off the map, so I can't get them to help me with this.
I get a message when I try to access it all that reads: An App ID with Identifier 'info.NAMEOFDEVELOPER.demeter' is not available. Please enter a different string." and another one for the Bundle ID that shows the Identifier 'info.ORIGINALDEVNAME.demeter' with the version and build.
I placed my name into the team area, and got a message that says no non-expired provisioning profiles are installed with a "Fix Issue" button.
How do I go about gaining access to my app code (if that is what it does) so I can get a new developer to make changes and updates to it?
Thanks,
Ed
You're likely up a creek here. If you don't have your app code there's no way anyone can help you gain access to it except the developer.
Regarding the bundleID it will be tied to whichever Dev Portal created it. If you own that portal you're fine. If the developer owns that portal and they either don't renew their account or block you from accessing it there will be no way for you to re-use it.
For an ASP.NET web application that is packaged and sold to customers for deployment, what would be the best location for a "read me" file with notes about setup and configuration on the target system?
Requirements:
The file should not be accessible by
users of the web application, only
the person doing setup and
configuration.
The file should be
consumable by the MSI installer
program, so that it can be displayed
as part of the setup wizard UI.
The solution should be simple and very
low cost. (I don't want an elaborate
solution for just a simple text
file.)
Some thoughts I have are to copy the file to *App_Data* or to bin as those are protected folders by default, and then pull the file in from one of those locations in the setup program.
The readme should be a separate file that sits beside the MSI on the media you distribute the web app on. This is a standard practice dating from generations ago the dark ages. If you distribute as a download from the web then have a link for the MSI, and a link for the readme.
You could also include the same file into the MSI, but arguably that is the wrong place for it as the user has yet to reach the configuration stage, and unless they print it they won't be able to refer to it later in the MSI process (if you have any configuration steps in the MSI).
Having the instructions available via the web app is also arguably wrong, as the user may have to do some initial configuration in order to reach the page telling them how to configure the app....
So ship the instructions separately to the MSI, and make sure they look okay and are easily readable when printed out. Remember these pointers:
Instructions are not always read
Instructions are not always read at the time of installation
Instructions are not always read by the same person that does the installation
Instructions are not always read from the screen
Instructions are not always read correctly, even when they are simple
Instructions are not always read (I know that is a duplicate of the first point...)
Don't forget to clearly distinguish between pre-install and post-install configuration instructions (even if they are in the same document) - you want to minimize the risk of the end user getting it wrong (which some of them will do no matter how hard you try).
Build the important message into your application. Do it like Apache where it says "this is a new installation of...." and don't allow that screen to go away until they go in and do all the things that you consider important.
This isn't a problem for your installer to solve.