User configurable config files #21
Projects
Comments
Nos78
added a commit
that referenced
this issue
Aug 25, 2020
…e below for further details. This has been added into the library, but is unreferenced within the main code. The following changes have been made: + library/config/config.js: This is a new API for accessing configurations. Regardless of storage medium, having a wrapper for the configurations means that we can switch between a file-based system, or a database system, and only the functions need to be modified. The API currently consists of the following exposed functions: + **appPath()** - returns the application absolute path. + **absolutePath(relativePath)** - joins the given path with the application path to create an absolute path/file + **userConfigFile(gid)** - returns an absolute path for a given guild config file. No filesystem checks are made. + **serializeConfigObjToString(configString)** - wrapper only, no implementation. + **parseConfigStringToObj(configObj)** - wrapper only, no implementation. + **exportConfig(config)** - wrapper only, no implementation. *This may change in future, proposing writeConfig.* + **importConfig(config)** - wrapper only, no implementation. *This may change, proposing readConfig.* library/index.js: + Added the new config library to expose the API functions. config.json: + Added three new fields to store the path and filename prefix of the user-defined config files (should a file-based system be decided) - currently the global config is stored as a json within the filesystem, so development will assume that the user-defined config files will also be stored in the filesystem. package.json & package-lock.json: + Incremented the version number. New API module for accessing config files.
Nos78
added a commit
that referenced
this issue
Aug 28, 2020
…e below for further details. This has been added into the library, but is unreferenced within the main code. The following changes have been made: + library/config/config.js: This is a new API for accessing configurations. Regardless of storage medium, having a wrapper for the configurations means that we can switch between a file-based system, or a database system, and only the functions need to be modified. The API currently consists of the following exposed functions: + **appPath()** - returns the application absolute path. + **absolutePath(relativePath)** - joins the given path with the application path to create an absolute path/file + **userConfigFile(gid)** - returns an absolute path for a given guild config file. No filesystem checks are made. + **serializeConfigObjToString(configString)** - wrapper only, no implementation. + **parseConfigStringToObj(configObj)** - wrapper only, no implementation. + **exportConfig(config)** - wrapper only, no implementation. *This may change in future, proposing writeConfig.* + **importConfig(config)** - wrapper only, no implementation. *This may change, proposing readConfig.* library/index.js: + Added the new config library to expose the API functions. config.json: + Added three new fields to store the path and filename prefix of the user-defined config files (should a file-based system be decided) - currently the global config is stored as a json within the filesystem, so development will assume that the user-defined config files will also be stored in the filesystem. package.json & package-lock.json: + Incremented the version number. New API module for accessing config files. (cherry picked from commit 22f3721)
Nos78
added a commit
that referenced
this issue
Aug 28, 2020
… replaces 'uptime'. Various wew functions, querying system resources and obtaining package information have been added to Config library. Modified file headers as per issue #22.
Nos78
added a commit
that referenced
this issue
Sep 4, 2020
Nos78
added a commit
that referenced
this issue
Sep 11, 2020
…user configuration - this change improves caching of the guild configurations, in order to minimise the number of database accesses. Headers updated for issue #22. Ensuring objects are passed by value where required, for issue #31. + System/system.js: new functions (cacheSettings, cacheParameter) allow a given property of the settings json (we are calling them parameters, although this might be confusing - consider renaming), or the whole object, to be cached into the client.guildSettings for a given guild id. Exceptions will be thrown where the guild id or the client parameters are null. Re-factor saveParameter, savePrefix, to use the new caching functions where appropriate. Add missing JSDoc headers for the other exported functions. saveGuildSettings now throws exceptions. Renamed getGuildSettings to be more meaningful -> getGuildSettingsFromDb. And added a new function, also named getGuildSettings, which wraps getGuildSettingsFromDb to preserve the existing logic. This new function attempts to acccess the cached settings before accessing the Db. The client parameter has a default value of null to preserve existing logic. + bot.js: New and old version numbers are now logged when upgrading settings objects during the client.on.ready handler. Removed a re-declaration of a for loop index variable that was already declared. + commands/datahelp.js: Execute is now async, and the function will wait for the database to return the command prefix, in order to fix issue #24 dynamic prefixes.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Background
The main config.json contains the global settings that MrData requires to function - paths, colours for rich embed messages, the debug level, and so forth, the bot's command prefix.
In order to make MrData better, some of these configurations could be user-defined. That way, if a guild admin wants to have a different command prefix, he could do so.
Proposal
Configuration should be stored on a per-guild basis. These settings would override the main config.json, if they exist. If they do not exist, then the global setting will apply.
The text was updated successfully, but these errors were encountered: