We have an E20 installation where we are on the 5.25 ESR series. We attempted to move to 5.31 in a test area this morning. While the upgrade appears to have happened just fine, we always go through the updated config.json to compare against what was in version control to ensure all new settings are evaluated. We did that and there are some settings in config.json that do not appear in documentation Configuration Settings — Mattermost 5.31 documentation which is unusual. Can someone please help either update that documentation or tell me what the following settings are for:
In the ServiceSettings area:
EnableAWSMetering
SplitKey
FeatureFlagSyncIntervalSeconds
DebugSplit
CollapsedThreads
In the LogSettings area:
EnableSentry
In the ExperimentalAuditSettings:
AdvancedLoggingConfig (NOTE, the addition of this item in the LogSettings section is documented)
In the FileSettings area:
AmazonS3PathPrefix
In the SupportSettings area:
EnableAskCommunityLink
In the AnnoucementSettings area:
NoticesURL
NoticesFetchFrequency
NoticesSkipCache
In the ExperimentalSettings area:
CloudUserLimit
CloudBilling
In the MessageExportSettings area:
DownloadExportResults
In the Plugins area:
BotUserID
The entire CloudSettings area, to include CWSUrl
The entire FeatureFlags area to include TestFeature, TestBoolFeature, and CloudDelinquentEmailJobsEnabled
Your comment made me to back and confirm that none of these are in our production 5.25 config.json. These are ‘new’ post 5.25 settings that were generated as a result of the upgrade to 5.31.
Here are some details, also updated the Github issue:
Need to look at documenting these:
EnableAWSMetering, DownloadExportResults, and BotUserID.
Documented:
EnableSentry - Documented at Telemetry — Mattermost 5.31 documentation. We do not currently list segment or rudder in the config.json documentation page either but do link to the Telemetry docs.
CollapsedThreads - this is for a new back-end collapsed threads feature and currently not available front-end, so all documentation for this will be done once the feature is complete. More details at Mattermost.
NoticesURL, NoticesFetchFrequency, and NoticesSkipCache are not documented separately because they are mainly for internal use. Documentation about Notices here: Configuration Settings — Mattermost 5.31 documentation.
These are just for internal testing purposes: TestFeature, TestBoolFeature.
These are related to Mattermost Cloud product: CloudUserLimit; CloudBilling; CloudDelinquentEmailJobsEnabled; the entire CloudSettings area, to include CWSUrl.
EnableSentry - not sure I would agree that it is documented. Neither the Configuration page nor the telemetry page list the entry ‘EnableSentry’. How do I disable it? Set it to ‘0’? False? If I set it to ‘off’ is there still information that leaks? All great topics for a configuration settings page.
‘AdvancedLoggingConfig’ - Perhaps I wasn’t clear enough in my original report. This setting is indeed documented in the LogSettings section (LogSettings.AdvancedLoggingConfig). However, this is also separately in the ExperimentalAuditSettings section. What does enabling this in the LogSettings area and disabling in the ExperimentalAuditSettings area do? I assume they control different things if they are in different sections.
‘EnableAskCommunityLink’ - I guess I kind of see it now, but that page seems to conflict with the settings. The documentation states that I should set enable_ask_community_link, not EnableAskCommunityLink. Which is correct?
AmazonS3PathPrefix - You are correct on this one. This one is my mistake.
For all the ones that are ‘internal’ - I feel these should be documented, especially in a user setting configuration file. What should I set these to? Especially since it seems like it is trying to communicate with some external Internet sites (ex: ‘NoticesURL’)? We run a high compliance site and understanding data flow is extremely important to us.
Cloud:
What should I set these to? I have no idea what are rationale settings. I want to make sure I set correctly, as I will be running in a private AWS ec2 instance and it is possible that some of the ‘cloud’ code may think it is in a cloud (where it is, but our private VPC). Without documentation, it is impossible to tell.