The admin privilege seems to conflate the server admin role with chief moderator role.
My question is based on our use-case whereby the IT department setup our Discourse server instance but have no responsibility or interest in running/developing the content within Discourse.
Is there some way in which to separate options that an server admin should be responsible (such as SSL configuration) from tasks that a chief moderator would do, like setting up Categories?
An IT admin responsible for settings SSL, for example, doesn’t even need a Discourse account, just access to the server. Also, most IT-related settings can be set as environment variables on the app.yml making unnecessary IT-access for the web part of Discourse.
This way your ‘chief’ moderator can be a Discourse admin/moderator just fine.
Thanks @Falco.
Then, is it possible to have levels within the admin privilege? Where adminType2 is able to do XYZ but not JKL?
No, there is no fine-grained customization permission system.
@Falco, that seems to me to be somewhat unfortunate.
There are some fields in the Email section which would be of concern to some server admins which the chief moderator does not really need. For example, the email account and password, the port number to use for pop3 polling, and other stuff.
In addition, there are a number of other Admin parameters that have the potential to affect server load, and I can easily see server admins wanting to control those settings as well. Just a simple example being maximum file size of images and attachments. After scanning all the Admin options, there are a lot of settings which should be controlled by a server admin rather than chief moderator.
The up-shot of my questions is that the public facing team can easily be hampered by the back-end team, though both have legitimate concerns.
Is there perhaps a chief moderator template which removes access to certain parameters from the Admin panel?
You can put those settings in the app.yml env section and they’ll not be visible in the ux.
Have a look at Using Object Storage for Uploads (S3 Clones) for examples. All site settings can be overridden and hidden this way.
Thanks @pfaffman.
I had a look at the link which refers to external storage, but for a new user its a bit confusing.
So, as I understand it, what you’re saying is two fold: (1) all the settings seen in the Admin area can be configured in the app.yml file, and (2) that the Admin area will not display any options which are configured in the app.yml file.
Is that correct?
A follow-up question is; can the current admin settings be exported to a file, which would be incorporated in the app.yml file?
It seems like you understand. You will need to generate the env values by hand.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.