In case valid PURL or URL is specified I would like to be able to pull license and copyright information from external sources such as pypi, clearly defined or github.
In the best case this could be somehow configurable, in a first POC one could limit the supported sources.

Helpful links/resources:
https://api.clearlydefined.io/api-docs/
https://docs.github.com/en/rest/reference/licenses
curl -sG -H 'Host: pypi.org' -H 'Accept: application/json' https://pypi.org/pypi/numpy/json

As shown in screenshot the labels are overlapping with the other text boxes. This is probably due to some update in a material-ui related package.

A pie chart for incomplete licenses in attributions shall be added to the statistics popup.
It should have two sectors: one for complete attributions and one for incomplete attributions. Further, the data should exclude first party.

As a user I do not want to have two scroll bars in the signals column. The result should satisfy the following goals:

• it should be easy to skip to another section of signals, e.g. jump to ScanCode
• if there are just a few signals, e.g. 4 from different sources for a file, they should all be visible at first glance
• If there are many signals, it should be easy to get an understanding of the "most common signals" over all sources

Ideas:

• A possible solution is to have - besides the accordions for signals, signals in folder content, and attributions in folder contents - accordions that contain the respective signals from different sources. These would initially be collapsed. If a user wants to look into one they have to expand the respective source. This could remove the double scrollbar.
• Another idea would be to remove the accordions completely and put everything into a single virtual list (maybe with some way to quickly go to a certain section).
• A scroll trough accordeon would be the premium solution.

Now:

When running tests, e.g. using yarn test:unit the terminal is flooded with warnings like:

  Warning: An update to $Component inside a test was not wrapped in act(...).
      
      When testing, code that causes React state updates should be wrapped into act(...):
      
      act(() => {
        /* fire events that update state */
      });
      /* assert on the output */

Some of these warnings can be fixed by wrapping the testStore.dispatch(...) into an act(...) in the tests. However, not all of these warnings are fixable by this approach.

The goal of the current ticket is to get rid of the warnings.

Note: this might be related to our upgrade to React 18.

Currently, there is a free text field that allows adding licenses (or license expressions):

The scope of this issue is to support license expressions explicitly in the UI. I.e. there are several fields for licenses that can be concatenated using AND and OR. Furthermore, exceptions like GPL with a classpath exception have to be handled.

User can open multiple pop up windows (e.g. "Show Project Metadata") at the same time one above the others and have to close them one by one later.

The current project metadata popup does not look good. It would be nice to improve the appearance of the table.

Is your feature request related to a problem? Please describe.
Currently, navigating the package lists, a user has to click each package individually in order to traverse the list.
For the user that implies the need to click a lot.

Navigation:

• simple up-down navigation with arrows
• experiment if it's better to select the item with space or if an item should be immediately selected after the navigation event

Describe the solution you'd like
As a user navigating a package list, I want to be able to use keyboard navigation.

The attribution counts we show in attribution view should also be shown in report view.

A possible place to display these is next the the filter panel:

Two e2e test are required:

• one with a small file, that checks that contained signals and contained attributions are correctly displayed in the accordion
• one with a file big enough to get web workers out of memory
  • about 100MB each for signals and attributions should be enough, check
  • keep the input parsing time to a minimum
    • uncompressed
    • maybe just one attribution each with 100MB text?

The pie chart should display the number of signals as clustered by criticaliy: high, medium, or no criticality.

As a user I want to get a quick overview of the percentage of files covered by a signal in the folder content.
Alternatively the total number might be sufficient.

Note: So far we do not use inference for signals (unlike we do for attributions). This seems to be necessary for this feature to make sense.

test

As a developer and as a reviewer it would be nice to see the coverage in all requests on github.
Similar to https://github.com/marketplace/actions/coverage-monitor

Add a table showing critical licenses (clustered by criticality high or medium). The table should have two columns: One should contain the license name and the other one total number.
Make sure to use deduplicated data as described in #943.

Add a pie chart for most frequent licenses in signals statistics popup.
The 5 most frequent licenses should be presented in a pie chart using the same deduplication as used in #943. Show the remaining ones as one more sector.

Note: for pie charts the following library might be well suited: https://devexpress.github.io/devextreme-reactive/react/chart/demos/pie/pie/

In the attribution view the chosen attribution is not highlighted (background color is not dark) in the list of all attributions if any of the required fields within the description is empty (e.g. license name, version...) and vice versa when hover on item.

• This is how it works for a complete atrribution.

• With empty fields.

What is wrong

When opening a large file the Signals in Folder Contents tab does not show any content even though there are signals further down the tree.
Moreover, an error message is logged:

Web worker error in workers context provider:  DOMException: Failed to execute 'postMessage' on 'Worker': Data cannot be cloned, out of memory.

What is expected

The Signals in Folder Contents tab should show some content.
How it looks:

How it should look like:

Steps to reproduce

Open https://github.com/opossum-tool/OpossumUI/blob/main/example-files/input_from_ort.json.gz and navigate to the root folder.

In Attribution View we show the number of follow ups and the total number of attributions:

It would be good to also show the numbers of incomplete and preselected attributions as well.

Many analysis and inventory tools already create SPDX documents. Instead of requiring special OpossumUI JSON schema as input, why not allow using an SPDX JSON document as input? This makes sense especially if OpossumUI can already export SPDX JSON/YAML documents. It would also make OpossumUI more interoperable with existing SBOM tooling.

The following Improvements for the Signals per Sources table should be implemented:

• use some deduplication for licenses
  • deduplicate by stripping emtpy spaces, dashes, making everything lowercase
  • For display use the license name occuring most often
• move Signals per Sources table to the bottom of the popup
• highlight criticality using color (the same we use at other places). Be creative and check what looks good.

There has been a case (at least on Windows) of the executable being built without errors and then throwing when starting the app. That should be tested for in the CI.

As some purls are highly ambiguous without namespace it should be required to be present for a purl to be valid in the following cases (hardcoded as config):

• github
• maven

Currently we have some parts where we fetch data from external APIs with fetch. In #472 we started using axios (mostly because it handles error codes for you).

Known usages of fetch:

• useFetchPackageInfo

Do a search to find any other occurrences. Also look at #472 to see how requests can be mocked.

The first time the user opens a URL, we want to show a warning message with just the domain name and three options:

• Accept for now and open the link.
• Accept forever and open the link (store domain in config).
• Cancel

Is your feature request related to a problem? Please describe.
Currently, as a user, I see all the signals attached to resources contained in a folder in the "signals in folder content" panel. However, I,m only interested in signals, that are attached to resources which do not have attribution attached (since these are "unresolved").
Such signals are not of interest, as an attribution that is attached to a resource propagates down and also applies to all its children (until there is another attribution attached to a child). In consequence, the signals are no longer relevant for all resources higher in the resource tree, as there is already an attribution.

Describe the solution you'd like
Therefore, these signals should be hidden in "signals in folder content" panel.

The current implementation of a loading spinner is not the best. As users we want the following:

• center window on macOs
• center spinner in Window
• make it smaller
  Now:
  

When opening an input file that has signals that consist of only a first party flag, the corresponding package card displays the "first party icon" but no text (see screenshot). Instead it should display some standard placeholder text like e.g. "First Party" or "is first party".

OpossumUI shows "unknown-version" of the app on Windows. For Mac version it seems to work fine.

Currently, we show a plain list of resources in the "Resources for selected attribution" popup:

Instead a small resource tree containing just these resources should be displayed (basically a filtered tree of all resources). This is similar to the case for the attribution view: #962.

The overall arrangement and styling of existing components should be improved.
The goal is to create a more modular appearance.

For testing purposes it would be good to have a large OpossumUI input file that contains a lot of signals from (many) different sources where the field criticality is non-empty.
This would be, in particular, helpful for testing the project statistics popup and performance in general.

As a user I would like to be able to navigate back to the previously visited resource.
This could be implemented by adding "go back" button for the resource tree, menu item and a shortcut.

Currently the criticality of signals is displayed in the package cards. This enables the user to quickly identify signals that are critical.
However, there is no way to easily identify the resources that have critical signals attached.

It would be valuable to have the following:

• Resources with critical licenses are highlighted (done, see #1028)
  • The icons indicating presence of signals shall be colored based on highest criticality for resources with critical signals and also their tooltip texts should be modified:
    
• There is a way to easily navigate through these resources
  • Introduce a second clickable progress bar for critical licenses (#1029)
    • there are three colors for no, high, and low criticality (only resources that have a signal but no attribution should be included)
    • there should be a nice on hover message incl the number of resources with critical (high and low separately) signal
    • there is a toggle (right next to existing bar) to switch between the new progress bar and the current one
  • clicking on the new bar brings the user to resources with critical signals and no attributions (high criticality first), see #1030

Currently, we pretty much always use the same setup (e.g. ipcRenderer mocking) in integration tests. However, this is duplicated code.

A nice way to extract this would be to use something like jest testEnvironment:

https://jestjs.io/docs/configuration#testenvironment-string

It would be great to include the user guide in the release information (besides the executables).

Current situation

Package URLs are notoriously difficult to fill in for the user. They are complicated and often there are several possibilities for a given package (e.g. pkg:mavencentral/junit/junit/4.6 and pkg:github/junit/junit4/4.6). #216 partly reduces this pain point as by fetching information from package managers one can often create a valid and meaningful PURL.
However, without a URL and incomplete/ambiguous license information (4.6 vs 4.6.0) it is still very hard to derive a PURL.

Suggestion

ClearlyDefined (CD) offers an endpoint to query their database with a search string.
Example:

curl -X GET https://api.clearlydefined.io/definitions?pattern=junit%404.6
[
  "sourcearchive/mavencentral/junit/junit/4.6",
  "sourcearchive/mavencentral/org.robolectric/junit/4.6",
  "maven/mavencentral/junit/junit/4.6",
  "maven/mavencentral/org.robolectric/junit/4.6",
  "maven/mavencentral/org.robolectric/junit/4.6-alpha-1",
  "sourcearchive/mavencentral/org.robolectric/junit/4.6-alpha-1",
  "maven/mavencentral/org.robolectric/junit/4.6.1",
  "sourcearchive/mavencentral/org.robolectric/junit/4.6.1",
  "maven/mavencentral/org.fluentlenium/fluentlenium-junit/4.6.1",
  "maven/mavencentral/io.cucumber/cucumber-junit/4.6.0",
  "sourcearchive/mavencentral/org.apache.openejb/openejb-junit/4.6.0",
  "sourcearchive/mavencentral/io.cucumber/cucumber-junit/4.6.0",
  "maven/mavencentral/org.apache.openejb/openejb-junit/4.6.0.2",
  "maven/mavencentral/org.apache.openejb/openejb-junit/4.6.0.1",
  "maven/mavencentral/org.fluentlenium/fluentlenium-junit/4.6.2",
  "maven/mavencentral/org.fluentlenium/fluentlenium-junit/4.6.0",
  "maven/mavencentral/org.apache.openejb/openejb-junit/4.6.0",
  "sourcearchive/mavencentral/org.ops4j.pax.exam/pax-exam-invoker-junit/4.6.0",
  "maven/mavencentral/org.ops4j.pax.exam/pax-exam-invoker-junit/4.6.0"
]

I suggest to offer a popup where the user can query this endpoint and sees a list of valid coordinates from (CD).
The user can then select an appropriate coordinate and we convert it to a valid PURL.
Another interesting endpoint is:

curl -X GET https://api.clearlydefined.io/definitions/maven/mavencentral/junit/junit/4.6
{
...
 "licensed": {
    "declared": "BSD-3-Clause",
    "toolScore": {
      "total": 75,
      "declared": 30,
      "discovered": 0,
      "consistency": 15,
      "spdx": 15,
      "texts": 15
    },
    "facets": {
      "core": {
        "attribution": {
          "unknown": 207,
          "parties": [
            "Copyright (c) 2000-2006, www.hamcrest.org"
          ]
        },
        "discovered": {
          "unknown": 207,
          "expressions": [
            "BSD-3-Clause"
          ]
        },
        "files": 208
      }
    },
    "score": {
      "total": 75,
      "declared": 30,
      "discovered": 0,
      "consistency": 15,
      "spdx": 15,
      "texts": 15
    }
  },
  "coordinates": {
    "type": "maven",
    "provider": "mavencentral",
    "namespace": "junit",
    "name": "junit",
    "revision": "4.6"
  },
...
}

One could enrich the list shown to the user with information from this endpoint to help choosing the good coordinate and at the same time get valuable copyright and license information.

Relevant links

https://api.clearlydefined.io/api-docs/
https://github.com/package-url/purl-spec/blob/master/PURL-TYPES.rst

Upgrade to node 17 would be nice. Currently blocked by react-scripts
facebook/create-react-app#11562

There are multiple references to the ORT fork opossum-tool/oss-review-toolkit in the README.
As this fork is not accessible, and as ORT itself notes support for OpossumUI, I assume this is out of date information and the reference should instead be to oss-review-toolkit/ort?

Locations where this reference occurs:

• the graphic under integration
• the section generating-input-files

Apologies if I'm misreading (or if the issue is considered noise, I could not find an issue template).

If all resources in a folder have an attribution the user shall get visible feedback about that.

Currently, there is no visual feedback for the user (ElectronBackend should be green):

Important: check performance afterwards.

As a user I want to see the resource tree in the attribution view. This is to see where linked resources are located. Probably it should be "read only" and look similar to the resource tree in the Audit view.
Currently:

Some terms within the User's guide are used before the declaration: attribution, signal, pre-selected, breakpoint
which makes the guide less clear.

We could use the screenshot functionality of playwright to automatically generate screenshots. Currently they get outdated rather fast and need to be fixed manually.

resourcesWithAttributedChildren have been introduced in AttributionData back at the time when we were showing down-arrows for signals and attributions (and were not virtualizing the tree). This data it is not optimized for the folder colors, and expensive to compute. Therefore:

1. remove it
2. if tree navigation becomes slower add new pre-computed data, that is:
   2.1 optimized to get the folder color,
   2.2 can be updated with cheap (aka fast) calculation if an attribution is created/deleted or a signal is hidden.

There is a log file for the electron backend. Include there error messages from the frontend.

Also see whether logging in backend in general could be improved. E.g. log file exports

In the past we sorted signals in audit view by the number of occurrences.

This is no longer the case:

This feature should be restored.

Opening the example file opossum_input.json in OpossumUI and triggering the Follow-up export, the respective export is triggered multiple times

Sometimes this causes the UI to be stuck in the following state:

This behavior seems to have been introduced in #815

If a user clicks on a directory in the Audit view, he expects the highlighting to "change"/stop at breakpoints or explicit attributions.
This should help to highlight what is / would be affected by an explicit attribution to the currently focused directory.
Now:

Should be:

After we introduce new graphs, tables and styling on project statistic popup it would be nice to finalize and clean up:

• check that styling is consistent
• check if there are any bugs or any things to improve
• refactor and clean up the code e.g. remove (or merge) duplicating styles...