fix(people): honor dashboard classification filter on /v2/people

[SergioChan]

What Changed

• use the computed route filters ($filterByGender, $filterByClsId, $filterByFmrId) when exporting serverVars to the people-list JS initializer
• stop reading non-existent filterBy* query parameters, which left serverVars.filterByClsId empty for /v2/people?Classification=<id> links from People Dashboard
• this restores initial Classification/Role/Gender filter trigger behavior so dashboard links show the expected filtered list

Fixes #8208

Type

• ✨ Feature
• 🐛 Bug fix
• ♻️ Refactor
• 🏗️ Build/Infrastructure
• 🔒 Security

Testing

• Manual reasoning validation from code path:
  • listPeople() computes $filterByClsId from Classification query param
  • template now passes that computed value into serverVars.filterByClsId
  • existing shouldTriggerClassificationFilter logic then triggers .filter-Classification change on load
• Runtime validation not executed locally because this environment does not have php installed (php: command not found), so PHP lint/test commands were unavailable

Screenshots

• n/a (behavioral wiring fix)

Pre-Merge

• Tested locally
• No new warnings
• Build passes
• Backward compatible (or migration documented)

[Copilot]

Pull request overview

Restores People Dashboard → People List filtering by ensuring the /v2/people template exports the computed route filter values to the JS initializer (instead of reading non-existent query params), so initial Classification/Role/Gender filters can be applied on load.

Changes:

• Export $filterByGender, $filterByClsId, $filterByFmrId into the serverVars payload for the people list initializer.
• Stop reading $_GET['filterByGender'], $_GET['filterByClsId'], $_GET['filterByFmrId'] (which were not actual query params used by dashboard links).

[Copilot]

filterByClsId/filterByFmrId are now passed into serverVars as the computed display names, but the JS initializer (webpack/people/person-list.js) builds <option>s with numeric values and then calls .val(filterByClsId)/.val(filterByFmrId) to preselect. Because the option values are numbers, setting .val() to a name will not select anything, so triggering the change event will not apply the intended Classification/Role filters. Align the values by either (a) passing the option index/id in serverVars, or (b) changing the initializer to use option values matching the displayed text / to select by matching option text.

[Copilot]

familyActiveStatus is still being read directly from $_GET here even though the route already computes and passes a $familyActiveStatus value into the template. For consistency with the other filters (and to avoid discrepancies if the route logic/defaults change), use the computed template variable instead of raw query params.

Suggested change

	familyActiveStatus: <?= json_encode(isset($_GET['familyActiveStatus']) ? $_GET['familyActiveStatus'] : '', JSON_THROW_ON_ERROR) ?>
	familyActiveStatus: <?= json_encode($familyActiveStatus ?? '', JSON_THROW_ON_ERROR) ?>

[SergioChan]

Thanks for the review — both points are addressed in the latest commit (733942d):

• The server vars now pass numeric option IDs for Classification and FamilyRole, so the Select2 filters initialize with the correct option value IDs from webpack/people/person-list.js.
• familyActiveStatus in serverVars now uses the routed $familyActiveStatus value instead of reading $_GET directly.

Please re-check when you have a moment.

[DawoudIO]

Thanks for the PR, AI started working on this #8214 check it out and let me know when youare ready for a final review, also we should add some more testing if this is not covered yet

[SergioChan]

Thanks — I reviewed #8214.

I can continue with this PR if you prefer the minimal-scope server-var wiring fix already here, and I can add an explicit regression test case around /v2/people?Classification=<id> initialization behavior in this branch.

If you’d rather consolidate into #8214 instead, I’m also happy to close this one to avoid duplicate review overhead.

[SergioChan]

Added a focused regression test in this branch to cover the requested initialization behavior:

• cypress/e2e/ui/people/standard.people.filterbyclassification.spec.js
• New case: applies Classification query filter on initial load
• It verifies /v2/people?Classification=1 preselects the Classification Select2 filter (Member) and loads rows.

Validation run for this change:

• node --check cypress/e2e/ui/people/standard.people.filterbyclassification.spec.js

If you want, I can also add the same initialization assertion for FamilyRole in this PR.

[SergioChan]

Thanks — I added a focused regression test in this PR to cover the URL-initialization behavior discussed.

What I pushed:

• cypress/e2e/ui/people/standard.people.filterbyclassification.spec.js
• New test: applies the Classification URL filter on initial load
• It loads /v2/people?Classification=1&familyActiveStatus=all and verifies:
  • the hidden classification select is initialized to 1
  • the Select2 label shows Member
  • the members grid still renders rows

Validation run locally for this change:

• node --check cypress/e2e/ui/people/standard.people.filterbyclassification.spec.js

I did not run the full Cypress suite in this environment (it depends on the project’s Dockerized test stack), but this keeps the test addition scoped to the reported regression path.

[DawoudIO]

Let me test and release as part of 7.0.3