Hi @mcascone , I admit this can be confusing and is unintuitive because these were added separately over time, and the weren't originally designed for how they're used today. We need to rethink/redesign this based on the use cases. I'm going to add this thread under the "promotion/repackaging workflows" topic for our next major version of ProGet. Once we know what we want to do, we can may be able to implement some changes as a preview feature in v6. FYI, this is exactly how the big API Key changes and feed/package usage instructions came about! https://forums.inedo.com/topic/3204/proget-feature-request-api-key-admin-per-user So stay tuned :)

Hi Francois, The quickest way to get something like this implemented is by going through the feature request process this process really drives our roadmap. as for ETA, I wouldn't want to predict that, but we do release new versions on a frequent basis. Thanks, Jason

Are you granting "Anonymous" the permission to view/download packages? If you remove that from the User Tasks page, then authentication would be required.

Turns out I needed to migrate the feed to the "new format" that supports semver. Everything worked like a charm afterwards. Thanks

Manage Pipelines cannot be scoped to an environment, because pipelines are not associated with an environment. They deploy to a series of environments. you can restrict deployment to environments. You can restrict editing of configuration file instances to a particular environment, and as long as that configuration file is associated with an environment.

In order to create a feed-scoped permission, the task must be feed-scopable. Go to Tasks > Customize Tasks, and remove any attributes that aren't marked "F" for feed scopable. Then you can apply to to feeds.

Ah ha! Thank you so much. I'll look in to this right now :)

I would remove the "NuGet API Key" from your NuGet feed; that is a seperate thing from "ProGet API Keys", which makes it quite confusing. This is why it will be deprecated in v5. You don't need an API key; you can just publish using usename/[password.

Hello Jim, You can run the ProGet service in interactive mode to see its logs: Stop the ProGet service. In Command Prompt or PowerShell, run .\ProGet.Service.exe run from C:\Program Files\ProGet\Service (or wherever you installed ProGet if you didn't use the default location). It will run the drop path monitor every 60 seconds by default. The message for the drop path monitor starting is Executing DropPathMonitorExecuter.... You can edit Service.DropPathMonitorExecuterThrottle in /administration/advanced-settings to less than 60 seconds if waiting gets too annoying. Immediately after the drop path monitor runs, there should be a message that says Scanning for packages in f:\dsc\droppath. This will be followed by Found f:\dsc\droppath\file.ext any packages it finds. In order to be found, the package files must end in the expected extension: .tgz for npm feeds .nupkg for NuGet feeds .gem for Ruby Gems feeds .upack for Universal feeds .vsix for VSIX feeds If an error occurs while trying to add a package from the drop path, it will appear on a line shortly after the Found f:\dsc\droppath\file.ext line, starting with Error installing package:.

The "Pull from Another Repository" actually requires the Feeds_PullPackage privilege; so make sure to grant anonymous that as well. Then it should work as expected!

The admin tool does not currently add the user back; but you can do so directly in the database; the tables are fairly straightforward. To reinstall, make sure to drop the database after install well. It does not get removed by default.

That doesn't sound right for a default obviously; I've opened [BM-2256] to investigate further. It's possible it happened during an upgrade of some sorts. In the mean time, you can safely exclude that.

Thanks Alana. Could you guide me to-what table should I be making what changes?

LDAPMultipleDomainEnabled needs to be true to see users in a different domain from the one that the server is running on. The privileges for multiple domain enabled will also be different since the domain becomes a part of the username e.g. principal@domain instead of just principal

Oh I see what you mean - I thought you meant that you were able to upload packages using the NuGet client... I was able to reproduce in that way. We'll have a fix for this in maintenance release v3.0.4 (logged as issue PG-210). Apologies for the confusion.

Feeds_DownloadPackage refers to a user downloading a package from the feed (via NuGet client, VS client, etc.) regardless if it's hosted locally or downloaded from a connector. Feeds_PullPackage refers to pulling a package down from a connected feed into the ProGet-hosted feed. There's a button that does this on the package details page.

The user that connects to SQL Server needs to be granted the BuildMasterUser_Role; this role is created as part of the database creation. No additional roles or access is needed.

Generally this is a result of the web application domain account lacking sufficient privileges. Ensure that the account that the BuildMaster web standalone service (for the self-hosted web server) or the IIS application pool is running under an account that can query service statuses on the machine.