What is the general design philosophy regarding permissions and visibility in ProGet?

jw

My colleagues have reported a few issues with the ProGet UI to me. Usually it revolves around them seeing a link or a button but when they click that element, either nothing happens or they receive a 403 error, either in-page or as popup.

From permission point of view this makes totally sense, as they are trying to access resources which they are not authorized for.

I tend to agree with them that from a UI/UX perspective this is a bit annoying.

From what I could gather from the ProGet UI is that the general design philosophy seems to be to hide elements (links, buttons, pages, panels, etc.) when a user does not have the appropriate permissions.

Is my assumption here correct and does it make sense for me to report those issues that my colleagues and I have found?

atripp

Hi @jw

You're correct, the general design philosophy is to hide elements (links, buttons, pages, panels, etc.) when a user does not have the appropriate permissions.

As you also might imagine, it's hard to get that right all the time and obviously it's not a high-priority in testing (internally) or reporting (users/externally).... so if you spot places where it's incorrect, let us know. We're always keen to improve the UI/UX :)

Best,
Alana

jw

I think it makes sense to put the SCA 2024 Preview UI feedback in a different post, or this one will get too long.

Here a some of the issues my colleagues reported to me.

Version: 2023.32.
For a user with the following permission set:

Top menu bar - Replication /

Link leads to 403 page and exception is recorded in admin log.

=> The replication link should be hidden if the feature is not licensed or at least be moved into the admin panel. A user without permissions should never be able to see that link, since they usually have no business configuring it.

Packages and Container page /packages and/containers

The bulk edit menu is always visible, clicking on it shows a menu with delete or promote option. Selecting Delete selected results in no action at all, which is misleading.

=> The "bulk edit" link should be hidden for users that do not have delete or promote permissions in any feed.

What might be a bit more tricky to handle is the case when users have local feed permissions. Some feedback to the user about what did or did not happen would probably be a good start.

Package page /feeds/nuget-feed/package-name/1.0.0

The Repackage Package and Reanalyze Packge link both lead to 403 pages and exceptions are recorded in the admin log.

=> Both menu items should be hidden

Package metadata page /feeds/nuget-feed/package-name/1.0.0/metadata

details link causes 403 and exception is recorded in admin log.

=> There should probably be two links "view" and "edit"
View should be available for everyone regardless of permission, since they can just navigate to the file tab and find the embedded license file directly. Edit should only be visible with appropriate permissions.

stevedennis

@jw excellent, thanks for the finds! I also added this to our "final touches" for ProGet 2024 to address all these-- all pretty easy fixes I think

jw

Thanks for squeezing these all into the upcoming release.

On semi-related notes:

Does it make sense to give feedback about SCA 2024 issues for the 24.0.0-ci.5 version, or will there be a RC before the release?

atripp

Hi @jw ,

We're in the final stretches of ProGet 2024 now (looks like we're on ci-27 as of this morning); you're welcome to try it, we've been using it for a bit ourselves. It seems to mostly work.

You're also welcome to send us a BAK of your database (opne a ticket for that, and we'll send a secure link to upload). Then we can test upgrades and make sure the UI/UX works with your data.

Our plan as of now is to do some final touches, testing, and bug fixes next week, and then ship 2024.0 on Friday assuming it passes the final tests. And I'm sure we'll be shipping a 2024.1 shortly after :)

We don't plan on doing an RC however; those are mostly for getting "patch" maintenance releases sooner.

Thanks,
Alana

jw

We're in the final stretches of ProGet 2024 now (looks like we're on ci-27 as of this morning); you're welcome to try it, we've been using it for a bit ourselves. It seems to mostly work.

I've been looking into ci-30 a bit, since I had some issues with the SCA API, but it seems they still persist in this version.

https://docs.inedo.com/docs/proget-sca-releases-get
- I cannot get the /api/sca/releases?project= to work, I always get some Persisted object is not a ProjectReleaseConfiguration. HTTP 500 error.
- According to docs ReleaseInfo does not contain the id, it would be good to have that there. From what I understand the id is needed for the /api/json/Projects_GetBuildInfo?ProjectBuild_Id= API
- Few docs issues
  - releases endpoint should probably be builds now
  - /api/sca/releases?name= is mentioned a few times but the parameter should probably be project
Export SBOM for both formats is still broken for me in this version.
Version number is cut off in the UI
The SCA Events seem quite granular

Do these really fire for every single "noncompliant package", "vulnerability detected" or "issue opened"?
I was hope something along the lines of "Build Added" that fires after a new SBOM was imported, containing the build id, project name and build version

atripp

Hi @jw , let's move some of these to a new thread, since this is sort of getting a bit long / off topic. I'll reply here then lock the thread, but feel free to reply as a new thread for any one of these topics.

First, if you haven't already, I'd submit your database so we can test using your database. I don't know what has/hasn't been tested yet, but that's what we plan to do this week.

Internal Ids --- we will likely not include internal Ids in the /sca endpoints; those are only exposed in the native API (which we don't recommend using). We really don't you to use the Native API since it arbitrarily changes.

Docs -- the docs are going to be a little behind, but those will come out shortly after; note that our primary API will become a CLI, so the API docs will favor examples for pgutil. This will actually make building out new APIs a lot easier, since we can just point to GitHub code to show how it works, etc.

SCA Events -- these will also trigger when you upload a noncompliant package and one is discovered in an overnight scan (either of packages or builds). This is our starting point from zero, so we'll see what feedback we have and adjust accordingly.