mirror of
https://github.com/ZoneMinder/zoneminder.git
synced 2026-06-04 11:58:03 -04:00
0538bd48fc
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>