JAYSON DERULO

1 files changed, 28 insertions, 0 deletions

diff --git a/admin/config_preference.md b/admin/config_preference.md
new file mode 100644
index 0000000..842b7d5
--- /dev/null
+++ b/admin/config_preference.md
@@ -0,0 +1,28 @@
+# Config Preference
+
+[back to admin](README.md) /// [home](../README.md)
+
+If the server can read none critical settings from two places in addition to the `jde_settings` table in the database something has to win. The `config_preference` setting controls that.
+
+## Config Preference States
+
+### tables (default)
+
+Database always wins. If a value exists in `jde_settings` it overrides whatever the config files say (unless its a criticial setting)
+
+This is the default because you usually want admins to be able to change stuff at runtime via the database without having to edit files and restart.
+
+### local
+
+Config file wins for keys that were **explicitly written** in the config file. If you actually typed `session_timeout_minutes = 120` in your security config then that value sticks regardless of whats in the database.
+
+But for settings you didnt write in the file (or ones that got set as default because empty) the database can still override them.
+
+This is useful when you want your local file to be the source of truth but still allow the database to fill in settings you havent configured locally.
+
+## Notes
+
+- the database is always read regardless of this setting. config_preference only controls who wins when they are fighting and having a hissifit as to who wins.
+- this applies to security settings, permission definitions, group configs etc
+- changing this setting itself requires editing the config file (its not a DB overridable setting, that would be idiotic)
+- after changing settings in the database call some servers might choose not to implement live hot reloading for all settings, use `POST /reload` to apply them