@smi-jonathan global moderators exist as a group to essentially be admins but without access to the ACP. If you want a restricted group of admins, that's what you're looking for. If you'd like them to be able to do more, then I'd suggest opening as issue on Github. As for your particular request, no, this isn't possible without a plugin.
Separate System config data from User data
We are working on deploying nodebb with Docker image and One of the biggest issue we found in we found is the mix of system config data and user data.
System config data include system settings, activated plugin info, plugin settings and etc.
User data include all the posts.
To build a ready to deploy docker image, you want install all the necessary plugins and add their config data. This is really hard if the system data is mixed with user posts.
Do we have a plan to separate these two kind of data?
Are you talking about the data being in the same database? What kind of plugin data are you referring to?
@pitaj Yes. For example, we need to set API keys or other configurations for some plugin, and those data are saved the same way as forum posts in MongoDB. Would it be nice to separate "system settings" from real user generated data?
Depends on how the plugin is set up... if you don't want to store the keys in the database, you can alter the plugins to read values from
process.envinstead, and then you can pass them in environment variables.
@julian Thanks. Can we use process.env for all the plugins, or it is plugin specific thing?
process.envis a global Node.js variable. You may want to look into more of how Node.js works before you continue.
BartVB last edited by
For a large part this is an architectural issue.
It would extremely useful if it were possible to test a plugin on the production database in a development or staging environment.
That's not possible when NodeBB gets the list of activated modules from the database.
We have a similar problem like this with Drupal7. It's close to impossible to test something on the production data without making a copy (which is extremely unpractical with a large DB) because of the tight coupling between configuration and content.
Haven't used it yet but Drupal 8 has improved on that issue quite a bit: