Critical wasn't added in the StdLevels slice
and due to that mlog.Critical wasn't printing anything.
This was a complete blindspot that was missed.
We have removed all references to mlog.Critical in the codebase
and pointed Critical to be Fatal in the library.
In v8, we will remove Critical altogether.
```release-note
Servers with an encrypted key will throw an error
during startup now.
```
* Revert "Revert "MM-43828: Pass object length for some image operations (#20711)" (#20740)"
This reverts commit c7ae090dad.
* Fix to work in bifrost mode
```release-note
NONE
```
For user profile and plugin upload, we use a bytes.Buffer.
In that case, we know the object size and can find
it out from the length of the buffer.
This helps reduce multi-part uploads.
This approach can also be taken in thumbnail and preview
images. However, they use an io.Pipe to directly upload
the image as it is being encoded. We could make the whole
process in separate parts of writing the full image in the
buffer and then upload it. But taking a conservative approach
for now.
Also, while here, removed some unused code.
https://mattermost.atlassian.net/browse/MM-43828
```release-note
NONE
```
* [MM-44667] Set InsecureSkipVerify for S3 when EnableInsecureOutgoingConnections is set
* Cleanup s3New, customTransport
* Lint fixes
* Cleanup s3store_test.go
* Using default transport
```release-note
NONE
```
Co-authored-by: Jake Gutierrez <jakegut0108@gmail.com>
Co-authored-by: Mattermod <mattermod@users.noreply.github.com>
* MM-40179 traverse directories when trying to export
* fix test
* fix s3 to behabe the same way
* add test for paths way too deep
* test recursion only on localstorage
* make list directories non recursively the default approach
* fix linting error
* fix non-recursive case
Co-authored-by: = <=>
Co-authored-by: Mattermod <mattermod@users.noreply.github.com>
This PR adds the necessary resolvers to support
the graphQL front-end. Some additional methods
need to be added to the model structs to support
this. Comments have been made to clarify their purpose.
There is a slight duplication of code in the api layer.
But eventually that's going to go away when we move
away from the REST API entirely.
The schema is in api4/schema.graphqls and gets compiled
into the binary as an asset.
The GraphiQL editor url is at GET /api/v5/graphql.
Everything is behind the feature flag MM_FEATUREFLAGS_GRAPHQL.
```release-note
NONE
```
The TestValidateToken was actually testing
the underlying library rather than testing our code.
So, in a way, it was ineffective.
The actual flaky test was that in a rare care,
the random string generated might actually lead
to 000000 being an actual code rather than invalid.
So using random strings is fundamentally incorrect.
Even the tests in the library use hardcoded strings
and not random strings.
To fix this properly would be to use hardcoded strings,
but then we would just be testing the library
and not our code. To keep things simple,
we just keep the test to verify the error message
and remove the others.
https://community-daily.mattermost.com/boards/workspace/zyoahc9uapdn3xdptac6jb69ic/285b80a3-257d-41f6-8cf4-ed80ca9d92e5/495cdb4d-c13a-4992-8eb9-80cfee2819a4/cidjhgy1ag3yktn5eszae1489yr
```release-note
NONE
```
Our store upgrade methods used mlog.Critical and then slept
for a second and triggered os.Exit.
First of all, with the new mlog refactor Critical wasn't a standard
log level so it was never to be logged.
And secondly, this completely missed the fact that there already
existed an API method Fatal which did exactly this.
We mark the Critical API as deprecated, and use Fatal for all
occurences.
The choice should be between either to use Error or Fatal.
While here, we also remove the non-standard exit codes which
just confused things further while debugging.
https://mattermost.atlassian.net/browse/MM-38712
```release-note
NONE
```
Fix an issue where context fields logged by server on behalf of plugins didn't contain correct name/value pairs:
- bump Logr version to add key/value methods to sugar logger
- expose factory args when configuring logging with custom target types (needed for FocalBoard to create log target adapter that converts typed fields into slices of interface{} as per plugin logging API)
This PR builds up on the pass-through DB driver to a fully functioning DB driver implementation via our RPC layer.
To keep things separate from the plugin RPC API, and have the ability to move fast with changes, a separate field Driver is added to MattermostPlugin. Typically the field which is required to be compatible are the API and Helpers. It would be well-documented that Driver is purely for internal use by Mattermost plugins.
A new Driver interface was created which would have a client and server implementation. Every object (connection, statement, etc.) is created and added to a map on the server side. On the client side, the wrapper structs hold the object id, and communicate via the RPC API using this id.
When the server gets the object id, it picks up the appropriate object from its map and performs the operation, and sends back the data.
Some things that need to be handled are errors. Typical error types like pq.Error and mysql.MySQLError are registered with encoding/gob. But for error variables like sql.ErrNoRows, a special integer is encoded with the ErrorString struct. And on the cilent side, the integer is checked, and the appropriate error variable is returned.
Some pending things:
- Context support. This is tricky. Since context.Context is an interface, it's not possible to marshal it. We have to find a way to get the timeout value from the context and pass it.
- RowsColumnScanType(rowsID string, index int) reflect.Type API. Again, reflect.Type is an interface.
- Master/Replica API support.
* MM-34787: Add colored output for non JSON console logs
https://mattermost.atlassian.net/browse/MM-34787
```release-note
A new field EnableColor is added to LogSettings and NotificationLogSettings.
Non-JSON console logs will now be colored if that field is set to true.
```
* Trigger CI
Remote Cluster Service
- provides ability for multiple Mattermost cluster instances to create a trusted connection with each other and exchange messages
- trusted connections are managed via slash commands (for now)
- facilitates features requiring inter-cluster communication, such as Shared Channels
Shared Channels Service
- provides ability to shared channels between one or more Mattermost cluster instances (using trusted connection)
- sharing/unsharing of channels is managed via slash commands (for now)
