Use the correct level order when getting arbitrary settings
This shouldn't currently be causing problems, but will in teh future. The bug can be exposed by having a setting where the level order is completely reversed, therefore causing LEVEL_ORDER[0] to actually be the most generic, not the most specific. Instead, we'll pull in the setting's level order and fallback to LEVEL_ORDER, therefore requesting the most specific value. Signed-off-by: Travis Ralston <travpc@gmail.com>
This commit is contained in:
parent
cf8ff6aed3
commit
f141ee1944
1 changed files with 9 additions and 1 deletions
|
@ -176,7 +176,15 @@ export default class SettingsStore {
|
|||
* @return {*} The value, or null if not found
|
||||
*/
|
||||
static getValue(settingName, roomId = null, excludeDefault = false) {
|
||||
return SettingsStore.getValueAt(LEVEL_ORDER[0], settingName, roomId, false, excludeDefault);
|
||||
// Verify that the setting is actually a setting
|
||||
if (!SETTINGS[settingName]) {
|
||||
throw new Error("Setting '" + settingName + "' does not appear to be a setting.");
|
||||
}
|
||||
|
||||
const setting = SETTINGS[settingName];
|
||||
const levelOrder = (setting.supportedLevelsAreOrdered ? setting.supportedLevels : LEVEL_ORDER);
|
||||
|
||||
return SettingsStore.getValueAt(levelOrder[0], settingName, roomId, false, excludeDefault);
|
||||
}
|
||||
|
||||
/**
|
||||
|
|
Loading…
Reference in a new issue