| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
* Default APIv3 to disabled for new installs
* Add EnableAPIv3 setting to client config
* Enable APIv3 for needed tests
|
| | | | | | | | | |
|
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
* remove global site url
* missed one
* revert mysterious change
|
| | | | | | | | | |
|
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
* Adding saml migration command
* Texts fixed
|
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
* Adding config settings nessisary for using CloudFront.
* Adding new config settings to diagnostics.
|
| | | | | | | | | |
|
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
* webhub optimizations
* test fix
* minor fix
* big perf improvement to ToJson after precomputing
* fix hub connection count
|
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
* MM-9556 Added ability to upload files without a multipart request
* MM-9556 Handled some unusual test behaviour
|
| | | | | | | | | |
|
| | | | | | | | | |
|
|\ \ \ \ \ \ \ \ \
| |_|_|_|_|_|_|_|/
|/| | | | | | | | |
|
| | | | | | | | | |
|
|/| | | | | | | |
| |/ / / / / / / |
|
| |\ \ \ \ \ \ \ |
|
| | | | | | | | | |
|
| |/ / / / / / / |
|
| |\ \ \ \ \ \ \ |
|
| |/ / / / / / / |
|
| |\ \ \ \ \ \ \ |
|
| | |\ \ \ \ \ \ \
| | |/ / / / / / /
| |/| | | | | | | |
|
| |\ \ \ \ \ \ \ \ |
|
| | | | | | | | | | |
|
| | |\ \ \ \ \ \ \ \ |
|
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
model.ChannelMemberHistoryResult object that includes those fields that are selected from a join on other tables
|
| |\ \ \ \ \ \ \ \ \ \ |
|
| | | | | | | | | | | | |
|
| |\ \ \ \ \ \ \ \ \ \ \ |
|
| | | | | | | | | | | | | |
|
| | | | | | | | | | | | | |
|
| | | | | | | | | | | | | |
|
| | | | | | | | | | | | | |
|
| | | | | | | | | | | | | |
|
| | |/ / / / / / / / / / |
|
| |\ \ \ \ \ \ \ \ \ \ \ |
|
| |/| | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | | |
jespino-XYZ-111
|
| | |/ / / / / / / / / / |
|
| | |_|/ / / / / / / /
| |/| | | | | | | | | |
|
| | | | | | | | | | | |
|
| | | | | | | | | | | |
|
| | |_|/ / / / / / /
| |/| | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
notifications
|
| | | | | | | | | | |
|
| | | | | | | | | | |
|
| | | | | | | | | | |
|
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
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.
|
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
* PLT-8723: Fix DeadLock on reactions insertions
* Improved the HasReactions update SQL
|
| | | | | | | | | | |
|
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
attachments with the same file name (#8289)
|
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
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.
|
|\ \ \ \ \ \ \ \ \ \
| |_|_|_|_|_|_|_|_|/
|/| | | | | | | | | |
|