Today, the server emits a system message containing one of `<username> left the channel.` or `<username> removed from the channel.` when such an event occurs.
While the client interprets this special kind of message to take into account the enduser's username display settings (e.g. to render `First Last left the channel.`), the server also processes this "message" to look for mentions.
With the user in question no longer in the channel, it incorrectly splits usernames containing a period into two tokens and tries to mentions users accordingly. So `christopher.poile` ends up trying to mention `christopher` and `poile`. If such a user exists, they receive a spurious mention for this event.
Change the message rendered by the server to explicitly prepend an `@`, which in turn is detected by the mention logic to avoid splitting. As above, this has no effect on the client-side rendered message.
* add ability to upload other plugins to the plugin API
* generated client rpc glue code
* fix UploadPlugin API signature
* generated plugin mocks
* added upload plugin test
* removed unused comment
* using single line to call InstallPlugin with file Reader
* fix minimum server version
* added successful plugin upload test
* renamed UploadPlugin to InstallPlugin
* chore: refactor to use structured logging
- change fmt.sprintf method used in the logger to appropriate mlog
method
* implement suggested changes by removing added line during merge conflict
* chore: refactor to use structured logging
- remove the unsed fmt package
- convert the fmt.sprintt to the structured logging
* implement requested changes from iomodo
* implement feedback from willfrog
* [MM-19007] Migrate tests from "app/job_test.go" to use testify
- Use 'require' and 'assert' methods instead of 't.Fatal'
* [MM-19007] Change 'assert' to 'require' to keep 't.Fatal' behavior
* MM-18540 - Demo plugin crashes on server shutdown
* MM-18540 - Removed unncessary lock statements
* Added comments, logging a warning if PluginsEnv is updated while shutting down plugins
* Don't clean up PluginsEnv if another Env is detected
* Changing warn to debug
* Revert "Changing warn to debug"
This reverts commit 46f20ab21eeabb01d07f53e02d850cd6d9b2b837.
* Convert app/user_test.go t.Fatal calls into assert/require calls
* arrange expected and actual arguments as per semantics
* arrange expected and actual arguments as per go semantics
* fix for notEqual
* diagnostics_test.go: fix spacing
* diagnostics_test.go: explicitly assert payload
This fails, since the package is currently receiving struct pointers and won't set the MessageId or Timestamp on the corresponding Message.
* MM-18115: fix segment v3 usage
In v5.14, we updated [github.com/segmentio/analytics-go](https://github.com/segmentio/analytics-go) to v3 as part of https://mattermost.atlassian.net/browse/MM-12389. As noted in the [migration guide](https://segment.com/docs/sources/server/go/#migrating-from-v2), the API subtly changed to expect a struct value and not a struct pointer:
```go
// in v2, you would call the `Track` method with a `Track` struct.
client.Track(&track)
// in v3, you would call the `Enqueue` method with a `Track` struct.
// Note that a pointer is not used here.
client.Enqueue(track)
```
Unfortunately, we kept passing a pointer, and the package didn't complain since it only required an interface -- which the pointer to these structs still implemented. Internally, it only checked for the value types, and failed to annotate our payloads with the requisite metadata. Upstream, segment.io accepted the payload, but then discarded it silently.
This has since been reported and fixed in https://github.com/segmentio/analytics-go/pull/146, but isn't yet part of a tagged release of the package.
Fix our code to pass struct values instead.
Fixes: MM-18115
* Convert app/notification_email_test.go t.Fatal calls into assert/require calls
* changes as per review
* using require.Regexp instead of require.True
