security(registry): enforce configured search limits server-side in search_registrants

[gonzalesedwin1123]

Problem

spp_registry_search/models/res_partner.py::search_registrants (@api.model, callable by any
authenticated user via /web/dataset/call_kw) searches sensitive registrant PII — name, ID number,
phone, email. The administrator-configurable Registry Search controls added with this feature were
enforced only in the JavaScript portal client; the RPC itself applied none of them:

1. min_chars bypass. The server's only term check was if not search_term. A direct call with
   a one-character term ran ilike across all PII fields. Worse: ilike does not escape SQL LIKE
   wildcards, so search_term="%%%" (three characters — passing even a naive length check) matched
   every registrant.
2. Result-limit bypass. limit = max(10, min(200, limit or config_limit)) let the caller's
   limit override the configured spp_registry_search.result_limit, clamped only to the
   hardcoded [10, 200] — an admin cap of 20 was bypassed with limit=200.
3. Targeted-mode downgrade. if search_mode == "targeted" and search_field: fell back to
   unified search over all PII fields whenever search_field was omitted (or invalid), silently
   undoing the admin's targeted-mode restriction.

Adjacent weaknesses in the same entry point (included, same class as #325): a non-numeric limit
(e.g. "abc") raised TypeError → unhandled generic 500, as did a non-string search_term; and
the server did not mirror get_search_config()'s [10, 200] / [1, 10] clamps.

Not an ACL bypass — all searches run un-sudo'd, so ACLs and record rules still apply. The issue is
that the search-governance/anti-enumeration controls were client-side only. Severity: medium
(authenticated PII enumeration aid + throttling bypass).

Fix

Enforce everything server-side at the RPC entry point (single choke point; the JS client already
complies, so no client change):

• Input validation: non-string search_term → []; limit coerced via int() with fallback
  to the configured limit (no more TypeError → 500).
• min_chars on effective characters: SQL LIKE wildcards (%, _) are stripped before counting,
  so %%% and Al% are rejected under min_chars=3. Matching semantics are deliberately
  unchanged — terms containing _ (e.g. emails) behave exactly as before.
• Limit capped at admin config: limit = min(limit, config_limit) if limit > 0 else config_limit,
  with config_limit/min_chars clamped exactly as get_search_config() clamps them for the JS.
  Callers may request fewer results than the maximum, never more.
• Targeted mode never widens: missing or unknown search_field falls back to the configured
  target_field; valid caller-supplied fields stay honored (the settings help text documents that
  portal users may change the field).

Tests

Written test-first (red → green): the module had no tests at all for search_registrants.
New tests/test_search_registrants.py (14 tests, 10 failing before the fix):

• min_chars: short term, wildcard-only term (%%%), wildcard-padded term (Al%) → []
  (all matched registrants before).
• Limit: caller limit=200 vs configured 10 → ≤10 (returned 12 before); lower caller limit
  honored; non-numeric limit no longer crashes (raised TypeError: '<' not supported between instances of 'str' and 'int' before).
• Targeted mode: missing search_field stays targeted (found the registrant via phone in unified
  fallback before); invalid field uses the configured default; valid caller field still honored.
• Regressions: compliant search finds results, search_type filters, non-string term rejected.

./spp t spp_registry_search → 0 failed, 0 error(s) of 36 tests (was 7 failed + 2 errors).
Ruff/ruff-format clean. No existing tests removed or modified.

Staff-review round

An adversarial staff review confirmed the core fix (limit logic simulated against bool/float/negative/
huge/garbage inputs, targeted mode traced fail-closed, no JS regression) and caught one gap, fixed here:
a non-dict advanced_filters value reached .get() -> AttributeError -> unhandled 500 (the same
malformed-input class this PR closes). Guarded with isinstance, plus a test; also added a test pinning
that targeted mode fails closed when the admin-configured target_field is itself invalid.

Scope

• No sibling security branch or open PR touches spp_registry_search.
• Version bump 19.0.2.1.1 → 19.0.2.1.2 + HISTORY fragment; README.rst /
  static/description/index.html to be regenerated from CI's pinned generator.

[gemini-code-assist]

Caution

The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 68.13%. Comparing base (1caf794) to head (178c39b).
⚠️ Report is 3 commits behind head on 19.0.

Additional details and impacted files

@@            Coverage Diff             @@
##             19.0     #335      +/-   ##
==========================================
- Coverage   74.28%   68.13%   -6.16%     
==========================================
  Files         372      144     -228     
  Lines       25385    13483   -11902     
==========================================
- Hits        18857     9186    -9671     
+ Misses       6528     4297    -2231     

Flag	Coverage Δ
spp_analytics	?
spp_api_v2_cycles	?
spp_api_v2_entitlements	?
spp_api_v2_gis	?
spp_api_v2_programs	?
spp_api_v2_simulation	?
spp_audit_programs	?
spp_base_common	91.07% <ø> (+0.80%)	⬆️
spp_case_demo	?
spp_case_entitlements	?
spp_case_programs	?
spp_cr_type_assign_program	?
spp_dci_compliance	?
spp_dci_demo	?
spp_dci_server_social	?
spp_demo	?
spp_demo_phl_luzon	?
spp_drims	?
spp_drims_sl	?
spp_drims_sl_demo	?
spp_farmer_registry	88.58% <ø> (?)
spp_farmer_registry_cr	61.24% <ø> (?)
spp_farmer_registry_demo	61.06% <ø> (+0.04%)	⬆️
spp_gis_report	?
spp_grm_demo	?
spp_indicator	?
spp_indicator_studio	?
spp_metric_service	?
spp_mis_demo_v2	70.99% <ø> (+0.03%)	⬆️
spp_programs	65.27% <ø> (+<0.01%)	⬆️
spp_registry	86.94% <ø> (+0.10%)	⬆️
spp_registry_search	75.53% <100.00%> (?)
spp_security	69.56% <ø> (+2.89%)	⬆️
spp_simulation	?
spp_starter_sp_mis	86.66% <ø> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
spp_registry_search/models/res_partner.py	70.65% <100.00%> (ø)

... and 295 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[gonzalesedwin1123]

Staff-review follow-ups filed (pre-existing, out of this PR's scope):

• security(spp_registry_search): corrupt search config parameter makes every search 500 [Severity: Low] #339 — corrupt admin search config parameter (result_limit/min_chars non-numeric) makes every search 500, also affects get_search_config [Low]
• security(spp_registry_search): un-sudo'd sub-searches 500 for roles without ACL on phone/ID co-models [Severity: Low] #340 — un-sudo'd sub-searches raise AccessError → 500 for roles with res.partner read but no ACL on spp.registry.id/spp.phone.number [Low, needs design decision]