Rocket.chat: SETTINGS_HIDDEN, SETTINGS_BLOCKED env settings has bugs, needs docs

[timkinnane]

I was intrigued by a mention of these environment settings in demo.rocket.chat, but they don't seem to do what they're intended for. The only check of the environment setting happens when settings are added. It looks like it's intended to override the passed in hidden and blocked properties (if the setting name is found in the CSV of the env setting), which would update the record in the DB, but that doesn't seem to work.

Even if it did overwrite the save values, I can't find any logic that supports them in the client when rendering settings pages. I would assume that's the primary goal? If so, would it make sense to move the reading of those env settings into client template helpers, so that when settings fields are being rendered they can either be hidden or set as disabled?

My use case for hiding settings is to give third-party admin access without revealing some private settings (like SMTP password or AWS keys), then I'd like to block some for similar reasons, to protect our branding etc, but let them customise other configs.

Rocket.Chat Version: 0.50.0

[engelgabriel]

@timkinnane maybe for the lack o documentation you are not doing it right. We have the same use case on our cloud service, and the SMTP details are indeed hidden.

[engelgabriel]

@sampaiodiego please help @timkinnane and clarify the documentation about this feature.

[timkinnane]

Sorry I derped hard on this one. Figured out that it just wasn't reading because I had spaces in the CSV. Is working now, an example in docs would still be nice though.

[timkinnane]

Actually I've found a valid bug after all... The SETTINGS_BLOCKED settings can still be changed by the reset button....

[timkinnane]

@sampaiodiego I also found that using RocketChat.settings.get in a template helper returned null for a SETTINGS_HIDDEN setting.

You can reproduce this by trying export SETTINGS_HIDDEN=Assets_logo, then (clear cache and) watch the logo on the login page disappear. Tried on v0.50.1.

[engelgabriel]

Thanks @timkinnane

[sampaiodiego]

thanks @timkinnane ..

Actually I've found a valid bug after all... The SETTINGS_BLOCKED settings can still be changed by the reset button....

The reset button doesn't work.. but agreed we shouldn't show it for blocked settings ;)

I also found that using RocketChat.settings.get in a template helper returned null for a SETTINGS_HIDDEN setting.

this is by design.. if a setting is hidden, no client can read it, just the server has access to it.

[timkinnane]

Actually I've found a valid bug after all... The SETTINGS_BLOCKED settings can still be changed by the reset button....

The reset button doesn't work.. but agreed we shouldn't show it for blocked settings ;)

How does it not work? For me, as pictured, It resets the setting (though in this case it shouldn't).

I also found that using RocketChat.settings.get in a template helper returned null for a SETTINGS_HIDDEN setting.

this is by design.. if a setting is hidden, no client can read it, just the server has access to it.

What about client side methods that use RocketChat.settings.get - There's a bunch of them, that seem pretty critical, like Site_Name - I assumed the reason to make a setting hidden, was to simplify settings pages by removing settings that would never change and/or are unnecessary for the instance admins, but they would still need to be used in the client code. If they're not even accessible in the code, that's sure to cause bugs in those methods, no?

[sampaiodiego]

How does it not work? For me, as pictured, It resets the setting (though in this case it shouldn't).

it looks it resets, but it doesn't :stuck_out_tongue: anyways, I've submitted a PR (#6432) to fix this weird behavior.

What about client side methods that use RocketChat.settings.get - There's a bunch of them, that seem pretty critical, like Site_Name - I assumed the reason to make a setting hidden, was to simplify settings pages by removing settings that would never change and/or are unnecessary for the instance admins, but they would still need to be used in the client code. If they're not even accessible in the code, that's sure to cause bugs in those methods, no?

I see what you want, but it was designed to prevent settings being sent to client.

[timkinnane]

Surprised to see this closed. As per @engelgabriel's initial response, the least I was hoping for was some docs for these features. Especially as its not at all obvious how they're meant to behave.

[geekgonecrazy]

@timkinnane did some preliminary documenting of this here: https://github.com/RocketChat/Rocket.Chat.Docs/issues/261

[timkinnane]

Thanks Aaron. 👍