Fix elementOptions: rename typo 'ordeable' to 'orderable'#1585
Merged
jokob-sk merged 2 commits intonetalertx:mainfrom Apr 3, 2026
Merged
Fix elementOptions: rename typo 'ordeable' to 'orderable'#1585jokob-sk merged 2 commits intonetalertx:mainfrom
jokob-sk merged 2 commits intonetalertx:mainfrom
Conversation
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. Fixes netalertx#1584 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Contributor
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThis PR renames the misspelled select option key Changes
Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
front/js/settings_utils.js (1)
1-1538:⚠️ Potential issue | 🔴 CriticalFix property name and return value inconsistency with
multiEditCore.php.The
handleElementOptions()function has two mismatches withmultiEditCore.php:
Property name: Line 1103 checks for
option.orderable === "true", but config.json files useordeable(notorderable). Change tooption.ordeable === "true".Return property: The function returns
isOrderable, butmultiEditCore.php(line 139) destructuresisOrdeable, causing the variable to be undefined. Either rename the variable toisOrdeablethroughout the function or adjust the return statement to match whatmultiEditCore.phpexpects.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@front/js/settings_utils.js` around lines 1 - 1538, The handleElementOptions function currently checks option.orderable and returns isOrderable while multiEditCore.php expects option.ordeable and the returned property name isOrdeable; fix by reading option.ordeable === "true" (instead of orderable) and return the property with the exact name expected by multiEditCore.php (isOrdeable) or rename usages in multiEditCore.php to match—ensure both the local variable (previously isOrderable) and the returned object property match the identifier isOrdeable, and update any internal uses in handleElementOptions (e.g., where you set addCss or logic relying on ordering) to reference the renamed variable.
🧹 Nitpick comments (1)
front/js/settings_utils.js (1)
1226-1228: Pre-existing:constdeclaration in switch case without block scope.The static analysis tool flags this
constdeclaration inside acaseblock. While not introduced by this PR, it can cause issues if other cases accidentally referenceaddCss. Consider wrapping the case body in a block.🔧 Suggested fix to add block scope
switch (elementType) { - case 'select': + case 'select': { const multi = isMultiSelect ? "multiple" : ""; const addCss = isOrderable ? "select2 select2-hidden-accessible" : ""; // ... rest of case body ... break; + }Apply similar blocks to other cases with
const/letdeclarations.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@front/js/settings_utils.js` around lines 1226 - 1228, The const declarations inside the switch case ('select') (variables multi and addCss that use isMultiSelect and isOrderable) need to be scoped to a block to avoid hoisting issues; wrap the case 'select' body in braces ({ ... }) so the consts are block-scoped, and apply the same pattern to any other switch cases that declare let/const to prevent cross-case name collisions.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@front/plugins/notification_processing/config.json`:
- Line 37: Revert the incorrect key value in the plugin config: change the
elementOptions entry that currently uses "orderable" back to the required
project spelling "ordeable" so the frontend continues to work; specifically
update the elementOptions array item (the object containing "multiple": "true")
to use "ordeable": "true" instead of "orderable": "true" and ensure no other
occurrences of "orderable" remain in this plugin's config.json.
---
Outside diff comments:
In `@front/js/settings_utils.js`:
- Around line 1-1538: The handleElementOptions function currently checks
option.orderable and returns isOrderable while multiEditCore.php expects
option.ordeable and the returned property name isOrdeable; fix by reading
option.ordeable === "true" (instead of orderable) and return the property with
the exact name expected by multiEditCore.php (isOrdeable) or rename usages in
multiEditCore.php to match—ensure both the local variable (previously
isOrderable) and the returned object property match the identifier isOrdeable,
and update any internal uses in handleElementOptions (e.g., where you set addCss
or logic relying on ordering) to reference the renamed variable.
---
Nitpick comments:
In `@front/js/settings_utils.js`:
- Around line 1226-1228: The const declarations inside the switch case
('select') (variables multi and addCss that use isMultiSelect and isOrderable)
need to be scoped to a block to avoid hoisting issues; wrap the case 'select'
body in braces ({ ... }) so the consts are block-scoped, and apply the same
pattern to any other switch cases that declare let/const to prevent cross-case
name collisions.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 72abed3f-499b-4715-8095-fdc17db1864c
📒 Files selected for processing (35)
front/js/settings_utils.jsfront/plugins/__template/config.jsonfront/plugins/adguard_import/config.jsonfront/plugins/arp_scan/config.jsonfront/plugins/asuswrt_import/config.jsonfront/plugins/avahi_scan/config.jsonfront/plugins/ddns_update/config.jsonfront/plugins/dhcp_leases/config.jsonfront/plugins/dhcp_servers/config.jsonfront/plugins/dig_scan/config.jsonfront/plugins/freebox/config.jsonfront/plugins/icmp_scan/config.jsonfront/plugins/internet_ip/config.jsonfront/plugins/internet_speedtest/config.jsonfront/plugins/ipneigh/config.jsonfront/plugins/luci_import/config.jsonfront/plugins/mikrotik_scan/config.jsonfront/plugins/nbtscan_scan/config.jsonfront/plugins/newdev_template/config.jsonfront/plugins/nmap_dev_scan/config.jsonfront/plugins/nmap_scan/config.jsonfront/plugins/notification_processing/config.jsonfront/plugins/nslookup_scan/config.jsonfront/plugins/omada_sdn_imp/config.jsonfront/plugins/omada_sdn_openapi/config.jsonfront/plugins/pihole_api_scan/config.jsonfront/plugins/pihole_scan/config.jsonfront/plugins/snmp_discovery/config.jsonfront/plugins/sync/config.jsonfront/plugins/ui_settings/config.jsonfront/plugins/unifi_api_import/config.jsonfront/plugins/unifi_import/config.jsonfront/plugins/vendor_update/config.jsonfront/plugins/website_monitor/config.jsonserver/initialise.py
| { | ||
| "elementType": "select", | ||
| "elementOptions": [{ "multiple": "true", "ordeable": "true" }], | ||
| "elementOptions": [{ "multiple": "true", "orderable": "true" }], |
Contributor
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Description: Verify no remaining "ordeable" occurrences in the codebase
echo "=== Checking for remaining 'ordeable' in front/plugins ==="
rg -n '"ordeable"' front/plugins/ || echo "✓ No occurrences found in front/plugins"
echo ""
echo "=== Checking for remaining 'ordeable' in server/ ==="
rg -n '"ordeable"' server/ || echo "✓ No occurrences found in server/"
echo ""
echo "=== Checking for remaining 'ordeable' in front/js/ ==="
rg -n 'ordeable' front/js/ || echo "✓ No occurrences found in front/js/"
echo ""
echo "=== Verifying 'orderable' is now used consistently ==="
rg -c '"orderable"' front/plugins/ | head -20Repository: netalertx/NetAlertX
Length of output: 1238
Revert to "ordeable" — this change breaks frontend functionality.
The migration from "ordeable" to "orderable" is incorrect. The elementOptions property in plugin config.json files requires the spelling "ordeable" (not "orderable") for proper frontend functionality. The current change will cause the frontend to malfunction. This property name spelling will be standardized across the project in the future, but for now it must remain "ordeable".
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@front/plugins/notification_processing/config.json` at line 37, Revert the
incorrect key value in the plugin config: change the elementOptions entry that
currently uses "orderable" back to the required project spelling "ordeable" so
the frontend continues to work; specifically update the elementOptions array
item (the object containing "multiple": "true") to use "ordeable": "true"
instead of "orderable": "true" and ensure no other occurrences of "orderable"
remain in this plugin's config.json.
…value The rename of the elementOptions key from "ordeable" to "orderable" (part of netalertx#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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
"ordeable"inelementOptionshas been a typo for"orderable"since the beginningsettings_utils.jsused the same misspelled key, so the feature worked consistently on both sides — no functional breakage existedui_settings/config.jsonalready used the correct spelling, but with"orderable": "false"— so the spelling mismatch had no functional impact there eitherChanges
front/js/settings_utils.js:option.ordeable→option.orderable,isOrdeable→isOrderable(6 occurrences)server/initialise.py:245:"ordeable"→"orderable"in the hardcodedLOADED_PLUGINSJSON stringfront/plugins/*/config.json(33 files, 90 occurrences): renamed via sedfront/multiEditCore.php:139:isOrdeable→isOrderable(destructured property name alignment)🔍 Related Issues
Closes #1584
📋 Type of Change
🧪 Testing Steps
/settings.php, navigate to any plugin section (e.g. ARP Scan) and verify that orderable multi-selects (e.g. "Set always columns") still support drag-to-reordergrep -r "ordeable" front/plugins server front/js— expect zero results✅ Checklist
🤖 Generated with Claude Code
Summary by CodeRabbit
Release Notes