CVEs with many affected packages frontend is overwhelming

[jess-lowe]

https://github.com/user-attachments/assets/688048cc-8e22-4e9e-9c9b-7d93a78b21a3

Too many affected packages where all of the information is being displayed makes the information overwhelming for users.

Possible solutions could include:

• Better grouping
• Collapse tabs by default when > ~7 affected packages

[hogo6002]

Nice video description!

[andrewpollock]

@jess-lowe for the record, could you please state which records this screen cast is showing?

[jess-lowe]

@jess-lowe for the record, could you please state which records this screen cast is showing?

UBUNTU-CVE-2024-45341

[Kunal9027]

Hi, @jess-lowe

I’d like to work on this issue. For auto-collapsing, I believe the following logic can help:

{% set collapse_threshold = 7 %}
<spicy-sections
  class="vulnerability-packages{% if vulnerability.affected | length > collapse_threshold %} force-collapse{% endif %}">

This would collapse the section when the number of affected packages exceeds 7.

Regarding grouping, I have implemented logic to group affected packages by their ecosystem:

{% set grouped_packages = {} %}
{% for affected in vulnerability.affected %}
    {% set ecosystem = affected.package.ecosystem if 'package' in affected else 'Git' %}
    {% if ecosystem not in grouped_packages %}
        {% set _ = grouped_packages.update({ecosystem: []}) %}
    {% endif %}
    {% set _ = grouped_packages[ecosystem].append(affected) %}
{% endfor %}

{% for ecosystem, packages in grouped_packages.items() %}
  <h2>{{ ecosystem }}</h2>
  <div>
    {% for package in packages %}
      <h3>{{ package.package.name }}</h3>
    {% endfor %}
  </div>
{% endfor %}

Thanks! Kunal9027

[jess-lowe]

Hey @Kunal9027. Happy for you to work on this - feel free to put the logic into a PR and so we can check out the commit and play around with the frontend that way.

We have recently added a way of hopefully testing the frontend without GCP access but I haven't yet set up a test case that would help with this specific case, otherwise I'd ask if you'd be able to test it.

Let's move this chat to a PR regardless :)

[Kunal9027]

Hi! @jess-lowe

Should I open a PR only with the auto-collapse logic (when affected packages exceed the threshold of 7) for testing?

Also, could you please clarify how you'd like the affected packages to be grouped?

Should it be grouped by ecosystem, package name, or purl?

Thanks a lot!

[jess-lowe]

Hey - yes, feel free to open a PR for the auto-collapse logic.

I'll chat with the rest of the team to see what they think about for grouping, but for now, maybe just do it by ecosystem if you don't mind? It can be a separate PR :)

[Kunal9027]

Hey @jess-lowe Thanks for testing it and for the update.

I’d love to keep working on it. That said, I’m currently running into some issues while trying to run the local frontend server — I’ve attached a few screenshots to show what’s happening. If you could help me figure out how to set it up properly, that’d be awesome!

run this command gcloud auth login --update-adc i get this error

then i run make run-website

i also try run the main.py file directly by using this command cd gcp/website && poetry run python main.py but still i get the internal server error.

but when i go to different URL like /blog it works perfectly

i understand that it's an API issue but how do i fix this i read docs , contribution.md and Readme files but i do not find any solution .

Once that’s sorted, having those relevant bugs for the local frontend emulator would definitely help me test and iterate more effectively. Appreciate the support! 😊

[jess-lowe]

Hey @Kunal9027, sorry for the delayed response - have been OOO :).

Can you try running make run-website-emulator instead? Unfortunately, I haven't gotten around to updating the contribution docs on how to use the emulator yet, or adding a bunch of affected fields to any specific bug, but seeing if that works is a good start.

run-website-emulator runs the frontend locally, with the bugs from the whereas run-website uses the GCP data, which needs GCP access auth, unfortunately.

[Kunal9027]

It's working now—thanks for your help, @jess-lowe! I set up the project on WSL Ubuntu 24.04, and it worked in one go using your run-website-emulator command. Could you please guide me on which issues or bugs I should start working on?

[jess-lowe]

Just added a test case that should work. Try /vulnerability/CVE-2 with the latest pull of the repo, and hopefully that should be good enough to work with. You may have to relaunch the make run-website-emulator each time you make change. Let me know if you have any questions :)

[Kunal9027]

@jess-lowe I am working on the grouping — now the affected packages are sorted and grouped by ecosystem, so it’s easier to follow. i have attach the video

https://github.com/user-attachments/assets/aa0991f3-e2e7-4ebb-a984-75e055d2c846

yes there are still some issues like when I click on the ecosystem it only collapses the first affected package i am still working on it and the affected packages are collapsing automatically on refreshing so that logic is working but not working for ecosystem

if you want any change in UI or any suggestions Tell me i am ready for working on it

[jess-lowe]

Hey @Kunal9027, so sorry for the long wait. I appreciate the work but I'm worried it adds more vertical breadth to the page (which is what we are trying to reduce).

I'm learning that the current logic is when it gets over a certain amount of ecosystems, it turns to that sort of expanded box, from originally the tab format (like in a below image)

I was thinking of maybe more of a combined solution where you have the tabs like:

, but also have the collapsible boxes for each project within. Maybe auto-collapsing might not be as much of a concern then?

If it's too weird and complicated and needs more UX design work (entirely likely), feel free to shelve this issue for now to work on one of the easier projects.

Thanks!