mirror of https://github.com/ZoneMinder/zoneminder.git synced 2026-06-04 03:45:53 -04:00

Files

Steve Gilvarry 0538bd48fc fix: apply filter result limit when an empty Tags term is present

The event filter "Limit to first N" stopped being honored in 1.38. Using
"List Matches" on a filter that should return N events returned all
matching events instead. This was a regression from 1.36, triggered by
the Tags feature.

Root cause chain:

1. The events view adds a default, empty `Tags` term to unsaved filters.
   That term is invalid (empty value) so Filter::sql() correctly omits it
   from the WHERE clause, but pre_sql_conditions()/post_sql_conditions()
   counted it regardless of validity.

2. Tags was classified as a post-sql condition, even though it is filtered
   in SQL (sql_attr() returns T.Id, with EXISTS/NOT EXISTS for any/no tag)
   and its post-sql test() was a no-op stub. So the empty Tags term made
   has_post_sql_conditions true.

3. has_post_sql_conditions being true disabled the SQL LIMIT fast-path in
   ajax/events.php, leaving the PHP-side trim as the only limit enforcement
   -- and that trim used an inverted comparison (limit > row count), so it
   never trimmed when there were more rows than the limit.

Fixes:

- Filter::pre_sql_conditions()/post_sql_conditions() now require
  term->valid(), so empty default terms no longer count as conditions and
  the SQL LIMIT fast-path stays enabled.
- FilterTerm::is_post_sql() no longer returns true for Tags, since Tags is
  handled in SQL.
- ajax/events.php filter-limit trim comparison corrected to '<' so the
  limit is applied when there are more matches than the limit (matches the
  pagination trim below it). This covers genuine post-sql filters such as
  ExistsInFileSystem.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

2026-06-04 00:08:34 +10:00