| name | netalertx-settings-management |
| description | Manage NetAlertX configuration settings. Use this when asked to add setting, read config, get_setting_value, ccd, or configure options. |
Settings Management
Quick Reference
Read a setting (backend):
from helper import get_setting_value
value = get_setting_value('SETTING_NAME')
Never hardcode ports, secrets, or configuration values. Always use get_setting_value().
Read a setting (frontend):
getSetting("SETTING_NAME")
Add a core setting — use ccd() in server/initialise.py:
ccd('SETTING_NAME', 'default_value', 'description')
Add a plugin setting — define in the plugin's config.json under the settings key.
| File | Purpose |
|---|
/data/config/app.conf | Runtime config (source of truth, modified by app) |
back/app.conf | Default config (template) |
Use APP_CONF_OVERRIDE for settings that must be set before startup.
Development Guide
The goal is for every setting to be:
- Declarative and self-documenting
- Automatically rendered by the Settings UI
- Fully localized
- Backwards compatible
- Easy to maintain
1. Follow existing patterns
Before creating a new setting, search for similar ones. Reuse existing naming conventions, types, and validation patterns. Follow the style already used by similar plugins. Avoid introducing new setting types unless absolutely necessary.
2. Setting naming
Setting keys use uppercase snake case: UI_DEV_SECTIONS, SCAN_INTERVAL, MQTT_HOST.
Names should clearly describe the purpose.
3. Categories
Place settings into the most appropriate category. Keep related settings together. Avoid creating new categories unless there is a clear need.
4. Choose the correct type
Use the simplest type that correctly models the value: string, integer, float, boolean, password, select, array, textarea. Avoid encoding structured JSON inside string settings.
5. Validation
Always define validation whenever appropriate (min/max values, regex, allowed options). Reject invalid configuration rather than silently accepting it.
6. Defaults
Provide sensible defaults that work for a fresh installation. The default_value in config.json is the single source of truth — do not duplicate it in Python or JavaScript.
7. Names and descriptions
Names should be concise. Descriptions should explain what the setting does, when to use it, and any important side effects — not implementation details.
8. Boolean settings
Prefer verbs: Enable, Disable, Require, Allow, Ignore, Show, Hide. Examples: Enable MQTT, Require NICs Online, Hide Offline Devices.
9. Select settings
Use when users must choose from predefined values. Each option must have a meaningful label — never require users to remember internal values.
10. Array settings
Use only when multiple independent values are expected (e.g., ignored MACs, subnet lists, plugin lists).
11. Localization
Every setting must have localized language strings. If not defined directly in config.json, they must exist in en_us.json.
Example for UI_DEV_SECTIONS:
"UI_DEV_SECTIONS_name": "Hide device sections",
"UI_DEV_SECTIONS_description": "Select which UI elements to hide on the Devices page."
When using external language files, config.json must reference:
"name": [{ "string": "_GLOBAL_LANG_FILES_" }]
12. Source of truth
app.conf is the source of truth. User-defined values always come from app.conf; defaults from config.json apply only when a setting is absent. Never read app.conf directly — always go through get_setting_value().
13. Plugin-first settings
Whenever possible, define new settings inside a plugin's config.json. Avoid adding hardcoded application settings unless there is a compelling architectural reason.
14. Runtime lifecycle
config.json (defaults)
→ app.conf (source of truth)
→ Settings database table
→ table_settings.json API
→ Frontend getSetting() / Backend get_setting_value()
The database and API are runtime representations only, regenerated from app.conf at init.
15. Backwards compatibility
Avoid renaming settings, changing data types, or changing semantics. If unavoidable, provide migration logic and preserve compatibility where possible.
16. Pull request checklist
References
