* MM-8810: Add CSV Compliance export
* Only allowing to schedule actiances export throught the cli
* De-duplicating some code
* Fixes on texts
* Fixes on translations
* factor out GetSubpathFromConfig
* mv web/subpath.go to utils/subpath.go
* serve up web, api and ws on /subpath if configured
* pass config to utils.RenderWeb(App)?Error
This allows the methods to extract the configured subpath and redirect
to the appropriate `/subpath/error` handler.
* ensure GetSubpathFromConfig returns trailing slashes deterministically
* fix error 404 handling
* redirect /subpath to /subpath/
This is necessary for the static handler to match, otherwise none of the
registered routes find anything. This also makes it no longer necessary
to add trailing slashes in the root router.
Examine ServiceSettings.SiteURL on startup and rewrite assets
accordingly if not in a development environment.
Also export `mattermost config subpath` command to manually do same.
This accompanies a webapp PR to use the updated `root.html` to define
the necessary webpack asset path for dynamically loading assets.
* MM-6839: search relative to executable (#8853)
* MM-6839: searching for paths relative to executable
In addition to searching relative to the current working directory, also
search relative to the location of the binary. This helps locate config
and i18n files when invoking an absolute path to the mattermost binary.
* MM-6839: find mattermost/ binary using utils.FindFile
* add unit tests for utils.FindFile to exclude directories
* fix filtering out directories in FindFile
* fix platform invoking ./bin/mattermost
* MM-6839: searching for paths relative to executable
In addition to searching relative to the current working directory, also
search relative to the location of the binary. This helps locate config
and i18n files when invoking an absolute path to the mattermost binary.
* MM-6839: find mattermost/ binary using utils.FindFile
* MM-10264: Adds CLI command to import and export permissions.
* MM-10264: Changes Scheme Name to DisplayName and adds Name slug field.
* MM-10264: Changes display name max size.
* MM-10264: Another merge fix.
* MM-10264: Changes for more Schemes methods checking for migration.
* MM-10264: More updates for Schemes migration checking.
* Remove api package
* Remove api dependency from cmd package
* Remove EnableAPIv3 setting
* Update web tests
* Add more websocket tests
* Move some ws and oauth tests to api4 package
* Move command tests into api4 package
* Test fixes
* Fix msg command test
* Add some app file tests
* Refactor context out of API packages
* Update function names per feedback
* Move webhook handlers to web and fix web tests
* Move more webhook tests out of api package
* Fix static handler
* Implementing structured logging
* Changes to en.json to allow refactor to run.
* Fixing global logger
* Structured logger initalization.
* Add caller.
* Do some log redirection.
* Auto refactor
* Cleaning up l4g reference and removing dependancy.
* Removing junk.
* Copyright headers.
* Fixing tests
* Revert "Changes to en.json to allow refactor to run."
This reverts commit fd8249e99b.
* Fixing some auto refactor strangeness and typo.
* Making keys more human readable.
* 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.
