I've added filtering to the developers page that is only available to administrators and recruiters.
I've extended developers/model.go so I can reuse ValidRoleLevels and ValidRoleTypes, and I've introduced some Sorted... methods in there so we can control the order in which these fields render on the filters page.
When the search filters are applied, I'm taking the recruiter filters and adding them to the URL as query parameters.
The backend code only applies these filters if the logged in user is a recruiter or admin. For unauthorised users, the query parameters are ignored entirely – we don't even parse them.
To apply the filters, I've had to really change up how we were building the SQL query in DevelopersByLocationAndTag so we can dynamically add WHERE conditions when relevant.
This has allowed us to simplify the query in ways, as we no longer need a switch statement that covers every possible permutation of location, skills, and these new filters.
Annoyingly, the postgres database doesn't like ? placeholder values and instead requires us to set $1, $2, $3, etc. To make it work I've had to introduce argIndex to keep track of how many dynamic arguments we insert, so the next placeholders are set correctly (this enables the next condition to be added as $4.
Of course, I'm not wedded to any particular styling or behavioural decisions. Happy to work with y'all and tweak as required :)
ghost
commented
1 year ago
As requested in #76
I've added filtering to the developers page that is only available to administrators and recruiters.
I've extended
developers/model.goso I can reuseValidRoleLevelsandValidRoleTypes, and I've introduced someSorted...methods in there so we can control the order in which these fields render on the filters page.When the search filters are applied, I'm taking the recruiter filters and adding them to the URL as query parameters.
The backend code only applies these filters if the logged in user is a recruiter or admin. For unauthorised users, the query parameters are ignored entirely – we don't even parse them.
To apply the filters, I've had to really change up how we were building the SQL query in
DevelopersByLocationAndTagso we can dynamically add WHERE conditions when relevant.This has allowed us to simplify the query in ways, as we no longer need a
switchstatement that covers every possible permutation of location, skills, and these new filters.Annoyingly, the postgres database doesn't like
?placeholder values and instead requires us to set$1,$2,$3, etc. To make it work I've had to introduceargIndexto keep track of how many dynamic arguments we insert, so the next placeholders are set correctly (this enables the next condition to be added as$4.Of course, I'm not wedded to any particular styling or behavioural decisions. Happy to work with y'all and tweak as required :)
Bounty hunting: /claim #76