Implement search, filter and sort functionality for ORT runs view

[bs-ondem]

The ORT runs view currently does not allow to search, filter or sort ORT runs, which makes it difficult for users to quickly find specific ORT runs. To improve usability and efficiency, we should implement search, filter and sort options that will allow users to easily navigate and manage the ORT runs.

[sschuberth]

FYI, this is something that's part of our next sprint. Ping @Etsija and @lamppu.

[bs-ondem]

Thanks, good to know! Is there another issue to track the progress, or can we use this one? The issue #2047 is partly required for this one, right?

[sschuberth]

Is there another issue to track the progress, or can we use this one?

We only have an internal ticket so far, so let's this one to track it publicly.

The issue #2047 is partly required for this one, right?

Correct. It'd be nice if we could share the work by e.g. you doing the back-end work, and we doing the front-end work. Or doing both via pair programming, as you hinted at wanting do to some front-end work as well, and esp. @lamppu also does back-end work already.

[bs-ondem]

Or doing both via pair programming, as you hinted at wanting do to some front-end work as well, and esp. @lamppu also does back-end work already.

Yes, we can split the work, but I'm not sure if pair programming makes sense right now. Depending on when @lamppu will start working on the issue, we can consider pair programming. However, I need to dig deeper into the UI code to get a better understanding first.

[Etsija]

We could already sort and filter the runs table, but client-side, that would have a bad impact on performance, so yes, we would need the features described in #2047 first, then do server-side filtering and sorting in the UI, because that is far more performant.

The basic rule-of-thumb is, never mix and match server-side and client-side data manipulation for a table, because that will very easily lead to going out-of-sync between the client and server when showing the data. That's why we have only pagination (server-side) implemented for those tables that do not support filtering and sorting properly (on server-side). For those tables which aren't anticipated to include so much data (for example, vulnerabilities, issues, rule violations), we are currently using client-side pagination, filtering and sorting, but the ultimate goal is that also these would be using server-side data manipulation.

In the UI code, it doesn't make much difference which we use, the changes between using server-side / client-side data manipulation for tables are pretty minor.

[Etsija]

BTW I am also available to do some pair programming on the UI code, when needed and feasible.