In order to get rid of client-side data manipulation of the issues, rule violations, and projects tables in the UI - and, correspondingly, usage of ALL_ITEMS when fetching these items from the back-end, the following filters need to be added to the corresponding API endpoints:
- Issues endpoint: package identifier, PURL, severity, category.
- Rule violations endpoint: package identifier, PURL, severity, rule.
- Projects endpoint: identifier, declared license, definition file path.
Adding these filters will enable the UI to switch using server-side data manipulation in the corresponding tables, while retaining the current filtering capability.
Of all these filters, "issues/category" and "rule violations/rule" are the ones probably needing team discussion first, because it's not self-evident how they should be implemented.
In order to get rid of client-side data manipulation of the issues, rule violations, and projects tables in the UI - and, correspondingly, usage of ALL_ITEMS when fetching these items from the back-end, the following filters need to be added to the corresponding API endpoints:
Adding these filters will enable the UI to switch using server-side data manipulation in the corresponding tables, while retaining the current filtering capability.
Of all these filters, "issues/category" and "rule violations/rule" are the ones probably needing team discussion first, because it's not self-evident how they should be implemented.