AC:

Currently, we have a different param for every new filter we add (nyu, patina, hunter, etc).

As a result, the URL is getting a lot harder to keep track of. Here’s an example of one:

https://codebloom.patinanetwork.org/leaderboard/ec94650f-a2a4-4b62-b3d1-b3a367b87718?nyu=true&hunter=true&globalIndex=true

And it will only get worse as we keep adding new tags.

A good alternative is to add a new param called filters, which will pass in a list of strings. Here’s the same example with this new change:

https://codebloom.patinanetwork.org/leaderboard/ec94650f-a2a4-4b62-b3d1-b3a367b87718?filters=nyu,hunter,globalIndex

Now, the absense of a filter inside of filters is assumed to be false , and vice versa.

Make sure to take screenshots of testing this backend method to ensure that the same data is shown with the old way and the new way, and upload the screenshot to the PR!

Spring can automatically parse these params into a Set<String>, which makes it very easy to work with. We can then check for the enabled filters and set the rest to be false.

This task will set this logic inside of LeaderboardController.getLeaderboardUsersById

When we add this new filters property, we will not be removing any of the old logic for now so we don’t break anything in the frontend while we work on this. Instead, we want to check if filters is null or filters.isEmpty() , use the previous logic to create the LeaderboardFiltersOptions . Else, we will use the new way where inside of each method inside of options, we can check if filters contains the expected param string.