* MM-9849 Added tracking of which settings are set through environment variables
* Removed old version of viper
* Added forked version of viper
* Fixed unit tests
* Fixed more unit tests
* Removed copy from App.GetEnvironmentConfig
* log the config file path used by the server on startup
* return an err if the bulk import command fails
* log the underlying errors that occur when importing
The code assumed all errors meant a missing resource, but it's possible
something else is at fault. Including the error helps pinpoint that more
readily.
* Add supported timezones into config
Remove Timezone list creation in favor of timezone from configs
Add Timezone field to Users table
Clean up format of SupportedTimezones in config
* Remove unwanted change
* Add test for updating user timezone
* Add empty map[string]string if Timezone is null
* Add EnableTimezoneSelection config
* Revert back to map[string]string for ClientConfig
* Refactor SupportedTimezones into timezones.json
* Include timezones.json in TestConfigFlag
* Add timezone api endpoint
* Bump varchar size to 256 and setMaxSize in user_store
* Refactor LoadConfig to LoadConfig and LoadTimezoneConfig
* Remove unnecessary argument in LoadConfig, mail_test
* Add test for timezone endpoint
* Add license header
* Refactor timezones endpoint to system.go
* Add system base route to timezone endpoint
* db timezone upgrade in db v4.9
* Avoid saving SupportedTimezones to config.json
* Add timezonePath support in config
* Remove EnableTimezoneSelection from config
* Use return statement without return parameter
* Refactor test for SupportedTimezones
* Check for supportedTimezone != nil instead of using len
* Decouple SupportedTimezones out of Config
* Fix failing test
* Add LastTeamIconUpdate back in upgrade.go
* Write timezone config in config_flag_test
* Add code fallback for default timezone support
Currently, when starting Mattermost programmatically, it's hard to tell
when the server is actually ready to receive network connections.
This isn't convenient for monitoring (the systemd service status is
"running" although the server is still booting), nor for programatic use
(where a script would need to know when the server is ready to perform
further actions).
To improve this, systemd allow processes to tell when they started
successfully. The launcher waits for this notification before
reporting the service as successfully launched.
The way processes notify systemd is by sending a `READY=1` string over
a standard unix socket, whose path is provided in an environment var.
The systemd service is then told to expect this notification:
```diff
[Service]
-Type=simple
+Type=notify
ExecStart=/home/vagrant/go/bin/platform
```
Now, when starting the server, systemd will actually wait for the server to
be ready before returning the control to the shell.
Additionally, during this time, querying the server status with
`service mattermost status` will report the service as "activating" – before
transitioning to "running" when the server is ready.
When running server tests, the server will exit while some jobs spawned
through a goroutine are still running. This may crash the test harness,
as the jobs try to access a shut down app instance.
Fortunately the fix is easy: we just have to use the same App
goroutine-counting facility than the rest of the method's goroutines.
* Cleanup app state on initialization error
When returning an initialization error, the app state was not cleaned
up. This is especially visible during tests, as `appCount` is not
decremented, and makes the new app initialization fail.
* Test the `platform server` command
As the `platform server` command only exits when interrupted by
a signal, it is not possible to test it as the other cobra
commands. Instead we directly test the actual command function.
The internal command handler is slighly refactored to take
a channel in argument, and registers it as the signal handler.
Nothing very different—except than controlling this channel
from the outside allows the test to send the system signal
itself, thus preventing the server to run forever.
* [PTL-7537] implement feature and test
* [PTL-7537] Update feature to post the the room requiring a username flag to be used
* [PTL-7537] update tests with username
* update test to remove changes to the test helper struct
* use the basic team and user
Only a handful of critical errors are present in the codebase.
They all occur during server startup (in `app.StartServer()`).
Currently, when one of these critical error occurs, it is simpled
mentionned in the logs – then the error is discarded, and the app
attempts to continue the execution (and probably fails pretty quickly in
a weird way).
Rather than continuing operations in an unknow state, these errors should
trigger a clean exit.
This commit rewrites critical startup errors to be correctly
propagated, logged, and then terminate the command execution.
Additionnaly, it makes the server return a proper error code to the
shell.
* XYZ-13: Update Permission and Role structs to new design.
* XYZ-10: Role store.
* XYZ-9/XYZ-44: Roles API endpoints and WebSocket message.
* XYZ-8: Switch server permissions checks to store backed roles.
* XYZ-58: Proper validation of roles where required.
* XYZ-11/XYZ-55: Migration to store backed roles from policy config.
* XYZ-37: Update unit tests to work with database roles.
* XYZ-56: Remove the "guest" role.
* Changes to SetDefaultRolesFromConfig.
* Short-circuit the store if nothing has changed.
* Address first round of review comments.
* Address second round of review comments.
When starting the server using `platform server`, errors occuring during
startup are not reported in the console. The command exit with a 0 exit
code (i.e. "success"), although the server failed to launch.
With this change, when an error occurs while initializing the app (like
a missing or invalid configuration file):
- the error is printed to the console;
- the command exit with a "-1" exit code.
This allow shell scripts to properly detect the startup failure, and to
react to it.
Example of error displayed:
```
$ platform server
Error: LoadConfig: Error decoding config file=config.json, err=While parsing config: invalid character ':' after top-level value,
``
* Created message export scheduled task
* Added CLI command to immediately kick off an export job
* Added email addresses for users joining and leaving the channel to the export
* Added support for both MySQL and PostgreSQL
* Fixing gofmt error
* Added a new ChannelMemberHistory store and associated tests
* Updating the ChannelMemberHistory channel as users create/join/leave channels
* Added user email to the message export object so it can be included in the actiance export xml
* Don't fail to log a leave event if a corresponding join event wasn't logged
* Adding copyright notices
* Adding message export settings to daily diagnostics report
* Added System Console integration for message export
* Cleaned up TODOs
* Made batch size configurable
* Added export from timestamp to CLI command
* Made ChannelMemberHistory table updates best effort
* Added a context-based timeout option to the message export CLI
* Minor PR updates/improvements
* Removed unnecessary fields from MessageExport object to reduce query overhead
* Removed JSON functions from the message export query in an effort to optimize performance
* Changed the way that channel member history queries and purges work to better account for edge cases
* Fixing a test I missed with the last refactor
* Added file copy functionality to file backend, improved config validation, added default config values
* Fixed file copy tests
* More concise use of the testing libraries
* Fixed context leak error
* Changed default export path to correctly place an 'export' directory under the 'data' directory
* Can't delete records from a read replica
* Fixed copy file tests
* Start job workers when license is applied, if configured to do so
* Suggestions from the PR
* Moar unit tests
* Fixed test imports
* Fixes system message posted to Town Square when adding/removing team member (#6483)
Fixes unit test method call to match RemoveUserFromTeam modification (#6483)
Fixes system message posted to Town Square when adding/removing team member (#6483)
Removes unnessary error message
* Updates system message when a user leaves a team (#6483)
* Changes system message when a user is removed from team (#6483)
* Adds a new string to be post to town-square when a member is added to a team (#6483)
