Filter project boards based on labels

[techknowlogick]

Partial implementation of #21846
Without filtering:

With filtering:

Per the ticket, this is a naive approach where the filtering is done via client side. The proper approach would be to do it client side, and this can be done once the sorting of tickets issue is solved.

[KlavsKlavsen]

Whats missing for this? We're going to test it out - as we need to "filter" on assignee - so we can use it for standup (as swimlanes are not there) - as a way to isolate to each person when they're doing standup - to show their issues only

[techknowlogick]

@KlavsKlavsen What's missing is an actual implementation. This "gets the job done", but in many cases makes page loads too slow to be usable as it needs to process the entire board in client side. The PR is marked as draft to make sure it doesn't accidentally get merged. Project board filtering by label was requested, and so I made this PR for two reasons 1. to have something that meets the definition of done, but more so 2. to really walk through the problem set and fully understand the issue and how best it could be solved.

The blocker is that if the filtering is done server side (which code exists already to be able to do that) is that once filtered the sorting javascript, posts the entire column and if an issue in the column is filtered out then when the post happens it'll remove the filtered issues from the kanban as a whole.

This is something that could be solved, and I've documented my entire process so far so that that next step be taken even without me.

[KlavsKlavsen]

as I understand it - kanban board (project board) view - today shows ALL tasks.. no matter who they'are assigned to.
So WHY would it be heavy to simply "filter" on client side - based on f.ex. "assignee" ? is it the browser that spends too much CPU processing the "cards" on the board ?

yes - you COULD save backend time - by NOT getting all issues from backend (when you're going to filter anyways) - but this IS still an improvement over current code - and the performance problem of fetching "all issues when you have many" - will still be a problem - with or without this swimlanes in UI filtering.

So IMHO this should be merged (if it runs fast enough on clientside with parsing issues) - and a task for improving this, with allowing filtering on backend instead - should be added for improvement later.

But yes - the "right implementation" - would probably be to extend the API where the UI gets issues from - to support filtering.. and then simply extend UI to add that "filtering param" when you select swimlanes

which API endpoint is being called to get these cards? does not sound like a huge task to extend the backend to support filtering - if it doesn't already.
And then UI will have to build a select list of swimlane filters.. like you already do