The rename of the elementOptions key from "ordeable" to "orderable" (part of
#1584) updated handleElementOptions() in settings_utils.js to return the
property as isOrderable. However, multiEditCore.php still destructured the
old name isOrdeable from that return value (line 139). Because JavaScript
object destructuring resolves properties by name, isOrdeable would silently
evaluate to undefined — no runtime error, just a broken binding.
The bug was masked because isOrdeable is not referenced after destructuring
in the current code of multiEditCore.php. The incorrect binding would become
a functional regression as soon as that code path is extended to actually
consume the orderable flag (e.g. to conditionally apply select2 sorting in
the multi-edit form).
Changes:
- front/multiEditCore.php:139 — isOrdeable → isOrderable
Aligns the destructured property name with the renamed return key of
handleElementOptions() so the binding resolves to the correct boolean
value instead of undefined.
All 35 previously updated files already use the correct spelling; this was
the single remaining inconsistency. After this commit, grep for "isOrdeable"
and "ordeable" across front/ and server/ returns zero results.
The key 'ordeable' in elementOptions was a long-standing typo for the
correct English word 'orderable'. Since the JS check in settings_utils.js
used the same misspelled key, the feature appeared to work — but it was
relying on the consistent propagation of a typo across the entire codebase.
Two pre-existing entries in front/plugins/ui_settings/config.json already
used the correct spelling 'orderable', but these had no effect because the
JavaScript check (option.ordeable === 'true') never matched them. As a
result, orderable behavior was silently disabled for those two settings.
Changes:
- front/js/settings_utils.js: renamed option.ordeable → option.orderable
and isOrdeable → isOrderable (6 occurrences, lines 792/823/824/880/1079/
1192/1228). The JS key check is the authoritative definition of the
elementOptions property name, so this must change atomically with all
config files.
- server/initialise.py:245: renamed "ordeable" → "orderable" in the
hardcoded JSON string for LOADED_PLUGINS setting. This string is the
source-of-truth for that setting's elementOptions and is not auto-
generated from the plugin config files.
- front/plugins/*/config.json (33 files, 90 occurrences): renamed all
"ordeable": "true" entries to "orderable": "true" via sed. All plugins
used the typo consistently; they must be updated in the same commit to
avoid a broken intermediate state.
The two formerly broken 'orderable' entries in ui_settings/config.json
are now matched by the corrected JS check and work as intended.
Fixesnetalertx/NetAlertX#1584
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Added support for pagination (page and limit) in the session events endpoint.
- Implemented sorting functionality based on specified columns and directions.
- Introduced free-text search capability for session events.
- Updated SQL queries to retrieve all events and added a new SQL constant for events.
- Refactored GraphQL types and helpers to support new plugin and event queries.
- Created new GraphQL resolvers for plugins and events with pagination and filtering.
- Added comprehensive tests for new GraphQL endpoints and session events functionality.
- Updated test cases to reflect new column names (eve_MAC -> eveMac, eve_DateTime -> eveDateTime, etc.) across various test files.
- Modified SQL table definitions in the database cleanup and migration tests to use camelCase naming conventions.
- Implemented migration tests to ensure legacy column names are correctly renamed to camelCase equivalents.
- Ensured that existing data is preserved during the migration process and that views referencing old column names are dropped before renaming.
- Verified that the migration function is idempotent, allowing for safe re-execution without data loss.
