Repository navigation
Conversation
…oneMinder#5289 An option whose name is set in zm.conf or a conf.d file is shown on the Options page as a link ending in ' *': green when the file value equals the Config table value, red when it differs. The link opens a dialog naming the file and showing both values; values are left out for Private and password options, and for a viewer who may not see the Private value the colour is left out too. The web UI and Perl scripts use the file value for any option, while zmc and zms read most options from the Config table only, so a differing file value does not apply everywhere. Saving an overridden option writes the table and the file keeps winning in the web UI. Admins had no way to see which options a file sets when the values match, and no single place to audit them. loadConfigFiles() is split out of loadConfig() so the view can tell which names came from a file. Each entry carries the file it came from; loadConfig() drops that key before returning, so configs/viewByName answers as before.
connortechnology
left a comment
connortechnology
left a comment
There was a problem hiding this comment.
Thanks. Showing which options a file sets is useful, and the handling of Private and password options is careful. One design point changes what this needs to do, though.
Options in zm.conf and conf.d are set by the owner of the box. Options in the database are set by the ZoneMinder admin. The box owner must be able to limit what the admin can do, so a file setting has to win everywhere. That makes a file-set option something the admin can't change, not just something to flag. Please:
- Make file-set options read-only on the Options page. Show the file's value with something like "Set by the system owner in
<file>" (throughtranslate()), and disable the input. That replaces both the red/green link and the existing "This value has been overriden via configuration files" note at the bottom of the row, so there is one indicator, not two for the mismatch case. - Enforce it on the server.
includes/actions/options.phpshould skip anynewConfig[...]entry for an option a file sets, so a hand-made POST can't change it either. - Compare booleans by type if anything still compares the two values: the database stores
1/0, and a file may sayyesortrue.
The text in options.js and the PHP should go through translate() like the rest of the page.
The C++ side (zmc, zms and zmu read most options from the database only, as #5289 describes) is a separate fix. We're doing that one, on master and release-1.38: the daemons will apply file values after the database, the same as PHP and Perl.
This branch has not been deployed
2 participants
Impact: feature (admin audit) (admins can see which options a config file overrides, and whether it differs from the database)
TL;DR
*, greenwhen the file matches the database and red when it differs; the link opens a dialog with the
file and both values (none for Private or password options).
loadConfigFiles()is splitout of
loadConfig(). 3 files, +71/-6.loadConfig()runs on every request; it reads the same files in the same order,and
configs/viewByNameanswers as before.tests green. Reproduction and full results are in Options page: no way to see which options zm.conf / conf.d override, and C++ daemons ignore those overrides #5289.
Fixes #5289
🤖 Generated with Claude Code