## Problem
PR #1182 introduced SafeConditionBuilder to prevent SQL injection, but it only
supported single-clause conditions. This broke notification filters using multiple
AND/OR clauses, causing user filters like:
`AND devLastIP NOT LIKE '192.168.50.%' AND devLastIP NOT LIKE '192.168.60.%'...`
to be rejected with "Unsupported condition pattern" errors.
## Root Cause
The `_parse_condition()` method used regex patterns that only matched single
conditions. When multiple clauses were chained, the entire string failed to match
any pattern and was rejected for security.
## Solution
Enhanced SafeConditionBuilder with compound condition support:
1. **Added `_is_compound_condition()`** - Detects multiple logical operators
while respecting quoted strings
2. **Added `_parse_compound_condition()`** - Splits compound conditions into
individual clauses and parses each one
3. **Added `_split_by_logical_operators()`** - Intelligently splits on AND/OR
while preserving operators in quoted strings
4. **Refactored `_parse_condition()`** - Routes to compound or single parser
5. **Created `_parse_single_condition()`** - Handles individual clauses (from
original `_parse_condition` logic)
## Testing
- Added comprehensive test suite (19 tests, 100% passing)
- Tested user's exact failing filter (6 AND clauses with NOT LIKE)
- Verified backward compatibility with single conditions
- Validated security (SQL injection attempts still blocked)
- Tested edge cases (mixed AND/OR, whitespace, empty conditions)
## Impact
- ✅ Fixes reported issue #1210
- ✅ Maintains all security protections from PR #1182
- ✅ Backward compatible with existing single-clause filters
- ✅ No breaking changes to API
Fixes#1210🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
is the schedule input is incorrect, an error message is logged and the plugin will NOT run.
Creating a dummy schedule would throw the system out of balance as there's the danger of schedules running out of sync.
`setup.sh` and `start.sh` combined into a single script
netalertx now starts and runs via systemd unit, can be started, stopped and restarted
`systemctl start netalertx`
`systemctl stop netalertx`
`systemctl status netalertx`
etc
Logs to `journalctl` and output can be followed with `journalctl -f`
Amalgamated chmods
tuned chmods based on earlier feedback and discussion
install script accepts command line parameter:
- 'install' to continue and DELETE ALL!
- 'update' to just update from GIT (keeps your db and settings)
- 'start' to do nothing, leave install as-is (just run the start script, set up services etc)
Please have a look, comments welcome :-)
The stdout and stderr are useful logs when debugging and trying to figure out why plugin output is causing backend to stop and exception. This commit enables output redirection to `/app/stdout.log` and `/app/stderr.log` from the backend. This may need backporting to production as it appears the fields are unused in the backend.
Additionally, when searching logs in the UI, the old logs appear first and your search results will invariably find old information when searching with ctrl-f-"string"-enter. So upon backend start and to keep them relevant, the stdout, stderr, and app logs are cleared.
Jeff Keller
Jokob @NetAlertX
priestlypython
jokob-sk
Ingo Ratsdorf
Adam Outler