* move plugin signature verification to caller
The semantics for when plugin signature validation is required are unique to the caller, so move this logic there instead of masking it, thus simplifying some of the downstream code.
* support transitionally prepacked plugins
Transitionally prepackaged plugins are prepackaged plugins slated for unpackaging in some future release. Like prepackaged plugins, they automatically install or upgrade if the server is configured to enable that plugin, but unlike prepackaged plugins they don't add to the marketplace to allow for offline installs. In fact, if unlisted from the marketplace and not already enabled via `config.json`, a transitionally prepackaged plugin is essentially hidden.
To ensure a smooth transition in the future release when this plugin is no longer prepackaged at all, transitionally prepackaged plugins are persisted to the filestore as if they had been installed by the enduser. On the next restart, even while the plugin is still transitionally prepackaged, the version in the filestore will take priority. It remains possible for a transitionally prepackaged plugin to upgrade (and once again persist) if we ship a newer version before dropping it altogether.
Some complexity arises in a multi-server cluster, primarily because we don't want to deal with multiple servers writing the same object to the filestore. This is probably fine for S3, but has undefined semantics for regular filesystems, especially with some customers backing their files on any number of different fileshare technologies. To simplify the complexity, only the cluster leader persists transitionally prepackaged plugins.
Unfortunately, this too is complicated, since on upgrade to the first version with the transitionally prepackaged plugin, there is no guarantee that server will be the leader. In fact, as all nodes restart, there is no guarantee that any newly started server will start as the leader. So the persistence has to happen in a job-like fashion. The migration system might work, except we want the ability to run this repeatedly as we add to (or update) these transitionally prepackaged plugins. We also want to minimize the overhead required from the server to juggle any of this.
As a consequence, the persistence of transitionally prepackaged plugins occurs on every cluster leader change. Each server will try at most once to persist its collection of transitionally prepackaged plugins, and newly started servers will see the plugins in the filestore and skip this step altogether.
The current set of transitionally prepackaged plugins include the following, but this is expected to change:
* focalboard
* complete list of transitionally prepackaged plugins
* update plugin_install.go docs
* updated test plugins
* unit test transitionally prepackged plugins
* try restoring original working directory
* Apply suggestions from code review
Co-authored-by: Michael Kochell <6913320+mickmister@users.noreply.github.com>
* clarify processPrepackagedPlugins comment
---------
Co-authored-by: Michael Kochell <6913320+mickmister@users.noreply.github.com>
This got missed out in the initial PR review.
There's been only one instance of this, and that too in a spinwick
so it's not widepsread. We will cp this if we see more crashes.
https://mattermost.atlassian.net/browse/MM-54158
```release-note
NONE
```
Somewhere in the build pipeline, we run `make config-reset` to generate a default `config.json` to include with the tarball. Unfortunately, this was being built without the `-tags production` signal that changes the default service environment to `production`, and in turn caused the `CWS` environment to default to testing. The trial licenses returned by the testing environment aren't compatible with the production environment, preventing new customers from starting trials by themselves.
As an immmediate workaround, customers can simply delete the `config.json` included with the tarball and start the server anew. Without any further configuration, it will correctly default to the `production` service environment and use the correct `CWS` environment.
Fix the tarball generation by adding `-tags production` to the `config-reset` Makefile target. We don't add a dev version of this for now, as it's not really needed given the server creates the right value on startup.
Fixes: https://mattermost.atlassian.net/browse/CLD-6137
- Prevents commands from receiving potential whitespace characters
- Adds a new root test case ensuring various whitespace characters are removed
Co-authored-by: Nathan Geist <ngeist@spiria.com>
After reliable websockets were introduced,
we would keep pushing to a webConn even after
the client has disconnected. This would lead
to the websocket.slow/full and eventually
the disconnect messages which unnecessarily
confuse the admin.
We don't log them if the connection is inactive.
We use the active field and convert it to an atomic
to use more widely.
```release-note
NONE
```
* Update group_store.go
Replace raw SQL with query builder for Get, Update, and Delete methods in GroupStore
* Update group_store.go
Replace raw SQL with query builder for GetByRemoteID, GetAllBySource, and Restore methods in GroupStore
* Add error handling when using query builder in group_store.go
* Use builder methods to cut down on boilerplate
* Update server/channels/store/sqlstore/group_store.go
Implement suggestion from PR review
Co-authored-by: Ibrahim Serdar Acikgoz <serdaracikgoz86@gmail.com>
---------
Co-authored-by: Ibrahim Serdar Acikgoz <serdaracikgoz86@gmail.com>
Co-authored-by: Mattermost Build <build@mattermost.com>
* remove boards data-retention
* remove another variable
* update snapshots, to remove boards
* need to keep config settings until focalboard is updated
---------
Co-authored-by: Mattermost Build <build@mattermost.com>
* Making all the counts aware of Remote users
* Disable login for remote users
* Adding tests for login remote_users error
* Adding tests for the store
* Adding frontend part of not counting remote users in the license
* Addressing PR review comment
* Adding the new ExternaUserId field to users
* Running make migrations-extract
* Running make app-layers and make gen-serialized
* Revert "Adding the new ExternaUserId field to users"
This reverts commit 12e5fd5189.
* Adding GetUserByRemoteID methods
* Adding needed migration for users
* i18n-extract
* Fixing postgres increase remote user id field size migration up and down
* run make gen-serialized
* Removing migration code
* Not count remote users as part of the cloud pricing
* Add the cloud subscription when a user gets promote from remote to not-remote
* Fixing merge problems
---------
Co-authored-by: Mattermost Build <build@mattermost.com>
* Mark category as read
* Fix lint and test
* Fix tests
* Fix test and remove wrong aria
* Address server issues and add mark as read for unreads
* Missing changes
* Fix tests
* fix tests
* Add confirmation popup to mark as read category
* Always use viewMultipleChannels and other fixes
* Remove unneeded code
* Fix test
* Address feedback
* Address feedback
* Fix tests
* Fix test
* Fix tests
* Update aria-haspopup depending on the number of channels to mark as viewed
---------
Co-authored-by: Mattermost Build <build@mattermost.com>
Enforce the existing `engine` directives requiring node at `16.x` and npm at `7.x`, failing with a clear error message if a mismatch exists:
```
npm ERR! code EBADENGINE
npm ERR! engine Unsupported engine
npm ERR! engine Not compatible with your version of node/npm: undefined
npm ERR! notsup Not compatible with your version of node/npm: undefined
npm ERR! notsup Required: {"node":"^16.10.0","npm":"^7.24.0"}
npm ERR! notsup Actual: {"npm":"8.5.0","node":"v16.14.2"}
npm ERR! A complete log of this run can be found in:
npm ERR! /Users/jesse/.npm/_logs/2023-08-08T15_09_40_758Z-debug-0.log
```
This change makes the version mismatch exceedingly and immediately clear instead of the developer having to infer from an obscure error much later on in the installation process.
