snapshot of https://github.com/mattermost/mattermost.git (master, 2026-09-16; blobs > 131072B omitted)
Some checks failed
Server CI / Postgres (shard 0) (push) Has been skipped
Server CI / Postgres (shard 3) (push) Has been skipped
BuildEnv Docker Image / build-image (push) Failing after 4s
BuildEnv Docker Image / build-image-fips (push) Failing after 4s
Migration Review & Release Notes / Generate migration review & release notes (push) Failing after 3s
Server CI / Build Environment (push) Failing after 3s
Server CI / Postgres (shard 1) (push) Has been skipped
Tools CI / check-style (mattermost-govet) (push) Failing after 4s
Server CI / Postgres (shard 2) (push) Has been skipped
Tools CI / check-style (mmgotool) (push) Failing after 3s
Server CI / Elasticsearch v8 Compatibility (push) Has been skipped
Server CI / OpenSearch v2 Compatibility (push) Has been skipped
Server CI / Postgres FIPS (shard 0) (push) Has been skipped
Tools CI / Test (mattermost-govet) (push) Failing after 3s
Server CI / Postgres FIPS (shard 1) (push) Has been skipped
Server CI / Postgres FIPS (shard 2) (push) Has been skipped
Tools CI / Test (mmgotool) (push) Failing after 3s
Server CI / Postgres FIPS (shard 3) (push) Has been skipped
Server CI / Run mmctl tests (push) Has been skipped
Server CI / Run mmctl tests (FIPS) (push) Has been skipped
Server CI / Merge Postgres Test Results (push) Has been skipped
Server CI / Merge Postgres FIPS Test Results (push) Has been skipped
Server CI / Check backport migrations (push) Has been skipped
Server CI / Check generated files (push) Has been skipped
Server CI / check-style (push) Has been skipped
Server CI / Vet API (push) Has been skipped
Server CI / Build mattermost server app (push) Has been skipped
Server CI / Server CI Complete (push) Failing after 2s
Server CI / Server CI Artifacts (push) Has been skipped
Server CI / Sentry Upload (push) Has been skipped
Server CI / Server CI Report (push) Failing after 5m1s
Server CI Nightly Race / Race Detector (push) Has been skipped
CodeQL / Analyze (go) (push) Has been cancelled
CodeQL / Analyze (javascript) (push) Has been cancelled
Webapp CI Cache Warm / Warm Webapp node_modules Cache (push) Has been cancelled
E2E CI Cache Warm / Warm E2E npm Registry Cache (push) Has been cancelled
API / build (push) Has been cancelled
Web App CI / check-types (push) Has been cancelled
Web App CI / check-lint (push) Has been cancelled
Web App CI / check-i18n (push) Has been cancelled
Web App CI / check-external-links (push) Has been cancelled
Web App CI / test (platform) (push) Has been cancelled
Web App CI / test (mattermost-redux) (push) Has been cancelled
Web App CI / test (channels shard 1/4) (push) Has been cancelled
Web App CI / test (channels shard 2/4) (push) Has been cancelled
Web App CI / test (channels shard 3/4) (push) Has been cancelled
Web App CI / test (channels shard 4/4) (push) Has been cancelled
Web App CI / upload-coverage (push) Has been cancelled
Web App CI / build (push) Has been cancelled
YAML Lint / yamllint (push) Has been cancelled
Push mirrored docker images / cd/Push mirrored docker images (push) Has been cancelled
docs-cd / Build and deploy docs (push) Has been cancelled
Docs CI / build (push) Has been cancelled
E2E Cache Warm: Cypress deps / Warm Cypress deps cache (push) Has been cancelled
Scorecards supply-chain security / Scorecard analysis (push) Has been cancelled
Server CI Weekly / Postgres FIPS (push) Has been skipped
Server CI Weekly / Run mmctl tests (FIPS) (push) Has been skipped
Server CI Weekly / Postgres with binary parameters (push) Has been skipped
Server CI Weekly / Build Environment (push) Failing after 1s
Server CI Cache Warm / Warm Go Module and Build Cache (push) Failing after 2s
Server CI Nightly Race / Build Environment (push) Failing after 1s
Some checks failed
Server CI / Postgres (shard 0) (push) Has been skipped
Server CI / Postgres (shard 3) (push) Has been skipped
BuildEnv Docker Image / build-image (push) Failing after 4s
BuildEnv Docker Image / build-image-fips (push) Failing after 4s
Migration Review & Release Notes / Generate migration review & release notes (push) Failing after 3s
Server CI / Build Environment (push) Failing after 3s
Server CI / Postgres (shard 1) (push) Has been skipped
Tools CI / check-style (mattermost-govet) (push) Failing after 4s
Server CI / Postgres (shard 2) (push) Has been skipped
Tools CI / check-style (mmgotool) (push) Failing after 3s
Server CI / Elasticsearch v8 Compatibility (push) Has been skipped
Server CI / OpenSearch v2 Compatibility (push) Has been skipped
Server CI / Postgres FIPS (shard 0) (push) Has been skipped
Tools CI / Test (mattermost-govet) (push) Failing after 3s
Server CI / Postgres FIPS (shard 1) (push) Has been skipped
Server CI / Postgres FIPS (shard 2) (push) Has been skipped
Tools CI / Test (mmgotool) (push) Failing after 3s
Server CI / Postgres FIPS (shard 3) (push) Has been skipped
Server CI / Run mmctl tests (push) Has been skipped
Server CI / Run mmctl tests (FIPS) (push) Has been skipped
Server CI / Merge Postgres Test Results (push) Has been skipped
Server CI / Merge Postgres FIPS Test Results (push) Has been skipped
Server CI / Check backport migrations (push) Has been skipped
Server CI / Check generated files (push) Has been skipped
Server CI / check-style (push) Has been skipped
Server CI / Vet API (push) Has been skipped
Server CI / Build mattermost server app (push) Has been skipped
Server CI / Server CI Complete (push) Failing after 2s
Server CI / Server CI Artifacts (push) Has been skipped
Server CI / Sentry Upload (push) Has been skipped
Server CI / Server CI Report (push) Failing after 5m1s
Server CI Nightly Race / Race Detector (push) Has been skipped
CodeQL / Analyze (go) (push) Has been cancelled
CodeQL / Analyze (javascript) (push) Has been cancelled
Webapp CI Cache Warm / Warm Webapp node_modules Cache (push) Has been cancelled
E2E CI Cache Warm / Warm E2E npm Registry Cache (push) Has been cancelled
API / build (push) Has been cancelled
Web App CI / check-types (push) Has been cancelled
Web App CI / check-lint (push) Has been cancelled
Web App CI / check-i18n (push) Has been cancelled
Web App CI / check-external-links (push) Has been cancelled
Web App CI / test (platform) (push) Has been cancelled
Web App CI / test (mattermost-redux) (push) Has been cancelled
Web App CI / test (channels shard 1/4) (push) Has been cancelled
Web App CI / test (channels shard 2/4) (push) Has been cancelled
Web App CI / test (channels shard 3/4) (push) Has been cancelled
Web App CI / test (channels shard 4/4) (push) Has been cancelled
Web App CI / upload-coverage (push) Has been cancelled
Web App CI / build (push) Has been cancelled
YAML Lint / yamllint (push) Has been cancelled
Push mirrored docker images / cd/Push mirrored docker images (push) Has been cancelled
docs-cd / Build and deploy docs (push) Has been cancelled
Docs CI / build (push) Has been cancelled
E2E Cache Warm: Cypress deps / Warm Cypress deps cache (push) Has been cancelled
Scorecards supply-chain security / Scorecard analysis (push) Has been cancelled
Server CI Weekly / Postgres FIPS (push) Has been skipped
Server CI Weekly / Run mmctl tests (FIPS) (push) Has been skipped
Server CI Weekly / Postgres with binary parameters (push) Has been skipped
Server CI Weekly / Build Environment (push) Failing after 1s
Server CI Cache Warm / Warm Go Module and Build Cache (push) Failing after 2s
Server CI Nightly Race / Build Environment (push) Failing after 1s
This commit is contained in:
@@ -0,0 +1,14 @@
|
||||
---
|
||||
title: "Administration Guide"
|
||||
---
|
||||
Welcome to the Mattermost Administration Guide. This guide is organized around what you're doing — setting the server up, getting users in, running it day to day, keeping it healthy, meeting your compliance obligations, upgrading it, and migrating data in and out.
|
||||
|
||||
- [Configure](/administration-guide/configure/configure-index) - System Console settings, search, email, file storage, branding, agents, and plugins.
|
||||
- [Onboard users](/administration-guide/onboard/onboard-index) - Single sign-on, AD/LDAP, provisioning, and guest accounts.
|
||||
- [Manage](/administration-guide/manage/admin/server-maintenance) - Access control, server operations, licensing, Cloud workspaces, and notices.
|
||||
- [Monitor and troubleshoot](/administration-guide/manage/admin/monitoring-and-performance) - Metrics and dashboards, logging, health checks, support packets, and error codes.
|
||||
- [Comply](/administration-guide/comply/comply-index) - Compliance export and monitoring, eDiscovery, data retention, legal hold, and audit logs.
|
||||
- [Upgrade](/administration-guide/upgrade/upgrade-index) - Upgrade notes, upgrade and downgrade procedures, and post-upgrade rollout tasks.
|
||||
- [Migrate](/administration-guide/manage/admin/migration) - Bulk import and export, MySQL to PostgreSQL, FIPS migration, and moving from another platform.
|
||||
|
||||
If you're deploying Mattermost for the first time, start with the [deployment guide](/deployment-guide/deployment-guide-index) instead.
|
||||
224
docs/main/administration-guide/comply/compliance-export.mdx
Normal file
224
docs/main/administration-guide/comply/compliance-export.mdx
Normal file
@@ -0,0 +1,224 @@
|
||||
---
|
||||
title: "Compliance export"
|
||||
---
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
<PlanAvailability slug="ent-plus" />
|
||||
|
||||
Mattermost Enterprise customers can archive history or transfer message data to third-party systems for auditing and compliance purposes with compliance exports. Supported integrations include [Smarsh (Actiance) Vantage](#actiance-xml), [Global Relay](#global-relay-eml), and [Proofpoint](#proofpoint).
|
||||
|
||||
From Mattermost v10.5, compliance exports include performance improvements for large daily data sets with changes affecting output formats, system performance, and logic. Compliance exports provide compliance teams complete information to reconstruct the state of a channel, and to determine who had visibility on an initial message, or when the message was edited or deleted. Compliance teams can track a message by its MessageId as it is edited or deleted, and across batches and exports periods.
|
||||
|
||||
## Overview
|
||||
|
||||
Compliance exports are produced from the System Console, and contain all messages including:
|
||||
|
||||
- Messages sent in direct message channels
|
||||
- File uploads
|
||||
- Posts from plugins
|
||||
- Posts from bots/webhooks
|
||||
|
||||
Exports include information on channel member history at the time the message was posted.
|
||||
|
||||
## Set up guide
|
||||
|
||||
Use the following guides to configure exports for [CSV](#csv), [Smarsh / Actiance XML](#actiance-xml), [Global Relay EML](#global-relay-eml), or [Proofpoint](#proofpoint).
|
||||
|
||||
<Note>
|
||||
|
||||
- For self-hosted deployments, compliance exports are written to the `exports` subdirectory of the configured filestore in the chosen format. This will either be in the [Local Storage directory](/administration-guide/configure/environment-configuration-settings#file-storage) or the Mattermost S3 bucket if S3 storage is configured.
|
||||
- Alternatively, you can specify an alternate filestore target and generate an S3 presigned URL for compliance exports. See the [dedicated export filestore target](/administration-guide/configure/environment-configuration-settings#enable-dedicated-export-filestore-target) configuration settings documentation for details.
|
||||
- Compliance exports don't contain posts sent before the feature was enabled. For self-hosted deployments, you can export past history via the `export` [command line tool](/administration-guide/manage/mmctl-command-line-tool).
|
||||
|
||||
</Note>
|
||||
|
||||
### CSV
|
||||
|
||||
1. Go to **System Console \> Compliance \> Compliance Export**.
|
||||
2. Set **Enable Compliance Exports** to **true**.
|
||||
3. Set the **Compliance Export time**. This is the start time of the daily scheduled compliance export job and must be a 24-hour time stamp in the form `HH:MM`. Choose a time when fewer people are using your system.
|
||||
4. Set the export file format to **CSV**.
|
||||
5. Select **Save**.
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="from-mattermost-v10-5" label="From Mattermost v10.5">
|
||||
|
||||
You can review export job status in the System Console.
|
||||
|
||||
When the daily compliance export job is finished, a parent directory is created named based on when the export was started and the `startTimestamp` and `endTimestamp` of the export, e.g, `administration-guide/comply/compliance-export-2024-08-13-05h08m-1723105062492-1723109100075`. That parent directory contains 1 zip file for each batch, named based on the batch number and the start and end timestamps of the messages in that batch, e.g, `batch001-1723105062492-1723106622163.zip`. Each zip file contains the same information available in previous Mattermost server releases.
|
||||
|
||||
Working from the same example above, the directory would look like this:
|
||||
|
||||
``` bash
|
||||
administration-guide/comply/compliance-export-2024-08-13-05h08m-1723105062492-1723109100075
|
||||
├── batch001-1723105062492-1723106622163.zip
|
||||
├── batch002-1723106622163-1723108196005.zip
|
||||
└── batch003-1723108196005-1723109100075.zip
|
||||
```
|
||||
|
||||
And each batch would look like this:
|
||||
|
||||
``` bash
|
||||
batch001-1723105062492-1723106622163.zip
|
||||
├── files
|
||||
├── metadata.json
|
||||
└── actiance_export.xml
|
||||
```
|
||||
|
||||
## Updated CSV export fields
|
||||
|
||||
**Post Creation Time** is always the `CreateAt` for messages and attachments, or `JoinTime` and `LeaveTime` for participant join and leave events, respectively.
|
||||
|
||||
- **Update Time** indicates that the message has been updated, and this is the `updateAt` time.
|
||||
- **Updated Type** helps differentiate what kind of update it was as one of the following:
|
||||
- **EditedNewMsg** indicates that the message has been edited, and this is the new message (post-edit) content.
|
||||
- **EditedOriginalMsg** indicates that the message has been edited, and this the original message (pre-edit) content. This message will have another field `EditedNewMsgId`, which is the Id of the message which holds the post-edited message contents.
|
||||
- **UpdatedNoMsgChange** indicates that message's content hasn't changed, but the post was updated for some reason, such as reaction, replied-to, a reply was edited, or a reply was deleted.
|
||||
- **Deleted** indicates that this message was deleted.
|
||||
- **FileDeleted** indicates that this message is recording that a file was deleted.
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="prior-to-mattermost-v10-5" label="Prior to Mattermost v10.5">
|
||||
|
||||
The daily compliance export job creates a `.zip` file with a unique job identifier of all messages posted in the last 24 hours. You can unzip the file to easily transform the default `.csv` format into a desired format for your third-party archive system.
|
||||
|
||||
For a sample CSV output, [download a CSV export file here](/files/samples/csv_export.zip).
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
### Actiance XML
|
||||
|
||||
Actiance XML is the supported format for the 'Smarsh Vantage product \[https://central.smarsh.com/s/product/vantage\](https://central.smarsh.com/s/product/vantage\)\`\_.
|
||||
|
||||
1. Go to **System Console \> Compliance \> Compliance Export**.
|
||||
2. Set **Enable Compliance Exports** to **true**.
|
||||
3. Set the **Compliance Export time**. This is the start time of the daily scheduled compliance export job and must be a 24-hour time stamp in the form HH:MM. Choose a time when fewer people are using your system.
|
||||
4. Set the export file format to **Actiance XML**.
|
||||
5. Select **Save**.
|
||||
|
||||
<Note>
|
||||
|
||||
In Actiance XML exports, channel type is prepended to the channel names.
|
||||
|
||||
</Note>
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="from-mattermost-v10-5" label="From Mattermost v10.5">
|
||||
|
||||
You can review export job status in the System Console. Once you've selected Actiance XML as your file format, you can set up an integration with Actiance Vantage archive system.
|
||||
|
||||
When the daily compliance export job is finished, a parent directory is created named based on when the export was started and the `startTimestamp` and `endTimestamp` of the export, e.g, `administration-guide/comply/compliance-export-2024-08-13-05h08m-1723105062492-1723109100075`. That parent directory contains 1 zip file for each batch, named based on the batch number and the start and end timestamps of the messages in that batch, e.g, `batch001-1723105062492-1723106622163.zip`. Each zip file contains the same information available in previous Mattermost server releases.
|
||||
|
||||
Working from the same example above, the directory would look like this:
|
||||
|
||||
``` bash
|
||||
administration-guide/comply/compliance-export-2024-08-13-05h08m-1723105062492-1723109100075
|
||||
├── batch001-1723105062492-1723106622163.zip
|
||||
├── batch002-1723106622163-1723108196005.zip
|
||||
└── batch003-1723108196005-1723109100075.zip
|
||||
```
|
||||
|
||||
And each batch would look like this:
|
||||
|
||||
``` bash
|
||||
batch001-1723105062492-1723106622163.zip
|
||||
├── 20240808
|
||||
└── actiance_export.xml
|
||||
```
|
||||
|
||||
## Updated Actiance XML export fields
|
||||
|
||||
If an XML field is empty, it won't be exported. This is a change from previous Mattermost releases, where empty XML nodes were exported.
|
||||
|
||||
- `MessageId` is the unique `messageId`.
|
||||
- `DateTimeUTC` is always the post's `CreateAt` time.
|
||||
- `UpdatedDateTimeUTC` indicates that the message has been updated, and this is the `updateAt` time.
|
||||
- `UpdatedType` helps differentiate what kind of update it was, including:
|
||||
- `EditedNewMsg` indicates that this message has been edited, and this is the new message (post-edit) content.
|
||||
- `EditedOriginalMsg` indicates that this message has been edited, and this the original message (pre-edit) content. This message will have another field `EditedNewMsgId`, which is the Id of the message which holds the post-edited message contents.
|
||||
- `UpdatedNoMsgChange` indicates that this message's content hasn't changed, but the post was updated for some reason, such as a reaction, replied-to, a reply was edited, or a reply was deleted.
|
||||
- `Deleted` indicates that the message was deleted.
|
||||
- `FileDeleted` indicates that the message is recording that a file was deleted.
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="prior-to-mattermost-v10-5" label="Prior to Mattermost v10.5">
|
||||
|
||||
The daily compliance export job creates a `.zip` file with a unique job identifier of all messages posted in the last 24 hours. Once you've selected Actiance XML as your file format, you can set up an integration with Actiance Vantage archive system. For a sample Actiance output, [download an Actiance XML export file here](/files/samples/actiance_export.xml).
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
### Global Relay EML
|
||||
|
||||
For more information on Global Relay archive system, visit [their website](https://www.globalrelay.com/).
|
||||
|
||||
1. Go to **System Console \> Compliance \> Compliance Export**.
|
||||
2. Set **Enable Compliance Export** to **true**.
|
||||
3. Set the **Compliance Export time**. This is the start time of the daily scheduled compliance export job and must be a 24-hour time stamp in the form HH:MM. Choose a time when fewer people are using your system.
|
||||
4. Set the **Export Format** to **GlobalRelay EML**.
|
||||
5. Select **A9/Type 9**, **A10/Type 10**, or **Custom** for the **Global Relay Customer Account**. This is the type of Global Relay customer account your organization has.
|
||||
- For **A9/Type 9** and **A10/Type 10** types, set the **Global Relay SMTP username**, **Global Relay SMTP password**, and **Global Relay SMTP email address**, provided by Global Relay.
|
||||
- For a **Custom** type, set the **Global Relay SMTP username**, **Global Relay SMTP password**, **Global Relay SMTP email address**, **SMTP Server Name**, and the **SMTP Server Port**, provided by Global Relay. **Custom** type can be used to integrate with Proofpoint.
|
||||
6. Select **Save**.
|
||||
|
||||
<Note>
|
||||
|
||||
Messages larger than 250 MB will have their attachments removed because they are too large to send to Global Relay. An error is added to the server logs with id `global_relay_attachments_removed`. It includes the post ID the attachments were removed from, as well as the attachment IDs. A [ticket is queued to better handle large messages](https://mattermost.atlassian.net/browse/MM-10038).
|
||||
|
||||
</Note>
|
||||
|
||||
Once you've selected Global Relay EML as your file format, you can set up an integration with Global Relay archive system. For more information, see [Global Relay Archive](https://www.globalrelay.com/products/archive-data-compliance/).
|
||||
|
||||
### Proofpoint
|
||||
|
||||
1. Go to **System Console \> Compliance \> Compliance Export**.
|
||||
2. Set **Enable Compliance Export** to **true**.
|
||||
3. Set the **Compliance Export time**. This is the start time of the daily scheduled compliance export job and must be a 24-hour time stamp in the form HH:MM. Choose a time when fewer people are using your system.
|
||||
4. Set the **Export Format** to **GlobalRelay EML**.
|
||||
5. Select **Custom** for the **Global Relay Customer Account** to integrate with Proofpoint.
|
||||
6. Set the **SMTP username**, **SMTP password**, **SMTP email address**, **SMTP Server Name**, and the **SMTP Server Port**, provided by Proofpoint.
|
||||
7. Select **Save**.
|
||||
|
||||
See the [Global Relay](#global-relay-eml) section for details on updated Global Relay export fields. Now you can set up an integration with the Proofpoint archive system. For more information, visit the [Proofpoint Archive webiste](https://www.proofpoint.com/us/products/archiving-and-compliance/archive).
|
||||
|
||||
## Frequently Asked Questions (FAQ)
|
||||
|
||||
### Are Playbooks and Boards data included in compliance exports?
|
||||
|
||||
No. Compliance exports only include channel messages, direct messages, file uploads, and posts from plugins/bots/webhooks. Data from Mattermost Playbooks (including run activities, status updates, and retrospectives) and Mattermost Boards (including cards, comments, and board activities) are not included in the compliance export functionality. Organizations requiring compliance archiving of Playbooks and Boards data should consider separate data retention strategies for these features.
|
||||
|
||||
### How do I export past history?
|
||||
|
||||
Run the `export` [command line tool](/administration-guide/manage/mmctl-command-line-tool). You can specify an `exportFrom` option to export data from a specified timestamp. All posts that were made after this timestamp will be exported.
|
||||
|
||||
### How do I download compliance export jobs using mmctl?
|
||||
|
||||
From Mattermost Server v10.11, system administrators can download compliance export jobs using the [mmctl compliance_export download](/administration-guide/manage/mmctl-command-line-tool#mmctl-compliance-export-download) command. This provides a command-line interface for retrieving completed compliance export jobs by job ID.
|
||||
|
||||
### What happens if I export data manually?
|
||||
|
||||
If the compliance export job is run automatically, manually via the System Console, or manually via the CLI (without the `--exportFrom` option), it exports all posts that were made since the last post that the previous execution of the job exported. If this is the first time that the job has ever run, all posts that were made since the feature was enabled will be exported.
|
||||
|
||||
If the `--exportFrom` option is specified with the CLI command, all posts that have been made since the supplied timestamp will be exported.
|
||||
|
||||
When run manually via the System Console, `.csv` and Actiance XML files are written to the `exports` subdirectory of the configured [Local Storage Directory](/administration-guide/configure/environment-configuration-settings#local-storage-directory). Files will be written to a folder with names based on an epoch time range. Global Relay EML export format files will be mailed to the configured email address when run manually.
|
||||
|
||||
### Is there a maximum row limit for CSV files?
|
||||
|
||||
No. There's no limit to the number of rows within Compliance Monitoring CSV files.
|
||||
|
||||
### How do I know if a compliance export job fails?
|
||||
|
||||
Mattermost provides the status of each compliance export job in **System Console \> Compliance \> Compliance Export**. Here, you can see if the job succeeded or failed, including the number of messages and files exported.
|
||||
|
||||
In addition, any failures are returned in the server logs for self-hosted deployments. The error log begins with the string `Failed job` and includes a `job_id key/value` pair. Compliance export job failures are identified with worker name `MessageExportWorker`. You can optionally create a script that programmatically queries for such failures and notifies the appropriate system.
|
||||
|
||||
<Note>
|
||||
|
||||
This compliance export feature replaces legacy Compliance Reporting Oversight functionality. We recommend Enterprise customers migrate to the new system. For a sample CSV output of the new compliance export system, [download a CSV export file here](/files/samples/csv_export.zip).
|
||||
|
||||
</Note>
|
||||
243
docs/main/administration-guide/comply/compliance-monitoring.mdx
Normal file
243
docs/main/administration-guide/comply/compliance-monitoring.mdx
Normal file
@@ -0,0 +1,243 @@
|
||||
---
|
||||
title: "Compliance monitoring"
|
||||
---
|
||||
<PlanAvailability slug="ent-plus" />
|
||||
|
||||
This feature enables compliance exports to be produced from the System Console, with all query and download actions logged in an audit history to enable oversight and prevent unauthorized queries.
|
||||
|
||||
Compliance exports can be filtered to date range, user account, and keyword list. Requests from queries can be downloaded from the user interface in `.csv` format, with a `.json` metafile documenting the query, as well as placed in a directory set by the system admin.
|
||||
|
||||
Daily compliance reports may also be generated, supporting integration with compliance solutions like [Global Relay](#global-relay-support).
|
||||
|
||||
By default, all Mattermost deployments retain all messages, including edits and deletes, along with all files uploaded.
|
||||
|
||||
## Enable compliance reporting
|
||||
|
||||
To enable the option to generate daily compliance reports:
|
||||
|
||||
1. Go to **System Console \> Compliance \> Compliance Monitoring** and set the **Enable Compliance Reporting** value to **true**.
|
||||
2. (Optional) In **Compliance Report Directory** specify the directory in which to place completed compliance reports. Defaults to `./data/` if left blank.
|
||||
3. Select **Save**.
|
||||
|
||||
## Turn on daily compliance reports
|
||||
|
||||
After enabling compliance reporting:
|
||||
|
||||
1. Go to **System Console \> Compliance \> Compliance Monitoring** and set the **Enable Daily Report** value to **true**.
|
||||
2. Select **Save**.
|
||||
|
||||
Your system will now export all new messages posted within a 24-hour period as a `.csv` file to the location specified in **Compliance Report Directory**. This feature can be used in conjunction with centralized compliance reporting systems that move.
|
||||
|
||||
## Run compliance reports
|
||||
|
||||
Compliance reports are exports of all messages in Mattermost that match the report criteria. To run a report:
|
||||
|
||||
1. Go to **System Console \> Compliance \> Compliance Monitoring**.
|
||||
|
||||
2. Fill in the following:
|
||||
|
||||
> - **Job Name:** Name the compliance report you are about to run (e.g. "HR Audit 455").
|
||||
> - **From:** Start date for search in YYYY-MM-DD format (e.g. "2016-03-11").
|
||||
> - **To:** End date of search in YYYY-MM-DD format (e.g. "2016-05-11").
|
||||
> - **Emails:** Comma-separated list of email addresses of users whose posted messages you want to search (e.g. `bill@example.com, bob@example.com`).
|
||||
> - **Keywords:** Indicate the words that would be contained in a message for it to be included in the compliance report results.
|
||||
|
||||
3. Select **Run Compliance Report**.
|
||||
|
||||
The report will be queued in the display below the fields described above. The properties of each compliance report run is explained as follows:
|
||||
|
||||
- **Timestamp:** Time at which the report was requested.
|
||||
- **Status:** `running` indicates the report is being run; `finished` indicates the report is complete and ready for download.
|
||||
- **Records:** Shows the number of search results.
|
||||
- **Type:** `adhoc` indicates the report was requested by completing query fields; `daily` indicates the report is a daily export.
|
||||
- **Description:** Job Name indicated in request.
|
||||
- **Requested by:** Email of person requesting the report.
|
||||
- **Params:** Parameters of the compliance report request.
|
||||
|
||||
Each compliance report includes a **Download** link which downloads a compressed file named `adhoc-[UNIQUE_ID].zip`. Inside the file is `meta.json`, which includes the parameters of the search executed and `posts.csv` which includes the contents of messages found by the request.
|
||||
|
||||
### Compliance query definition stored in `meta.json`
|
||||
|
||||
The `meta.json` file contains the following information about the compliance query:
|
||||
|
||||
<table style={{width: '99%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '17%'}} />
|
||||
<col style={{width: '52%'}} />
|
||||
<col style={{width: '29%'}} />
|
||||
</colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Field</th>
|
||||
<th>Description</th>
|
||||
<th>Example</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>id</td>
|
||||
<td>Unique identifier for compliance query</td>
|
||||
<td>ja8z8egap7nq9kqetz3rt98khe</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>create_at</td>
|
||||
<td>Timestamp at which compliance query was executed</td>
|
||||
<td>1463637842478</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>user_id</td>
|
||||
<td>Mattermost User ID for person creating query</td>
|
||||
<td>3bq1shta93yztg3i6aiu1tzi5h</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>status</td>
|
||||
<td>Status of query: <em>finished</em> or <em>failed</em></td>
|
||||
<td>"finished"</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>count</td>
|
||||
<td>Count of messages found matching keyword</td>
|
||||
<td>36</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>desc</td>
|
||||
<td>User entered description of compliance query</td>
|
||||
<td>Example Compliance Report</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>type</td>
|
||||
<td>Type of compliance query: <em>adhoc</em> or <em>daily</em></td>
|
||||
<td>"adhoc"</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>start_at</td>
|
||||
<td>Timestamp at which query began to run</td>
|
||||
<td>1451606400000</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>end_at</td>
|
||||
<td>Timestamp at which query ended</td>
|
||||
<td>1463529600000</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>keywords</td>
|
||||
<td>Comma-separated, case insensitive keywords to match in query</td>
|
||||
<td>"drinking"</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>emails</td>
|
||||
<td>Comma-separated emails of users to search. Blank returns all</td>
|
||||
<td><code>frank.yu@ha.ca, mary.li@hi.co</code></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
### Compliance query results stored in `posts.csv` file
|
||||
|
||||
`posts.csv` contains the following information about the compliance query results, one search result per row:
|
||||
|
||||
<table style={{width: '98%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '18%'}} />
|
||||
<col style={{width: '53%'}} />
|
||||
<col style={{width: '26%'}} />
|
||||
</colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Field</th>
|
||||
<th>Description</th>
|
||||
<th>Example</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>TeamName</td>
|
||||
<td>URL name of team</td>
|
||||
<td>contosi</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>TeamDisplayName</td>
|
||||
<td>Display name of team</td>
|
||||
<td>Contosi Corporation</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>ChannelDisplayName</td>
|
||||
<td>Display name of channel where keyword was found</td>
|
||||
<td>Community Heartbeat</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>ChannelName</td>
|
||||
<td>URL name of channel</td>
|
||||
<td>community-heartbeat</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>UserUsername</td>
|
||||
<td>Username of user posting the message containing keyword</td>
|
||||
<td>frank.yu</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>UserEmail</td>
|
||||
<td>Email of user posting the message containing keyword</td>
|
||||
<td>"frank.yu@contosi.com"</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>UserNickname</td>
|
||||
<td>Nickname of user posting the message containing keyword</td>
|
||||
<td>fan du</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>UserType</td>
|
||||
<td>Type of user posting the message ("user" or "bot")</td>
|
||||
<td>user</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>PostId</td>
|
||||
<td>Unique ID of message post containing keyword</td>
|
||||
<td>xt9anyx6x3fx9y84aehgakdpze</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>PostCreateAt</td>
|
||||
<td>Timestamp at which post was created</td>
|
||||
<td>2016-03-02T16:01:59Z</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>PostDeletedAt</td>
|
||||
<td>Timestamp at which post was deleted (if applicable)</td>
|
||||
<td>2016-03-02T16:01:59Z</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>PostUpdatedAt</td>
|
||||
<td>Timestamp at which post was last edited (if applicable)</td>
|
||||
<td>2016-03-02T16:01:59Z</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>PostParentId</td>
|
||||
<td>Unique ID of parent post if post is a comment</td>
|
||||
<td>xt9anyx6x3fx9y84aehgakdpze</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>PostOriginalId</td>
|
||||
<td>Unique ID of post if deleted or edited</td>
|
||||
<td>xt9anyx6x3fx9y84aehgakdpze</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>PostMessage</td>
|
||||
<td>Message containing keyword</td>
|
||||
<td>Drinking from the fire hose</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>PostFilenames</td>
|
||||
<td>Comma separated list of filesnames attached to post</td>
|
||||
<td>["/f../ho.png","/f../hi.png"]</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
## Global Relay support
|
||||
|
||||
Mattermost daily compliance reports are compatible with Global Relay compliance solutions through the conversion of Mattermost `.CSV` exports into Global Relay `EML` files.
|
||||
|
||||
- This conversion can be done by in-house developers who have previously written scripts to convert other communication systems into Global Relay format based on your organization's specific needs.
|
||||
- You can also contact your Global Relay account manager about a services project to establish this conversion.
|
||||
|
||||
We recommend using the new [Compliance Export feature](/administration-guide/comply/compliance-export) for Global Relay exports.
|
||||
14
docs/main/administration-guide/comply/comply-index.mdx
Normal file
14
docs/main/administration-guide/comply/comply-index.mdx
Normal file
@@ -0,0 +1,14 @@
|
||||
---
|
||||
title: "Compliance with Mattermost"
|
||||
sidebar_label: "Comply"
|
||||
---
|
||||
Mattermost is purpose-built to help enterprises keep sensitive data safe and compliant in the strictest, most complex environments. Mattermost Enterprise Edition includes features designed to make compliance with all relevant regulations and internal policies easy to achieve and maintain.
|
||||
|
||||
- [Compliance exports](/administration-guide/comply/compliance-export) - Export compliance reports to third-party systems to archive history.
|
||||
- [Compliance monitoring](/administration-guide/comply/compliance-monitoring) - Enable oversight and prevent unauthorized queries with compliance exports.
|
||||
- [Electronic discovery](/administration-guide/comply/electronic-discovery) - Extract data from Mattermost for eDiscovery.
|
||||
- [Data retention](/administration-guide/comply/data-retention-policy) - Control how long data is stored in Mattermost with global and custom retention policies to meet data retention compliance requirements.
|
||||
- [Export channel data](/administration-guide/comply/export-mattermost-channel-data) - Migrate data between systems and back data up for operational continuity.
|
||||
- [Legal hold](/administration-guide/comply/legal-hold) - Preserve relevant Mattermost information when litigation is anticipated.
|
||||
- [Custom terms of service](/administration-guide/comply/custom-terms-of-service) - Require users to accept your own terms before they can access Mattermost.
|
||||
- [Audit log JSON schema](/administration-guide/comply/embedded-json-audit-log-schema) - Learn how to configure Mattermost audit logging using a JSON object.
|
||||
@@ -0,0 +1,47 @@
|
||||
---
|
||||
title: "Custom terms of service"
|
||||
---
|
||||
<PlanAvailability slug="ent-plus" />
|
||||
|
||||
Increase clarity on legal Mattermost expectations for internal employees and guests with the ability to set custom Terms of Service (“ToS”) agreements and re-acceptable periods.
|
||||
|
||||
## Configuring terms of service
|
||||
|
||||
To enable custom terms of service:
|
||||
|
||||
1. Go to **System Console \> Compliance \> Custom Terms of Service**.
|
||||
2. Set **Enable Custom Terms of Service** to **true**.
|
||||
3. Set **Custom Terms of Service Text** which contains your terms. Markdown formatting is supported, including lists, headings, and bolding.
|
||||
4. Set **Re-Acceptance Period** to configure the number of days before Terms of Service acceptance expires, and when the terms must be re-accepted. Set to 0 if you don't want your terms to expire.
|
||||
5. Select **Save**.
|
||||
|
||||
Once saved, all users must accept the terms of service by clicking **I Agree** next time they log in, or on the next page refresh. If they do not accept, they will be logged out.
|
||||
|
||||
<Note>
|
||||
|
||||
If you make an update to your Terms of Service, make sure to update your terms of service link at **System Console \> Site Configuration \> Customization \> Terms of Service link**. This link is presented to all users when they log in, and it's easily accessible to end users after accepting the terms.
|
||||
|
||||
</Note>
|
||||
|
||||
## Frequently asked questions
|
||||
|
||||
### What happens if I update my terms of service text?
|
||||
|
||||
There will be no impact to your end users. Users will simply be required to accept the new terms on next login or page refresh.
|
||||
|
||||
### What happens if a user doesn't accept the terms of service?
|
||||
|
||||
Users won't be able to log in if they don't accept the Terms of Service.
|
||||
|
||||
### How do I know if my users accepted the terms of service?
|
||||
|
||||
Each time a user agrees to the terms of service, the agreement is recorded in the database:
|
||||
|
||||
- A new field `AcceptedServiceTermsId` in the **Users** table indicates the most recent terms of service the user has accepted.
|
||||
- Each time a user accepts the terms, the action is recorded in the **Audits** table, containing the username, timestamp of acceptance, and other relevant information.
|
||||
|
||||
### Why isn't this feature in Team Edition for GDPR compliance?
|
||||
|
||||
Terms of service is presented to users on login and account creation, and available to users at all times in the link available by going to **System Console \> Site Configuration \> Customization**.
|
||||
|
||||
This feature is intended to meet compliance requirements for large Enterprise companies.
|
||||
120
docs/main/administration-guide/comply/data-retention-policy.mdx
Normal file
120
docs/main/administration-guide/comply/data-retention-policy.mdx
Normal file
@@ -0,0 +1,120 @@
|
||||
---
|
||||
title: "Data retention policy"
|
||||
---
|
||||
<PlanAvailability slug="ent-plus" />
|
||||
|
||||
Mattermost stores all message history providing an unlimited search history to system admins and end users.
|
||||
|
||||
Mattermost Enterprise customers can set a global retention policy as well as custom retention policies to manage how long messages and file uploads are kept in Mattermost channels and direct messages in order to meet data retention compliance requirements.
|
||||
|
||||
<Warning>
|
||||
|
||||
- By default, Mattermost uses a “soft delete” system where messages and files deleted based on user actions are removed from the user interface, but persist in the Mattermost database.
|
||||
- Once a message or a file is permanently deleted, the action is irreversible. We recommend using caution when setting up global or custom data retention policies to avoid data loss.
|
||||
|
||||
</Warning>
|
||||
|
||||
## Configure a global data retention policy
|
||||
|
||||
To set a global data retention policy:
|
||||
|
||||
1. Go to **System Console \> Compliance \> Data Retention Policies**.
|
||||
2. Select **Edit** from the menu located to the right of the **Global retention policy** table.
|
||||
3. Specify a global retention policy for channel messages and direct messages by selecting a **Channel & direct message retention** option from the dropdown, then set how long to keep those messages in hours, days, or years. When a time is set, messages and file attachments older than the duration you set will be deleted. The minimum retention period is one hour.
|
||||
4. Select a **File retention** option from the dropdown. Set the number of hours, days, or years to keep files. When a time is set, uploaded files which are older than the duration you set will be deleted from your file storage system (either from your local disk or your Amazon S3 service as specified in **System Console \> Environment \> File Storage**). The minimum retention period is one hour. The global file policy deletes all files regardless of whether they're in a direct message, private, or public channel.
|
||||
5. From Mattermost v10.10, you can optionally preserve pinned posts when data retention policies delete messages by enabling [Preserve pinned posts](/administration-guide/configure/compliance-configuration-settings#preserve-pinned-posts). Once enabled, pinned posts won't be deleted even if they exceed the configured retention period.
|
||||
6. Under the **Policy log** section, select **Edit** to specify the start time of the daily scheduled data retention job. Choose a time when fewer people are using your system.
|
||||
|
||||
Select **Save**. Messages and files older than the duration you set will be deleted at the specified server time, as applicable.
|
||||
|
||||
## Configure a custom data retention policy
|
||||
|
||||
To set a custom data retention policy:
|
||||
|
||||
1. Go to **System Console \> Compliance \> Data Retention Policies**.
|
||||
2. Select **Add policy** to the right of the **Custom retention policies** table.
|
||||
3. Specify a name for your policy.
|
||||
4. Specify a custom retention policy for channel and direct messages by selecting a **Channel & direct message retention** option from the dropdown, then set how long to keep uploaded files in days or years. When a time is set, messages and file attachments older than the duration you set will be deleted. The minimum retention period is one day.
|
||||
5. Assign teams and channels to this policy by selecting **Add teams** and searching for a specific team, or by selecting **Add channels** and searching for a specific channel. If only teams are specified, all channels for selected teams will be included in the a policy.
|
||||
6. Under the **Policy log** section, select **Edit** to specify the start time of the daily scheduled data retention job. Choose a time when fewer people are using your system. If a time is already set for a global retention policy, then the same time applies to custom data retention policies.
|
||||
|
||||
Save the settings. Messages and files older than the duration you set will be deleted at the specified server time, as applicable.
|
||||
|
||||
## Run a deletion job manually
|
||||
|
||||
You can also run the deletion job manually at any time by selecting **Run Deletion Job Now** in **System Console \> Compliance \> Data Retention Policy**.
|
||||
|
||||
<Note>
|
||||
|
||||
If using data retention with [ElasticSearch](/deployment-guide/scale/elasticsearch-setup), ensure the [ElasticSearch aggregate search indexes](/administration-guide/configure/environment-configuration-settings#aggregate-search-indexes) setting is set to a value that is greater than your data retention policy in days.
|
||||
|
||||
</Note>
|
||||
|
||||
## Frequently Asked Questions (FAQs)
|
||||
|
||||
### What happens when a message is deleted?
|
||||
|
||||
The message is removed from the Mattermost user interface and deleted from the `Posts` table. The message is no longer searchable and cannot be retrieved in saved posts lists.
|
||||
|
||||
Replies that did not exceed the message duration are still displayed in the user interface. However, further replies are no longer possible.
|
||||
|
||||
If there was a file attached to the message, it will be removed from the user interface only.
|
||||
|
||||
### Why can I still see messages that were supposedly deleted?
|
||||
|
||||
The web and desktop app cache posts. Posts deleted by a data retention job will be visible to end users until they clear their cache and refresh.
|
||||
|
||||
### What happens when a file is deleted by the file retention policy?
|
||||
|
||||
The file attachment is removed from the Mattermost user interface, deleted from the `FileInfo` table, and from your local disk or Amazon S3 service as specified in **System Console \> Environment \> File Storage**.
|
||||
|
||||
### Why do I see `Pending` in the deletion job table with no details?
|
||||
|
||||
This usually means another data retention job is in progress. You can verify this in the deletion job table in **System Console \> Compliance \> Data Retention Policy**.
|
||||
|
||||
### How is data retention handled in the mobile apps?
|
||||
|
||||
When messages or files are deleted, they are no longer searchable in the Mattermost mobile apps.
|
||||
|
||||
In v1.5 and later of the iOS and Android apps, messages and files are deleted from local storage in the following cases, if they exceed the retention policy duration:
|
||||
|
||||
1. When the user opens the app.
|
||||
2. When the user puts the app into the background.
|
||||
|
||||
In v1.4 and earlier of the mobile apps, messages and files are not cleared from local storage when the data retention policy is enabled.
|
||||
|
||||
### How do I know if a data retention job fails?
|
||||
|
||||
Mattermost provides the status of each data retention job in **System Console** \> **Compliance** \> **Data Retention Policy**. Here, you can see if the job succeeded or failed, including the details of the error.
|
||||
|
||||
Additionally, any failures are returned in the server logs. The error log begins with the string `Failed job` and includes a job_id key/value pair. Data retention job failures are identified with worker name `EnterpriseDataRetention`. You can optionally create a script that programmatically queries for such failures and notifies the appropriate system.
|
||||
|
||||
### What happens when the data retention period is changed?
|
||||
|
||||
Data retention runs once a day at the time specified in the `config.json` file. Changing the retention period does not automatically schedule any additional run of the data retention job - it only updates how long data is kept in Mattermost.
|
||||
|
||||
### Does the system administrator get any notification when the data retention period is changed?
|
||||
|
||||
No, the new config is updated, but the system admin does not receive any feedback on what the effects will be (e.g. reporting of how many messages are to be deleted).
|
||||
|
||||
### Does the data retention job affect the audits table?
|
||||
|
||||
Prior to v5.20, data retention would delete all user activity corresponding to the data retention time configuration. From v5.20, the audit table will retain the user activity corresponding to the data retention time configuration.
|
||||
|
||||
### Does the data retention job include archived channels?
|
||||
|
||||
Posts and attachments in archived channels are affected by the data retention job. If a post exceeds the age configured for the data retention job it will be deleted from the database.
|
||||
|
||||
### How long does it take to run a deletion query and does it affect server performance?
|
||||
|
||||
Data retention runs the actual deletion query in batches, deleting data in blocks of 1000 records per query. This is so the database won’t be locked up for extended periods of time with long-running queries. Keeping to this limit keeps the query down to a few milliseconds' execution time on the database itself.
|
||||
|
||||
Each batch of data is deleted based on indexes - making the queries quick to execute on small batches. This helps the server remain fully responsive while the process is running.
|
||||
|
||||
### How do I know whether the data retention job is running/scheduled?
|
||||
|
||||
The job scheduler runs the data retention job based on the time specified in the configuration settings. At this time a `DEBUG`-level log line is printed: `Scheduling data retention job`.
|
||||
|
||||
When a job server picks up that scheduled job for execution, a `DEBUG`-level log line is generated: `Worker EnterpriseDataRetention: Received a new candidate job`.
|
||||
|
||||
When the job is complete, an `INFO`-level log line is generated: `Worker EnterpriseDataRetention: Job is complete`.
|
||||
113
docs/main/administration-guide/comply/electronic-discovery.mdx
Normal file
113
docs/main/administration-guide/comply/electronic-discovery.mdx
Normal file
@@ -0,0 +1,113 @@
|
||||
---
|
||||
title: "Electronic discovery"
|
||||
---
|
||||
<PlanAvailability slug="ent-plus" />
|
||||
|
||||
Electronic discovery (also known as eDiscovery) refers to a process where electronic data is searched with the intent to use it as evidence in a legal case.
|
||||
|
||||
This page describes how to extract data from Mattermost for eDiscovery. There are three primary methods that can be used to accomplish the goal of extracting user post data from Mattermost:
|
||||
|
||||
- [Mattermost Compliance Exports](/administration-guide/comply/compliance-export)
|
||||
- [Mattermost RESTful API](/administration-guide/comply/electronic-discovery#mattermost-restful-api)
|
||||
- [Mattermost database using standard SQL queries](/administration-guide/comply/electronic-discovery#mattermost-database)
|
||||
|
||||
Each of the options is discussed in detail below.
|
||||
|
||||
<Note>
|
||||
|
||||
Litigation hold (also known as legal hold) is an extension of eDiscovery where in addition to searching for records, no electronically stored information nor paper documents may be discarded if they may be deemed relevant for a present or future legal case.
|
||||
|
||||
</Note>
|
||||
|
||||
## Mattermost compliance exports
|
||||
|
||||
Mattermost Enterprise has compliance report export capabilities.
|
||||
|
||||
Mattermost can export compliance related data, including the content of messages and who might have seen those messages, in three formats: Actiance XML, Global Relay EML, and generic CSV. Reports can be configured to run on a delay basis and stored in a shared location.
|
||||
|
||||
For more information about the exports feature and how to set up reporting, see [our documentation](/administration-guide/comply/compliance-export).
|
||||
|
||||
## Mattermost RESTful API
|
||||
|
||||
The Mattermost API can be used to export a user's posts in CSV compliance format that is part of Mattermost Enterprise. The following section outlines how to use the API to create and retrieve a report for a specific user via the API. Please note that full documentation for the Mattermost API can be found at [https://api.mattermost.com](https://api.mattermost.com).
|
||||
|
||||
To use the API, you must first authenticate [as described here](https://api.mattermost.com/#tag/authentication). The account you are authenticating with must have `manage_system` permissions. If you are using curl, you can authenticate using the following command:
|
||||
|
||||
``` sh
|
||||
curl -i -d '{"login_id": "username", "password": "password"}' https://yourmattermosturl/api/v4/users/login
|
||||
```
|
||||
|
||||
Mattermost will return a response that looks like this:
|
||||
|
||||
``` text
|
||||
HTTP/2 200
|
||||
server: nginx/1.10.3 (Ubuntu)
|
||||
date: Thu, 12 Jul 2018 14:43:45 GMT
|
||||
content-type: application/json
|
||||
content-length: 679
|
||||
set-cookie: MMAUTHTOKEN=yi94pwci6ibjfc9phbikhqutbe; Path=/; Expires=Sat, 11 Aug 2018 14:43:45 GMT; Max-Age=2592000; HttpOnly; Secure
|
||||
set-cookie: MMUSERID=qfjzamfg47bu9gsyyfbqjk4s6a; Path=/; Expires=Sat, 11 Aug 2018 14:43:45 GMT; Max-Age=2592000; Secure
|
||||
token: yi94pwci6ibjfc9phbikhqutbe
|
||||
x-request-id: 5y45pxyfxpb8updtge1zts39he
|
||||
x-version-id: 5.0.0.5.0.1.18c0fbd759664a85fe95132bb7fc04cf.true
|
||||
```
|
||||
|
||||
Include the `token` value sent in the response as part of the Authorization header on your future API requests with the Bearer method, e.g.:
|
||||
|
||||
``` sh
|
||||
curl -i -H 'Authorization: Bearer yi94pwci6ibjfc9phbikhqutbe' https://yourmattermosturl/api/v4/users/me
|
||||
```
|
||||
|
||||
Once you're authenticated into Mattermost, you can use the [Compliance API to create a new compliance report](https://api.mattermost.com/#tag/compliance%2Fpaths%2F~1compliance~1reports%2Fpost). The curl based example below demonstrates how to send a request that bases the authentication token and asks Mattermost to create a report that spans posts from Dec 31, 2017 - 8:15 PM to Dec 31, 2018 - 8:15 PM for a user with the email address [craig@mattermost.com](mailto:craig@mattermost.com):
|
||||
|
||||
<Note>
|
||||
|
||||
The data in the JSON payload must be formatted as Unix Epoch. A tool like [https://www.epochconverter.com/](https://www.epochconverter.com/) can be useful when converting to and from the required format.
|
||||
|
||||
</Note>
|
||||
|
||||
``` sh
|
||||
curl --header "Content-Type: application/json" \
|
||||
--request POST \
|
||||
-H 'Authorization: Bearer yi94pwci6ibjfc9phbikhqutbe' \
|
||||
--data '{"id":"","create_at":0,"user_id":"craig","status":"","count":0,"desc":" ","type":"","start_at":1514769359000,"end_at": 1546305359000,"keywords":"","emails":"craig@mattermost.com"}' \
|
||||
https://yourmattermosturl/api/v4/compliance/reports
|
||||
```
|
||||
|
||||
If the post is successful, Mattermost will return a message that looks like the following, indicating that the server is running the compliance export process:
|
||||
|
||||
``` json
|
||||
{"id":"du6kektczifqxexeroywpz3nbc"," create_at":1531444617901, "user_id":"qfjzamfg47bu9gsyyfbqjk4s6a", "status":"running", "count":0, "desc":" ", "type":"adhoc", "start_at":1514769359000, "end_at":1546305359000, "keywords":"", "emails":"craig@mattermost.com"}
|
||||
```
|
||||
|
||||
When the export process is complete (the execution time is based on the number of records to return and the current server load), you will need to send another HTTP Post request to Mattermost to retrieve and download a zip file containing the report that looks like the following curl request:
|
||||
|
||||
``` sh
|
||||
curl --request GET \
|
||||
-H 'Authorization: Bearer p9o1qx457fbc9gdrn39z9ah59o' \
|
||||
--data '{"status_code":0,"id":"du6kektczifqxexeroywpz3nbc","message":"","requestion_id":""}' \
|
||||
--output report-zip.zip \
|
||||
https://yourmattermosturl/api/v4/compliance/reports/du6kektczifqxexeroywpz3nbc/download
|
||||
```
|
||||
|
||||
When sending the request, you need to get the report ID from the response returned by Mattermost when the report was created. You also need to supply a name to save that file as. In the example above, the file will be saved as `report-zip.zip`.
|
||||
|
||||
## Mattermost database
|
||||
|
||||
Selecting messages from the Mattermost database using standard SQL is quite easy. If you know the username, the following query can be used to select all messages for the specified user:
|
||||
|
||||
``` sql
|
||||
SELECT * FROM mattermost.Posts WHERE UserId = (SELECT Id FROM mattermost.Users WHERE Username = 'username');
|
||||
```
|
||||
|
||||
If you want to limit the results of the query based on the date and time that the messages were posted, you can modify the above query to:
|
||||
|
||||
``` sql
|
||||
SELECT * FROM mattermost.Posts WHERE UserId = (SELECT Id FROM mattermost.Users WHERE Username = 'username' AND CreateAt > 1530405832000 AND CreateAt < 1532997832000);
|
||||
```
|
||||
|
||||
<Note>
|
||||
|
||||
The Mattermost database stores date and time stamps in the [Unix Epoch](https://en.wikipedia.org/wiki/Unix_time) format. A tool like the [Epoch Converter](https://www.epochconverter.com/) can be useful in converting to and from the required format.
|
||||
|
||||
</Note>
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,43 @@
|
||||
---
|
||||
title: "Export channel data"
|
||||
---
|
||||
import useBaseUrl from '@docusaurus/useBaseUrl';
|
||||
|
||||
<PlanAvailability slug="ent-plus" />
|
||||
|
||||
Ensure important data isn't trapped in silos by migrating data between systems or backing data up for operational continuity. Once exported, channel data can be analyzed using various tools for insights into team dynamics, productivity, and communication patterns, and to fulfill reporting and auditability requirements.
|
||||
|
||||
## Enable
|
||||
|
||||
<Note>
|
||||
|
||||
For Mattermost Cloud deployments, no setup is required. See the [usage](#usage) section below for details on exporting channel data.
|
||||
|
||||
</Note>
|
||||
|
||||
For self-hosted deployments, a Mattermost system admin must install the Channel Export integration from the in-product App Marketplace:
|
||||
|
||||
1. In Mattermost, from the Product menu <img src={useBaseUrl('/img/ui/products_E82F.svg')} alt="Navigate between Channels, collaborative playbooks, and boards using the product menu icon." className="theme-icon" />, select **App Marketplace**.
|
||||
2. Search for or scroll to **Channel Export**, and select **Install**.
|
||||
3. Once installed, select **Configure**. You're taken to the System Console.
|
||||
4. On the **Channel Export** configuration page, enable and configure the plugin, and then select **Save**. You can restrict the ability to export channels to system, team, and channel admins only, and you can configure a maximum file size for channel export files.
|
||||
|
||||
## Upgrade
|
||||
|
||||
We recommend upgrading this feature as new versions are released. Generally, updates are seamless and don't interrupt the user experience in Mattermost. Visit the [Releases page](https://github.com/mattermost/mattermost-plugin-channel-export/releases) for the latest release, available releases, and compatibiilty considerations.
|
||||
|
||||
## Usage
|
||||
|
||||
You need to be a Mattermost system admin to export channel data.
|
||||
|
||||
Use the `/export` slash command in a channel to export the current channel's message data into a CSV-formatted file.
|
||||
|
||||
## Get help
|
||||
|
||||
Mattermost customers can open a [Mattermost support case](https://support.mattermost.com/hc/en-us/requests/new). To report a bug, please open a GitHub issue against the [Mattermost Channel Export plugin GitHub repository](https://github.com/mattermost/mattermost-plugin-channel-export).
|
||||
|
||||
For questions, feedback, and assistance, join our pubic [Integrations and Apps channel](https://community.mattermost.com/core/channels/integrations) on the [Mattermost Community Server](https://community.mattermost.com/) for assistance.
|
||||
|
||||
## Customize this integration
|
||||
|
||||
This plugin contains both a server and web app portion. See the [Channel Export plugin README documentation](https://github.com/mattermost/mattermost-plugin-channel-export?tab=readme-ov-file#development) on GitHub for details. Visit the [Mattermost Developer Workflow](https://developers.mattermost.com/extend/plugins/developer-workflow/) and [Mattermost Developer environment setup](https://developers.mattermost.com/extend/plugins/developer-setup/) for information about developing, customizing, and extending Mattermost functionality.
|
||||
200
docs/main/administration-guide/comply/legal-hold.mdx
Normal file
200
docs/main/administration-guide/comply/legal-hold.mdx
Normal file
@@ -0,0 +1,200 @@
|
||||
---
|
||||
title: "Legal hold"
|
||||
---
|
||||
import useBaseUrl from '@docusaurus/useBaseUrl';
|
||||
|
||||
<PlanAvailability slug="ent-plus" />
|
||||
|
||||
A Legal Hold, also known as a litigation hold, is a process that an organization uses to preserve all forms of relevant information when litigation is reasonably anticipated. It's a requirement established by the Federal Rules of Civil Procedure (FRCP) in the United States and similar laws in other jurisdictions.
|
||||
|
||||
Primary use cases include:
|
||||
|
||||
1. **Litigation**: In anticipation or in the event of a lawsuit, organizations need to preserve all relevant documents and electronic data to ensure they can adequately defend their position. A failure to do so could result in court penalties.
|
||||
2. **Regulatory investigation**: If an organization is being investigated by a regulatory body, it may be required to preserve and produce certain documents or data.
|
||||
3. **Audits**: During an audit, whether internal or external, an organization might need to put a hold on certain data that is relevant to the audit.
|
||||
4. **Records management**: In some cases, organizations might use a Legal Hold to temporarily suspend the deletion of data that would otherwise be purged as part of its records management policy.
|
||||
|
||||
Mattermost is used as a secure collaboration hub by technical and operational teams, with critical documents and data shared on a daily basis. Thus, Legal Hold is a key requirement for Enterprises and public sector organizations who have deployed Mattermost for their teams, to meet compliance & auditory requirements while minimizing risk.
|
||||
|
||||
Mattermost Legal Hold can be combined with [eDiscovery](/administration-guide/comply/electronic-discovery) integration and [data retention policies](/administration-guide/comply/data-retention-policy) to customize the data retained and deleted to comply with compliance requirements.
|
||||
|
||||
## Legal Hold demo (Sneak Peek)
|
||||
|
||||
Check out this [YouTube sneak peek demo](https://www.youtube.com/watch?v=86c8NoOxlQw&feature=youtu.be) to learn about Mattermost's Legal Hold workflow.
|
||||
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/86c8NoOxlQw" alt="Mattermost Legal Hold workflow" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
|
||||
|
||||
Below are step-by-step instructions on how to carry out a Legal Hold for Mattermost using the Mattermost Legal Hold plugin.
|
||||
|
||||
## How to carry out a Legal Hold
|
||||
|
||||
### Step 1: Upgrade to Mattermost Enterprise
|
||||
|
||||
Legal Hold is available in [Mattermost Enterprise](/product-overview/editions-and-offerings#mattermost-enterprise-edition). Learn more about the Enterprise plan & request a quote online at [https://mattermost.com/pricing/](https://mattermost.com/pricing/)
|
||||
|
||||
### Step 2: Establish a Legal Hold policy
|
||||
|
||||
Establish a policy for when to implement a Legal Hold. This should be developed in consultation with your legal counsel and should include procedures for identifying relevant users (those who have potentially relevant information).
|
||||
|
||||
Establishing a Legal Hold policy first enables you to configure the Mattermost system correctly to meet your compliance & auditory requirements, minimizing associated risk.
|
||||
|
||||
### Step 3: Set up the Mattermost Legal Hold plugin
|
||||
|
||||
#### Install the plugin
|
||||
|
||||
1. Log in to your Mattermost [workspace](/end-user-guide/end-user-guide-index) as a system administrator.
|
||||
2. Download the latest version of the [plugin binary release](https://github.com/mattermost/mattermost-plugin-legal-hold/releases/), compatible with Mattermost v8.0.1 and later. If you are using an earlier version of Mattermost, [follow our documentation](/administration-guide/upgrade/upgrading-mattermost-server) to upgrade to Mattermost v8.0.1 or later.
|
||||
3. Go to **System Console \> Plugins \> Plugin Management \> Upload Plugin**, and upload the plugin binary you downloaded in the previous step.
|
||||
4. In the **Installed Plugins** section, scroll to **Legal Hold Plugin**, and select **Enable**.
|
||||
|
||||
#### Configure the plugin
|
||||
|
||||
When the Legal Hold integration is enabled, you can configure when it runs using the format `HH:MM ±HHMM` and `+0000` for UTC.
|
||||
|
||||
You can configure a custom Amazon S3 bucket for Legal Holds by specifying Amazon S3 configuration settings. If no S3 configuration is specified, the Mattermost server file store used. Learn more about file storage configuration options in our [product documentation](/administration-guide/configure/environment-configuration-settings#file-storage).
|
||||
|
||||
#### (Optional) Configure a data retention policy
|
||||
|
||||
You can optionally configure a [data retention policy](/administration-guide/comply/data-retention-policy) to control how long data and file attachments are retained in the Mattermost database.
|
||||
|
||||
### Step 4: Create a Legal Hold
|
||||
|
||||
In Mattermost, create a Legal Hold by completing the following steps:
|
||||
|
||||
1. Go to **System Console \> Plugins \> Legal Hold Plugin**, and select **Create new**.
|
||||
2. Enter a name for the Legal Hold.
|
||||
3. Specify the user names or user groups of users you want to place on Legal Hold.
|
||||
4. (Optional) Public channels are excluded by default. You can choose to include public channels that the specified users or user groups are members of, if preferred; however, doing so will significantly increase the amount of data held based on the number public channels available.
|
||||
5. Specify the number of days that users are placed in Legal Hold with a start date. An end date is optional.
|
||||
6. Select **Create Legal Hold**. [Downloadable data](#download-legal-hold-data) won't be available until the next scheduled job runs.
|
||||
|
||||
#### Manage Legal Holds
|
||||
|
||||
While a Legal Hold is in place, you can edit details of the Legal Hold, access the Legal Hold Secret, as well as download a copy of the preserved data to your local machine.
|
||||
|
||||

|
||||
|
||||
##### Edit a Legal Hold
|
||||
|
||||
Select the **Edit** <img src={useBaseUrl('/img/ui/edit-on-github.png')} alt="Contribute to Mattermost documentation by selecting the Edit option located in the top right corner of any documentation page." className="theme-icon" /> icon to change the name of the Legal Hold, add or remove users, change the end date, as well as include or exclude public channels.
|
||||
|
||||
##### Access a Legal Hold secret
|
||||
|
||||
A Legal Hold secret enables you to verify the authenticity of the data for a Legal Hold in Mattermost.
|
||||
|
||||
Select the **Show** <img src={useBaseUrl('/img/ui/eye-outline_F06D0.svg')} alt="Review your message text formatting using the Show/Hide preview icon in the message formatting toolbar." className="theme-icon" /> icon to display the Legal Hold secret key. Keep a copy of this key in a secure location.
|
||||
|
||||

|
||||
|
||||
To verfiy the contents of the files in this Legal Hold, you must append the processor command with the following flag: `--legal-hold-secret <KEY>`. The output verifies the file and returns the authenticity state of files along with the rest of the output for the processor, as follows:
|
||||
|
||||
Success:
|
||||
|
||||
``` text
|
||||
Secret key was provided, verifying legal holds...
|
||||
- Verifying Legal Hold *processor9*: Verified
|
||||
```
|
||||
|
||||
Error:
|
||||
|
||||
``` text
|
||||
...
|
||||
Secret key was provided, verifying legal holds...
|
||||
- Verifying Legal Hold *processor9*: [Error] hash mismatch for file: legal_hold/processor9_i7k1dbkipiyojeess6ozi4agyr/index.json
|
||||
...
|
||||
```
|
||||
|
||||
##### Download Legal Hold data
|
||||
|
||||
Select the **Download** <img src={useBaseUrl('/img/ui/download-outline_F0B8F.svg')} alt="Use the Download icon to download an attached file to your local system." className="theme-icon" /> icon to download a copy of the preserved data to a location on your local machine. Note, no data will be available to download until at least one scheduled job is completed. This may take up to 24 hours.
|
||||
|
||||
### Step 5: Release a Legal Hold
|
||||
|
||||
Once the Legal Hold has completed, release it to take users off of the Legal Hold by selecting the **Release** option to the right of the Legal Hold task.
|
||||
|
||||
<Important>
|
||||
|
||||
Once a Legal Hold is released, all data is irretrievably deleted from Mattermost and can't be recovered.
|
||||
|
||||
</Important>
|
||||
|
||||
## Frequently asked questions
|
||||
|
||||
### Who can implement Legal Hold?
|
||||
|
||||
Only Mattermost system admins can implement a Legal Hold.
|
||||
|
||||
### Does a user know if they're placed under a Legal Hold in Mattermost?
|
||||
|
||||
No, users won't be notified if they're placed under a Legal Hold, and no reference to Legal Holds will be visible in their Mattermost client or accessible via the Mattermost API. This allows for investigations to be conducted without influencing user behavior and without conflicts of interest.
|
||||
|
||||
### What types of content does Legal Hold cover?
|
||||
|
||||
The Legal Hold covers all messages and file uploads shared in conversations where the Legal Hold is active, including messages posted by plugins, bots or webhooks. This includes messages or files shared in public channels, private channels, direct messages and group messages.
|
||||
|
||||
However, Legal Hold does not apply to reactions, collaborative playbooks, or audio calls.
|
||||
|
||||
### Can users delete their messages while on a Legal Hold?
|
||||
|
||||
Yes, users can delete messages, but they are retained for the purposes of Legal Hold when implemented with the aforementioned steps.
|
||||
|
||||
### Can a Legal Hold be applied retroactively to collect past data?
|
||||
|
||||
Yes, but this is only guaranteed for existing and future messages/files once Legal Hold is activated. It won't recover messages or files that were deleted before the Legal Hold was activated.
|
||||
|
||||
### Is Legal Hold the same as e-discovery?
|
||||
|
||||
No. While they serve a related use case, they are not the same.
|
||||
|
||||
Legal Hold is an initial step to ensure relevant electronically stored information (ESI) is preserved. On the other hand, e-discovery is a multi-step process that uses this preserved data to identify, collect, preserve, process, review, and produce ESI in the context of a legal or investigative process.
|
||||
|
||||
### How do I enable e-discovery for Mattermost?
|
||||
|
||||
Learn more about extracting data for e-discovery in our [product documentation](/administration-guide/comply/electronic-discovery).
|
||||
|
||||
### How do I manage storage costs and version retention in S3?
|
||||
|
||||
If you plan to use an existing S3 bucket for Legal Hold data storage, and your existing S3 bucket has versioning enabled, we strongly recommend using a dedicated S3 bucket with versioning disabled.
|
||||
|
||||
The Legal Hold plugin frequently modifies files in the `legalhold` directory, and when S3 bucket versioning is enabled, each modification creates a new version. This can result in a rapid accumulation of object versions, increased storage costs, potential performance impact, higher S3 API usage, and complicating version management over time. See the [S3 Lifecycle Rules](https://docs.aws.amazon.com/AmazonS3/latest/dev/object-lifecycle-mgmt.html) documentation for additional details.
|
||||
|
||||
### How to view the downloaded Legal Hold zip file
|
||||
|
||||
To make use of the Legal Hold data, you use the [processor tool](https://github.com/mattermost/mattermost-plugin-legal-hold/releases#:~:text=processor%2Dv1.0.2%2Ddarwin%2Damd64) available on the Mattermost GitHub repository. This will output a self-contained HTML site you can open with your browser.
|
||||
|
||||
**Download and setup the processor tool:**
|
||||
|
||||
1. Download the appropriate processor binary for your platform from the [GitHub releases page](https://github.com/mattermost/mattermost-plugin-legal-hold/releases).
|
||||
2. On macOS and Linux, make the processor executable:
|
||||
|
||||
``` bash
|
||||
$ chmod +x processor-vX.X.X-<platform> # Replace with the actual filename you downloaded
|
||||
```
|
||||
|
||||
**Usage:**
|
||||
|
||||
``` bash
|
||||
$ ./processor --legal-hold-data ./legalholddata.zip --output-path ./path/to/where/you/want/the/html/output --legal-hold-secret "your secret"
|
||||
```
|
||||
|
||||
**Arguments:**
|
||||
|
||||
- `--legal-hold-data`: Path to the Legal Hold zip file downloaded from Mattermost
|
||||
- `--output-path`: Directory where the HTML output will be generated
|
||||
- `--legal-hold-secret`: (Optional) Used as a security measure for an operator to ensure the authenticity of a downloaded zip file. The operator can copy the key corresponding to a particular "hold" from the Legal Hold Plugin settings page in the System Console by selecting the **Show** <img src={useBaseUrl('/img/ui/eye-outline_F06D0.svg')} alt="Review your message text formatting using the Show/Hide preview icon in the message formatting toolbar." className="theme-icon" /> icon next to the Legal Hold entry.
|
||||
|
||||
### Is data gathered when a channel has been archived?
|
||||
|
||||
Yes. Filtering isn't done based on archive or deleted status. However, archived channels can be permanently deleted based on Data Retention settings, at which point they will no longer appear in legal hold reports.
|
||||
|
||||
### Is data gathered when a user was a member of a channel for a period of time but has since left the channel?
|
||||
|
||||
Yes. Channels are included when a target user was a member at any time during the legal hold start and end dates.
|
||||
|
||||
### Is data gathered from a direct message or group message with a user who has since been deactivated?
|
||||
|
||||
Yes. Filtering isn't done based on user deactivation state.
|
||||
|
||||
### Is data collected from group messages?
|
||||
|
||||
Yes. Data is collected from group messages like any public or private channel or direct message.
|
||||
@@ -0,0 +1,21 @@
|
||||
---
|
||||
title: "Mattermost Agents Admin Guide"
|
||||
---
|
||||
import AgentsAdminGuideBody from '../../agents/docs/_admin_guide_partial.mdx';
|
||||
|
||||
<PlanAvailability slug="all-commercial" />
|
||||
|
||||
<AgentsAdminGuideBody />
|
||||
|
||||
## Additional configuration guides
|
||||
|
||||
- [Configure Agents with AWS Bedrock](/agents/docs/aws_bedrock_setup)
|
||||
|
||||
<Tip>
|
||||
|
||||
- To access the contents of files using Agents, a Mattermost system admin must [enable document search by content](/administration-guide/configure/environment-configuration-settings#enable-document-search-by-content) in the System Console.
|
||||
- Looking for demo? [Try it yourself](https://mattermost.com/demo/copilot/)!
|
||||
- Download the [Mattermost datasheet](https://mattermost.com/mattermost-copilot-datasheet/) to learn more about integrating with industry-leading large language models (LLMs).
|
||||
- Mattermost Agents is formerly known as Mattermost Copilot.
|
||||
|
||||
</Tip>
|
||||
File diff suppressed because it is too large
Load Diff
200
docs/main/administration-guide/configure/azure-blob-storage.mdx
Normal file
200
docs/main/administration-guide/configure/azure-blob-storage.mdx
Normal file
@@ -0,0 +1,200 @@
|
||||
---
|
||||
title: "Configure Azure Blob Storage as the Mattermost file store"
|
||||
---
|
||||
<PlanAvailability slug="all-commercial" />
|
||||
|
||||
Mattermost can store user uploads -- attachments, profile images, plugin assets, emoji, compliance exports -- in an Azure Storage account. This guide walks an administrator through the steps to provision the Azure side and point a Mattermost server at it via the System Console.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- An Azure subscription with a storage account and a container already created.
|
||||
- Either the Azure portal, or the [Azure CLI](https://learn.microsoft.com/en-us/cli/azure/install-azure-cli) (`az`) installed and signed in with `az login`. Both are documented below.
|
||||
- A Mattermost deployment (v11.9 or later) with System Console access for a System Admin account.
|
||||
|
||||
If you plan to migrate existing files from another backend, take a backup of the current storage location (S3 bucket, local disk, etc.) before changing the configuration. Switching the file driver does not migrate existing files automatically.
|
||||
|
||||
## Step 1: Choose an authentication mode
|
||||
|
||||
Mattermost supports two ways for the server to authenticate to Azure. Pick the one that fits how the server runs:
|
||||
|
||||
- **Shared key**: the server signs each request with the [Storage Account access key](/administration-guide/configure/environment-configuration-settings#azure-storage-account-key). Works anywhere Mattermost runs (on-premises, non-Azure cloud, local development) because it does not depend on the host having an Azure identity. The trade-off is that the key is a long-lived secret stored in `config.json`.
|
||||
- **Default credential (Microsoft Entra ID)**: the server obtains a token from Microsoft Entra ID and signs requests with it. No long-lived secret in Mattermost configuration. This is the recommended mode for deployments running on Azure, where the host environment already provides an identity (managed identity on Azure VM / App Service / AKS, workload identity for federated workloads, or a service principal).
|
||||
|
||||
The Azure-side setup differs slightly between the two modes. Follow the subsection that matches your choice; you can switch modes later by changing the [Azure authentication](/administration-guide/configure/environment-configuration-settings#azure-authentication) setting in the System Console.
|
||||
|
||||
### Option A: Shared key
|
||||
|
||||
Retrieve the Storage Account access key.
|
||||
|
||||
**Azure portal**
|
||||
|
||||
1. Open the storage account, then **Security + networking** > **Access keys**.
|
||||
2. Select **Show** next to `key1` (or `key2`) and copy the value.
|
||||
|
||||
**Azure CLI**
|
||||
|
||||
```bash
|
||||
az storage account keys list \
|
||||
--account-name acmemattermost \
|
||||
--resource-group mm-prod-files \
|
||||
--query "[0].value" -o tsv
|
||||
```
|
||||
|
||||
<Note>
|
||||
|
||||
Treat the shared key as a secret -- anyone with it has full access to the storage account (every container and all data it holds). A shared key can't be scoped to a single container, to specific operations, or to a resource group; if you need least-privilege access, use [Option B: Default credential (Microsoft Entra ID)](#option-b-default-credential-microsoft-entra-id) with a container-scoped **Storage Blob Data Contributor** role instead. Azure provides two keys so you can rotate without downtime: update Mattermost to `key2`, regenerate `key1`, then swap on the next rotation cycle. Plan a rotation cadence that matches your organisation's policy.
|
||||
|
||||
</Note>
|
||||
|
||||
### Option B: Default credential (Microsoft Entra ID)
|
||||
|
||||
The server uses `DefaultAzureCredential` from the Azure SDK, which discovers a working identity at runtime in this order. The first source that returns a token is used.
|
||||
|
||||
1. `EnvironmentCredential` -- service-principal environment variables.
|
||||
2. `WorkloadIdentityCredential` -- federated workload identity.
|
||||
3. `ManagedIdentityCredential` -- the platform-provided managed identity.
|
||||
4. `AzureCLICredential` -- the signed-in `az` session, useful for local development.
|
||||
|
||||
Whichever identity the SDK selects, **that** identity needs **Storage Blob Data Contributor** (or a custom role with the equivalent `read/write/list/delete` data-plane actions) on the storage account or container. Without it, `TestConnection` returns `AuthorizationPermissionMismatch`.
|
||||
|
||||
Pick the identity source that matches the host:
|
||||
|
||||
| Host | Identity source |
|
||||
|:---|:---|
|
||||
| Azure VM, App Service, AKS, Container Apps | Assign a **system-assigned** or **user-assigned managed identity** to the compute resource. `DefaultAzureCredential` resolves to `ManagedIdentityCredential` with no extra configuration. For user-assigned identities, set `AZURE_CLIENT_ID` in the server's environment so the SDK picks the right one. |
|
||||
| AKS with workload-identity federation | Annotate the Mattermost `ServiceAccount` with the client ID and configure the OIDC issuer per the [AKS workload identity guide](https://learn.microsoft.com/en-us/azure/aks/workload-identity-overview). `DefaultAzureCredential` resolves to `WorkloadIdentityCredential`. |
|
||||
| Non-Azure host or container | Create a service principal and set `AZURE_TENANT_ID`, `AZURE_CLIENT_ID`, and `AZURE_CLIENT_SECRET` (or `AZURE_CLIENT_CERTIFICATE_PATH`) in the server's environment. `DefaultAzureCredential` resolves to `EnvironmentCredential`. |
|
||||
| Local development on an admin's workstation | Sign in with `az login`. `DefaultAzureCredential` resolves to `AzureCLICredential`. |
|
||||
|
||||
To prepare the account you're going to use, you'll need to assign the role from the Azure Portal or using the Azure CLI, as shown below (substitute the principal of the identity Mattermost will authenticate as):
|
||||
|
||||
```bash
|
||||
STORAGE_ACCOUNT_ID=$(az storage account show \
|
||||
--name acmemattermost \
|
||||
--resource-group mm-prod-files \
|
||||
--query id -o tsv)
|
||||
|
||||
# For a managed identity (system-assigned on a VM/App Service/AKS pod):
|
||||
az role assignment create \
|
||||
--assignee-object-id "<principalId-of-the-managed-identity>" \
|
||||
--assignee-principal-type ServicePrincipal \
|
||||
--role "Storage Blob Data Contributor" \
|
||||
--scope "$STORAGE_ACCOUNT_ID"
|
||||
|
||||
# For a service principal:
|
||||
az role assignment create \
|
||||
--assignee "<appId-of-the-service-principal>" \
|
||||
--role "Storage Blob Data Contributor" \
|
||||
--scope "$STORAGE_ACCOUNT_ID"
|
||||
```
|
||||
|
||||
<Note>
|
||||
|
||||
Granting the role requires **User Access Administrator** or **Owner** on the storage account; `Contributor` is not enough. Plan to have an administrator with that role run the `az role assignment create` step. If you scope the role to a single container instead of the whole storage account, replace `--scope "$STORAGE_ACCOUNT_ID"` with `--scope "$STORAGE_ACCOUNT_ID/blobServices/default/containers/<container>"`.
|
||||
|
||||
</Note>
|
||||
|
||||
<Tip>
|
||||
|
||||
Azure RBAC role assignments can take 30-120 seconds to propagate. If the first `TestConnection` returns `AuthorizationPermissionMismatch` immediately after the role assignment, wait a minute and retry before assuming a misconfiguration.
|
||||
|
||||
</Tip>
|
||||
|
||||
<Note>
|
||||
|
||||
Mattermost holds the credential, not the token. Microsoft Entra ID access tokens are short-lived, but the Azure SDK caches each token and refreshes it automatically before it expires, so routine token rotation never interrupts file access while the server is running. Access stops only if the underlying identity or its authorization changes or is removed.
|
||||
|
||||
</Note>
|
||||
|
||||
## Step 2: Configure Mattermost
|
||||
|
||||
Sign in as a System Admin and open **System Console > Environment > File Storage**.
|
||||
|
||||
1. **File storage system**: select **Azure Blob Storage**. The Azure-specific fields appear and the S3/local fields are hidden.
|
||||
2. **Azure cloud**: select the Azure cloud that hosts the storage account:
|
||||
|
||||
- **Azure Commercial** (default): the global Azure cloud (`{account}.blob.core.windows.net`). Only the storage account name is required.
|
||||
- **Azure Government**: the US Government cloud (`{account}.blob.core.usgovcloudapi.net`). Only the storage account name is required.
|
||||
- **Custom Endpoint**: any other Azure cloud (for example, Azure China), an Azurite emulator, or a reverse proxy. Provide the full Blob service URL via **Azure endpoint** below.
|
||||
|
||||
3. **Azure Storage account**: the storage account name (for example, `acmemattermost`).
|
||||
4. **Azure container**: the container name (for example, `mattermost`).
|
||||
5. **Azure path prefix**: optional. Set this if you want Mattermost to write under a sub-path inside the container, for example `prod/`. Leave empty to use the container root.
|
||||
6. **Azure authentication**: select the mode you set up in step 1:
|
||||
|
||||
- **Shared key** (default): Mattermost signs each request with the Storage Account access key. Choose this if you completed [Option A: Shared key](#option-a-shared-key).
|
||||
- **Default credential (Microsoft Entra ID)**: Mattermost authenticates as the identity provided by the host environment. Choose this if you completed [Option B: Default credential (Microsoft Entra ID)](#option-b-default-credential-microsoft-entra-id). The **Azure Storage account key** field below is hidden because the access key is not used in this mode.
|
||||
|
||||
7. **Azure Storage account key** (visible only when **Azure authentication** is **Shared key**): paste the shared key from [Option A: Shared key](#option-a-shared-key).
|
||||
8. **Azure endpoint** (visible only when **Azure cloud** is set to **Custom Endpoint**): the full Blob service URL, including scheme and storage account. Mattermost passes this URL to the Azure SDK unchanged, so the storage account must already be embedded in the hostname (vhost-style, for example `https://acmemattermost.blob.core.chinacloudapi.cn/`) or in the path (path-style, for example `http://localhost:10000/devstoreaccount1/` for Azurite). The chosen authentication mode signs against the host this URL points at, so the host must serve the storage account named above.
|
||||
9. **Enable secure Azure Blob Storage connections** (visible only when **Azure cloud** is **Azure Commercial** or **Azure Government**): keep this enabled (the default). The Custom Endpoint cloud determines the scheme from the **Azure endpoint** URL, so this toggle is hidden for that mode.
|
||||
10. **Azure request timeout (milliseconds)**: default is `30000` (30 seconds). Increase only if your network needs more time for large objects.
|
||||
|
||||
Save the settings and click **Test Connection**. Mattermost issues a no-op write/read/delete against the configured container using the credentials submitted in the form. A green `Connection was successful` message confirms the credentials, container name, and endpoint all work. A red error message includes the underlying reason; common ones are listed in [Troubleshooting](#troubleshooting).
|
||||
|
||||
<Warning>
|
||||
|
||||
**Restart required.** The Mattermost server caches the file storage backend at startup and does not re-create it when the file storage configuration changes. After saving, restart every Mattermost server in the deployment (`systemctl restart mattermost`, recycle the container, or roll the deployment in your cluster) for the new driver to take effect. **Test Connection** works before the restart because it builds a temporary backend from the submitted form values.
|
||||
|
||||
</Warning>
|
||||
|
||||
<Warning>
|
||||
|
||||
Switching the file driver does **not** migrate existing files. If you are moving an existing deployment from Amazon S3, see [Migrate existing files from Amazon S3](#migrate-existing-files-from-amazon-s3) below before changing the driver. For migrations from local disk, copy the directory contents into the Azure container using `azcopy` ([docs](https://learn.microsoft.com/en-us/azure/storage/common/storage-use-azcopy-v10)). In either case, files uploaded before the switch are unreachable once the driver changes unless they are present at the same key in the destination.
|
||||
|
||||
</Warning>
|
||||
|
||||
## Step 3: Verify
|
||||
|
||||
1. After the restart, reload the System Console or any channel.
|
||||
2. Upload an attachment in any channel. A small image is a good test, because Mattermost stores three blobs for an image (original, preview, thumbnail), which exercises the upload path more thoroughly than a plain file.
|
||||
3. The post should render the attachment and preview as usual.
|
||||
4. In the Azure portal, open the container and confirm new blobs appeared under the path `<YYYYMMDD>/teams/<team>/channels/<channel>/users/<user>/<file_id>/` (the same layout the local-disk and S3 backends use). For an image you will see `<name>.<ext>`, `<name>_preview.<ext>`, and `<name>_thumb.<ext>`.
|
||||
|
||||
## Migrate existing files from Amazon S3
|
||||
|
||||
If you are switching an existing deployment from S3 to Azure Blob Storage, the file content must be present in the Azure container at the same key Mattermost would have written to. Mattermost itself does not move files between backends, so this is an out-of-band copy that you run once before flipping the driver.
|
||||
|
||||
Mattermost writes blobs at the same relative path on every backend:
|
||||
|
||||
```text
|
||||
{path-prefix}/{YYYYMMDD}/teams/{teamID}/channels/{channelID}/users/{userID}/{fileID}/{filename}
|
||||
```
|
||||
|
||||
This means a straight key-for-key copy from the S3 bucket to the Azure container is sufficient. If you use `AmazonS3PathPrefix` on the S3 side, set `AzurePathPrefix` to the same value on the Azure side (or rewrite the prefix during the copy).
|
||||
|
||||
There are multiple ways to accomplish this. The recommended way is using the [Azure Storage Mover service](https://learn.microsoft.com/en-us/azure/storage-mover/cloud-to-cloud-migration), which provides a cloud-to-cloud migration from Amazon S3 to Azure Blob Storage.
|
||||
|
||||
There are alternative tools that can also help, like [rclone](https://rclone.org/azureblob/) and [AzCopy](https://learn.microsoft.com/en-us/azure/storage/common/storage-use-azcopy-s3).
|
||||
|
||||
## (Optional) Configure the export backend
|
||||
|
||||
Compliance and data exports can be stored separately from regular file uploads. The **File Storage (Exports)** section directly below **File Storage** in the System Console mirrors the fields above and accepts the same Azure credentials. Customers typically point exports at a different container (or a different account) so the export retention policy can differ from regular uploads. The export target is an independent backend with its own driver and credentials, so it doesn't have to use the same provider as regular uploads; e.g., you can keep uploads on Amazon S3 and send exports to Azure Blob Storage, or the reverse.
|
||||
|
||||
See [Enable dedicated export filestore target](/administration-guide/configure/environment-configuration-settings#enable-dedicated-export-filestore-target) for the full list of `ExportAzure*` keys.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
| Symptom | Likely cause |
|
||||
|:---|:---|
|
||||
| `AuthenticationFailed` on **Test Connection** | When **Azure authentication** is **Shared key**: wrong account name or shared key. Confirm both in the **Access keys** blade of the Azure portal. When **Azure authentication** is **Default credential**: no identity source was available -- the host has no managed identity, the workload-identity federation is not set up, and no `AZURE_TENANT_ID` / `AZURE_CLIENT_ID` / `AZURE_CLIENT_SECRET` environment variables are set. |
|
||||
| `AuthorizationPermissionMismatch` on **Test Connection** | Only applies when **Azure authentication** is **Default credential**. The identity the SDK selected does not hold a data-plane role on the storage account. Grant **Storage Blob Data Contributor** to that identity per [Option B: Default credential (Microsoft Entra ID)](#option-b-default-credential-microsoft-entra-id), then wait 30-120 seconds for the role assignment to propagate. |
|
||||
| `ContainerNotFound` | Container name is wrong or was created under a different storage account. |
|
||||
| `connection refused` or TLS errors | When **Azure cloud** is **Custom Endpoint**, the **Azure endpoint** URL points at a host that isn't reachable or uses the wrong scheme. When **Azure cloud** is **Azure Commercial** or **Azure Government**, **Enable secure Azure Blob Storage connections** is disabled in front of a TLS-only destination. |
|
||||
| **Test Connection** succeeds but uploads in channels fail | Check **System Console > Reporting > Server Logs** for the Azure error returned by the SDK. The most common cause is a forgotten server restart after **Save**. |
|
||||
| Files uploaded before the switch are no longer visible | The existing files are still on the previous backend. For S3 migrations, follow [Migrate existing files from Amazon S3](#migrate-existing-files-from-amazon-s3) to copy the bucket into the Azure container at matching keys. For other backends, copy the contents into the Azure container with `azcopy` (or equivalent) and confirm the destination path matches the layout Mattermost uses. |
|
||||
|
||||
## Reference
|
||||
|
||||
Each Azure setting is documented in detail in [Environment configuration settings](/administration-guide/configure/environment-configuration-settings#file-storage):
|
||||
|
||||
- [File storage system](/administration-guide/configure/environment-configuration-settings#file-storage-system) (`FileSettings.DriverName`)
|
||||
- [Azure Storage account](/administration-guide/configure/environment-configuration-settings#azure-storage-account) (`FileSettings.AzureStorageAccount`)
|
||||
- [Azure container](/administration-guide/configure/environment-configuration-settings#azure-container) (`FileSettings.AzureContainer`)
|
||||
- [Azure path prefix](/administration-guide/configure/environment-configuration-settings#azure-path-prefix) (`FileSettings.AzurePathPrefix`)
|
||||
- [Azure authentication](/administration-guide/configure/environment-configuration-settings#azure-authentication) (`FileSettings.AzureAuthMode`)
|
||||
- [Azure Storage account key](/administration-guide/configure/environment-configuration-settings#azure-storage-account-key) (`FileSettings.AzureAccessKey`)
|
||||
- [Azure cloud](/administration-guide/configure/environment-configuration-settings#azure-cloud) (`FileSettings.AzureCloud`)
|
||||
- [Azure endpoint](/administration-guide/configure/environment-configuration-settings#azure-endpoint) (`FileSettings.AzureEndpoint`)
|
||||
- [Enable secure Azure Blob Storage connections](/administration-guide/configure/environment-configuration-settings#enable-secure-azure-blob-storage-connections) (`FileSettings.AzureSSL`)
|
||||
- [Azure request timeout](/administration-guide/configure/environment-configuration-settings#azure-request-timeout) (`FileSettings.AzureRequestTimeoutMilliseconds`)
|
||||
64
docs/main/administration-guide/configure/bleve-search.mdx
Normal file
64
docs/main/administration-guide/configure/bleve-search.mdx
Normal file
@@ -0,0 +1,64 @@
|
||||
---
|
||||
title: "Bleve search"
|
||||
---
|
||||
<PlanAvailability slug="all-commercial" />
|
||||
|
||||
<Important>
|
||||
|
||||
**From Mattermost v11, Bleve search has been deprecated.**
|
||||
|
||||
- **For v11.0 and later**: Use [Elasticsearch](/deployment-guide/scale/elasticsearch-setup) or [OpenSearch](/deployment-guide/scale/opensearch-setup) for [enterprise search](/deployment-guide/scale/enterprise-search) capabilities
|
||||
- **For pre-v11.0 deployments**: This documentation remains relevant for existing installations that continue using Bleve.
|
||||
|
||||
</Important>
|
||||
|
||||
Bleve is a search engine that uses Lucene-style full-text search and indexing. This style of search and indexing helps overcome limitations of the default database search such as challenges with characters and advanced search capabilities.
|
||||
|
||||
<Note>
|
||||
|
||||
Experimental Bleve search uses the scorch index type on newly-created indexes. This new index type features efficiency improvements and indexes that use significantly less disk space. Go to **System Console \> Experimental \> Bleve** and select **Purge Index** to run a purge operation. When that's complete, select **Index Now** to reindex. Bleve remains compatible with existing indexes, so currently indexed data will continue to work if a purge and reindex isn't run.
|
||||
|
||||
</Note>
|
||||
|
||||
## Configuring Bleve in Mattermost
|
||||
|
||||
<Note>
|
||||
|
||||
The following steps are only valid for Mattermost versions prior to v11.0. For v11.0 and later, consider using Elasticsearch or OpenSearch instead.
|
||||
|
||||
</Note>
|
||||
|
||||
Follow these steps to configure the Mattermost server to use Bleve and generate required indexes. Once the configuration is saved, new posts made to the database will be automatically indexed with Bleve.
|
||||
|
||||
**Note:** During indexing, search results may be incomplete until the indexing job is complete.
|
||||
|
||||
1. Open **System Console \> Experimental \> Bleve**.
|
||||
2. Set **Enable Bleve Indexing** to **true** to enable the other settings on the page.
|
||||
3. Set the directory path to use for storing Bleve indexes (e.g.: `/var/opt/mattermost/bleveindexes`). The user running Mattermost should have permissions to access the directory. See our [configuration settings](/administration-guide/configure/deprecated-configuration-settings#bleve-settings) documentation for details.
|
||||
4. Save the configuration.
|
||||
5. Select **Index Now**. All users, channels, and posts in the database will be indexed oldest to newest.
|
||||
6. Set **Enable Bleve for search queries** to **true**.
|
||||
7. Set **Enable Bleve for autocomplete queries** to **true**.
|
||||
|
||||
<Note>
|
||||
|
||||
Search results for files shared before upgrading to Mattermost Server v5.35 may be incomplete until an extraction command is run using the [mmctl](/administration-guide/manage/mmctl-command-line-tool#mmctl-extract). After running this command, the search index must be rebuilt. Go to **System Console \> Experimental \> Bleve \> Bulk Indexing**, then select **Index Now** to rebuild the search index to include older file contents.
|
||||
|
||||
</Note>
|
||||
|
||||
## Using Bleve search
|
||||
|
||||
<Note>
|
||||
|
||||
This section applies only to Mattermost versions prior to v11.0.
|
||||
|
||||
</Note>
|
||||
|
||||
The following conditions are applied when using Bleve search:
|
||||
|
||||
- **Unquoted terms:** Search terms that contain non-alphanumeric characters/special characters outside of quotation marks are removed. For example, using `abcd "**" && abc` as a search term will return results for a search for `abcd "**" abc` as the `&&` characters weren't within the quotation marks.
|
||||
- **Wildcard search:** Wildcard search (e.g., `abc*`) is supported.
|
||||
|
||||
## How does search work with Bleve disabled?
|
||||
|
||||
Mattermost performs full text searches against the database unless you have an [Enterprise license](/product-overview/editions-and-offerings#mattermost-enterprise) and [enterprise search](/deployment-guide/scale/enterprise-search) configured.
|
||||
@@ -0,0 +1,11 @@
|
||||
---
|
||||
title: "Cloud workspace subscription, billing, and account settings"
|
||||
---
|
||||
import useBaseUrl from '@docusaurus/useBaseUrl';
|
||||
|
||||
Review and manage the following aspects of your Mattermost cloud-based deployment by selecting the **Product** <img src={useBaseUrl('/img/ui/products_E82F.svg')} alt="Navigate between Channels, collaborative playbooks, and boards using the product menu icon." className="theme-icon" /> menu, selecting **System Console**, and then selecting **Billing and Account**:
|
||||
|
||||
- Access billing history
|
||||
- Manage the [product subscription](/product-overview/cloud-subscriptions) and account details for your Mattermost Cloud deployment.
|
||||
- Review trial details.
|
||||
- Talk to a [Mattermost Expert](https://mattermost.com/contact-sales/) for assistance.
|
||||
@@ -0,0 +1,579 @@
|
||||
---
|
||||
title: "Compliance configuration settings"
|
||||
---
|
||||
import useBaseUrl from '@docusaurus/useBaseUrl';
|
||||
|
||||
<PlanAvailability slug="ent-plus" />
|
||||
|
||||
Review and manage the following compliance configuration options in the System Console by selecting the **Product** <img src={useBaseUrl('/img/ui/products_E82F.svg')} alt="Navigate between Channels, collaborative playbooks, and boards using the product menu icon." className="theme-icon" /> menu, selecting **System Console**, and then selecting **Compliance**:
|
||||
|
||||
- [Data Retention Policies](#data-retention-policies)
|
||||
- [Compliance Export](/administration-guide/comply/compliance-export)
|
||||
- [Compliance Monitoring](#compliance-monitoring)
|
||||
- [Custom Terms of Service](#custom-terms-of-service)
|
||||
|
||||
<Tip>
|
||||
|
||||
System admins managing a self-hosted Mattermost deployment can edit the `config.json` file as described in the following tables. Each configuration value below includes a JSON path to access the value programmatically in the `config.json` file using a JSON-aware tool. For example, the `MessageRetentionHours` value is under `DataRetentionSettings`.
|
||||
|
||||
- If using a tool such as [jq](https://stedolan.github.io/jq/), you'd enter: `cat config/config.json | jq '.DataRetentionSettings.MessageRetentionHours'`
|
||||
- When working with the `config.json` file manually, look for an object such as `DataRetentionSettings`, then within that object, find the key `MessageRetentionHours`.
|
||||
|
||||
</Tip>
|
||||
|
||||
------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
## Data retention policies
|
||||
|
||||
Changes to properties in this section require a server restart before taking effect.
|
||||
|
||||
<Warning>
|
||||
|
||||
- Once a message or a file is deleted, the action is irreversible. Please be careful when setting up a custom data retention policy.
|
||||
- From Mattermost v9.5, data retention removes Elasticsearch indexes based on the day of the retention cut-off time.
|
||||
|
||||
</Warning>
|
||||
|
||||
Access the following configuration settings in the System Console by going to **Compliance \> Data Retention Policies**.
|
||||
|
||||
### Global retention policy for messages
|
||||
|
||||
Set how long Mattermost keeps messages across all teams and channels. This value is not used for any teams and channels that have a custom retention policy applied . Requires the [global retention policy for messages](/administration-guide/configure/compliance-configuration-settings#global-retention-policy-for-messages) configuration setting to be set to `true`.
|
||||
|
||||
By default, messages are kept forever. If **Hours**, **Days**, or **Years** is chosen, set how many hours, days, or years messages are kept in Mattermost. Messages older than the duration you set will be deleted nightly. The minimum message retention time is one hour.
|
||||
|
||||
The global retention time for messages can be superseded on a team or channel level by creating custom policies with unique post retention times See the [Custom retention policy](#custom-retention-policy) section below for details.
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
<col style={{width: '100%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>This feature's <code>config.json</code> setting is <code>"MessageRetentionHours": 1</code> with numerical input.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<Note>
|
||||
|
||||
From Mattermost v9.5, `MessageRetentionDays` has been deprecated in favor of `MessageRetentionHours`. See [deprecated configuration settings](/administration-guide/configure/deprecated-configuration-settings) for details.
|
||||
|
||||
</Note>
|
||||
|
||||
### Global retention policy for files
|
||||
|
||||
Set how long Mattermost keeps files across all teams and channels. Custom policies on team and channel level don't apply to file attachments. The global retention time for files will be used even if a custom policy for messages is in place. Requires the [global retention policy for files](/administration-guide/configure/compliance-configuration-settings#global-retention-policy-for-files) configuration setting to be set to `true`.
|
||||
|
||||
By default, files are kept forever. If **Hours**, **Days**, or **Years** is chosen, set how many hours, days, or years files are kept in Mattermost. Files older than the duration you set will be deleted nightly. The minimum file retention time is one hour.
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
<col style={{width: '100%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>This feature's <code>config.json</code> setting is <code>"FileRetentionHours": 1</code> with numerical input.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<Note>
|
||||
|
||||
From Mattermost v9.5, `FileRetentionDays` has been deprecated in favor of `FileRetentionHours`. See [deprecated configuration settings](/administration-guide/configure/deprecated-configuration-settings) for details.
|
||||
|
||||
</Note>
|
||||
|
||||
### Preserve pinned posts
|
||||
|
||||
From Mattermost v10.10, controls whether pinned posts are preserved when data retention policies delete messages. When enabled, pinned posts won't be deleted by data retention policies, even if they exceed the configured retention period.
|
||||
|
||||
**True**: Pinned posts are preserved and won't be deleted by data retention policies.
|
||||
|
||||
**False**: **(Default)** Pinned posts are deleted according to the configured data retention policy.
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
<col style={{width: '100%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>This feature's <code>config.json</code> setting is <code>"DataRetentionSettings.PreservePinnedPosts": false</code> with options <code>true</code> and <code>false</code>.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<Note>
|
||||
|
||||
- This global configuration setting must be enabled with mmctl using the [mmctl config set](/administration-guide/manage/mmctl-command-line-tool#mmctl-config-set) command.
|
||||
- This configuration setting applies to team and channel policies as well as data retention, and can't be overridden in those more granular team or channel policies.
|
||||
- Files attached to the pinned message aren't preserved.
|
||||
- Only the pinned post is preserved. If it's attached to a thread or if it's the root post of a thread, the other threaded messages aren't preserved.
|
||||
|
||||
</Note>
|
||||
|
||||
### Custom retention policy
|
||||
|
||||
Set how long Mattermost keeps messages across specific teams and channels by specifying a name for the custom retention policy, setting a duration value in days or years, and specifying the teams and channels that will follow this policy. The attachment retention time cannot be set on custom policy levels and the global retention time for attachments is always applied.
|
||||
|
||||
### Data deletion time
|
||||
|
||||
Set the start time of the daily scheduled data retention job. Choose a time when fewer people are using your system. Must be a 24-hour time stamp in the form `HH:MM`.
|
||||
|
||||
This setting is based on the local time of the server.
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
<col style={{width: '100%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>This feature's <code>config.json</code> setting is <code>"DeletionJobStartTime": "02:00"</code> with 24-hour timestamp input in the form <code>"HH:MM"</code>.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
### Run deletion job now
|
||||
|
||||
Start a Data Retention deletion job immediately. You can monitor the status of the job in the data deletion job table within the Policy Log section.
|
||||
|
||||
### Time between batches
|
||||
|
||||
The time in milliseconds between batches processed during data retention job execution. This setting helps control the rate at which data is deleted to reduce database load during retention operations.
|
||||
|
||||
Default is 100 milliseconds. Possible values are any non-negative integer (≥ 0).
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
<col style={{width: '100%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>This feature's <code>config.json</code> setting is <code>"TimeBetweenBatchesMilliseconds": 100</code> with numerical input.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
### Retention IDs batch size
|
||||
|
||||
The number of retention IDs to process in a single batch during data retention job execution. This setting controls how many items are processed together for optimal performance.
|
||||
|
||||
Default is 100. Possible values are any non-negative integer (≥ 0).
|
||||
|
||||
<table style={{width: '90%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '90%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>This feature's <code>config.json</code> setting is <code>"RetentionIdsBatchSize": 100</code> with numerical input.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
### Boards retention days
|
||||
|
||||
Set how long Mattermost keeps boards data. When set to a value greater than 0, boards data older than the specified number of days will be deleted during retention job execution only when boards deletion is enabled via `EnableBoardsDeletion`.
|
||||
|
||||
Default is 365 days. Possible values are any non-negative integer (≥ 0).
|
||||
|
||||
<table style={{width: '85%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '85%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>This feature's <code>config.json</code> setting is <code>"BoardsRetentionDays": 365</code> with numerical input.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
### Enable message deletion
|
||||
|
||||
**True**: Message deletion is enabled during data retention job execution.
|
||||
|
||||
**False**: Messages are not deleted during data retention job execution.
|
||||
|
||||
<table style={{width: '97%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '96%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>This feature's <code>config.json</code> setting is <code>"EnableMessageDeletion": false</code> with options <code>true</code> and <code>false</code>.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<Note>
|
||||
|
||||
When `EnableMessageDeletion` is set to `false`, messages will not be deleted regardless of other retention policy settings.
|
||||
|
||||
</Note>
|
||||
|
||||
### Enable file deletion
|
||||
|
||||
**True**: File deletion is enabled during data retention job execution.
|
||||
|
||||
**False**: Files are not deleted during data retention job execution.
|
||||
|
||||
<table style={{width: '94%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '94%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>This feature's <code>config.json</code> setting is <code>"EnableFileDeletion": false</code> with options <code>true</code> and <code>false</code>.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<Note>
|
||||
|
||||
When `EnableFileDeletion` is set to `false`, files will not be deleted regardless of other retention policy settings.
|
||||
|
||||
</Note>
|
||||
|
||||
### Enable boards deletion
|
||||
|
||||
**True**: Boards deletion is enabled during data retention job execution.
|
||||
|
||||
**False**: Boards data is not deleted during data retention job execution.
|
||||
|
||||
<table style={{width: '96%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '95%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>This feature's <code>config.json</code> setting is <code>"EnableBoardsDeletion": false</code> with options <code>true</code> and <code>false</code>.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<Note>
|
||||
|
||||
When `EnableBoardsDeletion` is set to `false`, boards data will not be deleted regardless of other retention policy settings.
|
||||
|
||||
</Note>
|
||||
|
||||
### Batch size
|
||||
|
||||
The number of records to process in a single batch during data retention job execution. This setting controls how many records are processed together for optimal performance.
|
||||
|
||||
Default is 3000. Possible values are any non-negative integer (≥ 0).
|
||||
|
||||
<table style={{width: '82%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '81%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>This feature's <code>config.json</code> setting is <code>"BatchSize": 3000</code> with numerical input.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
## Compliance export
|
||||
|
||||
Access the following configuration settings in the System Console by going to **Compliance \> Compliance Export**.
|
||||
|
||||
### Enable compliance export
|
||||
|
||||
**True**: Mattermost will generate a compliance export file that contains all messages that were posted in the last 24 hours. The export task is scheduled to run once per day. See the [documentation to learn more](/administration-guide/comply/compliance-export).
|
||||
|
||||
**False**: Mattermost doesn't generate a compliance export file.
|
||||
|
||||
<table style={{width: '89%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '89%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>This feature's <code>config.json</code> setting is <code>"EnableExport": false</code> with options <code>true</code> and <code>false</code>.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
### Compliance export time
|
||||
|
||||
Set the start time of the daily scheduled compliance export job. Choose a time when fewer people are using your system. Must be a 24-hour time stamp in the form `HH:MM`.
|
||||
|
||||
This setting is based on the local time of the server.
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
<col style={{width: '100%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>This feature's <code>config.json</code> setting is <code>"DailyRunTime": 01:00</code> with 24-hour timestamp input in the form <code>"HH:MM"</code>.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
### Export file format
|
||||
|
||||
File format of the compliance export. Corresponds to the system that you want to import the data into.
|
||||
|
||||
Currently supported formats are CSV, Actiance XML, and Global Relay EML.
|
||||
|
||||
If Global Relay is chosen, the following options will be presented:
|
||||
|
||||
### Global Relay customer account
|
||||
|
||||
Type of Global Relay customer account your organization has. Can be one of: `A9/Type 9`, `A10/Type 10`, or `Custom`.
|
||||
|
||||
<table style={{width: '98%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '98%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>This feature's <code>config.json</code> setting is <code>"CustomerType": "A9"</code> with options <code>"A9</code>, <code>"A10"</code>, and <code>CUSTOM</code>.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
### Global Relay SMTP username
|
||||
|
||||
The username for authenticating to the Global Relay SMTP server.
|
||||
|
||||
<table style={{width: '72%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '71%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>This feature's <code>config.json</code> setting is <code>"SmtpUsername": ""</code> with string input.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
### Global Relay SMTP password
|
||||
|
||||
The password associated with the Global Relay SMTP username.
|
||||
|
||||
<table style={{width: '72%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '71%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>This feature's <code>config.json</code> setting is <code>"SmtpPassword": ""</code> with string input.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
### Global Relay email address
|
||||
|
||||
The email address your Global Relay server monitors for incoming compliance exports.
|
||||
|
||||
<table style={{width: '72%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '71%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>This feature's <code>config.json</code> setting is <code>"EmailAddress": ""</code> with string input.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
### Global Relay sender address
|
||||
|
||||
An optional fixed From address used for every exported Global Relay EML and as the SMTP envelope sender. When left blank (the default), the export continues to derive From from the first channel participant by username. Participant emails remain in the To header so archiving systems can still index conversation participants.
|
||||
|
||||
<table style={{width: '72%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '71%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>This feature's <code>config.json</code> setting is <code>".MessageExportSettings.GlobalRelaySettings.SenderAddress": ""</code> with string input.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
### SMTP server name
|
||||
|
||||
The SMTP server name URL that will receive your Global Relay EML file when a [custom customer account type](#global-relay-customer-account) is configured.
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
<col style={{width: '100%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>This feature's <code>config.json</code> setting is <code>".MessageExportSettings.GlobalRelaySettings.CustomSMTPServerName": ""</code> with string input.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
### SMTP server port
|
||||
|
||||
The SMTP server port that will receive your Global Relay EML file when a [custom customer account type](#global-relay-customer-account) is configured. Default is `"25"`.
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
<col style={{width: '100%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>This feature's <code>config.json</code> setting is <code>".MessageExportSettings.GlobalRelaySettings.CustomSMTPPort": "25"</code> with string input.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
### Custom header name
|
||||
|
||||
An optional custom header added to each exported EML file when a [custom customer account type](#global-relay-customer-account) is configured. Both the custom header name and value must be set, or both left blank to omit. A save is rejected if only one of the two is set, or if the name reuses a header the export already writes (such as `From`, `To`, `Subject`, or `X-GlobalRelay-MsgType`).
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
<col style={{width: '100%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>This feature's <code>config.json</code> setting is <code>".MessageExportSettings.GlobalRelaySettings.CustomHeaderName": ""</code> with string input.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
### Custom header value
|
||||
|
||||
The value sent with the custom header when a [custom customer account type](#global-relay-customer-account) is configured. Both the custom header name and value must be set, or both left blank to omit. A save is rejected if only one of the two is set, or if the name reuses a header the export already writes.
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
<col style={{width: '100%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>This feature's <code>config.json</code> setting is <code>".MessageExportSettings.GlobalRelaySettings.CustomHeaderValue": ""</code> with string input.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
### Message export batch size
|
||||
|
||||
This setting isn't available in the System Console and can only be set in `config.json`.
|
||||
|
||||
Determines how many new posts are batched together to a compliance export file.
|
||||
|
||||
<table style={{width: '78%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '78%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>This feature's <code>config.json</code> setting is <code>"BatchSize": 10000</code> with numerical input.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
### Run compliance export job now
|
||||
|
||||
This button initiates a compliance export job immediately. You can monitor the status of the job in the compliance export job table.
|
||||
|
||||
------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
## Compliance monitoring
|
||||
|
||||
Settings used to enable and configure Mattermost compliance reports.
|
||||
|
||||
Access the following configuration settings in the System Console by going to **Compliance \> Compliance Monitoring**.
|
||||
|
||||
### Enable compliance reporting
|
||||
|
||||
**True**: Compliance reporting is enabled in Mattermost.
|
||||
|
||||
**False**: Compliance reporting is disabled.
|
||||
|
||||
<table style={{width: '84%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '84%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>This feature's <code>config.json</code> setting is <code>"Enable": false</code> with options <code>true</code> and <code>false</code>.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
### Compliance report directory
|
||||
|
||||
Sets the directory where compliance reports are written.
|
||||
|
||||
<table style={{width: '75%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '75%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>This feature's <code>config.json</code> setting is <code>"Directory": "./data/"</code> with string input.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
### Enable daily report
|
||||
|
||||
**True**: Mattermost generates a daily compliance report.
|
||||
|
||||
**False**: Daily reports are not generated.
|
||||
|
||||
<table style={{width: '88%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '88%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>This feature's <code>config.json</code> setting is <code>"EnableDaily": false</code> with options <code>true</code> and <code>false</code>.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
### Batch size
|
||||
|
||||
Set the size of the batches in which posts will be read from the database to generate the compliance report. This setting is currently not available in the System Console and can only be set in `config.json`.
|
||||
|
||||
<table style={{width: '81%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '80%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>This feature's <code>config.json</code> setting is <code>"BatchSize": 30000</code> with default value <code>30000</code>.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
## Custom terms of service
|
||||
|
||||
Access the following configuration settings in the System Console by going to **Compliance \> Custom Terms of Service**.
|
||||
|
||||
### Enable custom terms of service
|
||||
|
||||
<Note>
|
||||
|
||||
This configuration setting can only be modified using the System Console user interface.
|
||||
|
||||
</Note>
|
||||
|
||||
**True**: New users must accept the Terms of Service before accessing any Mattermost teams on desktop, web, or mobile. Existing users must accept them after login or a page refresh. To update the Terms of Service link displayed in account creation and login pages, go to **System Console \> Legal and Support \> Terms of Service Link**.
|
||||
|
||||
**False**: During account creation or login, users can review Terms of Service by accessing the link configured via **System Console \> Legal and Support \> Terms of Service link**.
|
||||
|
||||
### Custom terms of service text
|
||||
|
||||
Text that will appear in your custom Terms of Service. Supports Markdown-formatted text.
|
||||
|
||||
### Re-acceptance period
|
||||
|
||||
The number of days before Terms of Service acceptance expires, and the terms must be re-accepted.
|
||||
|
||||
Defaults to 365 days. 0 indicates the terms do not expire.
|
||||
@@ -0,0 +1,175 @@
|
||||
---
|
||||
title: "Store configuration in your database"
|
||||
---
|
||||
<PlanAvailability slug="all-commercial" />
|
||||
|
||||
If you have a self-hosted Mattermost deployment, you can use your database as the single source of truth for the active configuration of your Mattermost installation. This changes the Mattermost binary from reading the default `config.json` file to reading the configuration settings stored within a configuration table in the database. Mattermost has been running our [community server](https://community.mattermost.com) on this option since the feature was released, and recommends its use for those on [High Availability deployments](/deployment-guide/server/high-availability-cluster-based-deployment).
|
||||
|
||||
Benefits to using this option:
|
||||
|
||||
- Conveniently manages configuration changes directly from the System Console, even in High Availability deployments and read-only containerized environments.
|
||||
- Ensures all servers in a High Availability deployment have the same configuration, even when new servers are added to the cluster.
|
||||
- Automatically deploys SAML certificates and keys to all servers in the cluster.
|
||||
|
||||
<Tip>
|
||||
|
||||
The Mattermost configuration database and Mattermost application database are 2 different entities. It's possible to store Mattermost configuration in one database and Mattermost data in another database.
|
||||
|
||||
To do so, you must update the [Datasource](/administration-guide/configure/environment-configuration-settings#data-source) configuration setting to a new data source name, which can be done while the application is running. Explicitly setting the `MM_SQLSETTINGS_DATASOURCE` environment variable to override what has been defined in the configuration, whether it's in a database, or in a file, allows the correct data source name to be passed to the Mattermost application.
|
||||
|
||||
</Tip>
|
||||
|
||||
## How to migrate configuration to the database
|
||||
|
||||
These instructions cover migrating the Mattermost configuration to your database and updating your `systemd` configuration to load it from the database.
|
||||
|
||||
<Important>
|
||||
|
||||
- These instructions assume you have Mattermost server installed at `/opt/mattermost`. If you're running Mattermost in a different directory you'll have to modify the paths to match your environment.
|
||||
- If you're running Mattermost in a High Availability cluster-based deployment, you must complete all of the steps below on each server in the cluster.
|
||||
|
||||
</Important>
|
||||
|
||||
### Get your database connection string
|
||||
|
||||
The first step is to get your master database connection string. We recommend accessing your `config.json` file to make a copy of the value in `SqlSettings.DataSource`, or your equivalent environment variable, `MM_SQLSETTINGS_DATASOURCE`.
|
||||
|
||||
<Important>
|
||||
|
||||
- `SqlSettings.DataSource` must start with `postgres://` or `mysql://`. If it doesn't, add it to the beginning based on the database in use. For example: `postgres://mmuser:really_secure_password@localhost:5432/mattermost?sslmode=disable&connect_timeout=10`
|
||||
- If you see `\u0026`, replace it with `&`. For example: `mysql://mmuser:really_secure_password@tcp(127.0.0.1:3306)/mattermost?charset=utf8mb4,utf8&writeTimeout=30s`
|
||||
|
||||
</Important>
|
||||
|
||||
### Create an environment file
|
||||
|
||||
Create the file `/opt/mattermost/config/mattermost.environment` to set the `MM_CONFIG` environment variable to the database connection string. For example:
|
||||
|
||||
``` text
|
||||
MM_CONFIG='postgres://mmuser:mostest_password@localhost:5432/mattermost_test?sslmode=disable&connect_timeout=10'
|
||||
```
|
||||
|
||||
Run this command to verify the permissions on your Mattermost directory:
|
||||
|
||||
``` sh
|
||||
sudo chown -R mattermost:mattermost /opt/mattermost
|
||||
```
|
||||
|
||||
### Enable local mode
|
||||
|
||||
Edit the `config.json` to enable local mode by setting `EnableLocalMode` to `true`. See the [local mode](/administration-guide/manage/mmctl-command-line-tool#local-mode) documentation for details on activating and using local mode.
|
||||
|
||||
### Restart Mattermost
|
||||
|
||||
Run the following command to restart the Mattermost server and apply the configuration change:
|
||||
|
||||
``` sh
|
||||
sudo systemctl restart mattermost
|
||||
```
|
||||
|
||||
### Migrate configuration from `config.json`
|
||||
|
||||
You can use the [mmctl config migrate](/administration-guide/manage/mmctl-command-line-tool#mmctl-config-migrate) command to migrate the configuration by running the following command:
|
||||
|
||||
``` sh
|
||||
./bin/mmctl config migrate path/to/config.json "postgres://mmuser:mostest_password@localhost:5432/mattermost_test?sslmode=disable&connect_timeout=10" --local
|
||||
```
|
||||
|
||||
<Important>
|
||||
|
||||
- If you're using a High Availability cluster-based deployment, you only need to run this command once and migrate the configuration from one server in the cluster.
|
||||
- When migrating configuration, Mattermost incorporates configuration from any existing `MM_*` environment variables set in the current shell. See [Environment Variables](/administration-guide/configure/configuration-settings) documentation for details.
|
||||
- As with the environment file, you'll have to escape any single quotes in the database connection string.
|
||||
- Any existing SAML certificates will be migrated into the database as well so they are available for all servers in the cluster. When the certificates expire, you can upload new certificates using the System Console or mmctl, which triggers a database update. Replacing the certificate files manually requires a reload of the Mattermost server to re-pull the certificates. Configuration files are stored in the `configurationfiles` table in the database.
|
||||
|
||||
</Important>
|
||||
|
||||
When configuration in the database is enabled, any changes to the configuration are recorded to the `Configurations` and `ConfigurationFiles` tables. Furthermore, `ClusterSettings.ReadOnlyConfig` is ignored, enabling full use of the System Console.
|
||||
|
||||
If you have configuration settings that must be set on a per-server basis you should add them as environment variables to the `mattermost.environment` file. These must be on their own line, and you must escape them properly.
|
||||
|
||||
### Modify the Mattermost `systemd` file
|
||||
|
||||
Find the `mattermost.service` file using the following command:
|
||||
|
||||
``` sh
|
||||
sudo systemctl status mattermost.service
|
||||
```
|
||||
|
||||
The second line of output will have the location of the running `mattermost.service`.
|
||||
|
||||
``` text
|
||||
Loaded: loaded (/etc/systemd/system/mattermost.service; enabled; vendor preset: enabled)
|
||||
```
|
||||
|
||||
Edit this file as *root* to add the below text just above the line that begins with `ExecStart`:
|
||||
|
||||
``` text
|
||||
EnvironmentFile=/opt/mattermost/config/mattermost.environment
|
||||
```
|
||||
|
||||
Here's a complete `mattermost.service` file with the `EnvironmentFile` line added:
|
||||
|
||||
``` text
|
||||
[Unit]
|
||||
Description=Mattermost
|
||||
After=network.target
|
||||
After=postgresql.service
|
||||
Requires=postgresql.service
|
||||
|
||||
[Service]
|
||||
Type=notify
|
||||
EnvironmentFile=/opt/mattermost/config/mattermost.environment
|
||||
ExecStart=/opt/mattermost/bin/mattermost
|
||||
TimeoutStartSec=3600
|
||||
KillMode=mixed
|
||||
Restart=always
|
||||
RestartSec=10
|
||||
WorkingDirectory=/opt/mattermost
|
||||
User=mattermost
|
||||
Group=mattermost
|
||||
LimitNOFILE=49152
|
||||
|
||||
[Install]
|
||||
WantedBy=postgresql.service
|
||||
```
|
||||
|
||||
#### Verify that the configuration was migrated correctly
|
||||
|
||||
Configurations are stored in the `Configurations` table in the database. Run the following query to verify that you've migrated the configuration successfully:
|
||||
|
||||
``` sql
|
||||
SELECT * FROM Configurations WHERE Active=true;
|
||||
```
|
||||
|
||||
There should be exactly one line returned, and the `Value` field for that line should match your `config.json` file.
|
||||
|
||||
### Reload `systemd` files and restart Mattermost
|
||||
|
||||
Run these commands to reload the daemon and restart Mattermost using the new `MM_CONFIG` environment variable.
|
||||
|
||||
``` sh
|
||||
sudo systemctl daemon-reload
|
||||
sudo systemctl restart mattermost
|
||||
```
|
||||
|
||||
<Important>
|
||||
|
||||
Once you start using configuration in the database, you shouldn't manually edit the active configuration row. You should edit or update the configuration in one of the following ways:
|
||||
|
||||
- Use the System Console to make changes to the configuration.
|
||||
- Use `mmctl` to make changes to the configuration.
|
||||
|
||||
The Mattermost server keeps active configuration in memory and writes new ones to the database only when there is a change. This way we avoid polling the database to process changes to the configuration. Publishing the changes to the cluster are handled by the application itself.
|
||||
|
||||
</Important>
|
||||
|
||||
## Rolling back
|
||||
|
||||
If you run into issues with your configuration in the database you can roll back to the `config.json` file by commenting out the `MM_CONFIG` line in `/opt/mattermost/config/mattermost.environment` and restarting Mattermost with `systemctl restart mattermost`.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Server fails to start
|
||||
|
||||
Providing the `--disableconfigwatch` flag while not actually pointing at a file will fail to start the server with an appropriate error message.
|
||||
@@ -0,0 +1,49 @@
|
||||
---
|
||||
title: "System Console settings"
|
||||
---
|
||||
import useBaseUrl from '@docusaurus/useBaseUrl';
|
||||
|
||||
<PlanAvailability slug="all-commercial" />
|
||||
|
||||
System admins for both self-hosted and Cloud Mattermost deployments can manage Mattermost configuration using the System Console by selecting the **Product** <img src={useBaseUrl('/img/ui/products_E82F.svg')} alt="Navigate between Channels, collaborative playbooks, and boards using the product menu icon." className="theme-icon" /> menu and selecting **System Console**.
|
||||
|
||||
<Note>
|
||||
|
||||
- In self-hosted Mattermost deployments, configuration settings are maintained in the `config.json` configuration file, located in the `mattermost/config` directory, or [stored in the database](/administration-guide/configure/configuration-in-your-database). System admins managing self-hosted deployments can also modify the `config.json` file directly using a text editor.
|
||||
- Mattermost requires write permissions to the `config.json` file; otherwise, configuration changes made within the System Console will have no effect.
|
||||
|
||||
</Note>
|
||||
|
||||
Mattermost configuration settings are organized into the following categories within the System Console:
|
||||
|
||||
- [Site configuration settings](/administration-guide/configure/site-configuration-settings)
|
||||
- [Authentication configuration settings](/administration-guide/configure/authentication-configuration-settings)
|
||||
- [User management configuration settings](/administration-guide/configure/user-management-configuration-settings)
|
||||
- [System attributes](/administration-guide/configure/system-attributes)
|
||||
- [Environment configuration settings](/administration-guide/configure/environment-configuration-settings)
|
||||
- [Reporting configuration settings](/administration-guide/configure/reporting-configuration-settings)
|
||||
- [Compliance configuration settings](/administration-guide/configure/compliance-configuration-settings)
|
||||
- [Integrations configuration settings](/administration-guide/configure/integrations-configuration-settings)
|
||||
- [Plugins configuration settings](/administration-guide/configure/plugins-configuration-settings)
|
||||
- [Self-hosted workspace edition and license settings](/administration-guide/configure/self-hosted-account-settings)
|
||||
- [Cloud workspace subscription, billing, and account settings](/administration-guide/configure/cloud-billing-account-settings)
|
||||
- [Experimental configuration settings](/administration-guide/configure/experimental-configuration-settings)
|
||||
- [Deprecated configuration settings](/administration-guide/configure/deprecated-configuration-settings)
|
||||
|
||||
Search is configured outside the System Console settings pages above. See [Bleve search](/administration-guide/configure/bleve-search) for the built-in search engine, and the [deployment guide](/deployment-guide/scale/elasticsearch-setup) for Elasticsearch and OpenSearch.
|
||||
|
||||
## Configuration in database
|
||||
|
||||
Self-hosted system configuration can be stored in the database. This changes the Mattermost binary from reading the default `config.json` file to reading the configuration settings stored within a configuration table in the database. See the [Mattermost database configuration](/administration-guide/configure/configuration-in-your-database) documentation for migration details.
|
||||
|
||||
## Environment variables
|
||||
|
||||
You can use [environment variables](/administration-guide/configure/environment-variables) to manage Mattermost configuration for self-hosted deployments. Environment variables override settings in `config.json`. If a change to a setting in `config.json` requires a restart to take effect, then changes to the corresponding environment variable also require a server restart.
|
||||
|
||||
## Configuration reload
|
||||
|
||||
In self-hosted deployments, the “config watcher”, the mechanism that automatically reloads the `config.json` file, has been deprecated in favor of the [mmctl config reload](/administration-guide/manage/mmctl-command-line-tool#mmctl-config-reload) command that you must run to apply configuration changes you've made. This improves configuration performance and robustness.
|
||||
|
||||
## Deprecated configuration settings
|
||||
|
||||
See the [deprecated configuration settings documentation](/administration-guide/configure/deprecated-configuration-settings) for details on all deprecated Mattermost configuration settings that are no longer supported.
|
||||
29
docs/main/administration-guide/configure/configure-index.mdx
Normal file
29
docs/main/administration-guide/configure/configure-index.mdx
Normal file
@@ -0,0 +1,29 @@
|
||||
---
|
||||
title: "Configure Mattermost"
|
||||
sidebar_label: "Configure"
|
||||
---
|
||||
Configuration covers everything you set before and after your server is running: the System Console settings themselves, the subsystems Mattermost connects to, and the capabilities you turn on for your users.
|
||||
|
||||
## System Console settings
|
||||
|
||||
- [System Console settings](/administration-guide/configure/configuration-settings) - Every System Console setting, one page per section, with its `config.json` key and environment variable.
|
||||
- [Store configuration in your database](/administration-guide/configure/configuration-in-your-database) - Store configuration in your Mattermost database rather than as a JSON file.
|
||||
- [Environment variables](/administration-guide/configure/environment-variables) - Override configuration settings using environment variables.
|
||||
|
||||
## Subsystems
|
||||
|
||||
- [Search](/administration-guide/configure/bleve-search) - Enable Bleve search, and Chinese, Japanese, and Korean search.
|
||||
- [Email](/administration-guide/configure/smtp-email) - Set up SMTP email, and customize email templates.
|
||||
- [Configure Azure Blob Storage as the Mattermost file store](/administration-guide/configure/azure-blob-storage) - Use Azure Blob Storage instead of local or S3-compatible storage.
|
||||
|
||||
For enterprise search with Elasticsearch or OpenSearch, see the [deployment guide](/deployment-guide/scale/elasticsearch-setup).
|
||||
|
||||
## Capabilities
|
||||
|
||||
- [Branding and customization](/administration-guide/manage/admin/customize-branding) - Apply your organization's branding, and sign custom builds.
|
||||
- [Mattermost Agents](/administration-guide/configure/agents-admin-guide) - Enable AI-powered Agents and connect an LLM provider.
|
||||
- [Install and manage plugins](/administration-guide/configure/manage-plugins) - Install, enable, configure, update, and remove plugins.
|
||||
- [Install Mattermost Boards](/administration-guide/configure/install-boards) - Install and configure the Boards plugin.
|
||||
- [Set up auto-translation](/administration-guide/manage/admin/autotranslation) - Enable and configure automatic message translation.
|
||||
- [Set up content flagging](/administration-guide/manage/admin/content-flagging) - Let users flag messages for review, and handle data spillage.
|
||||
- [Connected workspaces](/administration-guide/onboard/connected-workspaces) - Connect your workspace to another Mattermost deployment.
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
title: "Custom branding tools"
|
||||
---
|
||||
import useBaseUrl from '@docusaurus/useBaseUrl';
|
||||
|
||||
<PlanAvailability slug="all-commercial" />
|
||||
|
||||
Use custom branding tools to present a Mattermost experience that's tailored to the branding of your organization.
|
||||
|
||||
<figure>
|
||||
<img src={useBaseUrl('/images/custom-branding-tools.png')} alt="/images/custom-branding-tools.png" />
|
||||
</figure>
|
||||
|
||||
## Enable custom branding
|
||||
|
||||
1. Go to **System Console \> Site Configuration \> Customization \> Enable Custom Branding** and set the value to **true**.
|
||||
2. Choose a **Site Name**, upload a **Custom Brand Image**, then enter **Custom Brand Text**.
|
||||
3. Choose **Save**.
|
||||
|
||||
Users should see your new custom branding on the login page of your Mattermost server the next time they log in.
|
||||
|
||||
You can remove the custom brand image by selecting the **X** in the top right corner of the image. To apply the change, choose **Save**. Note that the value must be set to **true** in order to perform this step.
|
||||
|
||||
More about settings available in **Customization**:
|
||||
|
||||
### Site name
|
||||
|
||||
Choose the name of your Mattermost site to be shown in the UI. The site name appears in the header and footer of the site login page, team selection page, team creation page, account creation page, email invitations, and replaces "Mattermost" on the **About** page. Note that the site name applies to the entire site and not just a specific team on the site. The site name is limited to 30 characters or less.
|
||||
|
||||
### Custom branding image
|
||||
|
||||
Upload a company logo or custom image representative of your site that is displayed on the left side of the site login page. Supported image formats are JPG, PNG, TIFF, and BMP. The recommended image size is 200-500px in width and height, and less than 2 MB since it's loaded for every user who logs in on desktop.
|
||||
|
||||
### Custom brand text
|
||||
|
||||
Write custom text to display your company tagline or a welcome prompt. Custom text will be shown below the custom brand image on the left side of site login page on desktop. You can format this text to a maximum of 500 characters using the same [Markdown formatting syntax](/end-user-guide/collaborate/format-messages) as used in Mattermost messages.
|
||||
|
||||
### Site description
|
||||
|
||||
Use this field to describe the purpose of your site. The site description is shown below the site name on the login page. This text defaults to **All team communication in one place, searchable and accessible anywhere**. This text can be a maximum of 1024 characters and is not formatted with Markdown.
|
||||
@@ -0,0 +1,60 @@
|
||||
---
|
||||
title: "Customizing Mattermost"
|
||||
---
|
||||
<PlanAvailability slug="all-commercial" />
|
||||
|
||||
There are several ways to customize your Mattermost server.
|
||||
|
||||
If customizing Mattermost, please avoid branding that could be confused with the Mattermost brand. For example, it's okay to brand as "Healthcare Central" because it's a completely different brand. "Mattermost Healthcare Central" is not okay, because it can potentially be confused with the Mattermost brand. Please see the [Mattermost trademark guidelines](https://mattermost.com/trademark-standards-of-use/) for details.
|
||||
|
||||
While you're welcome to add your own copyright notice in the user interface if you feel it is warranted by your changes, we ask that you do not remove the Mattermost, Inc. copyright notice from the login footer or from the About dialog.
|
||||
|
||||
## Mattermost Web App
|
||||
|
||||
The Mattermost webapp is licensed under the Apache 2.0 license. To modify and use with the Mattermost server, you can:
|
||||
|
||||
1. Install the Mattermost server by following one of our installation guides
|
||||
2. Fork the [mattermost](https://github.com/mattermost/mattermost) repository
|
||||
3. Go to the web app code located in the `webapp` directory and make your changes
|
||||
4. Run `make package` to create `mattermost-webapp.tar.gz`
|
||||
5. Copy `mattermost-webapp-tar.gz` to the location Mattermost was installed in Step 1
|
||||
6. Rename the existing `client` folder to `client-original`
|
||||
7. Run `tar -xvf mattermost-webapp.tar.gz` to extract your new customized `client` folder
|
||||
8. If you're installing Mattermost 7.5 - 7.10, copy the `products` folder from `client-original` into `client`
|
||||
9. Restart your Mattermost server
|
||||
|
||||
It is possible to customize certain parts of the webapp without forking by using our [Custom Branding](/administration-guide/configure/custom-branding-tools) settings.
|
||||
|
||||
To replace the logo in email notifications, change the file located in the `/images` directory. To change the app icon, modify the `/app/components/app_icon.js` file.
|
||||
|
||||
## Mattermost Server
|
||||
|
||||
There are a few things you can customize in the Mattermost server without forking:
|
||||
|
||||
1. Modify text in the Mattermost interface by modifying the `en.json` file.
|
||||
2. Customize or hide help and support links by modifying your [configuration settings](/administration-guide/configure/site-configuration-settings#customization).
|
||||
3. Customize the email notifications by editing the HTML files in `/templates`. From Mattermost v11.3.0, changes to HTML templates require a server restart to take effect.
|
||||
|
||||
## Mattermost mobile apps
|
||||
|
||||
The Mattermost mobile apps can be customized if you choose to build the apps yourself.
|
||||
|
||||
To brand the mobile apps:
|
||||
|
||||
1. Fork the [mattermost-mobile](https://github.com/mattermost/mattermost-mobile) repository.
|
||||
2. Replace the name, images, and any key text strings.
|
||||
3. Compile the custom apps.
|
||||
4. Deploy the apps to an app store.
|
||||
|
||||
While most organizations deploy to internal enterprise app stores, you are welcome to deploy to iTunes and Google Play as long as the branding is not confusable with official Mattermost products.
|
||||
|
||||
## Mattermost desktop apps
|
||||
|
||||
The Mattermost desktop apps can be customized if you choose to build the apps yourself.
|
||||
|
||||
To brand the desktop apps:
|
||||
|
||||
1. Fork the [mattermost/desktop](https://github.com/mattermost/desktop) repository
|
||||
2. Replace the name, images, and any key text strings
|
||||
3. Refer to [the Mattermost Developer documentation](https://developers.mattermost.com/contribute/more-info/desktop/) for help with compiling the apps
|
||||
4. Share the desktop application with your users
|
||||
File diff suppressed because it is too large
Load Diff
953
docs/main/administration-guide/configure/email-templates.mdx
Normal file
953
docs/main/administration-guide/configure/email-templates.mdx
Normal file
@@ -0,0 +1,953 @@
|
||||
---
|
||||
title: "Email templates"
|
||||
---
|
||||
<PlanAvailability slug="all-commercial" />
|
||||
|
||||
Mattermost has a few email templates that are sent out when a specific event occurs. Most of the time these templates do not need to be modified. In case additional modifications are necessary, all available props in each email are listed below. The 'Content'-Field is just to give a quick description of the prop. Please check the i18n strings for the exact wording.
|
||||
|
||||
The email templates are located in the Mattermost server directory in the `templates` folder. The corresponding strings for each prop can be found in the `i18n` folder.
|
||||
|
||||
<Note>
|
||||
|
||||
\- The props between different email templates are not interchangeable without additional server code changes. - Always back up changes to the `templates` and `i18n` folders before upgrading the server to avoid losing customizations. - From Mattermost v11.3, changes to HTML templates require a server restart to take effect.
|
||||
|
||||
</Note>
|
||||
|
||||
## Available templates
|
||||
|
||||
### Email footer
|
||||
|
||||
**Purpose**: This is appended to all outgoing emails sent by Mattermost.
|
||||
|
||||
**Props**:
|
||||
|
||||
<table style={{width: '68%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '12%'}} />
|
||||
<col style={{width: '25%'}} />
|
||||
<col style={{width: '30%'}} />
|
||||
</colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Prop</th>
|
||||
<th>Content</th>
|
||||
<th>i18n String</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>Footer</td>
|
||||
<td>Message intro</td>
|
||||
<td>api.templates.email_footer</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Organization</td>
|
||||
<td>Name of Organization</td>
|
||||
<td>api.templates.email_organization</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>EmailInfo1</td>
|
||||
<td>First line of footer</td>
|
||||
<td>api.templates.email_info1</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>EmailInfo2</td>
|
||||
<td>Second line of footer</td>
|
||||
<td>api.templates.email_info2</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>EmailInfo3</td>
|
||||
<td>Third line of footer</td>
|
||||
<td>api.templates.email_info3</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>SupportEmail</td>
|
||||
<td>Email for Mattermost support</td>
|
||||
<td>--</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
### SendChangeUsernameEmail
|
||||
|
||||
**Purpose**: Sent to the user when username has been changed.
|
||||
|
||||
**Body Props**:
|
||||
|
||||
<table style={{width: '72%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '8%'}} />
|
||||
<col style={{width: '25%'}} />
|
||||
<col style={{width: '37%'}} />
|
||||
</colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Prop</th>
|
||||
<th>Content</th>
|
||||
<th>i18n String</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>SiteURL</td>
|
||||
<td>URL of the Mattermost server</td>
|
||||
<td>--</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Title</td>
|
||||
<td>Message heading</td>
|
||||
<td>api.templates.username_change_body.title</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Info</td>
|
||||
<td>Message body</td>
|
||||
<td>api.templates.username_change_body.info</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Warning</td>
|
||||
<td>Warning text</td>
|
||||
<td>api.templates.email_warning</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
### SendEmailChangeVerifyEmail
|
||||
|
||||
**Purpose**: Sent to the user when an email change has been requested. Contains verification link and button.
|
||||
|
||||
**Body Props**:
|
||||
|
||||
<table style={{width: '82%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '12%'}} />
|
||||
<col style={{width: '26%'}} />
|
||||
<col style={{width: '42%'}} />
|
||||
</colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Prop</th>
|
||||
<th>Content</th>
|
||||
<th>i18n String</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>SiteURL</td>
|
||||
<td>URL of the Mattermost server</td>
|
||||
<td>--</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Title</td>
|
||||
<td>Message heading</td>
|
||||
<td>api.templates.email_change_verify_body.title</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Info</td>
|
||||
<td>Message body</td>
|
||||
<td>api.templates.email_change_verify_body.info</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>VerifyUrl</td>
|
||||
<td>URL for email verification</td>
|
||||
<td>--</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>VerifyButton</td>
|
||||
<td>Button for email verification</td>
|
||||
<td>api.templates.email_change_verify_body.button</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
### SendEmailChangeEmail
|
||||
|
||||
**Purpose**: Sent to the user when the email has been changed successfully.
|
||||
|
||||
**Body Props**:
|
||||
|
||||
<table style={{width: '69%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '8%'}} />
|
||||
<col style={{width: '25%'}} />
|
||||
<col style={{width: '35%'}} />
|
||||
</colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Prop</th>
|
||||
<th>Content</th>
|
||||
<th>i18n String</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>SiteURL</td>
|
||||
<td>URL of the Mattermost server</td>
|
||||
<td>--</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Title</td>
|
||||
<td>Message heading</td>
|
||||
<td>api.templates.email_change_body.title</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Info</td>
|
||||
<td>Message body</td>
|
||||
<td>api.templates.email_change_body.info</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Warning</td>
|
||||
<td>Warning text</td>
|
||||
<td>api.templates.email_warning</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
### SendVerifyEmail
|
||||
|
||||
**Purpose**: Sent to the user upon account creation to verify email address.
|
||||
|
||||
**Body Props**:
|
||||
|
||||
<table style={{width: '66%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '10%'}} />
|
||||
<col style={{width: '25%'}} />
|
||||
<col style={{width: '30%'}} />
|
||||
</colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Prop</th>
|
||||
<th>Content</th>
|
||||
<th>i18n String</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>SiteURL</td>
|
||||
<td>URL of the Mattermost server</td>
|
||||
<td>--</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Title</td>
|
||||
<td>Message heading</td>
|
||||
<td>api.templates.verify_body.title</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Info</td>
|
||||
<td>Message body</td>
|
||||
<td>api.templates.verify_body.info</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>VerifyUrl</td>
|
||||
<td>URL for email verification</td>
|
||||
<td>--</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Button</td>
|
||||
<td>Button for email verification</td>
|
||||
<td>api.templates.verify_body.button</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
### SendSignInChangeEmail
|
||||
|
||||
**Purpose**: Sent to the user when the login method has been changed (i.e. from email to LDAP, etc.)
|
||||
|
||||
**Body Props**:
|
||||
|
||||
<table style={{width: '75%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '8%'}} />
|
||||
<col style={{width: '25%'}} />
|
||||
<col style={{width: '40%'}} />
|
||||
</colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Prop</th>
|
||||
<th>Content</th>
|
||||
<th>i18n String</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>SiteURL</td>
|
||||
<td>URL of the Mattermost server</td>
|
||||
<td>--</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Title</td>
|
||||
<td>Message heading</td>
|
||||
<td>api.templates.signin_change_email.body.title</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Info</td>
|
||||
<td>Message body</td>
|
||||
<td>api.templates.signin_change_email.body.info</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Warning</td>
|
||||
<td>Warning text</td>
|
||||
<td>api.templates.email_warning</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
### SendWelcomeEmail
|
||||
|
||||
**Purpose**: Sent to the user when the account has been created. May also contain download links to Apps as well as email verification links.
|
||||
|
||||
**Body Props**:
|
||||
|
||||
<table style={{width: '82%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '15%'}} />
|
||||
<col style={{width: '25%'}} />
|
||||
<col style={{width: '41%'}} />
|
||||
</colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Prop</th>
|
||||
<th>Content</th>
|
||||
<th>i18n String</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>SiteURL</td>
|
||||
<td>URL of the Mattermost server</td>
|
||||
<td>--</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Title</td>
|
||||
<td>Message heading</td>
|
||||
<td>api.templates.welcome_body.title</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Info</td>
|
||||
<td>Message body</td>
|
||||
<td>api.templates.welcome_body.info</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Button</td>
|
||||
<td>Button for confirmation</td>
|
||||
<td>api.templates.welcome_body.button</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Info2</td>
|
||||
<td>Continuation of message body</td>
|
||||
<td>api.templates.welcome_body.info2</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Info3</td>
|
||||
<td>Continuation of message body</td>
|
||||
<td>api.templates.welcome_body.info3</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
**Optional Props**:
|
||||
|
||||
<table style={{width: '82%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '15%'}} />
|
||||
<col style={{width: '25%'}} />
|
||||
<col style={{width: '41%'}} />
|
||||
</colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Prop</th>
|
||||
<th>Content</th>
|
||||
<th>i18n String</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>AppDownloadInfo</td>
|
||||
<td>Info for App Downloads</td>
|
||||
<td>api.templates.welcome_body.app_download_info</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>AppDownloadLink</td>
|
||||
<td>Download link for Apps</td>
|
||||
<td>--</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>VerifyUrl</td>
|
||||
<td>Link for verification</td>
|
||||
<td>--</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
### SendPasswordChangeEmail
|
||||
|
||||
**Purpose**: Sent to the user when password has been changed.
|
||||
|
||||
**Body Props**:
|
||||
|
||||
<table style={{width: '72%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '8%'}} />
|
||||
<col style={{width: '25%'}} />
|
||||
<col style={{width: '37%'}} />
|
||||
</colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Prop</th>
|
||||
<th>Content</th>
|
||||
<th>i18n String</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>SiteURL</td>
|
||||
<td>URL of the Mattermost server</td>
|
||||
<td>--</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Title</td>
|
||||
<td>Message heading</td>
|
||||
<td>api.templates.password_change_body.title</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Info</td>
|
||||
<td>Message body</td>
|
||||
<td>api.templates.password_change_body.info</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Warning</td>
|
||||
<td>Warning text</td>
|
||||
<td>api.templates.email_warning</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
### SendAccessTokenEmail
|
||||
|
||||
**Purpose**: Sent to the user when an access token has been added to the account.
|
||||
|
||||
**Body Props**:
|
||||
|
||||
<table style={{width: '74%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '8%'}} />
|
||||
<col style={{width: '25%'}} />
|
||||
<col style={{width: '40%'}} />
|
||||
</colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Prop</th>
|
||||
<th>Content</th>
|
||||
<th>i18n String</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>SiteURL</td>
|
||||
<td>URL of the Mattermost server</td>
|
||||
<td>--</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Title</td>
|
||||
<td>Message heading</td>
|
||||
<td>api.templates.user_access_token_body.title</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Info</td>
|
||||
<td>Message body</td>
|
||||
<td>api.templates.user_access_token_body.info</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Warning</td>
|
||||
<td>Warning text</td>
|
||||
<td>api.templates.email_warning</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
### SendPasswordResetEmail
|
||||
|
||||
**Purpose**: Sent to the user when password request has been initiated.
|
||||
|
||||
**Body Props**:
|
||||
|
||||
<table style={{width: '64%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '9%'}} />
|
||||
<col style={{width: '25%'}} />
|
||||
<col style={{width: '29%'}} />
|
||||
</colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Prop</th>
|
||||
<th>Content</th>
|
||||
<th>i18n String</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>SiteURL</td>
|
||||
<td>URL of the Mattermost server</td>
|
||||
<td>--</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Title</td>
|
||||
<td>Message heading</td>
|
||||
<td>api.templates.reset_body.title</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Info1</td>
|
||||
<td>Message body</td>
|
||||
<td>api.templates.reset_body.info1</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Info2</td>
|
||||
<td>Continuation of message body</td>
|
||||
<td>api.templates.reset_body.info2</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>ResetUrl</td>
|
||||
<td>URL to reset password</td>
|
||||
<td>--</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Button</td>
|
||||
<td>Button for confirmation</td>
|
||||
<td>api.templates.reset_body.button</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
### SendMfaChangeEmail
|
||||
|
||||
**Purpose**: Sent to the user when multi-factor authentication method has been changed.
|
||||
|
||||
**Body Props when MFA is activated**:
|
||||
|
||||
<table style={{width: '70%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '8%'}} />
|
||||
<col style={{width: '25%'}} />
|
||||
<col style={{width: '35%'}} />
|
||||
</colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Prop</th>
|
||||
<th>Content</th>
|
||||
<th>i18n String</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>SiteURL</td>
|
||||
<td>URL of the Mattermost server</td>
|
||||
<td>--</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Title</td>
|
||||
<td>Message heading</td>
|
||||
<td>api.templates.mfa_activated_body.title</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Info</td>
|
||||
<td>Message body</td>
|
||||
<td>api.templates.mfa_activated_body.info</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Warning</td>
|
||||
<td>Warning text</td>
|
||||
<td>api.templates.email_warning</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
**Body Props when MFA is deactivated**:
|
||||
|
||||
<table style={{width: '72%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '8%'}} />
|
||||
<col style={{width: '25%'}} />
|
||||
<col style={{width: '37%'}} />
|
||||
</colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Prop</th>
|
||||
<th>Content</th>
|
||||
<th>i18n String</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>SiteURL</td>
|
||||
<td>URL of the Mattermost server</td>
|
||||
<td>--</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Title</td>
|
||||
<td>Message heading</td>
|
||||
<td>api.templates.mfa_deactivated_body.title</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Info</td>
|
||||
<td>Message body</td>
|
||||
<td>api.templates.mfa_deactivated_body.info</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Warning</td>
|
||||
<td>Warning text</td>
|
||||
<td>api.templates.email_warning</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
### SendDeactivateAccountEmail
|
||||
|
||||
**Purpose**: Sent to the user when account has been deactivated.
|
||||
|
||||
**Body Props**:
|
||||
|
||||
<table style={{width: '68%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '8%'}} />
|
||||
<col style={{width: '25%'}} />
|
||||
<col style={{width: '34%'}} />
|
||||
</colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Prop</th>
|
||||
<th>Content</th>
|
||||
<th>i18n String</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>SiteURL</td>
|
||||
<td>URL of the Mattermost server</td>
|
||||
<td>--</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Title</td>
|
||||
<td>Message heading</td>
|
||||
<td>api.templates.deactivate_body.title</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Info</td>
|
||||
<td>Message body</td>
|
||||
<td>api.templates.deactivate_body.info</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Warning</td>
|
||||
<td>Warning text</td>
|
||||
<td>api.templates.deactivate_body.warning</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
### SendInviteEmails
|
||||
|
||||
**Purpose**: Sent to the user when team invite via email has been used.
|
||||
|
||||
**Body Props**:
|
||||
|
||||
<table style={{width: '99%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '9%'}} />
|
||||
<col style={{width: '56%'}} />
|
||||
<col style={{width: '33%'}} />
|
||||
</colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Prop</th>
|
||||
<th>Content</th>
|
||||
<th>i18n String</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>SiteURL</td>
|
||||
<td>URL of the Mattermost server</td>
|
||||
<td>--</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Title</td>
|
||||
<td>Message heading</td>
|
||||
<td>api.templates.invite_body.title</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Info1</td>
|
||||
<td>Message body</td>
|
||||
<td>api.templates.invite_body.info</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Button</td>
|
||||
<td>Button for confirmation</td>
|
||||
<td>api.templates.invite_body.button</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>ExtraInfo</td>
|
||||
<td>Additional info about Mattermost</td>
|
||||
<td>api.templates.invite_body.extra_info</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>TeamURL</td>
|
||||
<td>URL to the team the user has been invited to</td>
|
||||
<td>--</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Link</td>
|
||||
<td>URL for team invite confirmation (not to be confused with TeamURL)</td>
|
||||
<td>--</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
### NotificationEmailBody
|
||||
|
||||
**Purpose**: Sent to the user as a notification for new messages or mentions.
|
||||
|
||||
**Body Props**:
|
||||
|
||||
<table style={{width: '63%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '9%'}} />
|
||||
<col style={{width: '25%'}} />
|
||||
<col style={{width: '28%'}} />
|
||||
</colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Prop</th>
|
||||
<th>Content</th>
|
||||
<th>i18n String</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>SiteURL</td>
|
||||
<td>URL of the Mattermost server</td>
|
||||
<td>--</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Button</td>
|
||||
<td>Button to post</td>
|
||||
<td>api.templates.post_body.button</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>TeamLink</td>
|
||||
<td>URL to Team</td>
|
||||
<td>--</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
This email can change depending on the settings and type of channel the notification is sent for.
|
||||
|
||||
**For group channels**:
|
||||
|
||||
**With full notification contents enabled**:
|
||||
|
||||
<table style={{width: '68%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '10%'}} />
|
||||
<col style={{width: '15%'}} />
|
||||
<col style={{width: '41%'}} />
|
||||
</colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Prop</th>
|
||||
<th>Content</th>
|
||||
<th>i18n String</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>BodyText</td>
|
||||
<td>Message intro</td>
|
||||
<td>app.notification.body.intro.group_message.full</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Info1</td>
|
||||
<td>Channel name</td>
|
||||
<td>app.notification.body.text.group_message.full</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Info2</td>
|
||||
<td>Message contents</td>
|
||||
<td>app.notification.body.text.group_message.full2</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>SenderName</td>
|
||||
<td>Name of sender</td>
|
||||
<td>--</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
**Without**:
|
||||
|
||||
<table style={{width: '67%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '9%'}} />
|
||||
<col style={{width: '13%'}} />
|
||||
<col style={{width: '44%'}} />
|
||||
</colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Prop</th>
|
||||
<th>Content</th>
|
||||
<th>i18n String</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>BodyText</td>
|
||||
<td>Message intro</td>
|
||||
<td>app.notification.body.intro.group_message.generic</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Info</td>
|
||||
<td>Timestamp</td>
|
||||
<td>app.notification.body.text.group_message.generic</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
**For direct messages**:
|
||||
|
||||
**With full notification contents enabled**:
|
||||
|
||||
<table style={{width: '69%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '10%'}} />
|
||||
<col style={{width: '23%'}} />
|
||||
<col style={{width: '35%'}} />
|
||||
</colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Prop</th>
|
||||
<th>Content</th>
|
||||
<th>i18n String</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>BodyText</td>
|
||||
<td>Message intro</td>
|
||||
<td>app.notification.body.intro.direct.full</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Info1</td>
|
||||
<td>Empty for direct messages</td>
|
||||
<td>--</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Info2</td>
|
||||
<td>Message contents</td>
|
||||
<td>app.notification.body.text.direct.full</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>SenderName</td>
|
||||
<td>Name of sender</td>
|
||||
<td>--</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
**Without**:
|
||||
|
||||
<table style={{width: '60%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '9%'}} />
|
||||
<col style={{width: '13%'}} />
|
||||
<col style={{width: '37%'}} />
|
||||
</colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Prop</th>
|
||||
<th>Content</th>
|
||||
<th>i18n String</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>BodyText</td>
|
||||
<td>Message intro</td>
|
||||
<td>app.notification.body.intro.direct.generic</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Info</td>
|
||||
<td>Timestamp</td>
|
||||
<td>app.notification.body.text.direct.generic</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
**Notifications**:
|
||||
|
||||
**With full notification contents enabled**:
|
||||
|
||||
<table style={{width: '67%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '10%'}} />
|
||||
<col style={{width: '15%'}} />
|
||||
<col style={{width: '40%'}} />
|
||||
</colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Prop</th>
|
||||
<th>Content</th>
|
||||
<th>i18n String</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>BodyText</td>
|
||||
<td>Message intro</td>
|
||||
<td>app.notification.body.intro.notification.full</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Info1</td>
|
||||
<td>Channel name</td>
|
||||
<td>app.notification.body.text.notification.full</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Info2</td>
|
||||
<td>Message contents</td>
|
||||
<td>app.notification.body.text.notification.full2</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>SenderName</td>
|
||||
<td>Name of sender</td>
|
||||
<td>--</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
**Without**:
|
||||
|
||||
<table style={{width: '78%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '9%'}} />
|
||||
<col style={{width: '25%'}} />
|
||||
<col style={{width: '42%'}} />
|
||||
</colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Prop</th>
|
||||
<th>Content</th>
|
||||
<th>i18n String</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>BodyText</td>
|
||||
<td>URL of the Mattermost server</td>
|
||||
<td>app.notification.body.intro.notification.generic</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Info</td>
|
||||
<td>Message heading</td>
|
||||
<td>app.notification.body.text.notification.generic</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
@@ -0,0 +1,167 @@
|
||||
---
|
||||
title: "Chinese, Japanese and Korean search"
|
||||
---
|
||||
<PlanAvailability slug="all-commercial" />
|
||||
|
||||
<Important>
|
||||
|
||||
Starting on Mattermost v11.5, searching for Chinese, Japanese or Korean (CJK) characters can be enabled with the [feature flag](https://developers.mattermost.com/contribute/more-info/server/feature-flags/#changing-feature-flag-values) `MM_FEATUREFLAGS_CJKSEARCH`.
|
||||
|
||||
The general recommendation of [using either Elasticsearch or Opensearch once the server reaches 2.5 million posts](https://docs.mattermost.com/administration-guide/scale/enterprise-search.html#do-i-need-to-use-elasticsearch-or-aws-opensearch) still applies.
|
||||
|
||||
What follows is the special configuration required for versions older than v11, where MySQL was still supported.
|
||||
|
||||
</Important>
|
||||
|
||||
See [database requirements documentation](/deployment-guide/software-hardware-requirements) for how to set up search for these languages.
|
||||
|
||||
Below is additional information on how to configure the database for different languages.
|
||||
|
||||
## 中文 / Chinese
|
||||
|
||||
尽管在 Mattermost 8.0 更新后,官方推荐为了更好的性能请使用 PostgreSQL 作为后端数据库。
|
||||
|
||||
但就目前而言,使用 MySQL 能够更容易的实现中文语言的全文搜索功能,在妥善配置 ngram 后,根据官方数据库构造重新生成索引即可达成。 具体的操作方式,可参考: [Cannot search CJK contents](https://github.com/mattermost/mattermost/issues/2033#issuecomment-182336690)。
|
||||
|
||||
有关 PostgreSQL 的配置方式,请参考以下流程:
|
||||
|
||||
### 配置 SCWS
|
||||
|
||||
``` sh
|
||||
# 取得 SCWS 代码
|
||||
wget http://www.xunsearch.com/scws/down/scws-1.2.3.tar.bz2
|
||||
# 解压缩
|
||||
tar xvjf scws-1.2.3.tar.bz2
|
||||
# 进入解压后的目录
|
||||
cd scws-1.2.3
|
||||
# 执行配置脚本、编译并安装
|
||||
./configure --prefix=/usr/local/scws ; make ; make install
|
||||
|
||||
# 可选:检查文件是否存在
|
||||
ls -al /usr/local/scws/lib/libscws.la
|
||||
/usr/local/scws/bin/scws -h
|
||||
# 可选:将词典安装在 /usr/local/scws/etc 中
|
||||
cd /usr/local/scws/etc
|
||||
wget http://www.xunsearch.com/scws/down/scws-dict-chs-gbk.tar.bz2
|
||||
wget http://www.xunsearch.com/scws/down/scws-dict-chs-utf8.tar.bz2
|
||||
tar xvjf scws-dict-chs-gbk.tar.bz2
|
||||
tar xvjf scws-dict-chs-utf8.tar.bz2
|
||||
```
|
||||
|
||||
### 配置 Zhparser
|
||||
|
||||
``` sh
|
||||
# 下载 Zhparser 源代码
|
||||
git clone https://github.com/amutu/zhparser.git
|
||||
# 进入下载后的目录
|
||||
cd zhparser
|
||||
# 编译并安装
|
||||
SCWS_HOME=/usr/local/scws make && make install
|
||||
```
|
||||
|
||||
<Note>
|
||||
|
||||
自 Mattermost 6.0 起,官方已不再使用 mattermost/mattermost-prod-db 作为数据库镜像,你可以直接使用安装在服务器上的 PostgreSQL 数据库,或者使用 PostgreSQL 官方的 Docker 镜像。
|
||||
|
||||
如果使用 Docker 镜像作为数据库,可以预先执行以下命令,安装依赖(请根据实际的 PostgreSQL 版本选择)。
|
||||
|
||||
``` sh
|
||||
# 更新本地缓存
|
||||
apt update
|
||||
# 配置 SCWS 时需要的依赖
|
||||
apt install wget make gcc
|
||||
# 配置 Zhparser 时需要的依赖
|
||||
apt install git postgresql-server-dev-13
|
||||
```
|
||||
|
||||
</Note>
|
||||
|
||||
### 创建 extension 并增加解析配置
|
||||
|
||||
``` sql
|
||||
-- 创建 extension
|
||||
CREATE EXTENSION zhparser;
|
||||
-- 创建 text search configuration
|
||||
CREATE TEXT SEARCH CONFIGURATION simple_zh_cfg (PARSER = zhparser);
|
||||
-- 配置 token mapping
|
||||
ALTER TEXT SEARCH CONFIGURATION simple_zh_cfg ADD MAPPING FOR n,v,a,i,e,l WITH simple;
|
||||
```
|
||||
|
||||
### 更新 PostgreSQL 配置
|
||||
|
||||
将 postgresql.conf 中的 default_text_search_config 的值更改为 simple_zh_cfg。
|
||||
|
||||
更改后,需要重启数据库方可生效。
|
||||
|
||||
<Note>
|
||||
|
||||
配置完成后,需根据 Mattermost 官方仓库中的 SQL 建表语句重新创建索引,方可正式启用中文语言的全文搜索功能。
|
||||
|
||||
未尽事宜,可以参考以下链接:
|
||||
|
||||
- SCWS 官方文档
|
||||
- [Zhparser 官方文档](https://github.com/amutu/zhparser/blob/master/README.md)
|
||||
- [Mattermost 建表语句](https://github.com/mattermost/mattermost/tree/master/server/channels/db/migrations/postgres)
|
||||
|
||||
</Note>
|
||||
|
||||
## 日本語 / Japanese
|
||||
|
||||
日本語翻訳の改善は大歓迎です。自由に変更していただいて結構です。
|
||||
|
||||
### 検索設定
|
||||
|
||||
Mattermost で日本語検索をするためにはデータベースの設定変更が必要です
|
||||
|
||||
- [MySQL](/deployment-guide/software-hardware-requirements#database-software)
|
||||
- [Postgres](/deployment-guide/software-hardware-requirements#database-software)
|
||||
|
||||
日本語(CJK)検索設定のドキュメントの改善にご協力ください
|
||||
|
||||
### ガイド
|
||||
|
||||
Qiita上で Mattermost のインストールおよび構成のガイドを提供しています。詳細については、\`こちら \[https://qiita.com/tags/mattermost\](https://qiita.com/tags/mattermost\)\`\_ をご覧ください。
|
||||
|
||||
## 한국어 / Korean
|
||||
|
||||
이 문제에 대한 논의는 이 [이슈](https://github.com/mattermost/mattermost/issues/2033) 에서 시작되었습니다.
|
||||
|
||||
한국어 버전 이용 시 문제점을 발견하면 [Localization 채널](https://community.mattermost.com/core/channels/localization) 또는 [한국어 채널](https://community.mattermost.com/core/channels/i18n-korean) 에서 의견을 제시할 수 있습니다.
|
||||
|
||||
### 검색을 위한 데이터베이스 설정
|
||||
|
||||
PostgreSQL: PostgreSQL 데이터베이스에서는 따로 설정이 필요하지 않습니다.
|
||||
|
||||
MySQL: MySQL에서는 전문 검색(Full-text search) 기능에 제한이 있기 때문에 추가적인 작업이 필요합니다.
|
||||
|
||||
### MySQL 해결 방법
|
||||
|
||||
1. n-gram parser 를 이용하기 위해서는 MySQL의 버전이 5.7.6 이상이어야 합니다.
|
||||
2. MySQL의 구성 파일에서 n-gram의 최소 토큰 크기를 다음과 같이 설정합니다.
|
||||
|
||||
``` sql
|
||||
[mysqld]
|
||||
ft_min_word_len = 2
|
||||
innodb_ft_min_token_size = 2
|
||||
```
|
||||
|
||||
3. 데이터베이스를 재시작합니다. (이 과정은 반드시 필요합니다.)
|
||||
4. 일부 테이블의 전문 검색 색인을 다음과 같이 재구성합니다.
|
||||
|
||||
- 게시물 검색을 위한 설정 ( [참조](https://github.com/mattermost/mattermost/issues/2033#issuecomment-182336690) )
|
||||
|
||||
``` sql
|
||||
DROP INDEX idx_posts_message_txt ON Posts;
|
||||
CREATE FULLTEXT INDEX idx_posts_message_txt ON Posts (Message) WITH PARSER ngram;
|
||||
```
|
||||
|
||||
- 해시 태그 검색을 위한 설정 ( [참조](https://github.com/mattermost/mattermost/pull/4555) )
|
||||
|
||||
``` sql
|
||||
DROP INDEX idx_posts_hashtags_txt ON Posts;
|
||||
CREATE FULLTEXT INDEX idx_posts_hashtags_txt ON Posts (Hashtags) WITH PARSER ngram;
|
||||
```
|
||||
|
||||
- 사용자 검색을 위한 설정
|
||||
|
||||
`Users.idx_users_txt_all` 과 `Users.idx_users_names_all` 을 n-gram 없이 재구성합니다.
|
||||
@@ -0,0 +1,47 @@
|
||||
---
|
||||
title: "Environment variables"
|
||||
---
|
||||
<PlanAvailability slug="all-commercial" />
|
||||
|
||||
You can use environment variables to manage the configuration. Environment variables override settings in `config.json`. If a change to a setting in `config.json` requires a restart for it to take effect, then changes to the corresponding environment variable also require a server restart.
|
||||
|
||||
The name of the environment variable for any setting can be derived from the name of that setting in `config.json`. For example, to derive the name of the Site URL setting:
|
||||
|
||||
1. Find the setting in `config.json`. In this case, *ServiceSettings.SiteURL*.
|
||||
2. Add `MM_` to the beginning and convert all characters to uppercase and replace the `.` with `_`. For example, *MM_SERVICESETTINGS_SITEURL*.
|
||||
3. The setting becomes `export MM_SERVICESETTINGS_SITEURL="http://example.com"`.
|
||||
|
||||
<Note>
|
||||
|
||||
- If Mattermost is run from an initialization file, environment variables can be set via `Environment=<>`, or `EnvironmentFile=<path/to/file>`. In the second case, the file specified contains the list of environment variables to set.
|
||||
- From Mattermost v7.5, environment configuration parsing supports JSON for `MM_PLUGINSETTINGS_PLUGINS` and `MM_PLUGINSETTINGS_PLUGINSTATES`. This is especially helpful for Helm configuration files, provided all plugins are configured at the same time. For example, `MM_PLUGINSETTINGS_PLUGINSTATES="{\"com.mattermost.calls\":{\"Enable\":true},\"com.mattermost.nps\":{\"Enable\":true}}"`.
|
||||
- When settings are configured through an environment variable, system admins can't modify them in the System Console. If a setting is configured through an environment variable, and any other changes are made in the System Console, the value stored of the environment variable will be written back to the `config.json` as that setting's value.
|
||||
- For any setting that's not set in `config.json` or in environment variables, the Mattermost server uses the setting's default value as documented in the sections below on this page.
|
||||
|
||||
</Note>
|
||||
|
||||
<Warning>
|
||||
|
||||
- Environment variables for Mattermost settings that are set within the active shell will take effect when migrating configuration. For more information, see the [configuration in a database](/administration-guide/configure/configuration-in-your-database) documentation.
|
||||
- Database connection strings for the database read and search replicas need to be formatted using [URL encoding](https://www.w3schools.com/tags/ref_urlencode.asp). Incorrectly formatted strings may cause some characters to terminate the string early, resulting in issues when the connection string is parsed.
|
||||
|
||||
</Warning>
|
||||
|
||||
## Override Mattermost license file
|
||||
|
||||
You can use an environment variable to override any license in the database or file configuration without replacing those licenses. When starting the server, specify the license key as `MM_LICENSE` with the contents of a license file.
|
||||
|
||||
<Note>
|
||||
|
||||
If `MM_LICENSE` is set to a non-empty string, but the license specified is not valid, the Mattermost server will be started without a license.
|
||||
|
||||
In a High Availability deployment, using an environment variable to override a server license only affects the individual app server and doesn't propagate to other servers in the cluster.
|
||||
|
||||
</Note>
|
||||
|
||||
## Load custom configuration defaults
|
||||
|
||||
This custom configuration applies only if the values are not already present in the current server configuration.
|
||||
|
||||
1. Create a JSON file that contains the custom configuration defaults. For example, `custom.json`.
|
||||
2. When starting the server, point the custom defaults environment variable to the defaults file: `MM_CUSTOM_DEFAULTS_PATH=custom.json`.
|
||||
File diff suppressed because it is too large
Load Diff
40
docs/main/administration-guide/configure/install-boards.mdx
Normal file
40
docs/main/administration-guide/configure/install-boards.mdx
Normal file
@@ -0,0 +1,40 @@
|
||||
---
|
||||
title: "Install Mattermost Boards"
|
||||
---
|
||||
<PlanAvailability slug="entry-ent" />
|
||||
|
||||
Mattermost Boards is not enabled by default for new Mattermost Enterprise instances. If the Mattermost Boards plugin isn't enabled for your Mattermost workspace, self-hosted Enterprise customers can install this plugin by manually uploading the binary release file into the System Console and enabling it.
|
||||
|
||||
Mattermost Cloud Enterprise customers can request the Boards plugins be enabled by contacting their Mattermost Account Manager or by [creating a support ticket](https://support.mattermost.com/hc/en-us/requests/new?ticket_form_id=11184911962004) request.
|
||||
|
||||
<Note>
|
||||
|
||||
The Mattermost Boards plugin is currently in maintenance mode. While adoption of this plugin is still supported for Enterprise customers, we recommend system admins proceed at their own risk. Mattermost is no longer actively developing new features or future improvements for the Boards plugin, beyond addressing bug fixes reported by Enterprise customers and any necessary security patches.
|
||||
|
||||
In the future, Mattermost plans to deliver a core Boards feature as part of the platform. Migration from the Boards plugin to this upcoming feature will be required, which could potentially involve downtime or data migration complexities. Keep this in mind when deploying the Boards plugin in production environments.
|
||||
|
||||
</Note>
|
||||
|
||||
## Install the plugin
|
||||
|
||||
The following steps apply to customers in fully connected environments as well as Denied, Disrupted, Intermittent, and Limited (DDIL) environments. A Mattermost system admin must perform the following steps in Mattermost.
|
||||
|
||||
1. Download the latest Mattermost Boards plugin binary file from the [Mattermost Boards Releases](https://github.com/mattermost/mattermost-plugin-boards/releases) page.
|
||||
2. Log in to your Mattermost System Console as a system admin.
|
||||
3. Go to **Plugins \> Plugin Management**.
|
||||
4. Select **Upload Plugin** to upload the Boards plugin binary file you downloaded from the Mattermost Releases page.
|
||||
|
||||
## Mattermost configuration
|
||||
|
||||
1. Go to **Plugins \> Mattermost Boards**.
|
||||
2. Select **Enable Plugin** to enable the plugin.
|
||||
3. You can optionally enable **Enable Publicly-Shared Boards** so that board editors can share boards with people outside of your Mattermost instance, who can view the board without needing a Mattermost account.
|
||||
4. Select **Save** to save your changes.
|
||||
|
||||
## Access
|
||||
|
||||
See the [navigate boards](/end-user-guide/project-management/navigate-boards) documentation to learn how to create and access boards.
|
||||
|
||||
## Work with boards
|
||||
|
||||
See the [project and task management](/end-user-guide/project-management/project-management-index) end user documentation to learn how to align, define, organize, track, and manage work across teams.
|
||||
@@ -0,0 +1,460 @@
|
||||
---
|
||||
title: "Integrations configuration settings"
|
||||
---
|
||||
import useBaseUrl from '@docusaurus/useBaseUrl';
|
||||
|
||||
<PlanAvailability slug="all-commercial" />
|
||||
|
||||
Review and manage the following integration configuration options in the System Console by selecting the **Product** <img src={useBaseUrl('/img/ui/products_E82F.svg')} alt="Navigate between Channels, collaborative playbooks, and boards using the product menu icon." className="theme-icon" /> menu, selecting **System Console**, and then selecting **Integrations**:
|
||||
|
||||
- [Integrations management](#integrations-management)
|
||||
- [Bot Accounts](#bot-accounts)
|
||||
- [GIF](#gif)
|
||||
- [CORS](#cors)
|
||||
|
||||
<Tip>
|
||||
|
||||
System admins managing a self-hosted Mattermost deployment can edit the `config.json` file as described in the following tables. Each configuration value below includes a JSON path to access the value programmatically in the `config.json` file using a JSON-aware tool. For example, the `EnableIncomingWebhooks` value is under `ServiceSettings`.
|
||||
|
||||
- If using a tool such as [jq](https://stedolan.github.io/jq/), you'd enter: `cat config/config.json | jq '.ServiceSettings.EnableIncomingWebhooks'`
|
||||
- When working with the `config.json` file manually, look for an object such as `ServiceSettings`, then within that object, find the key `EnableIncomingWebhooks`.
|
||||
|
||||
</Tip>
|
||||
|
||||
------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
## Integrations management
|
||||
|
||||
Access the following configuration settings in the System Console by going to **Integrations \> Integration Management**.
|
||||
|
||||
### Enable incoming webhooks
|
||||
|
||||
Developers building integrations can create webhook URLs for public channels and private channels. See the [incoming webhooks](https://developers.mattermost.com/integrate/webhooks/incoming/) developer documentation to learn about creating webhooks, viewing samples, and letting community know about integrations you've built.
|
||||
|
||||
**True**: Incoming webhooks are allowed. To manage incoming webhooks, select **Integrations** from the Mattermost Product menu. The webhook URLs created can be used by external applications to create posts in any public or private channels that you have access to.
|
||||
|
||||
**False**: The **Integrations \> Incoming Webhooks** section of the Mattermost Product menu is hidden and all incoming webhooks are disabled.
|
||||
|
||||
<Important>
|
||||
|
||||
Security note: By enabling this feature, users may be able to perform [phishing attacks](https://en.wikipedia.org/wiki/Phishing) by attempting to impersonate other users. To combat these attacks, a BOT tag appears next to all posts from a webhook. Enable at your own risk.
|
||||
|
||||
</Important>
|
||||
|
||||
<table style={{width: '97%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '96%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>This feature's <code>config.json</code> setting is <code>"EnableIncomingWebhooks": true</code> with options <code>true</code> and <code>false</code>.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
### Enable outgoing webhooks
|
||||
|
||||
Developers building integrations can create webhook tokens for public channels. Trigger words are used to fire new message events to external integrations. For security reasons, outgoing webhooks are only available in public channels. See the [outgoing webhooks](https://developers.mattermost.com/integrate/webhooks/outgoing/) developer documentation to learn about creating webhooks and viewing samples.
|
||||
|
||||
**True**: Outgoing webhooks will be allowed. To manage outgoing webhooks, select **Integrations** from the Mattermost Product menu.
|
||||
|
||||
**False**: The **Integrations \> Outgoing Webhooks** of the Mattermost Product menu is hidden and all outgoing webhooks are disabled.
|
||||
|
||||
<Important>
|
||||
|
||||
Security note: By enabling this feature, users may be able to perform [phishing attacks](https://en.wikipedia.org/wiki/Phishing) by attempting to impersonate other users. To combat these attacks, a BOT tag appears next to all posts from a webhook. Enable at your own risk.
|
||||
|
||||
</Important>
|
||||
|
||||
<table style={{width: '97%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '96%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>This feature's <code>config.json</code> setting is <code>"EnableOutgoingWebhooks": true</code> with options <code>true</code> and <code>false</code>.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<Note>
|
||||
|
||||
Disabling this configuration setting in larger deployments may improve server performance in the following areas:
|
||||
|
||||
- Reduced Network Traffic: Outgoing webhooks generate network requests to external services. Disabling them reduces the amount of traffic and resource usage related to those requests.
|
||||
- Decreased Load on Server: Handling webhook events and managing connections to external services uses server resources. By disabling outgoing webhooks, the server workload is reduced, allowing it to allocate more resources to other important tasks.
|
||||
- Improved Response Time: When outgoing webhooks are enabled, the server waits for the external services to return responses, potentially slowing down the performance if the external services are slow or unresponsive. Disabling them removes this dependency, leading to faster response times for user requests.
|
||||
- Lower Memory Usage: Webhooks need memory to process and store data about the requests and responses. Disabling them can free up memory which can be used to improve overall server performance.
|
||||
- Simplified Error Handling: Managing errors and retries for outgoing webhook failures can add complexity and overhead. Disabling outgoing webhooks can simplify error handling and reduce the processing overhead associated with it.
|
||||
- However, outgoing webhooks are often essential for integrating Mattermost with other services and workflows. It’s important to balance performance improvements with the needs of your organization and users.
|
||||
|
||||
</Note>
|
||||
|
||||
### Enable custom slash commands
|
||||
|
||||
Slash commands send events to external integrations that send a response back to Mattermost.
|
||||
|
||||
**True**: Allow users to create custom slash commands from **Main Menu \> Integrations \> Commands**.
|
||||
|
||||
**False**: Slash commands are hidden in the **Integrations** user interface.
|
||||
|
||||
<table style={{width: '91%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '90%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>This feature's <code>config.json</code> setting is <code>"EnableCommands": false</code> with options <code>true</code> and <code>false</code>.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
### Enable OAuth 2.0 service provider
|
||||
|
||||
**True**: Mattermost acts as an OAuth 2.0 service provider allowing Mattermost to authorize API requests from external applications.
|
||||
|
||||
**False**: Mattermost does not function as an OAuth 2.0 service provider.
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
<col style={{width: '100%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>This feature's <code>config.json</code> setting is <code>"EnableOAuthServiceProvider": true</code> with options <code>true</code> and <code>false</code>.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<Note>
|
||||
|
||||
Cloud admins can't modify this configuration setting.
|
||||
|
||||
</Note>
|
||||
|
||||
### Enable dynamic client registration
|
||||
|
||||
**True**: Enables Dynamic Client Registration (DCR) allowing applications to programmatically register OAuth 2.0 clients without manual admin intervention via the `POST /api/v4/oauth/apps/register` endpoint.
|
||||
|
||||
**False**: Dynamic Client Registration is disabled. OAuth 2.0 applications must be registered manually through the System Console.
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
<col style={{width: '100%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>This feature's <code>config.json</code> setting is <code>"EnableDynamicClientRegistration": false</code> with options <code>true</code> and <code>false</code>.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<Important>
|
||||
|
||||
**Security Warning**: When enabled, the DCR endpoint (`/api/v4/oauth/apps/register`) is **publicly accessible without authentication**. Any user or application can register OAuth clients on your Mattermost server. Only enable this setting if you understand and accept this security model, or have additional network-level access controls in place.
|
||||
|
||||
</Important>
|
||||
|
||||
<Note>
|
||||
|
||||
Cloud admins can't modify this configuration setting.
|
||||
|
||||
</Note>
|
||||
|
||||
### DCR redirect URI allowlist
|
||||
|
||||
A comma-separated list of permitted redirect URIs for OAuth Dynamic Client Registration (DCR). When configured, only OAuth clients that register via the DCR endpoint (`POST /api/v4/oauth/apps/register`) with a redirect URI matching an entry in this list will be accepted. Leave blank to allow any redirect URI.
|
||||
|
||||
In the System Console, enter URIs as a comma-separated list. When setting this value directly in `config.json` or via environment variable, provide URIs as a JSON string array (for example, `["https://example.com/callback", "https://app.example.com/oauth"]`).
|
||||
|
||||
This setting applies only when [Enable dynamic client registration](/administration-guide/configure/integrations-configuration-settings#enable-dynamic-client-registration) is enabled.
|
||||
|
||||
Redirect URIs are matched per URL component. Patterns support two wildcards:
|
||||
|
||||
- `*` matches any characters except `/` (for example, a single path segment or a hostname label).
|
||||
- `**` matches any characters including `/` (for example, a multi-segment path).
|
||||
|
||||
Wildcards are applied within URL components only: host wildcards match against the host, path wildcards match against the path, and a wildcard in one component can't satisfy another component. For example, `https://*.example.com/**` matches `https://app.example.com/callback` but not `https://attacker.example.net`.
|
||||
|
||||
Query strings are matched only when the pattern explicitly includes one. A pattern without a query string (such as `https://app.example.com/callback` or `https://app.example.com/**`) matches only redirect URIs that have no query string. To allow redirect URIs that carry query parameters, include a query component in the pattern, for example `https://app.example.com/callback?tenant=*`. To allow a callback both with and without a query string, add both patterns.
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
<col style={{width: '100%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>This feature's <code>config.json</code> setting is <code>"DCRRedirectURIAllowlist": []</code> with string array input, such as <code>["https://example.com/callback", "https://app.example.com/oauth"]</code>. |</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<Note>
|
||||
|
||||
Cloud admins can't modify this configuration setting.
|
||||
|
||||
</Note>
|
||||
|
||||
### Integration request timeout
|
||||
|
||||
The number of seconds to wait for external integration HTTP requests before timing out, including [custom slash commands](https://developers.mattermost.com/integrate/slash-commands/custom/), [outgoing webhooks](https://developers.mattermost.com/integrate/webhooks/outgoing/), [interactive messages](https://developers.mattermost.com/integrate/plugins/interactive-messages/), and [interactive dialogs](https://developers.mattermost.com/integrate/plugins/interactive-dialogs/). Increase this value if you have external integrations that can take some time to generate an HTTP response, or experience delayed responses due to latency.
|
||||
|
||||
<table style={{width: '81%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '80%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>This feature's <code>config.json</code> setting is <code>"OutgoingIntegrationRequestsTimeout": 30</code>.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
### Enable integrations to override usernames
|
||||
|
||||
**True**: Webhooks, slash commands, OAuth 2.0 apps, and other integrations, will be allowed to change the username they are posting as. If no username is present, the username for the post is the same as it would be for a setting of `False`.
|
||||
|
||||
**False**: **(Default)** Custom slash commands can only post as the username of the user who used the slash command. OAuth 2.0 apps can only post as the username of the user who set up the integration. For incoming webhooks and outgoing webhooks, the username is "webhook". See [https://developers.mattermost.com/integrate/other-integrations/](https://developers.mattermost.com/integrate/other-integrations/) for more details.
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
<col style={{width: '100%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>This feature's <code>config.json</code> setting is <code>"EnablePostUsernameOverride": false</code> with options <code>true</code> and <code>false</code>.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
### Enable integrations to override profile picture icons
|
||||
|
||||
**True**: Webhooks, slash commands, and other integrations, will be allowed to change the profile picture they post with.
|
||||
|
||||
**False**: **(Default)** Webhooks, slash commands, and OAuth 2.0 apps can only post with the profile picture of the account they were set up with. See [https://developers.mattermost.com/integrate/other-integrations/](https://developers.mattermost.com/integrate/other-integrations/) for more details.
|
||||
|
||||
<table style={{width: '98%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '97%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>This feature's <code>config.json</code> setting is <code>"EnablePostIconOverride": false</code> with options <code>true</code> and <code>false</code>.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
### Enable personal access tokens
|
||||
|
||||
**True**: Users can create [personal access tokens](https://developers.mattermost.com/integrate/admin-guide/admin-personal-access-token/) for integrations in **Profile \> Security**. They can be used to authenticate against the API and give full access to the account.
|
||||
|
||||
To manage who can create personal access tokens or to search users by token ID, go to the **System Console \> Users** page.
|
||||
|
||||
**False**: Personal access tokens are disabled on the server.
|
||||
|
||||
<table style={{width: '98%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '97%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>This feature's <code>config.json</code> setting is <code>"EnableUserAccessTokens": false</code> with options <code>true</code> and <code>false</code>.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
### Enforce incoming webhook channel locking
|
||||
|
||||
When enabled, this setting enforces that all incoming webhooks must be locked to their designated channel and cannot post messages to other channels. This provides administrators with greater control over webhook security and ensures that webhooks can only post to their intended channels.
|
||||
|
||||
**True**: Incoming webhooks are required to be locked to their specific channel. The **Lock to this channel** option is automatically enabled and cannot be disabled when creating or editing webhooks.
|
||||
|
||||
**False**: **(Default)** Incoming webhook creators can choose whether to lock webhooks to a specific channel by selecting **Lock to this channel**, or allow the webhook to post to any public channel or private channel the webhook creator is a member of.
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
<col style={{width: '100%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>This feature's <code>config.json</code> setting is <code>"EnforceIncomingWebhookChannelLocking": false</code> with options <code>true</code> and <code>false</code>.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
## Bot accounts
|
||||
|
||||
Access the following configuration settings in the System Console by going to **Integrations \> Bot Accounts**.
|
||||
|
||||
### Enable bot account creation
|
||||
|
||||
**True**: **(Default for Cloud deployments)** Users can create bot accounts for integrations in **Integrations \> Bot Accounts**. Bot accounts are similar to user accounts except they cannot be used to log in. See [documentation](https://developers.mattermost.com/integrate/admin-guide/admin-bot-accounts/) to learn more.
|
||||
|
||||
**False**: **(Default for self-hosted deployments)** Bot accounts cannot be created through the user interface or the RESTful API. Plugins can still create and manage bot accounts.
|
||||
|
||||
<table style={{width: '99%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '99%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>This feature's <code>config.json</code> setting is <code>"EnableBotAccountCreation": false</code> with options <code>true</code> and <code>false</code>.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
### Disable bot accounts when owner is deactivated
|
||||
|
||||
**True**: When a user is deactivated, disables all bot accounts managed by the user. To re-enable bot accounts, go to **Integrations \> Bot Accounts**.
|
||||
|
||||
**False**: When a user is deactivated, all bot accounts managed by the user remain active.
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
<col style={{width: '100%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>This feature's <code>config.json</code> setting is <code>"DisableBotsWhenOwnerIsDeactivated": false</code> with options <code>true</code> and <code>false</code>.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
## GIF
|
||||
|
||||
Access the following configuration settings in the System Console by going to **Integrations \> GIF**.
|
||||
|
||||
### Enable GIF picker
|
||||
|
||||
**True**: Allow users to select GIFs from the emoji picker via a GIPHY integration.
|
||||
|
||||
**False**: GIFs cannot be selected in the emoji picker.
|
||||
|
||||
<table style={{width: '91%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '90%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>This feature's <code>config.json</code> setting is <code>"EnableGifPicker": true</code> with options <code>true</code> and <code>false</code>.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<Important>
|
||||
|
||||
[Link previews](/administration-guide/configure/site-configuration-settings#enable-message-link-previews) must be enabled in order to display GIF link previews. Mattermost deployments restricted to access behind a firewall must open port 443 (for all request types) for this feature to work.
|
||||
|
||||
</Important>
|
||||
|
||||
------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
## CORS
|
||||
|
||||
The following configuration settings are applicable only to self-hosted deployments. Access the following configuration settings in the System Console by going to **Integrations \> CORS**.
|
||||
|
||||
### Enable cross-origin requests from
|
||||
|
||||
Enable HTTP cross-origin requests from specific domains.
|
||||
|
||||
- Type `*` to allow CORS from any domain.
|
||||
- Enter a specific domain or multiple domains separated by spaces.
|
||||
- Type `null` to prevent CORS from any domain.
|
||||
- Leave blank to disable it and use the Mattermost **Site URL** instead.
|
||||
|
||||
<Note>
|
||||
|
||||
Ensure you've entered your [Site URL](/administration-guide/configure/environment-configuration-settings#site-url) before enabling this setting to prevent losing access to the System Console after saving. If you lose access to the System Console after changing this setting, you can set your Site URL through the `config.json` file.
|
||||
|
||||
</Note>
|
||||
|
||||
<table style={{width: '72%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '72%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>This feature's <code>config.json</code> setting is <code>"AllowCorsFrom": ""</code> with string input.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
### CORS exposed headers
|
||||
|
||||
Whitelist of headers that will be accessible to the requester.
|
||||
|
||||
<table style={{width: '77%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '76%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>This feature's <code>config.json</code> setting is <code>"CorsExposedHeaders": ""</code> with string input.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
### CORS allow credentials
|
||||
|
||||
**True**: Requests that pass validation will include the `Access-Control-Allow-Credentials` header.
|
||||
|
||||
**False**: Requests won't include the `Access-Control-Allow-Credentials` header.
|
||||
|
||||
<table style={{width: '96%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '95%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>This feature's <code>config.json</code> setting is <code>"CorsAllowCredentials": false</code> with options <code>true</code> and <code>false</code>.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
### CORS debug
|
||||
|
||||
**True**: Prints messages to the logs to help when developing an integration that uses CORS. These messages will include the structured key value pair `"source": "cors"`.
|
||||
|
||||
**False**: Debug messages not printed to the logs.
|
||||
|
||||
<table style={{width: '87%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '86%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>This feature's <code>config.json</code> setting is <code>"CorsDebug": false</code> with options <code>true</code> and <code>false</code>.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
## Embedding
|
||||
|
||||
The following configuration settings are applicable only to self-hosted deployments. Access the following configuration settings in the System Console by going to **Integrations \> Embedding**.
|
||||
|
||||
### Frame ancestors
|
||||
|
||||
Enter a space-separated list of domains that are allowed to embed the Mattermost web client via an iFrame. Leave blank to disallow embedding. Leave blank to disable embedding. Blank by default.
|
||||
|
||||
<table style={{width: '56%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '55%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>This feature's <code>config.json</code> setting is <code>"FrameAncestors".</code></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<Note>
|
||||
|
||||
Embedding Mattermost via an iFrame can provide seamless integration for collaboration into an organization’s existing tools and workflows. However, you must ensure that correct configurations are in place to allow communication between the iframe and the parent domain without violating security.
|
||||
|
||||
</Note>
|
||||
184
docs/main/administration-guide/configure/manage-plugins.mdx
Normal file
184
docs/main/administration-guide/configure/manage-plugins.mdx
Normal file
@@ -0,0 +1,184 @@
|
||||
---
|
||||
title: "Install and manage plugins"
|
||||
---
|
||||
import useBaseUrl from '@docusaurus/useBaseUrl';
|
||||
|
||||
Plugins extend Mattermost with new features and integrations, from pre-built integrations such as GitHub, Jira, and Zoom to custom plugins your team builds in-house. As a system admin, you can install, enable, configure, update, and remove plugins using either the System Console or the [mmctl command line tool](/administration-guide/manage/mmctl-command-line-tool).
|
||||
|
||||
This page describes how to manage the plugin lifecycle. For a conceptual overview of pre-built and custom plugins, see the [plugins](/integrations-guide/plugins) documentation. For the complete list of plugin configuration options, see the [plugins configuration settings](/administration-guide/configure/plugins-configuration-settings) documentation. To build your own plugin, see the [Mattermost plugin developer](https://developers.mattermost.com/integrate/plugins/) documentation.
|
||||
|
||||
<Note>
|
||||
|
||||
You must be a system admin to install and manage plugins. Plugins are managed at the server level and apply to your entire Mattermost deployment.
|
||||
|
||||
</Note>
|
||||
|
||||
## Before you begin
|
||||
|
||||
Plugin availability and the actions you can take depend on a few configuration settings found in the System Console under **Plugins > Plugin Management**. Review these settings before installing or updating plugins:
|
||||
|
||||
- **Enable plugins** (`PluginSettings.Enable`) must be set to **true** (the default) for the plugin system to work. When disabled, all plugins are turned off.
|
||||
- **Enable Marketplace** (`PluginSettings.EnableMarketplace`) must be set to **true** (the default) to install plugins from the in-product Marketplace.
|
||||
- **Enable remote Marketplace** (`PluginSettings.EnableRemoteMarketplace`) must be set to **true** (the default) for the Marketplace to connect to the remote endpoint and list community and Mattermost-provided plugins. Set this to **false** for servers that can't reach the internet; the Marketplace then shows only pre-packaged and installed plugins.
|
||||
- **Upload Plugin** (`PluginSettings.EnableUploads`) must be set to **true** to upload plugin bundles from your local computer. This setting applies to self-hosted deployments only.
|
||||
|
||||
<Note>
|
||||
|
||||
If you receive a `Received invalid response from the server` error when uploading a plugin, the [maximum file size](/administration-guide/configure/environment-configuration-settings#maximum-file-size) configuration setting is likely too small for the plugin bundle. Increase it, and update any proxy settings as needed.
|
||||
|
||||
</Note>
|
||||
|
||||
See the [plugins configuration settings](/administration-guide/configure/plugins-configuration-settings) documentation for details on each of these settings, including their `config.json` paths and environment variables.
|
||||
|
||||
## Plugin installation methods
|
||||
|
||||
You can install a plugin from the in-product Marketplace, by uploading a plugin bundle, or by using mmctl. Pre-packaged plugins that ship with the Mattermost Server are installed and upgraded automatically when **Automatic prepackaged plugins** (`PluginSettings.AutomaticPrepackagedPlugins`) is enabled (the default).
|
||||
|
||||
### App Marketplace
|
||||
|
||||
Installing from the Marketplace is the recommended method for pre-built plugins. The Marketplace always installs the latest compatible version, and plugins downloaded from the Marketplace are signature-validated.
|
||||
|
||||
1. In Mattermost, from the Product menu <img src={useBaseUrl('/img/ui/products_E82F.svg')} alt="Navigate between Channels, collaborative playbooks, and boards using the product menu icon." className="theme-icon" />, select **App Marketplace**.
|
||||
2. Search for or scroll to the plugin you want, and then select **Install**.
|
||||
3. Once the plugin is installed, select **Configure** to open its settings in the System Console, or **Enable** to turn it on with the default configuration.
|
||||
4. Confirm the installation succeeded: the plugin appears in the **Installed Plugins** list under **Plugins > Plugin Management**, and its features are available in Mattermost.
|
||||
|
||||
<Tip>
|
||||
|
||||
The [Mattermost Marketplace](https://mattermost.com/marketplace/) website offers an expanded selection of community-supported integrations.
|
||||
|
||||
</Tip>
|
||||
|
||||
### Plugin upload
|
||||
|
||||
Upload a plugin bundle when you're installing a custom or third-party plugin that isn't in the Marketplace, or when your server runs in an air-gapped or restricted environment. Uploading requires the **Upload Plugin** setting to be enabled and the **Require plugin signature** (`PluginSettings.RequirePluginSignature`) setting to be disabled.
|
||||
|
||||
1. Download the plugin bundle (a `.tar.gz` file), typically from the plugin's GitHub releases page. Many plugins offer a separate, smaller bundle for each platform (for example, `linux-amd64`) alongside a larger universal bundle that contains the binaries for all supported platforms. Download the bundle that matches your server's operating system and architecture; a bundle built for a different platform won't start. If you use the universal bundle instead, Mattermost automatically selects the correct binary for your server.
|
||||
2. Log in to your Mattermost System Console as a system admin.
|
||||
3. Go to **Plugins > Plugin Management**.
|
||||
4. In the **Upload Plugin** section, select **Choose File**, select the plugin bundle you downloaded, and then select **Upload**.
|
||||
5. The plugin appears in the **Installed Plugins** list. Select **Enable** to turn it on.
|
||||
|
||||
### mmctl
|
||||
|
||||
The [mmctl command line tool](/administration-guide/manage/mmctl-command-line-tool) is useful for scripted or remote plugin management. Plugins must be enabled in the server configuration first.
|
||||
|
||||
Several commands take the plugin's ID, shown as `<id>` below. A plugin's ID is the `id` value in its `plugin.json` manifest. It's often the plugin's name, such as `github` or `playbooks`, but some plugins use a reverse-DNS identifier, such as `com.mattermost.calls` for the Calls plugin. To list the IDs of installed plugins, run `mmctl plugin list`.
|
||||
|
||||
- Install the latest version from the Marketplace by plugin ID:
|
||||
|
||||
```sh
|
||||
mmctl plugin marketplace install <id>
|
||||
```
|
||||
|
||||
- Install a plugin bundle from your local computer:
|
||||
|
||||
```sh
|
||||
mmctl plugin add myplugin.tar.gz
|
||||
```
|
||||
|
||||
- Install a plugin bundle from a URL:
|
||||
|
||||
```sh
|
||||
mmctl plugin install-url https://example.com/myplugin.tar.gz
|
||||
```
|
||||
|
||||
After installing, enable the plugin by its ID:
|
||||
|
||||
```sh
|
||||
mmctl plugin enable <id>
|
||||
```
|
||||
|
||||
## Enable or disable a plugin
|
||||
|
||||
Installing a plugin doesn't turn it on automatically. Enable a plugin to make it available to users, and disable it to remove it from the user interface without uninstalling it.
|
||||
|
||||
To enable or disable a plugin in the System Console:
|
||||
|
||||
1. Go to **Plugins > Plugin Management**.
|
||||
2. In the **Installed Plugins** list, locate the plugin.
|
||||
3. Select **Enable** or **Disable**.
|
||||
|
||||
To enable or disable a plugin with mmctl:
|
||||
|
||||
```sh
|
||||
mmctl plugin enable <id>
|
||||
mmctl plugin disable <id>
|
||||
```
|
||||
|
||||
<Note>
|
||||
|
||||
Disabling a plugin immediately removes it from the user interface and stops the plugin from running. The plugin remains installed and can be re-enabled at any time.
|
||||
|
||||
</Note>
|
||||
|
||||
## Configure a plugin
|
||||
|
||||
Most plugins have their own settings page. After a plugin is installed, go to **Plugins** in the System Console and select the plugin by name to configure it, then select **Save**. Refer to the documentation for each plugin for details on its available settings.
|
||||
|
||||
## Update a plugin
|
||||
|
||||
We recommend keeping plugins up to date as new versions are released. Updates are generally seamless and don't interrupt the user experience, but you should review each plugin's release notes for compatibility considerations, and test updates in a staging environment before applying them in production.
|
||||
|
||||
You can update a plugin using any of the following methods:
|
||||
|
||||
- **Pre-packaged plugins** are upgraded automatically when the **Automatic prepackaged plugins** setting is enabled (the default). If a newer version is already installed, no change is made.
|
||||
- **Marketplace plugins** show an **Update** option in the App Marketplace when a newer version is available. Select it to install the latest version.
|
||||
- **Uploaded plugins** are updated by uploading a newer bundle with the same plugin ID through **Plugins > Plugin Management**. The new version overwrites the existing one.
|
||||
- **mmctl** updates an installed plugin when you add a bundle that has the same plugin ID. Use the `--force` (`-f`) flag to overwrite the existing version:
|
||||
|
||||
```sh
|
||||
mmctl plugin add myplugin.tar.gz --force
|
||||
mmctl plugin install-url https://example.com/myplugin.tar.gz --force
|
||||
```
|
||||
|
||||
The `--force` flag overwrites the installed plugin without asking for confirmation, so verify the new bundle's compatibility (and ideally test it in a staging environment) before applying it in production.
|
||||
|
||||
You can also reinstall the latest Marketplace version with `mmctl plugin marketplace install <id>`.
|
||||
|
||||
<Tip>
|
||||
|
||||
To confirm the version currently installed, go to **Plugins > Plugin Management** and review the **Installed Plugins** list, or run `mmctl plugin list`.
|
||||
|
||||
</Tip>
|
||||
|
||||
## Remove a plugin
|
||||
|
||||
Removing a plugin disables it and uninstalls it from the server.
|
||||
|
||||
To remove a plugin in the System Console:
|
||||
|
||||
1. Go to **Plugins > Plugin Management**.
|
||||
2. In the **Installed Plugins** list, locate the plugin.
|
||||
3. Select **Remove**.
|
||||
|
||||
To remove a plugin with mmctl:
|
||||
|
||||
```sh
|
||||
mmctl plugin delete <id>
|
||||
```
|
||||
|
||||
<Note>
|
||||
|
||||
Removing a plugin uninstalls it from the server and stops it from running, but Mattermost preserves the plugin's associated data:
|
||||
|
||||
- **Configuration**: The plugin's configuration is retained and marked as disabled rather than deleted. Reinstalling the same plugin restores its previous settings.
|
||||
- **Key-value store data**: Data the plugin saved to the key-value (KV) store is preserved. It's cleared only by the plugin itself through the plugin API, not by removing the plugin.
|
||||
- **Bot accounts**: Bot accounts the plugin created remain on the server and stay active. To remove them, deactivate the bot accounts manually in **System Console > Integrations > Bot Accounts**.
|
||||
|
||||
Because the configuration and KV store data persist, removal is effectively reversible: reinstalling the plugin restores its prior configuration and data.
|
||||
|
||||
Mattermost doesn't provide a built-in way to fully delete a removed plugin's retained configuration or key-value data through the System Console or mmctl. If you must purge this data to meet a data-retention or compliance requirement, contact Mattermost support for guidance, as it requires direct changes to the Mattermost database.
|
||||
|
||||
</Note>
|
||||
|
||||
## Air-gapped and restricted environments
|
||||
|
||||
For deployments without internet access, set **Enable remote Marketplace** to **false** so the Marketplace shows only pre-packaged and installed plugins, and install plugins by uploading the bundle directly through the System Console. See the [air-gapped deployment](/deployment-guide/deployment-scenarios/air-gapped-deployment) documentation for details.
|
||||
|
||||
## Related documentation
|
||||
|
||||
- [Plugins overview](/integrations-guide/plugins) - Learn about pre-built and custom plugins.
|
||||
- [Pre-built integrations](/integrations-guide/popular-integrations) - Browse available pre-built plugins and how to get them.
|
||||
- [Plugins configuration settings](/administration-guide/configure/plugins-configuration-settings) - Review every plugin configuration setting.
|
||||
- [mmctl command line tool](/administration-guide/manage/mmctl-command-line-tool) - Manage plugins from the command line.
|
||||
@@ -0,0 +1,81 @@
|
||||
---
|
||||
title: "Manage user surveys"
|
||||
---
|
||||
<PlanAvailability slug="all-commercial" />
|
||||
|
||||
In a self-hosted Mattermost deployment, you can use the Mattermost User Survey integration to gather direct feedback from your Mattermost users to identify what's working well and what's not with your Mattermost instance.
|
||||
|
||||
All user responses are stored in and remain within your self-hosted deployment, and no telemetry data is sent back to Mattermost. You can export a CSV report of NPS scores and user responses for further analysis, or to share your feedback data with Mattermost. You can schedule when each survey begins, define how long each survey lasts, specify teams excluded from the survey, as well as customize both a welcome message and a user question you want feedback on.
|
||||
|
||||
<Important>
|
||||
|
||||
The User Satisfaction Survey Plugin is the recommended approach for gathering user feedback, replacing the deprecated [User Satisfaction Survey Plugin](/administration-guide/manage/user-satisfaction-surveys) for new deployments.
|
||||
|
||||
</Important>
|
||||
|
||||
## Setup
|
||||
|
||||
You must be a Mattermost system admin to [upload the plugin](#install) to your Mattermost self-hosted deployment [enable it](#enable), [create surveys](#create-surveys), and [export survey responses](#export-survey-responses) using the System Console.
|
||||
|
||||
The User Survey integration is compatible with Mattermost v9.11.2 or later.
|
||||
|
||||
## Install
|
||||
|
||||
From Mattermost v9.11.2 (ESR) and Mattermost Cloud v10, this plugin is pre-packaged with the Mattermost Server. If your Mattermost deployment is on a prior release, download the [latest plugin binary release](https://github.com/mattermost/mattermost-plugin-user-survey/releases), and upload it to your server via **System Console \> Plugin Management**.
|
||||
|
||||
### Upgrade
|
||||
|
||||
We recommend updating this integration as new versions are released. Generally, updates are seamless and don't interrupt the user experience in Mattermost.
|
||||
|
||||
Visit the [Releases page](https://github.com/mattermost/mattermost-plugin-user-survey/releases) for the latest release, available releases, and compatibiilty considerations.
|
||||
|
||||
## Enable
|
||||
|
||||
Go to **System Console \> Plugins \> User Survey** to enable this integration.
|
||||
|
||||
Once the integration is installed and enabled, create surveys by completing configuration in the System Console, as described below.
|
||||
|
||||
### Create surveys
|
||||
|
||||
Under **Survey setup**, specify the date, time, and details for a new survey:
|
||||
|
||||
1. **Send next survey at**: Specify the date and time when the survey will begin rolling out to users.
|
||||
|
||||
> <div class="note">
|
||||
>
|
||||
> <div class="title">
|
||||
>
|
||||
> Note
|
||||
>
|
||||
> </div>
|
||||
>
|
||||
> A single survey can be active at a time. If you already have an active survey running, you'll need to reschedule your new survey to start on a date after the current survey expires. Alternatively, you can end the active survey early by selecting **End survey**.
|
||||
>
|
||||
> </div>
|
||||
|
||||
2. **Survey expiry (days)**: Specify how long the survey will be open to responses in days.
|
||||
3. **Exclude specific teams**: Specify who will receive the survey. You can send the survey to all users, to all users on specific teams, or omit all users from specific teams.
|
||||
|
||||

|
||||
|
||||
4. **Survey message text**: Customize the introductory message text users see when prompted to complete the survey.
|
||||
5. **Linear scale question (1-10)**: This question is required that helps calculate the NPS score.
|
||||
6. **Textual question**: This question is required that helps gather user feedback.
|
||||
7. **Textual question (Optional)**: You can optionally specify a text-based question for your survey.
|
||||
8. Select **Save**. Your new survey is scheduled, and displays under **Active and past surveys** once the survey is shared with users.
|
||||
|
||||

|
||||
|
||||
## Active surveys
|
||||
|
||||
When a survey starts, all users recieve a direct message from a feedback bot containing the active survey. The survey includes one mandatory scale-based question, and optional text-based questions.
|
||||
|
||||

|
||||
|
||||
Users must answer all required questions in order to submit their response. When a user selects **Submit**, their responses are recorded.
|
||||
|
||||
## Export survey responses
|
||||
|
||||
Select **Export responses** to download a CSV file containing NPS scores and user responses gatherered through the survey. You can export data from active surveys which will contain data collected so far.
|
||||
|
||||

|
||||
@@ -0,0 +1,80 @@
|
||||
---
|
||||
title: "Optimize your Mattermost workspace"
|
||||
---
|
||||
import useBaseUrl from '@docusaurus/useBaseUrl';
|
||||
|
||||
<PlanAvailability slug="all-commercial" />
|
||||
|
||||
With workspace optimizations, system admins can review their workspace health and growth scores, then take advantage of recommended actions for ensuring their workspace is running smoothly and teams are maximizing productivity.
|
||||
|
||||
System admins can access their workspace optimization page in the System Console by selecting the **Product** <img src={useBaseUrl('/img/ui/products_E82F.svg')} alt="Navigate between Channels, collaborative playbooks, and boards using the product menu icon." className="theme-icon" /> menu, selecting **System Console**, and going to **Reporting \> Workspace Optimization**.
|
||||
|
||||

|
||||
|
||||
## How is the overall score calculated?
|
||||
|
||||
The highest score possible is 100. Your score is calculated based on the type of issue reported and the level of potential security risk introduced to your Mattermost deployment if ignored.
|
||||
|
||||
Each item on the dashboard is calculated based on its individual impact score. These differ depending on whether they're problems, warnings, or suggestions. For example, if SSL encryption isn't configured in your workspace, Mattermost reports that as a problem, which reduces your score until it's addressed.
|
||||
|
||||
Warnings impact your score less than problems, and suggestions have the least impact on your score.
|
||||
|
||||
Want to improve your overall workspace optimization score? Take action towards the problems, warnings, and suggestions reported on this dashboard. We recommend the following workspace optimizations.
|
||||
|
||||
## Recommendations
|
||||
|
||||
The following optimization areas can alert you to workspace suggestions, warnings, or problems that may require your attention:
|
||||
|
||||
<table style={{width: '100%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '7%'}} />
|
||||
<col style={{width: '34%'}} />
|
||||
<col style={{width: '57%'}} />
|
||||
</colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Optimization category</th>
|
||||
<th>Suggestions, Warnings, or Problems Detected</th>
|
||||
<th>Additional Information</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>Mattermost release</td>
|
||||
<td>Are you on the latest Mattermost release?</td>
|
||||
<td><p>You're notified when updates are available.</p><p>See the <a href="/administration-guide/upgrade/upgrading-mattermost-server">Upgrade Mattermost</a> product documentation for details on upgrading your workspace.</p></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Configuration issues</td>
|
||||
<td><ul>
|
||||
<li><strong>SSL</strong>: Should your workspace be more secure with SSL?</li>
|
||||
<li><strong>Session Length</strong>: The default value may not provide an optimal user experience.</li>
|
||||
<li><strong>File Storage</strong>: Write access to the configured file storage location is required.</li>
|
||||
</ul></td>
|
||||
<td><p>See the product documentation to learn more:</p><ul><li><a href="/administration-guide/onboard/ssl-client-certificate">Set up SSL</a></li><li><a href="/administration-guide/configure/environment-configuration-settings#session-lengths">Configure session length</a></li><li><a href="/administration-guide/configure/environment-configuration-settings#file-storage">Configure file storage</a></li></ul></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Workspace access</td>
|
||||
<td>Is the Mattermost workspace accessible to users?</td>
|
||||
<td>If your web server settings don't pass a live URL test, your workspace may not be accessible to others. See the <a href="/administration-guide/configure/environment-configuration-settings#web-server">Web server configuration settings</a> product documentation to learn more.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Search performance</td>
|
||||
<td>As your user base grows, is search getting slower?</td>
|
||||
<td>See the <a href="/administration-guide/scale/enterprise-search">Enterprise search</a> product documentation to learn more.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Data privacy</td>
|
||||
<td>Do you need more control and insights into your data?</td>
|
||||
<td><p>See the product documentation to learn more:</p><ul><li><a href="/administration-guide/comply/data-retention-policy">Data Retention</a></li><li><a href="/administration-guide/comply/compliance-export">Compliance Export</a></li></ul></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>User authentication</td>
|
||||
<td><ul>
|
||||
<li><strong>AD/LDAP</strong>: As your user base grows, would you benefit from easier onboarding, automated deactivations, and role assignments?</li>
|
||||
<li><strong>Guest accounts</strong>: Do you want to control user access to channels and teams with guest accounts?</li>
|
||||
</ul></td>
|
||||
<td><p>See the product documentation to learn more:</p><ul><li><a href="/administration-guide/configure/authentication-configuration-settings#adldap">AD/LDAP</a></li><li><a href="/administration-guide/onboard/guest-accounts">Guest accounts</a></li></ul></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,133 @@
|
||||
---
|
||||
title: "Enable push notifications"
|
||||
unlisted: true
|
||||
---
|
||||
{/* Snippet include: imported by environment-configuration-settings. Kept as its
|
||||
own page because 10 pages deep-link to its anchors. */}
|
||||
|
||||
With self-hosted deployments, you can configure mobile push notifications for Mattermost by going to **System Console \> Environment \> Push Notification Server**, or by editing the `config.json` file as described in the following tables. Changes to configuration settings in this section require a server restart before taking effect.
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
<col style={{width: '45%'}} />
|
||||
<col style={{width: '54%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><p>Enable or disable Mattermost push notifications.</p><ul><li><strong>Do not send push notifications</strong>: Mobile push notifications are disabled.</li><li><strong>Use HPNS connection with uptime SLA to send notifications to iOS and Android apps</strong>: <strong>(Default)</strong> Use Mattermost's hosted push notification service.</li><li><strong>Use TPNS connection to send notifications to iOS and Android apps</strong>: Use Mattermost's test push notification service.</li><li><strong>Manually enter Push Notification Service location</strong>: When building your own custom mobile apps, you must host your own mobile push proxy service, and specify that URL in the <strong>Push Notification Server</strong> field.</li></ul></td>
|
||||
<td><ul><li>System Config path: <strong>Environment > Push Notification Server</strong></li><li><code>config.json</code> setting: <code>EmailSettings</code> > <code>SendPushNotifications</code></li><li>Environment variable: <code>MM_EMAILSETTINGS_SENDPUSHNOTIFICATIONS</code></li></ul></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
## Hosted Push Notifications Service (HPNS)
|
||||
|
||||
Mattermost Enterprise, Professional, and Cloud customers can use Mattermost's Hosted Push Notification Service (HPNS). The HPNS offers:
|
||||
|
||||
- Access to a publicly-hosted Mattermost Push Notification Service (MPNS) [available on GitHub.](https://github.com/mattermost/mattermost-push-proxy)
|
||||
- An explicit [privacy policy](https://mattermost.com/data-processing-addendum/) for the contents of unencrypted messages.
|
||||
- Encrypted TLS connections:
|
||||
- Between HPNS and Apple Push Notification Services
|
||||
- Between HPNS and Google’s Firebase Cloud Messaging Service
|
||||
- HPNS and your Mattermost Server
|
||||
- Production-level uptime expectations.
|
||||
- Out-of-box configuration for new servers means nothing is required to enable HPNS for new deployments. HPNS can be [enabled for existing deployments](#enable-hpns-for-existing-deployments).
|
||||
|
||||
<Note>
|
||||
|
||||
\- The HPNS only works with pre-built apps Mattermost deploys through the [Apple App Store](https://www.apple.com/app-store/) and [Google Play Store](https://play.google.com/store/games?hl=en). If you build your own mobile apps, you must also [host your own Mattermost push proxy server](#host-your-own-push-proxy-service). - You must ensure that the push proxy can be reached on the correct port. For HPNS, it's port 443 from the Mattermost server. - Mattermost doesn't store any notification data. Any data being stored is at the server level only, such as the `device_id`, since the HPNS needs to know which device the notification must be sent to.
|
||||
|
||||
</Note>
|
||||
|
||||
## Test Push Notifications Service (TPNS)
|
||||
|
||||
Non-commercial self-hosted customers can use Mattermost's free, basic Test Push Notifications Service (TPNS).
|
||||
|
||||
<Note>
|
||||
|
||||
\- The TPNS isn’t recommended for use in production environments, and doesn’t offer production-level update service level agreements (SLAs). - The TPNS isn't available for Mattermost Cloud deployments. - The TPNS only works with the pre-built mobile apps that Mattermost deploys through the [Apple App Store](https://www.apple.com/app-store/) and [Google Play Store](https://play.google.com/store/games?hl=en). If you have built your own mobile apps, you must also [host your own Mattermost push proxy service](#host-your-own-push-proxy-service). - You must ensure that the push proxy can be reached on the correct port. For TPNS, it's port 80 from the Mattermost server. - If you don't need or want Mattermost to send mobile push notifications, disabling this configuration setting in larger deployments may improve server performance in the following areas:
|
||||
|
||||
- Reduced Processing Load: Generating and sending push notifications requires processing power and resources. By disabling them, the server can allocate those resources to other tasks.
|
||||
- Decreased Network Traffic: Push notifications involve network communication. Disabling them reduces the amount of data being transferred, which can enhance overall network performance.
|
||||
- Lower Database Load: Each push notification may involve reading from and writing to the database. Reducing these operations decreases the load on the database, improving response times for other queries.
|
||||
- Faster Response Times: With fewer tasks to handle related to notifications, the system can respond faster to other requests from users, leading to a better user experience.
|
||||
- Simplified Error Handling: Push notification services can sometimes fail or have latency issues, requiring additional error handling. Disabling these notifications simplifies the system's operations.
|
||||
- However, disabling push notifications can negatively impact user experience, communication efficiency, and overall productivity. It’s important to balance performance improvements with the needs of your organization and users.
|
||||
|
||||
</Note>
|
||||
|
||||
## ID-only push notifications
|
||||
|
||||
<PlanAvailability slug="entry-ent" />
|
||||
|
||||
Admins can enable mobile notifications to be fully private to protect a Mattermost customer against breaches in iOS and Android notification infrastructure by limiting the data sent to Apple and Google through a Mattermost configuration setting.
|
||||
|
||||
The standard way to send notifications to iOS and Android applications requires sending clear text messages to Apple or Google so they can be forwarded to a user’s phone and displayed on iOS or Android. While Apple or Google assure the data is not collected or stored, should the organizations be breached or coerced, all standard mobile notifications on the platform could be compromised.
|
||||
|
||||
To avoid this risk, Mattermost can be configured to replace mobile notification text with message ID numbers that pass no information to Apple of Google. When received by the Mattermost mobile application on a user’s phone, the message IDs are used to privately communicate with their Mattermost server and to retrieve mobile notification messages over an encrypted channel. This means that, at no time, is the message text visible to Apple or Google’s message relay system. The contents of the message also won't reach Mattermost.
|
||||
|
||||
<Note>
|
||||
|
||||
Because of the extra steps to retrieve the notifications messages under Mattermost’s private mobility capability with ID-only push notifications, end users may experience a slight delay before the mobile notification is fully displayed compared to sending clear text through Apple and Google’s platform.
|
||||
|
||||
</Note>
|
||||
|
||||
See our [configuration settings](/administration-guide/configure/site-configuration-settings#push-notification-contents) documentation to learn more about the ID-only push notifications configuration setting. See our [Mobile Apps FAQ documentation](/deployment-guide/mobile/mobile-faq#how-can-i-use-id-only-push-notifications-to-protect-notification-content-from-being-exposed-to-third-party-services) for details on using ID-only push notifications for data privacy.
|
||||
|
||||
# Push notification server location
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
<col style={{width: '44%'}} />
|
||||
<col style={{width: '55%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><p>The region of the Mattermost Hosted Push Notification Service (HPNS) server.</p><p>Select a region to automatically populate the <strong>Push Notification Server</strong> field with the corresponding URL:</p><ul><li><strong>Global</strong>: <code>https://global.push.mattermost.com</code> (load balances requests across the regional endpoints below)</li><li><strong>US</strong>: <code>https://us.push.mattermost.com</code></li><li><strong>EU (Germany)</strong>: <code>https://eu.push.mattermost.com</code></li><li><strong>AP (Japan)</strong>: <code>https://ap.push.mattermost.com</code></li></ul></td>
|
||||
<td><ul>
|
||||
<li>System Config path: <strong>Environment > Push Notification Server</strong></li>
|
||||
<li><code>config.json</code> setting: <code>EmailSettings</code> > <code>PushNotificationServer</code></li>
|
||||
<li>Environment variable: <code>MM_EMAILSETTINGS_PUSHNOTIFICATIONSERVER</code></li>
|
||||
</ul></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<Note>
|
||||
|
||||
`https://us.push.mattermost.com` supersedes the legacy `https://push.mattermost.com` URL, and `https://eu.push.mattermost.com` supersedes the legacy `https://hpns-de.mattermost.com` URL. The legacy URLs still work, but are deprecated and now point to the same new infrastructure as their replacements above.
|
||||
|
||||
</Note>
|
||||
|
||||
# Maximum notifications per channel
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
<col style={{width: '41%'}} />
|
||||
<col style={{width: '58%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><p>The maximum total number of users in a channel before @all, @here, and @channel no longer send desktop, email, or mobile push notifications to maximize performance.</p>
|
||||
<p>Numerical input. Default is <strong>1000</strong>.</p></td>
|
||||
<td><ul>
|
||||
<li>System Config path: <strong>Environment > Push Notification Server</strong></li>
|
||||
<li><code>config.json</code> setting: <code>TeamSettings</code> > <code>MaxNotificationsPerChannel</code> > <code>1000</code></li>
|
||||
<li>Environment variable: <code>MM_EMAILSETTINGS_MAXNOTIFICATIONSPERCHANNEL</code></li>
|
||||
</ul></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<Note>
|
||||
|
||||
- We recommend increasing this value a little at a time, monitoring system health by tracking [performance monitoring metrics](/administration-guide/scale/deploy-prometheus-grafana-for-performance-monitoring), and only increasing this value if large channels have restricted permissions controlling who can post to the channel, such as a [read-only channel](/administration-guide/onboard/advanced-permissions#read-only-channels).
|
||||
- Reducing this configuration setting value to **10** in larger deployments may improve server performance in the following areas:
|
||||
- **Reduced Load on Notification System**: Each notification generates a certain amount of computational and network load. By limiting the number of notifications per channel, the system processes fewer notifications, thereby reducing the load on servers.
|
||||
- **Database Efficiency**: Notifications are typically stored in a database. Fewer notifications mean less frequent database writes and reads, leading to quicker database operations and reduced latency.
|
||||
- **Minimized Client Processing**: Users' clients (e.g., desktop and mobile apps) have to fetch and process notifications. With fewer notifications, clients can operate more efficiently, reducing memory and CPU usage on users' devices.
|
||||
- **Improved User Experience**: An overload of notifications can lead to performance lags and a cluttered experience for users. Limiting the number ensures that users receive only the most important notifications, which can enhance usability and response times.
|
||||
- **Network Bandwidth**: High numbers of notifications can consume a lot of bandwidth, particularly if they are being sent to many users. Fewer notifications can lead to lower overall network usage and potentially faster delivery of critical messages.
|
||||
- **Server Load Balancing**: By reducing the number of notifications, the workload can be more evenly distributed across the servers, leading to better load balancing and preventing any single server from becoming a bottleneck.
|
||||
|
||||
</Note>
|
||||
@@ -0,0 +1,118 @@
|
||||
---
|
||||
title: "Enable rate limiting"
|
||||
unlisted: true
|
||||
---
|
||||
{/* Snippet include: imported by environment-configuration-settings. */}
|
||||
|
||||
With self-hosted deployments, rate limiting prevents your Mattermost server from being overloaded with too many requests, and decreases the risk and impact of third-party applications or malicious attacks on your server.
|
||||
|
||||
Configure rate limiting settings by going to **System Console \> Environment \> Rate Limiting**, or by editing the `config.json` file as described in the following tables. Changes to configuration settings in this section require a server restart before taking effect.
|
||||
|
||||
<Important>
|
||||
|
||||
Mattermost rate limiting configuration settings are intended for small deployments of Mattermost up to a few hundred users, and is not intended for larger, Enterprise-scale deployments.
|
||||
|
||||
</Important>
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
<col style={{width: '45%'}} />
|
||||
<col style={{width: '54%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><p>Enable or disable rate limiting to throttle APIs to a specified number of requests per second.</p><ul><li><strong>true</strong>: APIs are throttled at the rate specified by the <a href="#maximum-queries-per-second">Maximum queries per second</a> configuration setting.</li><li><strong>false</strong>: <strong>(Default)</strong> API access isn’t throttled.</li></ul></td>
|
||||
<td><ul><li>System Config path: <strong>Environment > Rate Limiting</strong></li><li><code>config.json</code> setting: <code>RateLimitSettings</code> > <code>Enable</code> > <code>false</code></li><li>Environment variable: <code>MM_RATELIMITSETTINGS_ENABLE</code></li></ul></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
# Maximum queries per second
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
<col style={{width: '46%'}} />
|
||||
<col style={{width: '53%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><p>Throttle the API at this number of requests per second when <a href="#enable-rate-limiting">rate limiting</a> is enabled.</p><p>Numerical input. Default is <strong>10</strong>.</p><p>Increase this value to accept more requests each second, and decrease this value to allow fewer requests.</p></td>
|
||||
<td><ul><li>System Config path: <strong>Environment > Rate Limiting</strong></li><li><code>config.json</code> setting: <code>RateLimitSettings</code> > <code>PerSec</code> > <code>10</code></li><li>Environment variable: <code>MM_RATELIMITSETTINGS_PERSEC</code></li></ul></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
# Maximum burst size
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
<col style={{width: '45%'}} />
|
||||
<col style={{width: '54%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><p>The maximum number of requests allowed beyond the per second query limit when <a href="#enable-rate-limiting">rate limiting</a> is enabled.</p><p>Numerical input. Default is <strong>100</strong>.</p><p>Increase this value to allow for more concurrent requests to be handled, and decrease this value to limit this capacity.</p></td>
|
||||
<td><ul><li>System Config path: <strong>Environment > Rate Limiting</strong></li><li><code>config.json</code> setting: <code>RateLimitSettings</code> > <code>MaxBurst</code> > <code>100</code></li><li>Environment variable: <code>MM_RATELIMITSETTINGS_MAXBURST</code></li></ul></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
# Memory store size
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
<col style={{width: '43%'}} />
|
||||
<col style={{width: '56%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><p>The maximum number of user sessions connected to the system as determined by vary rate limit settings when <a href="#enable-rate-limiting">rate limiting</a> is enabled.</p><p>Numerical input. Default is <strong>10000</strong>. Typically set to the number of users in the system.</p><p>We recommend setting this value to the expected number of users. A higher value may result in underutilized resources, and a lower value may result in user sessions/tokens expiring too frequently.</p></td>
|
||||
<td><ul><li>System Config path: <strong>Environment > Rate Limiting</strong></li><li><code>config.json</code> setting: <code>RateLimitSettings</code> > <code>MemoryStoreSize</code> > <code>10000</code></li><li>Environment variable: <code>MM_RATELIMITSETTINGS_MEMORYSTORESIZE</code></li></ul></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
# Vary rate limit by remote address
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
<col style={{width: '43%'}} />
|
||||
<col style={{width: '56%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><p>Configure Mattermost to rate limit API access by IP address when <a href="#enable-rate-limiting">rate limiting</a> is enabled.</p><ul><li><strong>true</strong>: <strong>(Default)</strong> Rate limit API access by IP address. Recommended when using a proxy.</li><li><strong>false</strong>: Rate limiting does not vary by IP address.</li></ul></td>
|
||||
<td><ul><li>System Config path: <strong>Environment > Rate Limiting</strong></li><li><code>config.json</code> setting: <code>RateLimitSettings</code> > <code>VaryByRemoteAddr</code> > <code>true</code></li><li>Environment variable: <code>MM_RATELIMITSETTINGS_VARYBYREMOTEADDR</code></li></ul></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
# Vary rate limit by user
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
<col style={{width: '45%'}} />
|
||||
<col style={{width: '54%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><p>Configure Mattermost to rate limit API access by authentication token or not when <a href="#enable-rate-limiting">rate limiting</a> is enabled.</p><ul><li><strong>true</strong>: Rate limit API access by user authentication token. Recommended when using a proxy.</li><li><strong>false</strong>: <strong>(Default)</strong> Rate limiting does not vary by user authentication token.</li></ul></td>
|
||||
<td><ul><li>System Config path: <strong>Environment > Rate Limiting</strong></li><li><code>config.json</code> setting: <code>RateLimitSettings</code> > <code>VaryByUser</code> > <code>false</code></li><li>Environment variable: <code>MM_RATELIMITSETTINGS_VARYBYUSER</code></li></ul></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
# Vary rate limit by HTTP header
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
<col style={{width: '45%'}} />
|
||||
<col style={{width: '54%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><p>Configure Mattermost to vary rate limiting API access by the HTTP header field specified. Recommended when you’re using a proxy.</p><ul><li>When configuring NGINX, set this to <strong>X-Real-IP</strong>.</li><li>When configuring AmazonELB, set this to <strong>X-Forwarded-For</strong>.</li></ul></td>
|
||||
<td><ul><li>System Config path: <strong>Environment > Rate Limiting</strong></li><li><code>config.json</code> setting: <code>RateLimitSettings</code> > <code>VaryByHeader</code> > <code>""</code></li><li>Environment variable: <code>MM_RATELIMITSETTINGS_VARYBYHEADER</code></li></ul></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
@@ -0,0 +1,128 @@
|
||||
---
|
||||
title: "Reporting configuration settings"
|
||||
---
|
||||
import useBaseUrl from '@docusaurus/useBaseUrl';
|
||||
|
||||
<PlanAvailability slug="all-commercial" />
|
||||
|
||||
View the following statistics for your overall deployment and specific teams, as well as access server logs, in the System Console by selecting the **Product** <img src={useBaseUrl('/img/ui/products_E82F.svg')} alt="Navigate between Channels, collaborative playbooks, and boards using the product menu icon." className="theme-icon" /> menu, selecting **System Console**, and then selecting **Reporting**:
|
||||
|
||||
- [System statistics](#system-statistics)
|
||||
- [Team statistics](#team-statistics)
|
||||
- [Server logs](#server-logs)
|
||||
- [Statistics configuration settings](#statistics-configuration-settings)
|
||||
|
||||
------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
<a id="site-statistics" />
|
||||
|
||||
## System statistics
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
<col style={{width: '48%'}} />
|
||||
<col style={{width: '51%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>View statistics on a wide variety of activities in Mattermost, including: users, seats, teams, channels, posts, calls, sessions, commands, webhooks, websocket and database connections, and collaborative playbooks.</td>
|
||||
<td><ul>
|
||||
<li>System Config path: <strong>Reporting > System Statistics</strong></li>
|
||||
<li><code>config.json setting</code>: N/A</li>
|
||||
<li>Environment variable: N/A</li>
|
||||
</ul></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<Note>
|
||||
|
||||
- Bots, deactivated users, and synthetic users in [Microsoft Teams integrations](/end-user-guide/collaborate/collaborate-within-connected-microsoft-teams) and [connected workspaces](/administration-guide/onboard/connected-workspaces) users aren't counted towards the total number of activated users.
|
||||
- **Single-channel Guests** shows the number of active guest accounts that belong to exactly one active channel. Direct messages and group messages don't affect whether a guest is counted as a single-channel guest. Archived channels are excluded. Single-channel guests are counted separately from the primary paid seat count and are free up to a 1:1 ratio with licensed seats. When this count exceeds the allowance, the statistic is highlighted as a warning for system admins.
|
||||
- Guests in multiple active channels continue to count as activated users for billing purposes. See the [guest accounts](/administration-guide/onboard/guest-accounts) documentation for details.
|
||||
|
||||
</Note>
|
||||
|
||||
------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
## Team statistics
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
<col style={{width: '49%'}} />
|
||||
<col style={{width: '50%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>View statistics per team on number of activated users, number of public and private channels, total post count, and count of paid users (self-hosted only).</td>
|
||||
<td><ul>
|
||||
<li>System Config path: <strong>Reporting > Team Statistics</strong></li>
|
||||
<li><code>config.json</code> setting: N/A</li>
|
||||
<li>Environment variable: N/A</li>
|
||||
</ul></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<Note>
|
||||
|
||||
Bots, deactivated users, and synthetic users in [Microsoft Teams integrations](/end-user-guide/collaborate/collaborate-within-connected-microsoft-teams) and [connected workspaces](/administration-guide/onboard/connected-workspaces) users aren't counted towards the total number of active users.
|
||||
|
||||
</Note>
|
||||
|
||||
------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
## Server logs
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
<col style={{width: '50%'}} />
|
||||
<col style={{width: '50%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><p>View logging of server-side events.</p>
|
||||
<p>Reload data, download the <code>mattermost.log</code> file locally, and view full log event details for any log entry.</p></td>
|
||||
<td><ul>
|
||||
<li>System Config path: <strong>Reporting > Server Logs</strong></li>
|
||||
<li><code>config.json</code> setting: N/A</li>
|
||||
<li>Environment variable: N/A</li>
|
||||
</ul></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<Note>
|
||||
|
||||
- This setting is applicable to self-hosted deployments only.
|
||||
- From Mattermost v10.9, you can toggle between JSON and plain text server logs in the System Console when console log output is configured as [JSON](/administration-guide/configure/environment-configuration-settings#output-console-logs-as-json) by specifying the log format as **JSON** or **Plain text**. This option is located in the top right corner of the page **Server logs** page.
|
||||
|
||||
</Note>
|
||||
|
||||
------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
## Statistics configuration settings
|
||||
|
||||
The following self-hosted deployment configuration setting controls statistics collection behavior. This setting is not available in the System Console and can only be set in the `config.json` file.
|
||||
|
||||
### Maximum users for statistics
|
||||
|
||||
This setting is used to maximize performance for large Enterprise deployments and isn't available in the System Console and can only be set in `config.json`.
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
<col style={{width: '44%'}} />
|
||||
<col style={{width: '55%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><p>Set the maximum number of users on the server before statistics for total messages, total hashtag messages, total file messages, messages per day, and activated users with messages per day are disabled.</p>
|
||||
<p>Numerical input. Default is <strong>2500</strong> users.</p></td>
|
||||
<td><ul>
|
||||
<li>System Config path: N/A</li>
|
||||
<li><code>config.json</code> setting: <code>"AnalyticsSettings.MaxUsersForStatistics": 2500</code></li>
|
||||
<li>Environment variable: N/A</li>
|
||||
</ul></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
@@ -0,0 +1,28 @@
|
||||
---
|
||||
title: "Self-hosted workspace edition and license settings"
|
||||
---
|
||||
import useBaseUrl from '@docusaurus/useBaseUrl';
|
||||
|
||||
<PlanAvailability slug="all-commercial" />
|
||||
|
||||
Start a trial or manage your self-hosted deployment by selecting the **Product** <img src={useBaseUrl('/img/ui/products_E82F.svg')} alt="Navigate between Channels, collaborative playbooks, and boards using the product menu icon." className="theme-icon" /> menu, selecting **System Console**, and then selecting **About \> Edition and License**.
|
||||
|
||||
## Start a trial
|
||||
|
||||
You can start a trial of [Mattermost Enterprise](/product-overview/editions-and-offerings#mattermost-enterprise-edition) for free for 30 days. Select **Start trial** and fill out the form to begin.
|
||||
|
||||
<Note>
|
||||
|
||||
Once you've started a trial, you can't start another one with the same Mattermost instance. If you need more time to evaluate Mattermost Enterprise, contact a [Mattermost Expert](https://mattermost.com/contact-sales/).
|
||||
|
||||
</Note>
|
||||
|
||||
## Manage your self-hosted deployment
|
||||
|
||||
You can also review and manage the following aspects of your self-hosted deployment:
|
||||
|
||||
- View the [edition](/product-overview/editions-and-offerings) of your Mattermost self-hosted deployment.
|
||||
- Manage your [product subscription](/product-overview/self-hosted-subscriptions).
|
||||
- [Upload a new license](/administration-guide/manage/admin/installing-license-key).
|
||||
- Remove a license to [downgrade the server](/administration-guide/upgrade/downgrading-mattermost-server).
|
||||
- Talk to a [Mattermost Expert](https://mattermost.com/contact-sales/) for assistance.
|
||||
163
docs/main/administration-guide/configure/smtp-email.mdx
Normal file
163
docs/main/administration-guide/configure/smtp-email.mdx
Normal file
@@ -0,0 +1,163 @@
|
||||
---
|
||||
title: "SMTP email setup"
|
||||
---
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
<PlanAvailability slug="all-commercial" />
|
||||
|
||||
In a production environment, Mattermost requires SMTP email enabled for email notifications and password resets when using [email-based authentication](/administration-guide/configure/authentication-configuration-settings#enable-sign-in-with-email).
|
||||
|
||||
## Set up an SMTP email service
|
||||
|
||||
Any SMTP email service can be used. You need a copy of the following information: `Server Name`, `Port`, `SMTP Username`, and `SMTP Password`.
|
||||
|
||||
<Tip>
|
||||
|
||||
If you don't have an SMTP service you can set one up with [Amazon Simple Email Service (SES)](https://aws.amazon.com/ses/):
|
||||
|
||||
1. Go to [Amazon SES console](https://console.aws.amazon.com/ses) then **SMTP Settings \> Create My SMTP Credentials**.
|
||||
2. Copy the `Server Name`, `Port`, `SMTP Username`, and `SMTP Password` values. You'll need these values to configure Mattermost.
|
||||
3. From the `Domains` menu, set up and verify a new domain, then enable `Generate DKIM Settings` for the domain. We recommend you set up [Sender Policy Framework](https://en.wikipedia.org/wiki/Sender_Policy_Framework) (SPF) and/or [Domain Keys Identified Mail](https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail) (DKIM) for your email domain.
|
||||
4. Choose a sender address like `mattermost@domain.com` and select `Send a Test Email` to verify setup is working correctly.
|
||||
|
||||
Alternatively, you can use one of the [services listed below](#sample-smtp-settings), or can set up local `sendmail` by setting **Server Name** `127.0.0.1` with **Port** `25`.
|
||||
|
||||
If deploying Mattermost using [Docker](/deployment-guide/server/deploy-containers), the standard docker `172.16.0.0/12` IP range isn't used. Specify the IP range `192.168.0.0/24` to the email service to avoid relay access errors. If using postfix, under `/etc/postfix/main.cf`, specify `mynetworks = 192.168.0.0/24`. This may vary depending on how Mattermost is deployed. Ensure that **Port 25** is open if a firewall is present.
|
||||
|
||||
</Tip>
|
||||
|
||||
<Note>
|
||||
|
||||
[Outlook365 no longer supports Basic Auth](https://support.microsoft.com/en-us/office/pop-imap-and-smtp-settings-for-outlook-com-d088b986-291d-42b8-9564-9c414e2aa040) which is required by Mattermost. We recommend using an alternate Email service like AWS SES (Simple Email Service).
|
||||
|
||||
</Note>
|
||||
|
||||
## Configure SMTP settings
|
||||
|
||||
1. In Mattermost go to **System Console \> Authentication \> Email**, and set **Allow Sign Up With Email** to **true**.
|
||||
2. In the System Console, go to **Notifications \> Email** and configure Mattermost for your SMTP service. See the [SMTP configuration](/administration-guide/configure/environment-configuration-settings#smtp) documentation for details.
|
||||
|
||||
> - Set **Send Email Notifications** to **true**.
|
||||
> - Set the **Notification Display Name** for the account sending notifications.
|
||||
> - Set **Notification Email Address** for the email address used to send notifications.
|
||||
> - Enter the **SMTP Username**, **SMTP Password**, **SMTP Server**, and **SMTP Port** you copied from initial setup.
|
||||
> - We recommend setting **Connection Security**: to **TLS (Recommended)** to encrypt communication between Mattermost and your SMTP service.
|
||||
|
||||
<Note>
|
||||
|
||||
`SMTPPort` and related port settings use string format (e.g., `"465"`) for compatibility with the `host:port` binding format, which requires string concatenation.
|
||||
|
||||
</Note>
|
||||
|
||||
3. Select **Save**.
|
||||
4. Under **Connection Security**, select **Test Connection**. Mattermost will confirm whether a connection to the SMTP service is successful by sending you an email. If the test fails, Mattermost will provide details about why it failed in the System Console. See the [check Mattermost logs](#troubleshooting-using-logs) section below for details.
|
||||
|
||||
## Sample SMTP settings
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="amazon-ses" label="Amazon SES">
|
||||
|
||||
- Set **SMTP Username** to **\[YOUR_SMTP_USERNAME\]**
|
||||
- Set **SMTP Password** to **\[YOUR_SMTP_PASSWORD\]**
|
||||
- Set **SMTP Server** to **email-smtp.us-east-1.amazonaws.com**
|
||||
- Set **SMTP Port** to **465**
|
||||
- Set **Connection Security** to **TLS**
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="postfix" label="Postfix">
|
||||
|
||||
Make sure Postfix is installed on the same machine as Mattermost.
|
||||
|
||||
- Set **SMTP Username** to **(empty)**
|
||||
- Set **SMTP Password** to **(empty)**
|
||||
- Set **SMTP Server** to **localhost**
|
||||
- Set **SMTP Port** to **25**
|
||||
- Set **Connection Security** to **(empty)**
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="gmail" label="Gmail">
|
||||
|
||||
- Set **SMTP Username** to **your_email@gmail.com**
|
||||
- Set **SMTP Password** to **your_password**
|
||||
- Set **SMTP Server** to **smtp.gmail.com**
|
||||
- Set **SMTP Port** to **587**
|
||||
- Set **Connection Security** to **STARTTLS**
|
||||
|
||||
<Warning>
|
||||
|
||||
Additional configuration is required in Google to allow SMTP email to relay through their servers. See [SMTP relay: Route outgoing non-Gmail messages through Google](https://support.google.com/a/answer/2956491?hl=en) for the required steps.
|
||||
|
||||
</Warning>
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="hotmail" label="Hotmail">
|
||||
|
||||
- Set **SMTP Username** to **your_email@hotmail.com**
|
||||
- Set **SMTP Password** to **your_password**
|
||||
- Set **SMTP Server** to **smtp-mail.outlook.com**
|
||||
- Set **SMTP Port** to **587**
|
||||
- Set **Connection Security** to **STARTTLS**
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="office365-outlook" label="Office365/Outlook">
|
||||
|
||||
- Set **SMTP Username** to **your_email@hotmail.com**
|
||||
- Set **SMTP Password** to **your_password**
|
||||
- Set **SMTP Server Name** to **smtp.office365.com**
|
||||
- Set **SMTP Port** to **587**
|
||||
- Set **Connection Security** to **STARTTLS**
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
## Troubleshooting SMTP
|
||||
|
||||
### TLS/STARTTLS requirements
|
||||
|
||||
If you fill in **SMTP Username** and **SMTP Password** then you must set **Connection Security** to **TLS** or to **STARTTLS**
|
||||
|
||||
### Troubleshooting using logs
|
||||
|
||||
If you have issues with your SMTP install, from your Mattermost team site go to **System Console \> Logs** to look for error messages related to your setup. You can do a search for the error code to narrow down the issue. Sometimes ISPs require nuanced setups for SMTP and error codes can hint at how to make the proper adjustments.
|
||||
|
||||
For example, if **System Console \> Logs** displays the following error, search for `554 5.7.1 error` and `Client host rejected: Access denied`.
|
||||
|
||||
``` text
|
||||
Connection unsuccessful: Failed to add to email address - 554 5.7.1 <unknown[IP-ADDRESS]>: Client host rejected: Access denied
|
||||
```
|
||||
|
||||
### Checking your Notifications settings
|
||||
|
||||
If an SMTP connection test in the System Console for a self-hosted Mattermost deployment fails with the message `Connection unsuccessful: Failed to set the to address: 550 5.7.27 [test@example.com](mailto:test@example.com)`, go to **System Console \> Site Configuration \> Notifications** to verify that notification settings are configured correctly, including **Notification Display Name**, **Notification From Address**, **Support Email Address**, and **Notification Reply-To Address**. Cloud administrators can't manage **Notification From Address** or **Notification Reply-To Address**.
|
||||
|
||||
### Checking your SMTP server is reachable
|
||||
|
||||
- Attempt to Telnet to the email service to make sure the server is reachable. For additional information, visit [https://learn.microsoft.com/en-us/exchange/mail-flow/test-smtp-with-telnet?view=exchserver-2019](https://learn.microsoft.com/en-us/exchange/mail-flow/test-smtp-with-telnet?view=exchserver-2019). If you're using an earlier version than Exchange Server 2019, select your version from the left-hand navigation menu.
|
||||
|
||||
- You must run the following commands from the same machine or virtual instance where `mattermost/bin/mattermost` is located.
|
||||
|
||||
- Telnet to the email server with `telnet mail.example.com 25`. If the command works you should see something like:
|
||||
|
||||
``` text
|
||||
Trying 24.121.12.143...
|
||||
Connected to mail.example.com.
|
||||
220 mail.example.com NO UCE ESMTP
|
||||
```
|
||||
|
||||
Then type something like `HELO <your mail server domain>`. If the command works you should see something like:
|
||||
|
||||
``` text
|
||||
250-mail.example.com NO UCE
|
||||
250-STARTTLS
|
||||
250-PIPELINING
|
||||
250 8BITMIME
|
||||
```
|
||||
|
||||
<Note>
|
||||
|
||||
- Telnet isn't included in official Mattermost Docker images, so you either need to use `ping` on those, or install Telnet yourself either directly or by modifying the Dockerfile.
|
||||
- For further assistance, review the [Troubleshooting forum](https://forum.mattermost.com/c/trouble-shoot/16) for previously reported errors, or [join the Mattermost user community for troubleshooting help](https://mattermost.com/community/).
|
||||
|
||||
</Note>
|
||||
@@ -0,0 +1,16 @@
|
||||
---
|
||||
title: "System attributes"
|
||||
---
|
||||
import useBaseUrl from '@docusaurus/useBaseUrl';
|
||||
|
||||
<PlanAvailability slug="ent-plus" />
|
||||
|
||||
System attributes configuration settings provide system admins with centralized control over key user account properties.
|
||||
|
||||
Review and manage the following system attributes configuration options in the System Console by selecting the **Product** <img src={useBaseUrl('/img/ui/products_E82F.svg')} alt="Navigate between Channels, collaborative playbooks, and boards using the product menu icon." className="theme-icon" /> menu, selecting **System Console**, and then selecting **System Attributes**.
|
||||
|
||||
You can define, manage, and enforce specific attributes, including:
|
||||
|
||||
- **User attributes**: Display details such as job titles, departments, or other metadata, on user profiles that align with your organizational structures and workflows. Learn more about [managing user attributes](/administration-guide/manage/admin/user-attributes). API responses for user attributes return default visibility and sort order when those values are missing.
|
||||
- **Granular access controls based on user attributes**: Ensure users have access to only the resources and functionality relevant to their roles, bolstering security and compliance across the organization. Learn more about [managing access based on user attributes](/administration-guide/manage/admin/attribute-based-access-control).
|
||||
- **Control user-managed attributes in attribute-based access control (ABAC)**: From Mattermost v10.11 (Enterprise Edition Advanced), user-managed attributes are excluded from ABAC rules by default to prevent unauthorized access. System admins can enable them with a configuration setting. Learn more about enabling user-managed attributes in ABAC rules in the [User Attributes documentation](/administration-guide/manage/admin/user-attributes#before-you-begin).
|
||||
@@ -0,0 +1,687 @@
|
||||
---
|
||||
title: "User management configuration settings"
|
||||
---
|
||||
import useBaseUrl from '@docusaurus/useBaseUrl';
|
||||
|
||||
<PlanAvailability slug="all-commercial" />
|
||||
|
||||
Review and manage the following in the System Console by selecting the **Product** <img src={useBaseUrl('/img/ui/products_E82F.svg')} alt="Navigate between Channels, collaborative playbooks, and boards using the product menu icon." className="theme-icon" /> menu, selecting **System Console**, and then selecting **User Management**:
|
||||
|
||||
- [Users](#users)
|
||||
- [Groups](#groups)
|
||||
- [Teams](#teams)
|
||||
- [Channels](#channels)
|
||||
- [Permissions](#permissions)
|
||||
- [System roles](#system-roles)
|
||||
|
||||
------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
## Users
|
||||
|
||||
Mattermost system admins can provision and manage user accounts, team membership, roles and permissions, and update user email addresses, usernames, and authentication data.
|
||||
|
||||
### Provision users
|
||||
|
||||
Getting people set up with a Mattermost account is typically something that system admins do when deploying and configuring the Mattermost deployment. A Mattermost admin can [provision Mattermost users](/administration-guide/onboard/user-provisioning-workflows) using one or more of the following methods:
|
||||
|
||||
- [Enable account creation](/administration-guide/configure/authentication-configuration-settings#enable-account-creation).
|
||||
- Use [mmctl user create](/administration-guide/manage/mmctl-command-line-tool#mmctl-user-create) or Mattermost [APIs](https://api.mattermost.com/#tag/users) to create user accounts.
|
||||
- [Migrate user accounts](/administration-guide/onboard/migrating-to-mattermost#migration-guide) from other collaboration systems and [bulk import](/administration-guide/onboard/bulk-loading-data) that user data into Mattermost.
|
||||
- Connect an authentication service to assist with user provisioning, such as [AD/LDAP authentication](/administration-guide/onboard/ad-ldap) or [SAML authentication](/administration-guide/onboard/sso-saml).
|
||||
|
||||
### Review user data
|
||||
|
||||
From Mattermost v9.6, you can review the following user data in the System Console:
|
||||
|
||||
- **Email**: The user's email address.
|
||||
- **Member since**: The number of days since the user joined the Mattermost server.
|
||||
- **Last login**: The date of the user's last successful login to the server.
|
||||
- **Last activity**: The total number of days since the user was last active on the server, which is typically based on the [user's availability](/end-user-guide/preferences/set-your-status-availability#set-your-availability).
|
||||
- **Last post**: The total number of days since the user's last sent message on the server.
|
||||
- **Days active**: (PostgreSQL only) The total number of days in which the user has sent a message in Mattermost.
|
||||
- **Messages posted**: (PostgreSQL only) The total number of messages the user has sent on the server.
|
||||
|
||||
From Mattermost v11.0, you can also review the following authentication data for each user:
|
||||
|
||||
- **Authentication Method**: Shows how users authenticate with the Mattermost server, including external authentication system details such as LDAP Distinguished Name (DN), SAML NameID, OAuth ID, or other external authentication identifiers. This information helps system administrators troubleshoot authentication issues and correlate Mattermost users with their external authentication systems.
|
||||
|
||||
By default, you see all columns of data and data for all time.
|
||||
|
||||
- Show or hide data all data columns exccept **User details** and **Actions**, as preferred.
|
||||
- Filter results to the last 30 days, the previous month, and the last 6 months for **Last post**, **Days active**, and **Messages posted** user data.
|
||||
|
||||
### Find users
|
||||
|
||||
Find a user using the System Console.
|
||||
|
||||
1. Go to **System Console \> User Management \> Users** to access all user accounts.
|
||||
2. Search for specific users by entering a partial or full username, user ID, first name, last name, or email address in the **Search** field and pressing <kbd>Enter</kbd>.
|
||||
|
||||

|
||||
|
||||
### Filter user searches
|
||||
|
||||
Filter System Console user searches to narrow down results based on the team membership, role, and user status.
|
||||
|
||||
1. Go to **System Console \> User Management \> Users** to access all user accounts.
|
||||
2. Select **Filters** located to the right of the **Search users** field to access available filter options.
|
||||
3. Select **Apply** to filter user search results.
|
||||
|
||||

|
||||
|
||||
### Identify a user's ID
|
||||
|
||||
Users can be specified in Mattermost by username or user ID. Usernames automatically resolve when a match is detected. Identify a user's ID using the System Console, the Mattermost API, or mmctl.
|
||||
|
||||
1. Go to **System Console \> User Management \> Users** to access all user accounts.
|
||||
2. Select a **User** to review their ID in the User Configuration page.
|
||||
|
||||

|
||||
|
||||
Alternatively, identify a user's ID using the Mattermost API or mmctl:
|
||||
|
||||
- Using the Mattermost API, make an HTTP GET request to the following endpoint: `https://your-mattermost-url/api/v4/users/username/username_here`. Replace `your-mattermost-url` with the URL of your Mattermost instance and `username_here` with the username you are looking for. The API response contains a JSON object that includes the user's ID among other details.
|
||||
- Using mmctl, in a terminal window, use the following command to list all users and their IDs: `mmctl user list` to return a list of user IDs.
|
||||
|
||||
### Export user data
|
||||
|
||||
From Mattermost v9.6, Mattermost Enterprise and Professional customers can export user data as a CSV report.
|
||||
|
||||
1. Go to **System Console \> User Management \> Users** to access all user accounts.
|
||||
2. [Filter](#filter-user-searches) the user data as needed.
|
||||
3. Select **Export** located in the top right corner of the System Console interface, and then select **Export data**. You'll receive the report in CSV format as a direct message in Mattermost.
|
||||
|
||||
### Deactivate users
|
||||
|
||||
To delete a user from your Mattermost deployment, you can deactivate the user's account. Deactivated users have an deactivated status, are logged out of Mattermost as soon as they are deactivated, and deactivated users can no longer log back in. You can manage the user's role, password, and email address while a user's account is deactivated.
|
||||
|
||||
<Note>
|
||||
|
||||
- From Mattermost v10.10, when a user account is deactivated, the account's [availability](/end-user-guide/preferences/set-your-status-availability#set-your-availability) is automatically set to offline.
|
||||
- LDAP-managed users must be deactivated through LDAP, and can't be deactivated using the System Console or the API.
|
||||
|
||||
</Note>
|
||||
|
||||
1. Go to **System Console \> User Management \> Users** to access all user accounts.
|
||||
2. Select a **User** that you wish to activate or deactivate.
|
||||
3. If the selected user is currently active, you can find the **Deactivate** button in the **User Configuration** page.
|
||||
4. Select **Deactivate**, and confirm the deactivation. You can re-activate a deactivated user by selecting **Activate**.
|
||||
|
||||

|
||||
|
||||
<Tip>
|
||||
|
||||
Re-activate a deactivated user by selecting **Activate**.
|
||||
|
||||
</Tip>
|
||||
|
||||
#### What happens to deactivated user integrations?
|
||||
|
||||
If you deactivate a Mattermost user who has integrations tied to their user account, consider the following consequences and recommendations based on the integration type:
|
||||
|
||||
- **Slash commands** will continue to work after user deactivation. Consider deleting the existing slash command and creating a new slash command associated with a different user account to decouple sensitive token data from the deactivated user account. Alternatively, consider regenerating the token of the existing slash command. Check that the deactivated user doesn't have access to the slash command **Request URL** which is the callback URL to receive the HTTP POST or GET event request when the slash command is run.
|
||||
- **Outgoing webhooks** will continue to work after user deactivation. Consider regenerating the webhook token and check that the deactivated user no longer has access to the callback URLs, as having access would result in the deactivating user receiving the outgoing webhooks.
|
||||
- **Incoming webhooks** will continue to work after user deactivation. Because the [URL produced](https://developers.mattermost.com/integrate/webhooks/incoming/#create-an-incoming-webhook) includes `xxx-generatedkey-xxx`, anyone who has the URL can post messages to the Mattermost instance. We recommend removing the incoming webhook and creating a new one associated with a different user account.
|
||||
- **Bot accounts** won't continue to work after user deactivation when the [disable bot accounts when owner is deactivated](/administration-guide/configure/integrations-configuration-settings#disable-bot-accounts-when-owner-is-deactivated) is enabled. This configuration setting is enabled by default.
|
||||
- **OAuth apps** won't continue to work after user deactivation, and associated tokens are deleted. Manual action is needed to keep these integrations running.
|
||||
|
||||
### Manage user attributes
|
||||
|
||||
From Mattermost v11.1, you can can view and update user attribute values for individual users directly from the System Console. This capability provides a centralized way to manage user profile attributes without requiring users to update their own profiles or using [mmctl user attribute commands](/administration-guide/manage/mmctl-command-line-tool#mmctl-cpa).
|
||||
|
||||
1. Go to **System Console \> User Management \> Users** to access all user accounts.
|
||||
2. Select a **User** to open their User Configuration page.
|
||||
3. Scroll to the **User Attributes** section to view and edit the user's attribute values.
|
||||
4. Update attribute values as needed and save your changes.
|
||||
|
||||
<Note>
|
||||
|
||||
- User attributes must be created first through **System Console \> Site Configuration \> System Attributes \> User Attributes** before they can be edited in individual user profiles. See the [User attributes](/administration-guide/manage/admin/user-attributes) documentation for details on creating and configuring attributes.
|
||||
- Users can edit their own attributes if that attribute is configured as [user-editable](/administration-guide/manage/admin/user-attributes#admin-managed-vs-user-editable-attributes).
|
||||
|
||||
</Note>
|
||||
|
||||
### Delete users
|
||||
|
||||
From Mattermost v10.11, when using email/password for authentication, you can enable users to permanently delete their own accounts, or you can delete user accounts as a system administrator.
|
||||
|
||||
#### Enable account deletion
|
||||
|
||||
Define the URL for a **Delete Account Link** that users can access by going to their profile and selecting **Security \> Delete Your Account**. Leave this field blank to hide the abiltiy for users to delete their account.
|
||||
|
||||
<table style={{width: '90%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '90%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>This feature's <code>config.json</code> setting is <code>"ServiceSettings.DeleteAccountLink": ""</code> with string input.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
When a user deletes their account, deleted accounts cannot be reactivated, and the user is automatically removed from all teams and channels.
|
||||
|
||||
#### What data is removed?
|
||||
|
||||
When an account is permanently deleted, the following data is permanently removed:
|
||||
|
||||
- User profile information (name, email, username)
|
||||
- User preferences and settings
|
||||
- User authentication credentials
|
||||
- Direct message channel memberships
|
||||
- Team and channel memberships
|
||||
- User session data
|
||||
- All posts and replies authored by the deleted user
|
||||
- File uploads and attachments shared in channels by the user
|
||||
- All webhooks, slash commands and OAuth apps created by the user
|
||||
|
||||
#### What data is retained?
|
||||
|
||||
After account deletion, audit logs referencing the user's actions, channel and team membership are retained.
|
||||
|
||||
### Manage user's roles
|
||||
|
||||
Apply roles to users using the System Console. The current available roles are **System admin** and **Member**.
|
||||
|
||||
1. Go to **System Console \> User Management \> Users** to access all user accounts.
|
||||
2. Under **Actions**, select **Manage roles**.
|
||||
3. Specify whether the user has the role of **System admin** or **Member**, and then select **Save**.
|
||||
|
||||

|
||||
|
||||
### Manage user's teams
|
||||
|
||||
Add or remove users from teams using the System Console.
|
||||
|
||||
1. Go to **System Console \> User Management \> Users** to access all user accounts.
|
||||
2. Select the user you want to manage.
|
||||
3. You can include the user in one new team or a group of teams. Select **Add Team**, select one or more teams, and then select **Add**.
|
||||
|
||||

|
||||
|
||||
4. To remove the user from a specific team, select **More** <img src={useBaseUrl('/img/ui/dots-horizontal_F01D8.svg')} alt="Use the More icon to access additional message options." className="theme-icon" /> next to the team name, and select **Remove from team**.
|
||||
|
||||

|
||||
|
||||
<Tip>
|
||||
|
||||
You can also remove the user from a specific team from the **Actions** column on the **Users** page. Select **Manage Teams**, and then select **Remove from Team** for applicable teams.
|
||||
|
||||
</Tip>
|
||||
|
||||
### Manage user's settings
|
||||
|
||||
<PlanAvailability slug="ent-plus" />
|
||||
|
||||
From Mattermost v9.11, system admins can help end users customize their Mattermost notifications by editing the user's [notification settings](/end-user-guide/preferences/manage-your-notifications) on the user's behalf within the System Console. Users can view, modify, and override their own settings at any time.
|
||||
|
||||
1. Go to **System Console \> User Management \> Users** to access all user accounts.
|
||||
2. Select the user you want to manage.
|
||||
3. Select **Manage User Settings**.
|
||||
4. In **Admin Mode**, modify the user's settings as needed. Saved changes take effect immediately in the user's account.
|
||||
|
||||
### Reset login attempts
|
||||
|
||||
If a user, whose account details are synchronized with AD/LDAP, can't access their Mattermost account due to too many failed login attempts, you can reset the number of failed login attempts for their user account in the System Console.
|
||||
|
||||
1. Go to **System Console \> User Management \> Users** to access all user accounts.
|
||||
2. Under **Actions**, select **Reset login attempts**.
|
||||
|
||||
<Note>
|
||||
|
||||
To adjust the maximum login attempts allowed for all users, go to **System Console \> Authentication \> AD/LDAP \> Maximum Login Attempts**. Lowering this [configuration setting](/administration-guide/configure/authentication-configuration-settings#maximum-login-attempts) value below the maximum threshhold allowed on your AD/LDAP server will ensure that your users won’t get locked out of AD/LDAP due to failed login attempts in Mattermost.
|
||||
|
||||
</Note>
|
||||
|
||||
### Update user's email
|
||||
|
||||
Update the emails of users using the System Console.
|
||||
|
||||
<Note>
|
||||
|
||||
From Mattermost v10.9, email addresses enclosed in angle brackets (e.g., `[billy@example.com](mailto:billy@example.com)`) will be rejected. To avoid issues, ensure all user emails comply with the plain address format (e.g., `billy@example.com`). In addition, we strongly recommend taking proactive steps to audit and update Mattermost user data to align with this product change, as impacted users may face issues accessing Mattermost or managing their user profile. You can update these user emails manually using [mmctl user email](/administration-guide/manage/mmctl-command-line-tool#mmctl-user-email).
|
||||
|
||||
</Note>
|
||||
|
||||
1. Go to **System Console \> User Management \> Users** to access all user accounts.
|
||||
2. Select the user, and enter a new email in the **Email** field.
|
||||
3. Select **Save**.
|
||||
|
||||

|
||||
|
||||
<Tip>
|
||||
|
||||
You can also update the email from the **Actions** column on the **Users** page. Select **Update email**, enter the new email for the user, and then select **Save**.
|
||||
|
||||
</Tip>
|
||||
|
||||
### Update user's username
|
||||
|
||||
From Mattermost 11.6: Update the username of a user using the System Console.
|
||||
|
||||
1. Go to **System Console \> User Management \> Users** to access all user accounts.
|
||||
2. Select the user, and enter a new username in the **Username** field.
|
||||
3. Select **Save**.
|
||||
|
||||
### Update user's authentication data
|
||||
|
||||
From Mattermost 11.6: System admins can view and update the authentication data (AuthData) for a user directly in the System Console. AuthData is the external identifier associated with the user's authentication method, such as an LDAP Distinguished Name (DN), SAML NameID, or OAuth ID. Updating this field is useful when a user's external authentication identifier changes, for example after an identity provider migration.
|
||||
|
||||
1. Go to **System Console \> User Management \> Users** to access all user accounts.
|
||||
2. Select the user to open their User Configuration page.
|
||||
3. In the **Authentication** section, view or update the user's authentication data value.
|
||||
4. Select **Save**.
|
||||
|
||||
### Reset user's password
|
||||
|
||||
Reset a user's password using the System Console.
|
||||
|
||||
1. Go to **System Console \> User Management \> Users** to access all user accounts.
|
||||
2. Select the user from the list, and then select **Reset Password**.
|
||||
3. Enter a new password and select **Reset**.
|
||||
|
||||

|
||||
|
||||
You can also reset the password using the **Actions** column for the specific user on the **Users** page. Select **Reset password** from the **Actions** column dropdown, enter the new password in the pop-up dialog box and select **Reset**.
|
||||
|
||||
### Revoke a user's session
|
||||
|
||||
Revoke the user sessions in case of an emergency to secure the user account using the System Console. This logs the user out of all devices.
|
||||
|
||||
1. Go to **System Console \> User Management \> Users** to access all user accounts.
|
||||
2. Under the **Actions** column for the specific user, select **Remove sessions**.
|
||||
3. Select **Revoke** to remove all sessions for that user.
|
||||
|
||||

|
||||
|
||||
### Review user profile details
|
||||
|
||||
View user profile details using the System Console. Gather information including the user's ID, username, email, authentication method, and team memberships.
|
||||
|
||||
1. Go to **System Console \> User Management \> Users** to access all user accounts.
|
||||
2. Select the user from the list, and browse user details.
|
||||
|
||||

|
||||
|
||||
------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
## Groups
|
||||
|
||||
<table style={{width: '99%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '46%'}} />
|
||||
<col style={{width: '45%'}} />
|
||||
<col style={{width: '7%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>Manage default teams and channels by linking AD/LDAP groups to Mattermost groups.</td>
|
||||
<td><ul>
|
||||
<li>System Config path: <strong>User Management > Groups</strong></li>
|
||||
<li><code>config.json setting</code>: N/A</li>
|
||||
<li>Environment variable: N/A</li>
|
||||
</ul></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan="3">See the <a href="/administration-guide/onboard/ad-ldap-groups-synchronization">AD/LDAP groups</a> documentation for details. |</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
## Teams
|
||||
|
||||
### Find Teams
|
||||
|
||||
You can find existing teams in your Mattermost instance using the System Console.
|
||||
|
||||
1. Go to **System Console \> User Management \> Teams** to access all available teams.
|
||||
2. Enter the team name in the **Search** box.
|
||||
|
||||

|
||||
|
||||
<Tip>
|
||||
|
||||
From Mattermost v9.6, you can search for specific teams by entering a partial or full team name in the **Search** field and pressing <kbd>Enter</kbd>.
|
||||
|
||||
</Tip>
|
||||
|
||||
### Filter team searches
|
||||
|
||||
Filter your team search to narrow down results based on the team management type (anyone can join, invite only, or group sync).
|
||||
|
||||
1. Go to **System Console \> User Management \> Teams** to access all available teams.
|
||||
2. Select **Filters** located to the right of the **Search** field to access available filter options.
|
||||
3. Choose any filter and select **Apply** to filter team search results.
|
||||
|
||||

|
||||
|
||||
### Review team configuration
|
||||
|
||||
View team configuration details using the System Console. Gather information including the team name, team description, team management options, groups, and members.
|
||||
|
||||
1. Go to **System Console \> User Management \> Teams** to access all available teams.
|
||||
2. Select the team from the list to view its configuration page.
|
||||
|
||||

|
||||
|
||||
### Manage team membership
|
||||
|
||||
Admins can directly add or remove member from the team and customize how members are added to the team using the System Console.
|
||||
|
||||
#### Add members
|
||||
|
||||
1. Go to **System Console \> User Management \> Teams** to access all available teams.
|
||||
2. Select the team from the list to view its configuration page.
|
||||
3. In the **Members** section, select **Add Members**.
|
||||
4. Select an user or available bot from the list or try using the **Search** to find a specific one.
|
||||
5. Select **Add** to add the user or bot.
|
||||
6. Select **Save**.
|
||||
|
||||

|
||||
|
||||
#### Remove members
|
||||
|
||||
1. Go to **System Console \> User Management \> Teams** to access all available teams.
|
||||
2. Select the team from the list to view its configuration page.
|
||||
3. In the **Members** section, select **Remove** for the user or bot that you want to remove.
|
||||
4. Select **Save**.
|
||||
|
||||

|
||||
|
||||
#### Sync group members
|
||||
|
||||
When enabled, adding and removing users from groups will add or remove them from this team. The only way of inviting members to this team is by adding the groups they belong to. See the [Synchronize teams and channels](/administration-guide/onboard/ad-ldap-groups-synchronization#synchronize-teams-and-channels) documentation for further details.
|
||||
|
||||
1. Go to **System Console \> User Management \> Teams** to access all available teams.
|
||||
2. Select the team from the list to view its configuration page.
|
||||
3. In the **Team Management** section, enable the **Sync Group Members** option.
|
||||
4. Select **Save**.
|
||||
|
||||

|
||||
|
||||
#### Anyone can join this team
|
||||
|
||||
This team can be discovered allowing anyone with an account to join this team.
|
||||
|
||||
1. Go to **System Console \> User Management \> Teams** to access all available teams.
|
||||
2. Select the team from the list to view its configuration page.
|
||||
3. In the **Team Management** section, enable the **Anyone can join this team** option.
|
||||
4. Select **Save**.
|
||||
|
||||

|
||||
|
||||
#### Only specific email domains can join this team
|
||||
|
||||
Users can only join the team if their email matches one of the specified domains.
|
||||
|
||||
1. Go to **System Console \> User Management \> Teams** to access all available teams.
|
||||
2. Select the team from the list to view its configuration page.
|
||||
3. In the **Team Management** section, enable the **Only specific email domains can join this team** option and add the specific domains.
|
||||
4. Select **Save**.
|
||||
|
||||

|
||||
|
||||
### Manage membership with attribute based membership policies
|
||||
|
||||
<PlanAvailability slug="entry-adv" />
|
||||
|
||||
From Mattermost v11.10, control who can be a member of this team based on their user attributes.
|
||||
|
||||
On private teams the rules are enforced: users who don't match can't join, and members who no longer match are removed at the next sync. On public teams the rules are advisory — the team is recommended to qualifying users, but anyone can still join.
|
||||
|
||||
1. Go to **System Console \> User Management \> Teams** to access all available teams.
|
||||
2. Select the team from the list to view its configuration page.
|
||||
3. In the **Team Management** section, enable the **Manage membership with attribute based membership policies** option. The **Membership policies** and **Team-specific membership rules** sections appear once this option is enabled.
|
||||
4. Link a system-wide policy, define team-specific rules, or both.
|
||||
5. Select **Save**.
|
||||
|
||||
This option is unavailable on group-synced teams, because group sync and attribute-based membership are mutually exclusive.
|
||||
|
||||
Team Admins with the **Manage Team Access Rules** permission can also define team membership rules from the **Team Membership** tab in [Team Settings](/end-user-guide/collaborate/team-settings), without access to the System Console.
|
||||
|
||||
See [Team membership access policies](/administration-guide/manage/admin/abac-team-membership) for full details.
|
||||
|
||||
### Synchronize team members
|
||||
|
||||
Admins can choose between inviting members to a team manually or synchronizing members automatically from AD/LDAP groups. See the [using AD/LDAP synchronized groups](/administration-guide/onboard/ad-ldap-groups-synchronization#synchronize-adldap-groups-to-mattermost) documentation for details on managing team or private channel membership.
|
||||
|
||||
### Archive the team
|
||||
|
||||
1. Go to **System Console \> User Management \> Teams** to access all available teams.
|
||||
2. Select the team from the list to view its configuration page.
|
||||
3. In the **Team Profile** section, select **Archive Team**.
|
||||
4. Select **Save**.
|
||||
|
||||

|
||||
|
||||
------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
## Channels
|
||||
|
||||
### Find Channels
|
||||
|
||||
Find existing channels in your Mattermost instance using the System Console.
|
||||
|
||||
1. Go to **System Console \> User Management \> Channels** to access all available channels.
|
||||
2. Enter the channel name in the **Search** box.
|
||||
|
||||

|
||||
|
||||
### Filter channel searches
|
||||
|
||||
Filter your channel search to narrow down results based on the channel type (as public, private or archived), channel management type (group sync or manual invites) or based on the team the channel belongs to.
|
||||
|
||||
1. Go to **System Console \> User Management \> Channels** to access all available channels.
|
||||
2. Select **Filters** located to the right of the **Search** field to access available filter options.
|
||||
3. Choose any filter and select **Apply** to filter channel search results.
|
||||
|
||||

|
||||
|
||||
### Review channel configuration
|
||||
|
||||
View channel configuration details using the System Console. Gather information including the channel profile, advanced access controls, channel management options, groups, and members.
|
||||
|
||||
1. Go to **System Console \> User Management \> Channels** to access all available channels.
|
||||
2. Select a channel from the list to review its channel configuration details.
|
||||
|
||||

|
||||
|
||||
### Advanced Access Control
|
||||
|
||||
Manage the Management actions available to channel members and guests.
|
||||
|
||||
#### Create Posts
|
||||
|
||||
The ability for members and guests to create posts in the channel.
|
||||
|
||||
1. Go to **System Console \> User Management \> Channels** to access all available channels.
|
||||
2. Select a channel from the list to view its configuration page.
|
||||
3. In the **Create Posts** section under the **Advanced Access Control** tab, select the option for **Guests**, **Members**, or both to enable those users to post messages in the channel.
|
||||
4. Select **Save**.
|
||||
|
||||

|
||||
|
||||
#### Post Reactions
|
||||
|
||||
The ability for members and guests to react with emojis on messages in the channel.
|
||||
|
||||
1. Go to **System Console \> User Management \> Channels** to access all available channels.
|
||||
2. Select a channel from the list to view its configuration page.
|
||||
3. In the **Post Reactions** section under the **Advanced Access Control** tab, select the option for **Guests**, **Members**, or both to enable those users to react with emojis on messages posted to the channel.
|
||||
4. Select **Save**.
|
||||
|
||||

|
||||
|
||||
#### Manage Members
|
||||
|
||||
The ability for members to add and remove people from the channels. Guests can't add or remove people from channels.
|
||||
|
||||
1. Go to **System Console \> User Management \> Channels** to access all available channels.
|
||||
2. Select a channel from the list to view its configuration page.
|
||||
3. In the **Manage Members** section under the **Advanced Access Control** tab, select **Members** to enable those users to manage members for the channel.
|
||||
4. Select **Save**.
|
||||
|
||||

|
||||
|
||||
#### Channel Mentions
|
||||
|
||||
The ability for members and guests to use channel mentions, including **@all**, **@here**, and **@channel**, in the channel.
|
||||
|
||||
1. Go to **System Console \> User Management \> Channels** to access all available channels.
|
||||
2. Select the channel from the list to view its configuration page.
|
||||
3. In the **Channel Mentions** section under the **Advanced Access Control** tab, select the option for **Guests**, **Members**, or both to enable those users to use channel mentions.
|
||||
4. Select **Save**.
|
||||
|
||||

|
||||
|
||||
<Tip>
|
||||
|
||||
**Guests** and **Members** can't use channel mentions without the ability to **Create Posts**. To enable this permission, these users must have been granted **Create Posts** permission first.
|
||||
|
||||
</Tip>
|
||||
|
||||
#### Manage Bookmarks
|
||||
|
||||
The ability for members to add, delete, and sort bookmarks. Guests can't add, remove, or sort bookmarks for the channel.
|
||||
|
||||
1. Go to **System Console \> User Management \> Channels** to access all available channels.
|
||||
2. Select the channel from the list to view its configuration page.
|
||||
3. In the **Manage Bookmarks** section under the **Advanced Access Control** tab, select **Members** to enable those users to add, sort, or remove bookmarks for the channel.
|
||||
4. Select **Save**.
|
||||
|
||||

|
||||
|
||||
<Tip>
|
||||
|
||||
The ability to manage bookmarks for the channel is available for **Members** only. **Guests** can't add, remove or sort bookmarks for the channel.
|
||||
|
||||
</Tip>
|
||||
|
||||
### Channel Management
|
||||
|
||||
Choose between inviting members manually or sychronizing members automatically from groups.
|
||||
|
||||
#### Sync Group Members
|
||||
|
||||
When enabled, adding and removing users from groups will add or remove them from this team. The only way of inviting members to this team is by adding the groups they belong to. See the [Synchronize teams and channels](/administration-guide/onboard/ad-ldap-groups-synchronization#synchronize-teams-and-channels) documentation for further details.
|
||||
|
||||
1. Go to **System Console \> User Management \> Channels** to access all available channels.
|
||||
2. Select the channel from the list to view its configuration page.
|
||||
3. In the **Channel Management** tab, enable the **Sync Group Members** option.
|
||||
4. Select **Save**.
|
||||
|
||||

|
||||
|
||||
#### Public channel or private channel
|
||||
|
||||
Public channels are discoverable and any user can join. Private channels require invitations to join.
|
||||
|
||||
1. Go to **System Console \> User Management \> Channels** to access all available channels.
|
||||
2. Select the channel from the list to view its configuration page.
|
||||
3. In the **Public channel or private channel** section under the **Channel Management** tab, toggle between **Public** or **Private** to change channel visibility.
|
||||
4. Select **Save**.
|
||||
|
||||

|
||||
|
||||
<Tip>
|
||||
|
||||
When Group Sync is enabled, private channels can't be converted to public channels.
|
||||
|
||||
</Tip>
|
||||
|
||||
### Members
|
||||
|
||||
Choose between inviting members manually or synchronizing members automatically from groups.
|
||||
|
||||
#### Add members
|
||||
|
||||
1. Go to **System Console \> User Management \> Channels** to access all available channels.
|
||||
2. Select the channel from the list to view its configuration page.
|
||||
3. In the **Members** section, select **Add Members**.
|
||||
4. Use the **Search** box to find a specific user or group to add to the channel.
|
||||
5. Select **Add** to add the user or group as a **Member**.
|
||||
6. Select **Save**.
|
||||
|
||||

|
||||
|
||||
#### Remove members
|
||||
|
||||
1. Go to **System Console \> User Management \> Channels** to access all available channels.
|
||||
2. Select the channel from the list to view its configuration page.
|
||||
3. In the **Members** section, select **Remove** for the user that you want to remove.
|
||||
4. Select **Save**.
|
||||
|
||||

|
||||
|
||||
### Archive a channel
|
||||
|
||||
1. Go to **System Console \> User Management \> Channels** to access all available channels.
|
||||
2. Select the channel from the list to view its configuration page.
|
||||
3. In the **Channel Profile** section, select **Archive Channel**.
|
||||
4. Select **Save**.
|
||||
|
||||

|
||||
|
||||
<Tip>
|
||||
|
||||
Channels can be deleted with all content, including posts in the database, using the [mmctl channel delete](/administration-guide/manage/mmctl-command-line-tool#mmctl-channel-delete) tool.
|
||||
|
||||
</Tip>
|
||||
|
||||
------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
## Permissions
|
||||
|
||||
<table style={{width: '99%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '48%'}} />
|
||||
<col style={{width: '43%'}} />
|
||||
<col style={{width: '6%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>Restrict actions in Mattermost to authorized users only.</td>
|
||||
<td><ul>
|
||||
<li>System Config path: <strong>User Management > Permissions</strong></li>
|
||||
<li><code>config.json setting</code>: N/A</li>
|
||||
<li>Environment variable: N/A</li>
|
||||
</ul></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan="3">See <a href="/administration-guide/onboard/advanced-permissions">advanced permissions</a> documentation for details</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
## System roles
|
||||
|
||||
<PlanAvailability slug="pro-plus" />
|
||||
|
||||
<table style={{width: '99%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '49%'}} />
|
||||
<col style={{width: '42%'}} />
|
||||
<col style={{width: '6%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>Restrict System Console access to authorized users only.</td>
|
||||
<td><ul>
|
||||
<li>System Config path: <strong>User Management > System Roles</strong></li>
|
||||
<li><code>config.json setting</code>: N/A</li>
|
||||
<li>Environment variable: N/A</li>
|
||||
</ul></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan="3">See the <a href="/administration-guide/onboard/delegated-granular-administration">delegated granular administration</a> documentation for details |</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
@@ -0,0 +1,332 @@
|
||||
---
|
||||
title: "Channel-specific access rules"
|
||||
---
|
||||
<PlanAvailability slug="entry-adv" />
|
||||
|
||||
Channel and Team Admins can self-manage access controls for their channels directly through the Channel Settings modal, without requiring System Admin intervention. For organization-wide policies created by System Admins, see [System-wide attribute-based access policies](/administration-guide/manage/admin/abac-system-wide-policies). For team-scoped policies that apply rules across multiple channels within a team, see [Team-level channel membership policies](/administration-guide/manage/admin/abac-team-channel-policies).
|
||||
|
||||
From Mattermost v11.8, channel access rules can be applied to **both private and public channels**. The two channel types behave differently under ABAC:
|
||||
|
||||
- **Private channels** are hard-gated. Non-matching members are removed during synchronization, and only matching users can be added or invited.
|
||||
- **Public channels** are advisory. Non-matching members are *never* removed (anyone can still join a public channel by browsing or via a direct link). With auto-add enabled the policy still pulls matching users in; with auto-add disabled the channel surfaces under **Browse Channels \> Recommended channels** for users whose attributes match.
|
||||
|
||||
Each ABAC channel access policy has an explicit active state that determines whether the policy will automatically add users who meet the policy's criteria but are not yet channel members. For private channels, the policy's rules are always enforced to remove members who no longer meet the required attribute rules, regardless of the active state. For public channels, no member is ever removed by ABAC — the rules are advisory only.
|
||||
|
||||
With channel access rules, Channel and Team Admins can:
|
||||
|
||||
- Create channel-specific access rules using a simple interface.
|
||||
- Use rules that are **additive** to any system policies. For private channels, both must be satisfied for adds and invites. For public channels, the combined rules affect auto-add and recommendations only, and don't block joins or remove members.
|
||||
- Automatic member synchronization with immediate feedback.
|
||||
- Self-exclusion prevention to avoid locking yourself out (private channels only).
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- [Attribute-Based Access Control (ABAC)](/administration-guide/manage/admin/attribute-based-access-control) must be enabled by a System Admin in **System Console \> System Attributes \> Attribute-Based Access**.
|
||||
- You need Channel Admin permissions and the `manage_channel_access_rules` permission.
|
||||
- Channel access rules are available for private and public channels, with behavior that varies by channel type. See [Public and private channel behavior](#public-and-private-channel-behavior). Default channels (such as Town Square and Off-Topic), shared channels, and group-synced channels remain ineligible.
|
||||
|
||||
### Access Channel Settings
|
||||
|
||||
1. In a private or public channel where you have Channel Admin permissions, select the channel name at the top of the center pane.
|
||||
2. Select **Channel Settings** from the dropdown menu.
|
||||
3. Navigate to the **Membership Policy** tab. This tab is only visible for eligible channels when you have the appropriate permissions and ABAC is enabled system-wide. The tab is hidden on default channels, shared channels, and group-synced channels.
|
||||
|
||||
<Tip>
|
||||
|
||||
You can also assign ABAC rules to a channel directly from a channel's details page in the System Console under **Channel Management** by enabling the **Enable attribute-based channel access** option. Under **Access policy**, select **Link to a policy** to select an existing policy.
|
||||
|
||||
</Tip>
|
||||
|
||||
## Configure access rules
|
||||
|
||||
Channel access rules use the same simple interface as system policies, allowing you to create attribute-based conditions without complex syntax.
|
||||
|
||||
1. In the **Membership Policy** tab, you'll see any inherited system policies at the top in a blue information banner (if applicable).
|
||||
2. Use the **Add attribute** button to create new access conditions:
|
||||
- **Select attribute**: Choose from available user attributes
|
||||
- **Choose operator**: Select how the attribute should match:
|
||||
- **Is**: Exact match with specified value
|
||||
- **Is not**: Must not match specified value
|
||||
- **In**: Must match any of multiple specified values
|
||||
- **Contains**: Attribute value must contain specified text
|
||||
- **Set values**: Enter the required attribute values
|
||||
3. Add multiple conditions as needed. All conditions are combined with logical AND (all must be satisfied).
|
||||
4. Select **Test access rules** to preview which users would be granted access based on your current rules.
|
||||
|
||||
### Auto-sync membership
|
||||
|
||||
The **Auto-add members based on access rules** toggle controls automatic membership management. The behavior differs by channel type:
|
||||
|
||||
- **Private channels (hard gate)**: Membership stays consistently aligned with the rules, similar to how LDAP group channels work.
|
||||
- **Enabled**: Users matching the rules are automatically added. If users temporarily lose attributes and later regain them, they will be automatically re-added.
|
||||
- **Disabled**: Rules act as a gate (preventing unauthorized joins) but don't automatically add qualifying users.
|
||||
- **Public channels (advisory)**: ABAC never removes members — anyone can still join a public channel.
|
||||
- **Enabled**: Matching users are automatically added (a convenience, not a gate).
|
||||
- **Disabled**: The channel appears under **Browse Channels \> Recommended channels** for users whose attributes match, surfacing the channel without adding anyone.
|
||||
|
||||
<Important>
|
||||
|
||||
- Auto-add/auto-sync is checked on a per-channel policy basis, not inherited from parent system-wide policies.
|
||||
- If a system policy has auto-sync enabled, Channel and Team Admins cannot disable it at the channel level.
|
||||
- If a system policy has auto-sync disabled, Channel and Team Admins can choose to enable it for their channel.
|
||||
- When no rules are configured, this toggle is automatically disabled.
|
||||
- On **private** channels, users who no longer meet required attribute rules are always removed during synchronization regardless of the auto-sync setting. On **public** channels, no member is ever removed by ABAC.
|
||||
|
||||
</Important>
|
||||
<Note>
|
||||
|
||||
If a policy rule references attribute values from a `shared_only` or `source_only` attribute that you don't personally hold, those values appear as `--------` and the row is read-only. Test and Delete actions are also disabled for those rows. See [Attribute value masking](/administration-guide/manage/admin/abac-system-wide-policies#attribute-value-masking) for details.
|
||||
|
||||
</Note>
|
||||
|
||||
### Validation and safety
|
||||
|
||||
Before saving changes, Mattermost validates your rules to prevent common issues:
|
||||
|
||||
- **Required fields**: All attribute selections and values must be completed.
|
||||
- **Self-exclusion prevention**: For private channels, you cannot save rules that would remove yourself from the channel. The check is skipped for public channels because they are advisory under ABAC and can't lock anyone out.
|
||||
- **Conflict detection**: Rules that create impossible conditions are identified.
|
||||
|
||||
When you save changes that affect membership, a confirmation dialog shows you:
|
||||
|
||||
- How many users will be added or removed.
|
||||
- Option to view the specific users affected.
|
||||
- Confirmation required before applying changes.
|
||||
|
||||
Once a policy is attached to a channel, the channel cannot be converted between public and private until the policy is removed. The two modes have different semantics (advisory vs. hard gate), so a silent conversion would change what an existing policy actually does to its members.
|
||||
|
||||
## Public and private channel behavior
|
||||
|
||||
Membership policies behave differently depending on the type of channel they're applied to:
|
||||
|
||||
- **Private channels**: Membership policies are enforced. Users who match the policy's rules are added, and users who don't match the rules are removed during synchronization.
|
||||
- **Public channels**: Membership policies are advisory. Matching users may be automatically added when auto-add is enabled, but non-matching members are not removed.
|
||||
- When auto-add is disabled for a public channel, matching channels are surfaced as **recommended** rather than enforcing membership.
|
||||
- Direct messages and group messages aren't eligible for membership policies.
|
||||
- Default channels such as **Town Square** and **Off-Topic** are excluded.
|
||||
|
||||
<Note>
|
||||
|
||||
Public channels with membership policies may appear in **Browse Channels** under **Recommended**, and matching users may be marked **Recommended** in the channel invite flow. See [Browse channels](/end-user-guide/collaborate/browse-channels) and [Manage channel members](/end-user-guide/collaborate/manage-channel-members) for the end-user experience.
|
||||
|
||||
</Note>
|
||||
|
||||
## Channel-level permission policies
|
||||
|
||||
From Mattermost v11.8.0, channel admins can define channel-level permission rules for file upload and file download based on user attributes and channel role. Applicable roles include **channel admin**, **channel member**, and **channel guest**.
|
||||
|
||||
For system-wide permission policies that restrict file upload and download actions, see [Permission policies](/administration-guide/manage/admin/abac-system-wide-policies#permission-policies).
|
||||
|
||||
## Simulate access
|
||||
|
||||
From Mattermost v11.8.0, admins can use **Simulate access** in Channel Settings to preview whether selected users can perform actions such as uploading files or downloading files before saving policy changes.
|
||||
|
||||
- Simulation can evaluate draft rules before they're saved, so you can confirm the intended scope without affecting live channel access.
|
||||
- Some denied results may indicate that the decision came from another policy. In that case, Mattermost shows that access was denied by another policy without exposing policy details you aren't authorized to see.
|
||||
|
||||
<Note>
|
||||
|
||||
Channel-level permission policies and **Simulate access** are gated by the `PermissionPolicies` feature flag (`MM_FEATUREFLAGS_PERMISSIONPOLICIES`) and require a Mattermost Enterprise Advanced license. See the Mattermost developer documentation for details on [enabling feature flags in a self-hosted deployment](https://developers.mattermost.com/contribute/more-info/server/feature-flags/#self-hosted-and-local-development). Mattermost Cloud customers can request this feature flag be enabled by contacting their Mattermost Account Manager or by [creating a support ticket](https://support.mattermost.com/hc/en-us/requests/new?ticket_form_id=11184911962004).
|
||||
|
||||
</Note>
|
||||
|
||||
## Manage team-scoped membership policies in Team Settings
|
||||
|
||||
From Mattermost v11.7, Team Admins can create, edit, and delete channel membership policies directly from Team Settings, scoped to channels within their team. This lets teams self-manage attribute-based membership for their own channels without requiring a System Admin to create or modify a system-wide policy.
|
||||
|
||||
### Prerequisites
|
||||
|
||||
- [Attribute-Based Access Control (ABAC)](/administration-guide/manage/admin/attribute-based-access-control) must be enabled by a System Admin in **System Console \> System Attributes \> Attribute-Based Access**.
|
||||
- You need Team Admin permissions for the team and the `manage_team_access_rules` permission.
|
||||
- Team-scoped membership policies can be assigned to both public and private channels within the team.
|
||||
|
||||
### Team Admin workflow
|
||||
|
||||
1. Open **Team Settings** from the team menu, and go to the **Channel Membership** tab. This tab is only visible to Team Admins with the `manage_team_access_rules` permission when ABAC is enabled system-wide.
|
||||
2. Select **Add Policy** and enter a name for the policy. Parent policy names must be unique; if you enter a name that's already in use, Mattermost displays a user-friendly error and prevents the policy from being saved.
|
||||
3. Define the attribute rules that determine which users can be members of channels assigned to this policy. Rules use the same attribute conditions available for channel-specific access rules.
|
||||
4. Assign the applicable private channels in the team to the policy.
|
||||
5. Select **Save** to create or update the policy. Team-scoped policies can be edited or deleted from the same tab at any time.
|
||||
|
||||
### Team Settings sync status footer
|
||||
|
||||
The **Channel Membership** tab includes a sync status footer that shows:
|
||||
|
||||
- **Last sync time**: The time of the most recent membership synchronization for policies in this team.
|
||||
- **Sync now**: An on-demand action that triggers an immediate synchronization for the team's policies.
|
||||
|
||||
Team-scoped sync is limited to the team admin's team scope. Triggering **Sync now** from Team Settings does not affect channels or policies outside the current team.
|
||||
|
||||
### Sync behavior by channel type
|
||||
|
||||
Sync behavior for team-scoped membership policies depends on the type of channel the policy is assigned to:
|
||||
|
||||
- **Public channels**: Sync is advisory and add-only. Users who match the policy's rules are added to the channel, but no users are removed if their attributes change.
|
||||
- **Private channels**: Sync is enforced. Users who match the policy's rules are added to the channel, and users who no longer match the rules are removed during the next synchronization.
|
||||
|
||||
### Automatic sync on policy changes
|
||||
|
||||
Mattermost automatically runs a sync job whenever a team-scoped membership policy is created, or its rules, assigned channels, or active state change. Team Admins don't need to manually trigger **Sync now** for these updates; the sync runs as part of the change.
|
||||
|
||||
## Policy inheritance
|
||||
|
||||
Channel-level (child) ABAC policies now behave independently and consistently, even when parent system-wide policies exist. Each policy maintains its own active state and configuration.
|
||||
|
||||
When both [system policies](/administration-guide/manage/admin/abac-system-wide-policies) and channel rules are configured:
|
||||
|
||||
1. **System policies** are displayed in a blue banner at the top (read-only)
|
||||
2. **Channel rules** are managed in the access rules section below
|
||||
3. **Users must satisfy BOTH** system policies and channel rules to access the channel
|
||||
4. Channel rules **add restrictions** but cannot weaken system policies
|
||||
5. **Auto-add behavior** is determined by the individual channel policy, not inherited from parent system-wide policies. System-wide policies can pass down their rules, but auto-add/auto-sync is evaluated per channel.
|
||||
|
||||
## Use cases and recommendations
|
||||
|
||||
**Ideal use cases for channel access rules:**
|
||||
|
||||
- **Project-specific channels**: Restrict access to team members working on specific projects
|
||||
- **Clearance-based discussions**: Ensure only users with appropriate security clearance can participate
|
||||
- **Department communications**: Limit channel access to specific organizational units
|
||||
- **Temporary access**: Create rules for short-term project teams or contractor access
|
||||
|
||||
**Best practices:**
|
||||
|
||||
- **Start simple**: Begin with basic attribute conditions before adding complexity
|
||||
- **Test before saving**: Always use the "Test access rules" feature to verify your intended scope
|
||||
- **Document changes**: Consider posting a message in the channel when access rules change
|
||||
- **Regular review**: Periodically review rules to ensure they remain appropriate
|
||||
- **Coordinate with IT**: Work with System Admins for complex organizational policies
|
||||
|
||||
**When to use system policies vs. channel rules:**
|
||||
|
||||
- **System policies**: Use for organization-wide standards, compliance requirements, or policies affecting multiple channels
|
||||
- **Channel rules**: Use for channel-specific restrictions, project-based access, or when you need immediate control without IT involvement
|
||||
|
||||
## End-user experience
|
||||
|
||||
When channels have attribute-based access controls applied, users will see clear indicators and experience specific behaviors designed to maintain security while providing transparency.
|
||||
|
||||
### Visual indicators
|
||||
|
||||
**Channel Members panel:**
|
||||
|
||||
- Information banner at the top explains that attribute-based access is enabled. The message differs by channel type: private channels indicate that access is restricted by user attributes, while public channels indicate that member recommendations are based on user attributes.
|
||||
- Displays required attribute values as tags (e.g., "Engineering", "Confidential").
|
||||
- Tooltip on hover shows the attribute name for each value.
|
||||
|
||||
**Add Members modal:**
|
||||
|
||||
- Similar information banner and attribute value display.
|
||||
- On **private** channels, users who don't match the access criteria won't appear in search results — only eligible users can be added.
|
||||
- On **public** channels, the full team list is shown and matching users are surfaced with a **Recommended** tag at the top of the list. Anyone can still be added because public-channel ABAC is advisory.
|
||||
|
||||
**Browse Channels:**
|
||||
|
||||
- A **Recommended channels** filter is available in the channel-type dropdown when ABAC is enabled. Selecting it lists the public channels whose policies the user matches — useful when auto-add is disabled and the channel is offered as a recommendation rather than auto-joined.
|
||||
|
||||
### Functional restrictions
|
||||
|
||||
When ABAC is enabled for a **private** channel:
|
||||
|
||||
- **Search limitations**: Users who don't match access criteria don't appear in member search results.
|
||||
- **Invitation restrictions**: Only users meeting attribute requirements can be added to the channel.
|
||||
- **Guest user exclusions**: Private channels with ABAC policies cannot have guest users invited.
|
||||
- **Automatic removal**: Users who lose required attributes are automatically removed during the next synchronization.
|
||||
|
||||
When ABAC is enabled for a **public** channel:
|
||||
|
||||
- **Search results are unfiltered**: All eligible team members appear in the Add Members modal so admins can still invite anyone; matching users carry a **Recommended** tag.
|
||||
- **Recommendations**: With auto-add disabled, the channel surfaces under **Browse Channels \> Recommended channels** for matching users.
|
||||
- **Auto-add (when enabled)**: Matching users are added automatically. **Members are never removed** by ABAC — users can always leave on their own, and joining freely is unaffected because the channel is public.
|
||||
|
||||
<Note>
|
||||
|
||||
These behaviors apply across all Mattermost clients, including web, desktop, and mobile, to ensure consistent enforcement.
|
||||
|
||||
</Note>
|
||||
|
||||
## Troubleshooting and FAQs
|
||||
|
||||
Common questions about attribute-based access control implementation and usage.
|
||||
|
||||
### Permission and access
|
||||
|
||||
#### Why can't I see the Membership Policy tab in Channel Settings?
|
||||
|
||||
The **Membership Policy** tab is only visible when all of these conditions are met:
|
||||
|
||||
- You have Channel Admin role or higher for the channel.
|
||||
- The channel is a private or public channel (not a default channel like Town Square or Off-Topic, group message, direct message, shared, or group-synced channel).
|
||||
- ABAC is enabled system-wide by a System Admin in **System Console \> System Attributes \> Attribute-Based Access**.
|
||||
- Your user role includes the `manage_channel_access_rules` permission.
|
||||
|
||||
#### Can Channel and Team Admins override system policies?
|
||||
|
||||
No. Channel rules are always **additive** to system policies. Users must satisfy both system policies AND channel rules to access the channel. Channel and Team Admins cannot weaken or override restrictions set by System Admins.
|
||||
|
||||
#### What happens if I create rules that would exclude myself?
|
||||
|
||||
For **private** channels, Mattermost prevents this with self-exclusion validation. If your rules would remove you from the channel, you'll see an error message and cannot save the changes until you adjust the rules or reset them.
|
||||
|
||||
For **public** channels, the self-exclusion check is skipped — public-channel ABAC is advisory, the policy can't kick anyone out, and you can always re-join a public channel directly. This lets you author a policy intended for a different team (for example, a Sales admin configuring an Engineering recommendation) without being blocked.
|
||||
|
||||
#### Can I convert a public channel to private (or vice versa) while a policy is attached?
|
||||
|
||||
No. The two modes have different semantics — a public-channel policy is advisory while a private-channel policy is a hard gate that removes non-matching members. A silent conversion would change what the existing policy does to its members, so Mattermost requires you to remove the policy first, convert the channel, and re-attach the policy if you still want it.
|
||||
|
||||
### Rule configuration
|
||||
|
||||
#### Can I use advanced CEL expressions in Channel Settings?
|
||||
|
||||
No. Channel Settings only supports Basic Mode with simple attribute conditions. For complex expressions with nested logic or mixed operators, System Admins need to create policies in the System Console.
|
||||
|
||||
#### How do I remove all access rules from a channel?
|
||||
|
||||
Delete all attribute conditions from the access rules table. When no rules are configured and no system policies are applied, the channel returns to standard access behavior.
|
||||
|
||||
#### Why is the auto-sync toggle disabled?
|
||||
|
||||
The auto-sync toggle is automatically disabled when:
|
||||
|
||||
- No access rules are configured
|
||||
- A system policy with auto-sync enabled is applied (Channel and Team Admins cannot disable it)
|
||||
- There are validation errors in the current rules
|
||||
- The channel's access control policy is not in an active state
|
||||
|
||||
<Note>
|
||||
|
||||
**Troubleshooting auto-sync issues**: If auto-sync functionality (automatic adding/re-adding of members) is not working as expected, verify that the channel's access control policy is in an active state. An inactive policy will prevent automatic member additions from occurring. Note that enforcement of rules (removal of members who no longer meet requirements) happens regardless of the policy's active state.
|
||||
|
||||
</Note>
|
||||
|
||||
### Synchronization and membership
|
||||
|
||||
#### How quickly are membership changes applied?
|
||||
|
||||
When you save access rules, membership sync job is created and changes are applied as soon as the job is completed. Additionally, Mattermost runs synchronization jobs on a schedule to handle attribute changes from external systems (LDAP, SAML). The interval is set by `AccessControlSettings.SyncJobIntervalSeconds` and defaults to 3600 seconds (60 minutes). User attributes used for access control evaluation are refreshed on a separate schedule controlled by `AccessControlSettings.AttributeRefreshIntervalSeconds`, which defaults to 30 seconds.
|
||||
|
||||
#### Will users be notified when they're removed from a channel?
|
||||
|
||||
Yes, users receive standard Mattermost notifications when they're removed from channels due to access rule changes, similar to manual removals.
|
||||
|
||||
#### Can I see who was added or removed during synchronization?
|
||||
|
||||
Yes, the confirmation modal before saving shows exactly which users will be affected. System Admins can also view detailed synchronization logs in the System Console.
|
||||
|
||||
### Attribute and data questions
|
||||
|
||||
#### Which user attributes can I use in access rules?
|
||||
|
||||
You can use any user attributes either synchronized via LDAP/SAML or manually configured by System Admins in **System Console \> System Attributes \> User Attributes**.
|
||||
|
||||
#### What happens if a user attribute changes?
|
||||
|
||||
During the next scheduled synchronization (every 60 minutes by default), users who no longer match the access rules will be removed from the channel, and new users who now match will be added (if auto-sync is enabled).
|
||||
|
||||
#### Do guest users work with ABAC channels?
|
||||
|
||||
No. Private channels with attribute-based access control cannot have guest users. This ensures strict adherence to access control policies based on organizational attributes.
|
||||
|
||||
#### Can group-sync channels use ABAC?
|
||||
|
||||
No. Channels configured with group synchronization cannot use attribute-based access control. Group-sync and ABAC are mutually exclusive features - you must choose one method of access control per channel.
|
||||
@@ -0,0 +1,193 @@
|
||||
---
|
||||
title: "System-wide attribute-based access policies"
|
||||
---
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
<PlanAvailability slug="entry-adv" />
|
||||
|
||||
Use this guide to create and manage organization-wide attribute-based access policies in the System Console. Policies can be assigned to both channels and teams. For channel-level rules managed by Channel Admins, see [Channel-specific access rules](/administration-guide/manage/admin/abac-channel-access-rules). For team membership policies, see [Team membership access policies](/administration-guide/manage/admin/abac-team-membership).
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- [Attribute-based access controls (ABAC)](/administration-guide/manage/admin/attribute-based-access-control) require defined user attributes. First [configure user attributes](/administration-guide/manage/admin/user-attributes) in the System Console.
|
||||
- Then go to **System Console \> System Attributes \> Attribute-Based Access** to enable attribute-based access controls for your Mattermost instance. This functionality requires a Mattermost Enterprise Advanced license.
|
||||
|
||||
From Mattermost v10.11, user-managed attributes are excluded from attribute-based access control (ABAC) rules by default for security reasons. This prevents access control policies from being circumvented by users editing their own profile attributes. To include user-managed attributes in ABAC rules, a system admin must explicitly enable the `EnableUserManagedAttributes` configuration setting. See the [user attribute](/administration-guide/manage/admin/user-attributes#before-you-begin) documentation for details on enabling this feature. This configuration setting is available only in Enterprise Edition Advanced and is disabled by default.
|
||||
|
||||
## Define access control policies
|
||||
|
||||
You can add multiple rules to a single policy, and each rule can include multiple attribute values.
|
||||
|
||||
1. In the System Console, go to **System Attributes \> Attribute-Based Access** and select **Add Policy**.
|
||||
|
||||
2. Enter a unique policy name. Parent access control policy names must be unique; if you enter a name that's already in use, Mattermost displays a user-friendly error message and prevents the policy from being saved until you choose a different name.
|
||||
|
||||
3. Choose whether to automatically add users who match your configured attribute values as new members. Automatic synchronization is disabled by default.
|
||||
|
||||
- **True**: Automatically maintains channel membership according to the defined rules as user attributes change.
|
||||
- **False** (**Default**): Only removes members and restricts adding them to the channel if they don’t match defined rules. Users are not automatically added.
|
||||
|
||||
Regardless of whether this configuration setting, users who no longer match the configured attribute values in the future will be removed from the channel after the next channel synchronization.
|
||||
|
||||
4. Define the attribute-based access rules to restrict channel membership.
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="simple-mode" label="Simple Mode">
|
||||
|
||||
Simple Mode is ideal for simple and straightforward access control scenarios. Each row is a single condition that must be met for a user to comply with the policy. Simple Mode only supports simple conditions without nested logic or mixed logical operators. All rules are combined with a logical AND operator `&&`.
|
||||
|
||||
1. Select **Add attribute** and select the attribute you want to use for access control.
|
||||
|
||||
2. Specify how you want the attribute to match the user profile. You can choose from the following options:
|
||||
|
||||
> - **Is**: The attribute must be an exact match of the value.
|
||||
> - **Is not**: The attribute must not contain specified value.
|
||||
> - **In**: The attribute must match at least one value.
|
||||
> - **Starts with**: The attribute value must start with the specified value.
|
||||
> - **Ends with**: The attribute value must end with the specified value.
|
||||
> - **Contains**: The attribute value must exist somewhere with the specified value.
|
||||
>
|
||||
> When the selected attribute is a **Ranked** attribute (an ordered list of values, such as clearance or classification levels), the match options are ordered comparisons instead. These let you match everyone at or above a threshold rather than only an exact value:
|
||||
>
|
||||
> - **Is exactly** / **Is not**: The value must exactly match, or must not match, the specified value.
|
||||
> - **Is at least**: The value must be equal to or higher than the specified value - for example, clearance *is at least* Secret matches Secret and every higher level.
|
||||
> - **Is greater than**: The value must be higher than the specified value.
|
||||
> - **Is at most**: The value must be equal to or lower than the specified value.
|
||||
> - **Is less than**: The value must be lower than the specified value.
|
||||
|
||||
3. Specify the attribute values that users must have to be granted access to the channel.
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="advanced-mode" label="Advanced Mode">
|
||||
|
||||
Advanced Mode is ideal for complex access control scenarios that require CEL syntax to combine multiple conditions with logical operators that support rules like `user.<attribute> == <value>`, using `&&` / `||` (and/or) for multiple conditions, and `()` to group conditions. The CEL Expression Editor provides real-time syntax validation and feedback, as well as context-aware autocomplete for attributes, operators, and attribute values.
|
||||
|
||||
You can also start defining rules in Simple Mode and then switch to Advanced Mode to refine the rules further as needed. However, you'll be blocked from switching from Advanced back to Simple Mode if one of the following are true:
|
||||
|
||||
- Mixed logical operators are used between conditions.
|
||||
- Nested logic/grouping (parentheses) are present.
|
||||
- Unsupported operators or expressions are detected.
|
||||
|
||||
The syntax structure is `user.<attribute> <operator> <value>`.
|
||||
|
||||
As you type, autocompletes show available attributes. As you select attributes, autocomplete suggests appropriate CEL operators. After selecting an operator, when attribute values are pre-defined, autocomplete suggests values to choose from. Mattermost will explicitly indicate issues such as missing operators, incorrect syntax, or incomplete conditions.
|
||||
|
||||
Select the **Validate syntax** bar to check the syntax of your rule. If the syntax is valid, the bar will turn green and display a message indicating that the syntax is valid. If there are any issues, the bar will turn red and display an error message.
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
### Simulate access
|
||||
|
||||
Select **Test access rule** to test the rule against your user base to return how many users would be granted access to the channel based on the current rule. Test your rules to ensure the intended scope and avoid unexpected access changes.
|
||||
|
||||
From Mattermost v11.8.0, you can use **Simulate access** to preview allowed and denied outcomes for specific users before saving policy changes:
|
||||
|
||||
1. Open the policy editor in the System Console.
|
||||
2. Select **Simulate access**.
|
||||
3. Choose the users you want to test.
|
||||
4. Review the allowed and denied outcomes by action, such as joining a channel or uploading and downloading files.
|
||||
5. Adjust the rules before saving.
|
||||
|
||||
Simulation can test draft policy changes before they affect live channel access or file permissions. Detailed rule and attribute information is shown only when the denial comes from the policy or scope you're editing; otherwise, Mattermost may show that access was denied by another policy.
|
||||
|
||||
<Note>
|
||||
|
||||
**Simulate access** and channel-level permission policies for file upload and file download are gated by the `PermissionPolicies` feature flag (`MM_FEATUREFLAGS_PERMISSIONPOLICIES`) and require a Mattermost Enterprise Advanced license. See the Mattermost developer documentation for details on [enabling feature flags in a self-hosted deployment](https://developers.mattermost.com/contribute/more-info/server/feature-flags/#self-hosted-and-local-development). Mattermost Cloud customers can request this feature flag be enabled by contacting their Mattermost Account Manager or by [creating a support ticket](https://support.mattermost.com/hc/en-us/requests/new?ticket_form_id=11184911962004).
|
||||
|
||||
</Note>
|
||||
|
||||
### Manage rules
|
||||
|
||||
You can apply changes to existing rules or remove rules at any time using either Simple Mode or Advanced Mode. Select **Save** to save your changes.
|
||||
|
||||
### Assign policies to channels
|
||||
|
||||
From Mattermost v11.8, system-wide policies can be assigned to **both private and public channels**. Select **Add channels** to search for and select the channels you want. You can assign the policy to multiple channels at once, or you can [assign it to individual channels](#define-access-controls-per-channel) later. Select **Save** to save your changes.
|
||||
|
||||
The two channel types behave differently under the same policy:
|
||||
|
||||
- **Private channels** are hard-gated. The policy adds matching users (when auto-add is enabled), removes non-matching members during synchronization, and prevents non-matching users from being added or invited.
|
||||
- **Public channels** are advisory. The policy never removes members and never blocks anyone from joining. With auto-add enabled it automatically adds matching users; with auto-add disabled the channel appears under **Browse Channels \> Recommended channels** for matching users.
|
||||
|
||||
Before saving, you'll be prompted to confirm the impact of the change so you can review how it affects each channel type.
|
||||
|
||||
Default channels (such as Town Square and Off-Topic), shared channels, and group-synced channels remain ineligible — they are excluded from the channel selector.
|
||||
|
||||
<Note>
|
||||
|
||||
Private channels with attribute-based access control policies can't have guest users invited to them. Only users who match the defined attribute criteria can be added to ABAC-controlled private channels, ensuring strict adherence to access control policies. Public channels remain joinable by anyone regardless of the policy.
|
||||
|
||||
</Note>
|
||||
|
||||
### Assign policies to teams
|
||||
|
||||
From Mattermost v11.10, system-wide policies can also be assigned to teams. Go to **System Console \> User Management \> Teams** and open the team you want to configure. In the **Team Management** section, enable **Manage membership with attribute based membership policies** — the **Membership policies** section only appears once this toggle is on. Then link an existing policy and select **Save**.
|
||||
|
||||
Group-synced teams cannot use membership policies, so the toggle is unavailable on them.
|
||||
|
||||
The policy behaves differently depending on the team's privacy mode:
|
||||
|
||||
- **Private teams** — strict enforcement: join is gated, non-qualifying members are removed at sync, and the team is hidden from non-qualifying non-members in Browse Teams.
|
||||
- **Public teams** — advisory: the policy is never a gate. Qualifying non-members see a **Recommended** chip in Browse Teams; anyone can still join freely.
|
||||
|
||||
For a full description of team assignment, custom rules, sync configuration, and end-user surfaces, see [Team membership access policies](/administration-guide/manage/admin/abac-team-membership).
|
||||
|
||||
### Delete policies
|
||||
|
||||
To delete a policy, select the **Delete** button next to the policy you want to remove. Policies that are still assigned to channels cannot be deleted — remove the policy from those channels first.
|
||||
|
||||
Team assignments are not checked before deletion, so unlink the policy from every team that uses it before deleting it. Otherwise those teams keep a reference to a policy that no longer exists.
|
||||
|
||||
## Define access controls per channel
|
||||
|
||||
You can assign an existing access control policy to a private or public channel for more granular control over channel membership. This is useful when you need to apply different rules for different channels.
|
||||
|
||||
1. In the System Console, go to **User Management \> Channels** to select the private or public channel you want to configure, and select **Edit**.
|
||||
2. In the **Channel Management** section, enable the **Enable attribute-based channel access** option.
|
||||
3. Under **Access policy**, select **Link to a policy** to select an existing policy.
|
||||
|
||||
Once a policy is attached, the channel's privacy can no longer be flipped between public and private until the policy is removed — see [Channel-specific access rules](/administration-guide/manage/admin/abac-channel-access-rules#validation-and-safety).
|
||||
|
||||
<Tip>
|
||||
|
||||
You can also assign ABAC rules to a channel directly from a channel's details page in the System Console under **Channel Management** by enabling the **Enable attribute-based channel access** option. Under **Access policy**, select **Link to a policy** to select an existing policy.
|
||||
|
||||
</Tip>
|
||||
|
||||
### Remove channel policies
|
||||
|
||||
Disable the policy for the channel by selecting **Remove Policy**. You can then link the channel to a different policy if preferred.
|
||||
|
||||
## Permission policies
|
||||
|
||||
From Mattermost v11.7, System Admins can define attribute-based **permission policies** that restrict specific user actions in addition to channel membership. Permission policies use the same attribute-based rules as access policies, but they apply to user actions rather than channel access.
|
||||
|
||||
Permission policies can be used to restrict the following actions based on user attributes:
|
||||
|
||||
- **File upload**: Prevent users who don't match the defined attribute rules from uploading file attachments.
|
||||
- **File download**: Prevent users who don't match the defined attribute rules from downloading file attachments.
|
||||
|
||||
When a permission policy applies, users who don't match the configured attribute values can't perform the restricted action. Users may see file attachments as unavailable or redacted in messages they would otherwise have access to. See [Restricted file attachments](/end-user-guide/collaborate/share-files-in-messages#restricted-file-attachments) for the end-user-facing behavior.
|
||||
|
||||
Permission policies follow the same unique-name requirement as access policies: each parent permission policy must have a unique name, and Mattermost surfaces a user-friendly error if a duplicate name is entered.
|
||||
|
||||
## Attribute value masking
|
||||
|
||||
From Mattermost v11.8, when a policy references attribute values that the editing admin doesn't personally hold, those values are hidden in the policy editor. This prevents admins from reading or copying sensitive attribute values they're not authorized to see, while still allowing the policy to enforce access control normally.
|
||||
|
||||
Masking only applies to attributes configured with a `shared_only` or `source_only` access mode. Attributes with a `public` access mode are always visible to all admins. See [Attribute access modes](/administration-guide/manage/admin/user-attributes#attribute-access-modes) for details on how each mode controls value visibility.
|
||||
|
||||
**What you'll see:**
|
||||
|
||||
- Masked values appear as `--------` in the rule editor instead of the raw value.
|
||||
- Rows containing masked values are **read-only** and cannot be modified.
|
||||
- **Test rule** and **Delete** actions are disabled for rules that contain masked values.
|
||||
|
||||
**Enforcement is unaffected:** masking applies to the editing UI only. The underlying rules continue to control channel access and permissions as configured.
|
||||
|
||||
**To edit a masked rule**, ask the policy owner or another System Admin who holds the relevant attribute values to make the change.
|
||||
|
||||
This behavior applies to both the table editor and the CEL editor, and also to Team Admin and Channel Admin policy editors in Team Settings and Channel Settings. Requires Enterprise Advanced license and the `AttributeValueMasking` feature flag.
|
||||
@@ -0,0 +1,149 @@
|
||||
---
|
||||
title: "Team-level channel membership policies"
|
||||
sidebar_label: "Team channel policies"
|
||||
---
|
||||
<PlanAvailability slug="entry-adv" />
|
||||
|
||||
Team Admins can create and manage attribute-based membership policies for private channels within their team, directly from Team Settings, without requiring System Admin involvement. For organization-wide policies managed by System Admins, see [System-wide attribute-based access policies](/administration-guide/manage/admin/abac-system-wide-policies).
|
||||
|
||||
<Note>
|
||||
|
||||
From Mattermost v11.10, Team Settings has four tabs: **Info**, **Access**, **Team Membership**, and **Channel Membership**. This page covers the **Channel Membership** tab — policies that Team Admins configure for *channels* within their team. For team-level membership policies (controlling who can join the team itself), see [Team membership access policies](/administration-guide/manage/admin/abac-team-membership).
|
||||
|
||||
</Note>
|
||||
|
||||
With team-level channel membership policies, Team Admins can:
|
||||
|
||||
- Create policies that apply attribute-based access rules to one or more private channels within their team.
|
||||
- Control which users can join or stay in those channels based on their profile attributes.
|
||||
- Manage auto-sync membership, so channels stay up to date as user attributes change.
|
||||
|
||||
## Use cases
|
||||
|
||||
- **Team-wide project access**: Restrict all private project channels to members with a specific project attribute.
|
||||
- **Department isolation**: Ensure only users from a specific department can join the team's private channels.
|
||||
- **Clearance tiers**: Apply clearance-level requirements consistently across multiple channels in the team without System Admin involvement for each change.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- [Attribute-Based Access Control (ABAC)](/administration-guide/manage/admin/attribute-based-access-control) must be enabled by a System Admin in **System Console \> System Attributes \> Attribute-Based Access**.
|
||||
- You need Team Admin permissions for the team. The `manage_team_access_rules` permission is included in the Team Admin role by default.
|
||||
- Team-level membership policies apply only to private channels within the team.
|
||||
|
||||
### Access Team Settings
|
||||
|
||||
1. Select the team name in the sidebar to open the team menu.
|
||||
2. Select **Team Settings**.
|
||||
3. Navigate to the **Channel Membership** tab (the fourth tab in Team Settings). This tab is only visible when ABAC is enabled system-wide and you have Team Admin permissions.
|
||||
|
||||
<Note>
|
||||
|
||||
System Admins also have access to the **Channel Membership** tab in Team Settings and see the same policies as Team Admins.
|
||||
|
||||
</Note>
|
||||
|
||||
## Manage membership policies
|
||||
|
||||
The **Channel Membership** tab shows policies scoped to the team. Each policy displays its name and the number of private channels it applies to.
|
||||
|
||||
Team Admins only see policies whose access rules their own user attributes satisfy. If a policy has rules that exclude the Team Admin's attributes (for example, a policy requiring `Department=Engineering` and the Team Admin has `Department=Finance`), that policy will not appear in their list. This is a self-inclusion safety mechanism to prevent admins from being locked out of policies they manage.
|
||||
|
||||
### Create a policy
|
||||
|
||||
1. In the **Channel Membership** tab, select **Add policy**.
|
||||
2. Enter a unique policy name.
|
||||
3. Define access rules under **Access rules**:
|
||||
- Select **Add attribute** to add a condition.
|
||||
- For each condition, choose the user attribute, the matching operator (**Is**, **Is not**, **In**, **Contains**), and the required value.
|
||||
- Add multiple conditions as needed. All conditions are combined with a logical AND, so users must satisfy all of them.
|
||||
4. Assign channels under **Assigned channels**:
|
||||
- Select **Add channels** to search for and select private channels within the team.
|
||||
- Channels already assigned to this policy are excluded from the search results to prevent duplicates.
|
||||
- A channel can be assigned to multiple policies simultaneously; all policies are enforced independently.
|
||||
5. Optionally, toggle **Auto-add members** per channel to control whether users matching the rules are automatically added to that channel.
|
||||
6. Select **Save** to apply the policy.
|
||||
|
||||
<Important>
|
||||
|
||||
Self-exclusion prevention is enforced during save. If your defined rules would exclude your own user account, Mattermost will block the save and display an error. Adjust your rules to include your own attributes before saving.
|
||||
|
||||
</Important>
|
||||
|
||||
### Edit a policy
|
||||
|
||||
Select a policy row in the list, or use the three-dot menu and select **Edit**, to open the policy editor. You can update the policy name, access rules, and channel assignments. Select **Save** to apply changes.
|
||||
|
||||
When saving changes that affect existing channel membership, a confirmation dialog shows how many users will be added or removed. Confirm to proceed.
|
||||
|
||||
### Delete a policy
|
||||
|
||||
You can only delete a policy that has no channels assigned to it. To delete a policy:
|
||||
|
||||
1. Open the policy editor and remove all assigned channels using the **Remove** link next to each channel.
|
||||
2. Once all channels are removed, select **Delete policy** at the bottom of the editor.
|
||||
3. Confirm the deletion.
|
||||
|
||||
### Auto-add members
|
||||
|
||||
Each channel assigned to a policy has an independent **Auto-add members** toggle:
|
||||
|
||||
- **Enabled**: Users matching the policy rules are automatically added to the channel. If a user loses the required attributes and later regains them, they are automatically re-added.
|
||||
- **Disabled** (default): The policy enforces rules as a gate, removing users who no longer qualify, but does not automatically add new qualifying users.
|
||||
|
||||
Regardless of this setting, users who no longer satisfy the access rules are always removed during the next synchronization.
|
||||
|
||||
<Note>
|
||||
|
||||
If a system-wide policy has auto-sync enabled for a channel, Team Admins cannot disable it for that channel. If a system-wide policy has auto-sync disabled, Team Admins can choose to enable it.
|
||||
|
||||
</Note>
|
||||
|
||||
## Policy inheritance and combination
|
||||
|
||||
When both a system-wide policy and a team-level policy apply to the same channel, both must be satisfied. Team-level policies are **additive** and cannot relax or override restrictions set by System Admins.
|
||||
|
||||
- System-wide policies are managed in the System Console.
|
||||
- Team-level policies are managed in Team Settings.
|
||||
- Users must meet the rules of all applicable policies to access the channel.
|
||||
|
||||
### Cross-team policies
|
||||
|
||||
A policy that has private channels from more than one team is considered a cross-team policy. Cross-team policies are not visible in any team's **Channel Membership** tab — they are managed exclusively through the System Console.
|
||||
|
||||
If a System Admin adds a channel from another team to a policy that was previously scoped to one team, that policy will no longer appear in any team's **Channel Membership** tab.
|
||||
|
||||
## Synchronization
|
||||
|
||||
When you save a policy or modify channel assignments, Mattermost creates a membership synchronization job. Changes are applied as soon as the job completes. Synchronization also runs automatically on a schedule to handle attribute changes from external systems such as LDAP or SAML. The interval is set by `AccessControlSettings.SyncJobIntervalSeconds` and defaults to 3600 seconds (60 minutes). User attributes used for access control evaluation are refreshed on a separate schedule controlled by `AccessControlSettings.AttributeRefreshIntervalSeconds`, which defaults to 30 seconds.
|
||||
|
||||
## Troubleshooting and FAQs
|
||||
|
||||
### Why can't I see the Channel Membership tab in Team Settings?
|
||||
|
||||
The **Channel Membership** tab is only visible when:
|
||||
|
||||
- You have Team Admin permissions.
|
||||
- ABAC is enabled system-wide by a System Admin in **System Console \> System Attributes \> Attribute-Based Access**.
|
||||
|
||||
### Why can't I see a policy that I know exists?
|
||||
|
||||
There are two reasons a policy may not appear in your **Channel Membership** tab:
|
||||
|
||||
- **Cross-team policy**: The policy includes private channels from more than one team. Cross-team policies are not visible in Team Settings for anyone and must be managed through the System Console.
|
||||
- **Self-inclusion filter**: Your own user attributes do not satisfy the policy's access rules. For example, if a policy requires `Department=Engineering` and your profile has `Department=Finance`, you will not see that policy. A System Admin or another Team Admin whose attributes do satisfy the rules would need to manage it instead.
|
||||
|
||||
### What happens when I save rules that would exclude me?
|
||||
|
||||
Mattermost validates your access rules against your own user attributes before saving. If the rules would remove you from any assigned channel, the save is blocked and an error is shown. Adjust the rules to include your own attributes, or reset them using the **Undo** option in the save panel.
|
||||
|
||||
### Can I assign a channel to more than one team-level policy?
|
||||
|
||||
Yes. A private channel can be assigned to multiple membership policies. Each policy's rules are applied independently, and users must satisfy all of them to access the channel.
|
||||
|
||||
### Can Team Admins override system-wide policies?
|
||||
|
||||
No. Team-level policies are always additive. Users must satisfy both the system-wide policy and the team-level policy to access a channel. Team Admins cannot weaken or bypass restrictions set by System Admins.
|
||||
|
||||
### How are membership changes communicated to users?
|
||||
|
||||
Users receive standard Mattermost notifications when they are removed from or added to channels due to policy changes, consistent with other membership change notifications.
|
||||
@@ -0,0 +1,448 @@
|
||||
---
|
||||
title: "Team membership access policies"
|
||||
sidebar_label: "Team membership policies"
|
||||
---
|
||||
<PlanAvailability slug="entry-adv" />
|
||||
|
||||
From Mattermost v11.10, system admins and team admins can apply attribute-based access control (ABAC) directly to teams — controlling who can join a team based on user profile attributes. This extends the existing ABAC channel membership system to the team boundary, closing the "hallway access" gap where users who fail channel policies could still see the team, its member list, and its channel structure.
|
||||
|
||||
Team membership ABAC uses the same policies and attribute rules as channel ABAC, but behaves differently depending on whether the team is public or private:
|
||||
|
||||
- **Public teams (advisory mode)**: The policy never blocks access. Anyone can still join freely. Qualifying users who are not yet members see a **Recommended** chip in Browse Teams. Sync can auto-add qualifying users when enabled but never removes anyone.
|
||||
- **Private teams (strict mode)**: The policy gates directory visibility, join evaluation, and membership at sync. Non-qualifying users cannot find or join the team. Non-qualifying members are removed at the next sync.
|
||||
|
||||
<Note>
|
||||
|
||||
**Upgrade notice:** The Access tab in Team Settings has a new UI from Mattermost v11.10 that affects **every team on every deployment** — whether or not ABAC is licensed or enabled. The old "Allow any user to join" checkbox has been replaced by **Public Team / Private Team** selection cards. See [Access tab: Public/Private team cards](#access-tab-publicprivate-team-cards) for details.
|
||||
|
||||
</Note>
|
||||
|
||||
## Access tab: Public/Private team cards
|
||||
|
||||
<Important>
|
||||
|
||||
This change affects **all Mattermost teams on all deployments**, regardless of whether ABAC is enabled or whether your organization has an Enterprise Advanced license. Any team admin who opens **Team Settings \> Access** after upgrading will see the new UI. The exception is teams managed by LDAP/AD group sync, which show a static message in place of the cards — see [Switching modes](#switching-modes).
|
||||
|
||||
</Important>
|
||||
|
||||
**What changed:** The "Allow any user to join" checkbox has been permanently replaced by two selection cards:
|
||||
|
||||
- **Public Team** — anyone on the server can find and join.
|
||||
- **Private Team** — only invited members can join.
|
||||
|
||||
**Why the change was made:** The cards make a team's public-vs-private state explicit and unambiguous, which is what team ABAC enforcement depends on to decide between advisory and strict mode.
|
||||
|
||||
**Behavior without ABAC:** Functionally identical to the old checkbox. Public Team = "Allow any user to join" was ON. Private Team = it was OFF. No other behavior changes for teams that have no membership policy.
|
||||
|
||||
**Behavior with ABAC:** The cards drive the enforcement mode — public teams get advisory ABAC, private teams get strict ABAC. Mode changes on policy-governed teams may trigger a confirmation modal (see below).
|
||||
|
||||
**Default on new teams:** New teams are Private by default, so any policy assigned before explicitly choosing a mode activates strict enforcement. Teams are always protected by default; advisory mode requires explicitly selecting **Public Team**.
|
||||
|
||||
### Switching modes
|
||||
|
||||
**Private → Public:** Relaxes enforcement. Saves directly with no confirmation modal. If a policy is applied, the team immediately transitions to advisory mode: no existing members are removed.
|
||||
|
||||
**Public → Private:** If team ABAC is enabled (Enterprise Advanced license and **Enable Attribute-Based Access Control**) and the team has a membership policy assigned, clicking **Private Team** opens a confirmation modal before saving:
|
||||
|
||||
- Title: **"Switch to Private Team?"**
|
||||
- Body shows how many current members do not meet the policy criteria and will be removed at the next sync. If all current members meet the criteria, the modal says no one will be removed. If no count is available, a generic warning is shown instead.
|
||||
- **Cancel** — closes the modal, no changes made.
|
||||
- **Switch to Private** — saves the change and immediately creates a team sync job to enforce strict mode.
|
||||
|
||||
If the admin making the switch does not meet the policy criteria, a **"Cannot switch to Private Team"** error modal appears instead and the switch is blocked, since strict mode would remove them from the team. Update the rules to include yourself, or ask another admin to make the switch.
|
||||
|
||||
If no policy is assigned, switching Public → Private saves directly with no modal.
|
||||
|
||||
Other Access tab fields (Invite Code and Allowed Email Domain) are unaffected by this change. On teams managed by LDAP/AD group sync, the Access tab shows a static "Members of this team are added and removed by linked groups" message instead of the cards.
|
||||
|
||||
## Advisory and strict enforcement
|
||||
|
||||
Whether a policy is enforced strictly or treated as advisory depends only on whether the team is public or private. The table below summarizes how each combination behaves.
|
||||
|
||||
| Team | ABAC policy? | Join gate | Browse Teams | Sync removal | Recommended tag |
|
||||
|----|----|----|----|----|----|
|
||||
| Public | No | Open | Visible to all | N/A | No |
|
||||
| Public | Yes — **Advisory** | Open (no gate) | Visible to all | Skipped | Yes (qualifying non-members) |
|
||||
| Private | No | Invite-only | Members only | N/A | No |
|
||||
| Private | Yes — **Strict** | Denied for non-qualifying users | Hidden from non-qualifying non-members | Non-qualifiers removed | No |
|
||||
|
||||
<Note>
|
||||
|
||||
Auto-add is the only behavior that applies to **both** advisory and strict mode. When enabled, sync adds qualifying non-members regardless of whether the team is public or private.
|
||||
|
||||
</Note>
|
||||
|
||||
## Prerequisites
|
||||
|
||||
Before configuring team membership policies:
|
||||
|
||||
1. [Configure user attributes](/administration-guide/manage/admin/user-attributes) in the System Console.
|
||||
2. Go to **System Console \> System Attributes \> Attribute-Based Access** and enable **Enable Attribute-Based Access Control**.
|
||||
3. For Team Admins configuring rules: the `manage_team_access_rules` permission is required. This permission is included in the Team Admin role by default.
|
||||
|
||||
Team membership ABAC is also gated by the `TeamMembershipAccessControl` feature flag, which is **enabled by default** from Mattermost v11.10. Disabling it turns off team enforcement without affecting channel ABAC. See the Mattermost developer documentation for details on [feature flags in a self-hosted deployment](https://developers.mattermost.com/contribute/more-info/server/feature-flags/#self-hosted-and-local-development).
|
||||
|
||||
**What changes when team membership ABAC is off:**
|
||||
|
||||
| Surface | Team membership ABAC ON | Team membership ABAC OFF |
|
||||
|----|----|----|
|
||||
| Join gate (private teams) | Enforced — non-qualifying users denied | Not evaluated — private teams stay invite-only, as before |
|
||||
| Browse Teams filter | Private+ABAC teams hidden from non-qualifying users | No attribute filtering — standard privacy rules apply |
|
||||
| Team Membership tab (Team Settings) | Visible to Team Admins and System Admins | Hidden — tab does not appear |
|
||||
| System Console per-team ABAC controls | Policy assignment + custom rules panel visible | Hidden |
|
||||
| Recommended tag | Shown to qualifying users on public+ABAC teams | Not shown |
|
||||
| Sync job — removal pass | Removes non-qualifiers from private+ABAC teams | No team sync jobs run |
|
||||
| Invite modal filtering | Filters on private+ABAC teams | All users shown, as before |
|
||||
| Public/Private cards (Access tab) | **Visible** — not gated | **Still visible** — rendered on every team except group-synced ones |
|
||||
| Channel ABAC | Unaffected | Unaffected |
|
||||
|
||||
## System Admin configuration
|
||||
|
||||
### Assign a membership policy to a team
|
||||
|
||||
System Admins assign existing system-wide membership policies to teams via the per-team System Console page.
|
||||
|
||||
1. Go to **System Console \> User Management \> Teams** and open the team you want to configure.
|
||||
2. In the **Team Management** section, enable **Manage membership with attribute based membership policies**. The **Membership policies** and **Team-specific membership rules** sections appear only once this toggle is on. The toggle is unavailable on group-synced teams, and becomes read-only once a policy is linked.
|
||||
3. In the **Membership policies** section, select **Link to a policy** and choose an existing policy from the picker.
|
||||
4. Select **Save**.
|
||||
|
||||
Before saving, an **Apply membership policy** confirmation modal appears. It shows only the outcomes that apply to this team:
|
||||
|
||||
- The number of current members who do not meet the policy criteria and will be removed at the next sync — private teams only, and only when that number is above zero.
|
||||
- The number of qualifying users who will be added at the next sync — only when auto-add is enabled and that number is above zero.
|
||||
- An **empty-team warning** if the team is private and no user matches the policy ("Saving may result in an empty private team").
|
||||
- A confirmation prompt: "Are you sure you want to apply the membership policy?"
|
||||
|
||||
**To remove a policy:** Select the trash icon next to the policy row and confirm in the **"Remove this team from policy"** modal, then **Save**. Existing members are retained and the team returns to its standard access mode at the next sync.
|
||||
|
||||
**Policy list team counts:** The **Membership Policies** list page shows the count of channels and teams each policy is applied to — for example, `2 channels, 1 team`. A zero side is omitted (so `1 team` not `0 channels, 1 team`).
|
||||
|
||||
### Configure team-specific membership rules
|
||||
|
||||
In addition to a system-wide parent policy, System Admins can define team-specific rules directly on the per-team System Console page.
|
||||
|
||||
1. Go to **System Console \> User Management \> Teams** and open the team.
|
||||
|
||||
2. Enable the **Manage membership with attribute based membership policies** switch.
|
||||
|
||||
3. Scroll to the **Team-specific membership rules** panel.
|
||||
|
||||
4. Select **Add attribute** to add a condition. For each condition, choose:
|
||||
|
||||
- **Attribute**: The user profile attribute to evaluate.
|
||||
- **Operator**: How the attribute must match. Options: **Is**, **Is not**, **In**, **Starts with**, **Ends with**, **Contains**. For ranked attributes: **Is exactly**, **Is at least**, **Is greater than**, **Is at most**, **Is less than**.
|
||||
- **Value**: The required attribute value.
|
||||
|
||||
All conditions are combined with a logical AND — users must satisfy all of them.
|
||||
|
||||
5. Optionally, check **Auto-add members based on access rules**. This checkbox is enabled once the team has at least one rule **or** a linked parent policy. There is only one auto-add setting per team — it is not configured per linked policy.
|
||||
|
||||
6. Select **Save**. The **Apply membership policy** modal shows the impact counts before changes are applied.
|
||||
|
||||
<Important>
|
||||
|
||||
Saving rules always triggers an immediate team sync — **even when auto-add is off**. On private teams, this immediately enforces the rules by removing members who no longer qualify. Confirm the impact in the save modal before proceeding.
|
||||
|
||||
</Important>
|
||||
|
||||
<Note>
|
||||
|
||||
Team-specific rules compose additively with any parent policy assigned to the team. A user must satisfy **both** the parent policy and the team-specific rules. Team-specific rules cannot weaken or bypass the parent.
|
||||
|
||||
</Note>
|
||||
|
||||
### Sync status footer (System Console)
|
||||
|
||||
A sync status footer is rendered at the bottom of the **Team-specific membership rules** panel — scroll down within the panel to find it.
|
||||
|
||||
- **"Never synced."** with a **Sync now** link — no sync has run for this team yet.
|
||||
- **"Last synced N minutes ago."** with a **Sync now** link — after a prior sync. Older syncs are reported in hours or days.
|
||||
- Clicking **Sync now** changes the link to **"Syncing…"** with a spinner while the job is in-flight, then updates to **"Last synced just now."** on completion.
|
||||
|
||||
### Monitor membership sync
|
||||
|
||||
System Admins can review the results of team sync jobs from the System Console.
|
||||
|
||||
1. Go to **System Console \> System Attributes \> Membership Policies** and scroll to the **Membership Sync Jobs** panel.
|
||||
2. Select a job row to open the **Sync Job Details** modal.
|
||||
3. Select the **Teams** tab.
|
||||
|
||||
The Teams tab shows per-team rows with:
|
||||
|
||||
- A `+N added / −N removed` summary for each governed team.
|
||||
- A **mass-removal warning indicator** on any team row where more than 50% of members would be removed. This is a warning only — the job is not blocked.
|
||||
- An expandable per-team user drill-down showing which users were added and removed.
|
||||
|
||||
<Note>
|
||||
|
||||
The Teams tab appears only when viewing a team sync job directly, or a channel sync job that was chained from a team sync. The system console section heading was renamed from "Channel access control sync jobs" to **"Membership Sync Jobs"** to reflect both job types.
|
||||
|
||||
</Note>
|
||||
|
||||
<Tip>
|
||||
|
||||
The **Run Channel Sync** button on the Membership Policies page runs a channel sync only, not a team sync. To trigger a team sync, use the **Sync now** link on the per-team System Console page or in Team Settings \> Team Membership tab.
|
||||
|
||||
</Tip>
|
||||
|
||||
## Team Admin configuration
|
||||
|
||||
### Team Membership tab
|
||||
|
||||
From Mattermost v11.10, Team Settings has four tabs: **Info**, **Access**, **Team Membership**, and **Channel Membership**.
|
||||
|
||||
<Note>
|
||||
|
||||
The fourth tab was previously labeled **Membership Policies**. It is now labeled **Channel Membership** and covers channel-scope policies only. The new **Team Membership** tab (the third tab) is for policies that control who can join the team itself.
|
||||
|
||||
</Note>
|
||||
|
||||
The **Team Membership** tab lets Team Admins view the system policy applied to their team and configure team-specific custom rules — without requiring System Admin involvement for every change.
|
||||
|
||||
The tab is visible only when:
|
||||
|
||||
- **Enable Attribute-Based Access Control** is on.
|
||||
- The `TeamMembershipAccessControl` feature flag is on (enabled by default).
|
||||
- The user has the `manage_team_access_rules` permission (Team Admin or System Admin).
|
||||
|
||||
To open Team Settings: select the team name in the sidebar → **Team Settings** → **Team Membership** tab.
|
||||
|
||||
### System policy indicator
|
||||
|
||||
When a system-level policy is applied to the team by a System Admin, a non-dismissible information banner appears at the top of the Team Membership tab, showing the name of the applied policy. The banner is absent when no parent policy exists.
|
||||
|
||||
### Configure custom rules
|
||||
|
||||
Team Admins can add attribute rules that apply on top of any system policy. These rules use the same Basic Mode editor as channel rules.
|
||||
|
||||
1. Select **Add attribute**.
|
||||
2. Choose the attribute, operator, and value for each condition.
|
||||
3. Add additional rules as needed. All rules are AND-combined.
|
||||
4. Select **Save** to open the save confirmation modal.
|
||||
|
||||
Clearing every rule and saving opens a **"Remove membership rules?"** modal instead. Confirming removes the team's attribute enforcement; current members keep their access.
|
||||
|
||||
Available operators: **Is**, **Is not**, **In**, **Starts with**, **Ends with**, **Contains**. For ranked attributes: **Is exactly**, **Is at least**, **Is greater than**, **Is at most**, **Is less than**.
|
||||
|
||||
<Important>
|
||||
|
||||
Saving rules always triggers an immediate team sync — **even when auto-add is off**. On private teams, this removes members who no longer satisfy the rules. Review the impact counts in the confirmation modal before saving.
|
||||
|
||||
</Important>
|
||||
|
||||
<Note>
|
||||
|
||||
Team Settings rules are Basic Mode only. Advanced CEL expressions are not available here. For complex rules with nested logic or mixed operators, a System Admin must create a system-wide parent policy in the System Console.
|
||||
|
||||
</Note>
|
||||
|
||||
### Auto-add members
|
||||
|
||||
The **Auto-add members based on access rules** checkbox controls whether the sync job automatically adds qualifying non-members to the team.
|
||||
|
||||
- This checkbox is enabled only when at least one rule exists, **or** when a system-level policy is applied.
|
||||
- Checking it and saving triggers an immediate backfill scan — qualifying non-members are added right away.
|
||||
- Subsequent syncs continue to add newly qualifying users.
|
||||
- Turning auto-add **off** does not remove any members — it is additive only. Toggling auto-add off also does **not** trigger a sync job.
|
||||
|
||||
### Test access rule
|
||||
|
||||
Select **Test access rule** to open a preview modal listing users who match the current rules, before saving. This lets you verify your intended scope without applying the rules.
|
||||
|
||||
<Note>
|
||||
|
||||
If the current rules would exclude the editing Team Admin, the **Test access rule** button is disabled with an explanatory tooltip rather than returning results.
|
||||
|
||||
</Note>
|
||||
|
||||
### Save confirmation and safety
|
||||
|
||||
Selecting **Save** opens a confirmation modal before changes are applied. What it shows depends on the team's mode:
|
||||
|
||||
**Private teams (strict):**
|
||||
|
||||
- The number of users who match the current rules and will have access.
|
||||
- The number of current members who do not match the rules and may be affected — shown only when that number is above zero.
|
||||
|
||||
**Public teams (advisory):**
|
||||
|
||||
- A note that the rules are advisory: no one is blocked or removed.
|
||||
- The number of users who match the current rules.
|
||||
|
||||
The counts are evaluated against the team's rules combined with any parent policy.
|
||||
|
||||
**Empty-team warning**: For private teams, if no user matches the rules, the modal displays a highlighted warning. Save is not blocked, but the team will be empty until sync runs.
|
||||
|
||||
**Self-exclusion hard block**: On private teams, if the rules would exclude the editing Team Admin, a separate error modal appears *before* the confirmation modal and prevents saving. Select **Back to editing** to adjust the rules. Public teams are exempt — advisory mode never removes anyone.
|
||||
|
||||
<Note>
|
||||
|
||||
By design, the self-exclusion block evaluates only the admin's own team rules. A system-level parent policy that excludes the admin is a System Admin decision and is not blocked here.
|
||||
|
||||
</Note>
|
||||
|
||||
### Sync status footer (Team Settings)
|
||||
|
||||
Below the auto-add section, a sync status footer appears whenever the team has at least one rule or a parent policy applied:
|
||||
|
||||
- **"Never synced."** + **Sync now** link.
|
||||
- **"Last synced N minutes ago."** + **Sync now** link.
|
||||
- After clicking **Sync now**: **"Syncing…"** with spinner → **"Last synced just now."** on completion.
|
||||
|
||||
The footer is not shown in the empty state (no rules and no parent policy).
|
||||
|
||||
Clicking **Sync now** creates a team sync job scoped to this team only.
|
||||
|
||||
## End-user experience
|
||||
|
||||
### Browse Teams
|
||||
|
||||
The Browse Teams directory respects team ABAC enforcement:
|
||||
|
||||
**Private + ABAC teams (strict mode):**
|
||||
|
||||
- Non-qualifying users who are not already members do not see the team in Browse Teams at all. The team is simply absent — not greyed out or locked.
|
||||
- Qualifying users and existing members see the team normally.
|
||||
|
||||
**Public + ABAC teams (advisory mode):**
|
||||
|
||||
- All users see the team.
|
||||
- Qualifying users who are not yet members see a **Recommended** chip (lightbulb outline icon) next to the team name.
|
||||
- Users who are already members, or who do not qualify for the policy, do not see the chip.
|
||||
|
||||
**Teams without a policy:**
|
||||
|
||||
- Behave exactly as before — no filtering, no chip.
|
||||
|
||||
### Invite People modal
|
||||
|
||||
The Invite People modal adapts to the team's enforcement mode:
|
||||
|
||||
**Private + ABAC team (strict mode):**
|
||||
|
||||
- Only users who qualify for the team's membership policy appear in search results. Non-qualifying users are filtered out before any results are shown.
|
||||
- A notice titled **"Team access is restricted by user attributes"** informs admins: *"Only users who meet the membership requirements can be added to this team."*
|
||||
- The notice lists the policy's attribute value tags (for example, "Department: Engineering").
|
||||
- The invite link warns: *"People who use this link must meet the membership requirements to join."*
|
||||
|
||||
**Public + ABAC team (advisory mode):**
|
||||
|
||||
- All users appear in search results — there is no filtering because advisory mode never blocks access.
|
||||
- A notice titled **"This team has membership requirements"** is still shown, explaining that users who do not meet them can still join but will not be automatically added.
|
||||
- The invite link warns: *"People who use this link can join even if they do not meet the membership requirements, but will not be automatically added."*
|
||||
|
||||
**Team without a policy:**
|
||||
|
||||
- No change from previous behavior — all users appear, no notice shown.
|
||||
|
||||
### Add Members flow (admin)
|
||||
|
||||
When a System Admin or Team Admin uses the **Add Members** admin flow on a private + ABAC team, non-qualifying users are blocked at selection time rather than at submission:
|
||||
|
||||
- Non-qualifying candidates show an inline **"Does not meet membership requirements"** indicator on their row and cannot be selected, including by keyboard.
|
||||
- Only qualifying users can be added to the selection, so the add never fails partway through.
|
||||
|
||||
On a public + ABAC team (advisory mode), all users can be added without restriction.
|
||||
|
||||
### Team Members modal
|
||||
|
||||
When a team has an active membership policy, a notice banner appears at the top of the Team Members modal:
|
||||
|
||||
- On private teams: **"Team access is restricted by user attributes"** — only people who meet the membership requirements can be members.
|
||||
- On public teams: **"This team has membership requirements"** — people who do not meet them can still join, but will not be automatically added.
|
||||
- The banner lists the policy's attribute value tags (for example, "Department: Engineering"). Values the viewer is not permitted to see are stripped server-side, so a non-holder sees only the notice.
|
||||
|
||||
### Membership notifications
|
||||
|
||||
**Removal notification:** When the sync job removes a non-qualifying member from a private team, that user receives a direct message from the System Bot identifying the team they were removed from. The message does not include policy names, attribute values, or CEL expressions.
|
||||
|
||||
**Auto-add notification:** When the sync job auto-adds a qualifying user to a team, that user receives a direct message from the System Bot identifying the team they were added to. Removal and auto-add notifications use different icons so users can distinguish them at a glance.
|
||||
|
||||
## Policy inheritance and composition
|
||||
|
||||
When a parent (system-level) policy and custom team rules both apply:
|
||||
|
||||
- The parent policy is shown in a non-dismissible info banner at the top of the Team Membership tab (read-only).
|
||||
- The user must satisfy **both** the parent policy and the custom team rules to be admitted.
|
||||
- Custom rules can only add restrictions — they cannot weaken or bypass the parent policy.
|
||||
- Deleting a parent policy does not unlink it from the team or delete the team's own rules. Unlink the policy from each team before deleting it.
|
||||
|
||||
## Sync behavior
|
||||
|
||||
A team sync batch runs in the following order:
|
||||
|
||||
1. **Evaluate team membership rules** for all teams that have a policy assigned.
|
||||
2. **Removal pass** (private + ABAC teams only): remove members who no longer qualify. Each removal triggers a channel cascade — the user is removed from all channels within the team. Each removal notifies the user by system-bot DM and is recorded in the audit log. Ordinary, non-ABAC team leaves are not recorded as policy-driven cascades.
|
||||
3. **Auto-add pass** (any mode, when auto-add is enabled): add qualifying non-members to the team. Each addition emits a system-bot DM.
|
||||
4. **Channel membership sync** (chained): evaluate and apply channel policy changes. Deduped against any already-pending or in-progress channel sync job.
|
||||
|
||||
**Mass-removal guardrail**: If a sync pass would remove more than 50% of a team's current members, the job sets a warning flag visible in the Sync Job Details \> Teams tab. The job is not blocked — all removals proceed — but the warning is surfaced for admin review.
|
||||
|
||||
Team sync also runs automatically on a schedule to handle attribute changes propagated from LDAP or SAML. The interval is set by `AccessControlSettings.SyncJobIntervalSeconds` and defaults to 3600 seconds (60 minutes). The minimum accepted value is 60 seconds, and a change requires a server restart to take effect. The same interval governs channel membership sync. User attributes used for access control evaluation are refreshed on a separate schedule controlled by `AccessControlSettings.AttributeRefreshIntervalSeconds`, which defaults to 30 seconds. Set this value to 0 to disable periodic attribute refresh.
|
||||
|
||||
## Mutual exclusivity with group sync
|
||||
|
||||
A team managed by LDAP/AD group synchronization cannot have an ABAC membership policy assigned. Attempting to assign a policy to a group-synced team returns an error.
|
||||
|
||||
You must choose one membership control mechanism per team: group sync or ABAC.
|
||||
|
||||
## Troubleshooting and FAQs
|
||||
|
||||
### Why did the Access tab change and where did the "Allow any user to join" checkbox go?
|
||||
|
||||
From Mattermost v11.10, the "Allow any user to join" checkbox has been permanently replaced by **Public Team** and **Private Team** selection cards on the Access tab. This change applies to all teams on all deployments regardless of ABAC. The cards are functionally equivalent to the old checkbox — Public Team is the same as having the checkbox enabled, Private Team is the same as having it disabled.
|
||||
|
||||
### Why is the Team Membership tab not visible in Team Settings?
|
||||
|
||||
The tab requires all of the following:
|
||||
|
||||
- **Enable Attribute-Based Access Control** is ON in System Console \> System Attributes \> Attribute-Based Access.
|
||||
- The `TeamMembershipAccessControl` feature flag is ON (enabled by default).
|
||||
- The user has the `manage_team_access_rules` permission (Team Admin or System Admin).
|
||||
|
||||
If all three conditions are met but the tab is still missing, confirm the feature flag has not been disabled by checking **System Console \> Experimental \> Feature Flags** or the server configuration.
|
||||
|
||||
### Why are private ABAC teams not appearing in Browse Teams for some users?
|
||||
|
||||
This is intended behavior. When a private team has an ABAC policy and a user does not satisfy that policy, the team is completely hidden from them in Browse Teams and search results. They will not see an error or a locked entry — the team simply does not appear. Qualifying users see the team normally.
|
||||
|
||||
### Can I use advanced CEL expressions in Team Settings?
|
||||
|
||||
No. The Team Membership tab uses Basic Mode only — the same simple attribute editor available in Channel Settings. For rules that require nested logic, mixed `&&` / `||` operators, or grouping, a System Admin must create a system-wide parent policy using the CEL editor in the System Console.
|
||||
|
||||
### Can a group-synced team use ABAC?
|
||||
|
||||
No. Group sync and ABAC are mutually exclusive on a per-team basis. If a team is group-constrained, assigning an ABAC policy returns an error. You must remove the group sync configuration before applying an ABAC policy, or vice versa.
|
||||
|
||||
### How quickly are membership changes applied?
|
||||
|
||||
Saving rules in Team Settings or the System Console triggers an immediate team sync — **including when auto-add is off**, because enforcement (removal on private teams) runs regardless of the auto-add setting. Changes are applied as soon as the sync completes. A scheduled sync also runs on the interval set by `AccessControlSettings.SyncJobIntervalSeconds` (60 minutes by default) to process attribute changes from LDAP or SAML. User attributes used for access control evaluation are refreshed on the interval set by `AccessControlSettings.AttributeRefreshIntervalSeconds` (30 seconds by default).
|
||||
|
||||
### Does System Admin role bypass team ABAC enforcement?
|
||||
|
||||
No. All roles — including System Admin — are subject to team ABAC policy evaluation. A System Admin who does not satisfy a private team's policy cannot join that team as a member through the standard UI, though they can still access the team's configuration in the System Console and make changes.
|
||||
|
||||
### What happens when I switch a team from public to private while a policy is assigned?
|
||||
|
||||
If team ABAC is enabled (Enterprise Advanced license and **Enable Attribute-Based Access Control**) and a policy is assigned to the team, clicking **Private Team** opens a confirmation modal — **"Switch to Private Team?"** — showing how many current members do not meet the policy criteria. Confirming the switch saves the change and triggers an immediate sync to enforce strict mode. Members who don't qualify are removed at that sync.
|
||||
|
||||
If the admin making the switch does not meet the criteria themselves, the switch is blocked with a **"Cannot switch to Private Team"** modal.
|
||||
|
||||
If no policy is assigned, the switch saves directly with no confirmation.
|
||||
|
||||
### What happens when I switch a team from private to public while a policy is assigned?
|
||||
|
||||
Switching from Private to Public always saves directly with no confirmation modal. The team immediately transitions to advisory mode: existing members (including non-qualifying ones) are retained, and no removals occur. The policy continues to drive the Recommended tag and optional auto-add for qualifying users.
|
||||
|
||||
### Can I add a non-qualifying user to a private ABAC team?
|
||||
|
||||
No. The enforcement gate applies to all add paths: the Invite People modal (non-qualifying users are filtered from search results entirely), the Add Members admin flow (non-qualifying users cannot be selected), and direct API calls. The error message is generic and does not expose policy names or attribute details.
|
||||
|
||||
### How does ABAC interact with email-domain restrictions?
|
||||
|
||||
Email-domain restrictions (configured on the Access tab) and ABAC rules (Team Membership tab) apply independently, and a user must satisfy both to join the team. The domain check runs first, so a user rejected on domain grounds never reaches policy evaluation. The two settings are not cross-validated at configuration time, so review them together when debugging unexpected access denials.
|
||||
|
||||
### Why does saving rules trigger a sync even when auto-add is off?
|
||||
|
||||
Auto-add controls only the **add pass** (whether sync adds qualifying non-members). The **enforcement pass** (removing non-qualifying members from private teams) runs whenever rules exist, regardless of auto-add. This ensures that newly saved or changed rules take effect immediately rather than waiting up to 60 minutes for the next scheduled sync.
|
||||
@@ -0,0 +1,58 @@
|
||||
---
|
||||
title: "Attribute-Based Access Control"
|
||||
---
|
||||
<PlanAvailability slug="entry-adv" />
|
||||
|
||||
From Mattermost v10.9, system admins in large or complex organizations who require Zero Trust Security when handling with sensitive information can prevent unauthorized access through attribute-based access controls.
|
||||
|
||||
Enforcing strict access controls based on user attributes eliminates manual role adjustment processes that can lead to security risks, inefficiencies, or inappropriate access, while maintaining security and compliance by ensuring that only authorized users can access specific private Mattermost channels and teams. On public channels and teams, policies are advisory rather than a gate — see the advisory and strict behaviour described below.
|
||||
|
||||
Attribute-based access control (ABAC) can be used with the following policy types:
|
||||
|
||||
- **System-wide access policies** (managed by System Admins): Centralized policies created in the System Console that can be applied across multiple channels and teams. See [System-wide attribute-based access policies](/administration-guide/manage/admin/abac-system-wide-policies).
|
||||
- **Permission policies** (managed by System Admins): Attribute-based restrictions on user actions such as file upload and file download. See [Permission policies](/administration-guide/manage/admin/abac-system-wide-policies#permission-policies).
|
||||
- **Team membership policies** (managed by System Admins and Team Admins): Attribute-based rules that control who can join a team. On private teams, rules gate directory visibility, join evaluation, and removal at sync (strict mode). On public teams, rules drive a "Recommended" tag and optional auto-add without restricting access (advisory mode). See [Team membership access policies](/administration-guide/manage/admin/abac-team-membership).
|
||||
- **Team-scoped channel membership policies** (managed by Team Admins): Channel membership policies that Team Admins can create, edit, and delete directly from the Channel Membership tab in Team Settings for channels in their team. See [Team-level channel membership policies](/administration-guide/manage/admin/abac-team-channel-policies).
|
||||
- **Channel-specific access rules** (managed by Channel Admins): Self-service access rules that Channel Admins can configure directly in Channel Settings for individual channels. See [Channel-specific access rules](/administration-guide/manage/admin/abac-channel-access-rules).
|
||||
|
||||
From Mattermost v11.8, ABAC policies can be applied to **both private and public channels**, with deliberately different semantics for each:
|
||||
|
||||
- **Private channels** are hard-gated by the policy. Non-matching members are removed during synchronization and only matching users can be added or invited.
|
||||
- **Public channels** are advisory. Anyone can still join freely, no member is ever removed by ABAC, and the policy is used either to **auto-add** matching users (when enabled) or to **recommend** the channel under **Browse Channels \> Recommended channels** (when auto-add is disabled).
|
||||
|
||||
Default channels (Town Square, Off-Topic), shared channels, and group-synced channels remain ineligible.
|
||||
|
||||
From Mattermost v11.10, ABAC policies can also be applied to **teams**, with the same advisory/strict model keyed on whether the team is public or private. See [Team membership access policies](/administration-guide/manage/admin/abac-team-membership) for details.
|
||||
|
||||
## Before you begin
|
||||
|
||||
Attribute-based access controls require defined user attributes that are either synchronized from an external system (such as LDAP or SAML) or manually configured and enabled on your Mattermost server. You'll need to [configure user attributes](/administration-guide/manage/admin/user-attributes) in the System Console first before creating access policies.
|
||||
|
||||
Each attribute becomes a user profile option users can populate, unless you disable the **Editable by Users** option, available from Mattermost v11. Admin-managed attributes can be used in addition to the LDAP/SAML synchronized attributes for attribute-based access control rules.
|
||||
|
||||
Once user attributes are defined, go to **System Console \> System Attributes \> Attribute-Based Access** to enable attribute-based access controls for your Mattermost instance. This functionality requires a Mattermost Enterprise Advanced license.
|
||||
|
||||
From Mattermost v10.11, user-managed attributes are excluded from attribute-based access control (ABAC) rules by default for security reasons. This prevents access control policies from being circumvented by users editing their own profile attributes. To include user-managed attributes in ABAC rules, a system admin must explicitly enable the `EnableUserManagedAttributes` configuration setting. See the [user attribute](/administration-guide/manage/admin/user-attributes#before-you-begin) documentation for details on enabling this feature. This configuration setting is available only in Enterprise Edition Advanced and is disabled by default.
|
||||
|
||||
## Configure access policies
|
||||
|
||||
Once enabled, you have multiple ways to configure access policies in Mattermost:
|
||||
|
||||
From Mattermost v11.8.0, admins can configure membership policies for both public and private channels, permission policies for file upload and file download, and simulate policy outcomes before saving.
|
||||
|
||||
**System Admins can:**
|
||||
|
||||
- Create [system-wide access policies](/administration-guide/manage/admin/abac-system-wide-policies) that can be assigned across multiple channels and teams in the System Console. Membership policies can be applied to both public and private channels, with [advisory behavior on public channels](/administration-guide/manage/admin/abac-channel-access-rules#public-and-private-channel-behavior).
|
||||
- Assign [individual channel policies](/administration-guide/manage/admin/abac-system-wide-policies#define-access-controls-per-channel) to specific channels in the System Console.
|
||||
- [Assign membership policies to teams](/administration-guide/manage/admin/abac-team-membership#assign-a-membership-policy-to-a-team) via the per-team System Console page, with advisory enforcement on public teams and strict enforcement on private teams.
|
||||
- Define [permission policies](/administration-guide/manage/admin/abac-system-wide-policies#permission-policies) that restrict actions such as file upload and file download based on user attributes.
|
||||
- [Simulate policy outcomes](/administration-guide/manage/admin/abac-system-wide-policies#simulate-access) to preview whether selected users can perform actions such as joining a channel or uploading and downloading files before saving policy changes.
|
||||
|
||||
**Team Admins can:**
|
||||
|
||||
- View the system policy applied to their team and [configure custom team membership rules](/administration-guide/manage/admin/abac-team-membership#configure-custom-rules) directly from the **Team Membership** tab in Team Settings, when granted the `manage_team_access_rules` permission.
|
||||
- Create and manage [team-level channel membership policies](/administration-guide/manage/admin/abac-team-channel-policies) from the **Channel Membership** tab in Team Settings, scoping attribute-based rules to one or more channels within their team.
|
||||
|
||||
**Channel Admins can:**
|
||||
|
||||
- Configure [channel-specific access rules](/administration-guide/manage/admin/abac-channel-access-rules) directly in Channel Settings without requiring a system admin.
|
||||
225
docs/main/administration-guide/manage/admin/autotranslation.mdx
Normal file
225
docs/main/administration-guide/manage/admin/autotranslation.mdx
Normal file
@@ -0,0 +1,225 @@
|
||||
---
|
||||
title: "Set up auto-translation (Beta)"
|
||||
---
|
||||
<PlanAvailability slug="ent-adv" />
|
||||
|
||||
From Mattermost v11.5, auto-translation automatically translates channel messages into each user's preferred display language. This enables multilingual teams to collaborate without language barriers.
|
||||
|
||||
Auto-translation uses an asynchronous queue-based architecture. When a message is posted in a channel with auto-translation enabled, the message is queued for translation into every configured target language. Translated messages replace the original display for users whose display language matches a target language, and they can view the original text at any time by selecting the translation icon on the message. A user's translation target language is determined by their Mattermost display language (set via **Settings \> Display \> Language**); decoupling the translation target from the display language is not currently supported.
|
||||
|
||||
Two translation provider options are available:
|
||||
|
||||
- **LibreTranslate**: A self-hosted, open-source machine translation engine.
|
||||
- **Agents**: Uses the [Mattermost Agents plugin](/administration-guide/configure/agents-admin-guide) with a configured LLM backend.
|
||||
|
||||
## Before you begin
|
||||
|
||||
- A Mattermost **Enterprise Advanced** license is required.
|
||||
- Choose a translation provider and ensure its infrastructure is available:
|
||||
- **LibreTranslate**: A running LibreTranslate server reachable from the Mattermost server.
|
||||
- **Agents**: The [Mattermost Agents plugin](/administration-guide/configure/agents-admin-guide) installed and configured with at least one LLM service.
|
||||
|
||||
## Set up Auto-translation
|
||||
|
||||
### Configure a translation provider
|
||||
|
||||
Choose one of the following translation providers and follow the setup instructions for your choice.
|
||||
|
||||
#### Set up LibreTranslate
|
||||
|
||||
[LibreTranslate](https://libretranslate.com/) is a self-hosted, open-source machine translation engine. See the [LibreTranslate installation guide](https://docs.libretranslate.com/guides/installation/) for deployment instructions.
|
||||
|
||||
Once your LibreTranslate server is running:
|
||||
|
||||
1. Go to **System Console \> Site Configuration \> Localization**.
|
||||
2. Set **Translation provider** to `libretranslate`.
|
||||
3. Enter the [LibreTranslate URL](/administration-guide/configure/site-configuration-settings#libretranslate-url) (for example, `http://libretranslate.internal:5000`).
|
||||
4. If your LibreTranslate instance requires authentication, enter the [LibreTranslate API key](/administration-guide/configure/site-configuration-settings#libretranslate-api-key).
|
||||
5. Select **Save**.
|
||||
|
||||
<Important>
|
||||
|
||||
The Mattermost server must be able to reach the LibreTranslate URL over the network. Ensure firewall rules and DNS resolution allow connectivity between the Mattermost server and the LibreTranslate instance.
|
||||
|
||||
</Important>
|
||||
|
||||
#### Set up the Agents provider
|
||||
|
||||
The Agents provider uses the Mattermost Agents plugin to translate messages via a configured LLM service.
|
||||
|
||||
Prerequisites:
|
||||
|
||||
- The [Mattermost Agents plugin](/administration-guide/configure/agents-admin-guide) is installed and enabled.
|
||||
- At least one LLM service is configured in the Agents plugin.
|
||||
|
||||
To configure:
|
||||
|
||||
1. Go to **System Console \> Site Configuration \> Localization**.
|
||||
2. Set **Translation provider** to `agents`.
|
||||
3. Enter the [Agents LLM service ID](/administration-guide/configure/site-configuration-settings#agents-llm-service-id) matching the LLM service configured in the Agents plugin.
|
||||
4. Select **Save**.
|
||||
|
||||
<Tip>
|
||||
|
||||
**Choosing between LibreTranslate and Agents**: LibreTranslate is a lightweight, self-hosted translation engine. The Agents provider uses an LLM backend and generally produces more accurate translations, especially for languages such as Japanese, Korean, and Chinese where contextual understanding improves quality. Consider your translation quality needs and existing infrastructure when choosing. LibreTranslate does not support direct translation between all language pairs; for unsupported combinations it performs a pivot translation through an intermediate language (typically English), which can reduce accuracy for those pairs.
|
||||
|
||||
**Choosing an LLM for the Agents provider**: Smaller, faster models are recommended for auto-translation. Translation is a well-defined task that doesn't benefit from the extended reasoning capabilities of larger models — larger models may actually overthink the task, adding unnecessary latency without improving quality. Choose a small, low-latency model that is currently supported by your configured LLM provider and validated in your environment.
|
||||
|
||||
</Tip>
|
||||
|
||||
### Enable auto-translation
|
||||
|
||||
1. Go to **System Console \> Site Configuration \> Localization**.
|
||||
2. Set [Enable autotranslation](/administration-guide/configure/site-configuration-settings#enable-auto-translation) to **True**.
|
||||
3. Select a [Translation provider](/administration-guide/configure/site-configuration-settings#translation-provider) (`libretranslate` or `agents`).
|
||||
4. Configure [Languages allowed](/administration-guide/configure/site-configuration-settings#languages-allowed) — every message in auto-translation-enabled channels is translated into each language in this list.
|
||||
5. Select **Save**.
|
||||
|
||||
<Note>
|
||||
|
||||
The languages available in the **Languages allowed** list are controlled by the **Available languages** setting (`AvailableLocales`) under **Site Configuration \> Localization**. If that field is blank, all supported languages are available; otherwise only listed languages appear as selectable auto-translation targets. Note that some locales (such as `zh-Hans`) are in beta — portions of the Mattermost UI may still display in English, which is a UI localization limitation and does not affect message translation.
|
||||
|
||||
</Note>
|
||||
|
||||
Use the [Restrict autotranslation in direct and group messages](/administration-guide/configure/site-configuration-settings#restrict-autotranslation-in-direct-and-group-messages) setting to control whether auto-translation can be enabled in direct and group messages.
|
||||
|
||||
See the [auto-translation configuration reference](../../configure/site-configuration-settings#auto-translation) for all available settings.
|
||||
|
||||
### Enable auto-translation in a channel
|
||||
|
||||
Auto-translation is managed on a per-channel basis and is disabled by default for all channels. System admins and channel admins can enable or disable auto-translation for individual channels.
|
||||
|
||||
- When auto-translation is enabled or disabled in a channel, a system post notifies channel members of the change.
|
||||
|
||||
<Note>
|
||||
|
||||
Enabling auto-translation in a channel only translates new messages going forward. Existing message history is not retroactively translated.
|
||||
|
||||
</Note>
|
||||
|
||||
## Tune worker performance
|
||||
|
||||
For most deployments the default worker settings are sufficient. If your deployment has a high message volume, many configured target languages, or you observe growing translation queue depth, you may need to increase the worker count. This section explains how to calculate and monitor the right values.
|
||||
|
||||
### How the translation queue works
|
||||
|
||||
When a message is posted in a channel with auto-translation enabled, it's added to a per-node translation queue. A worker picks up the post and translates it sequentially into each configured target language. Each completed language translation triggers a websocket broadcast to the channel so users see translations arrive in real time.
|
||||
|
||||
In a high availability deployment, each node runs its own pool of workers and processes its own queue independently.
|
||||
|
||||
### Calculate your worker count
|
||||
|
||||
Use the following formula to estimate how many workers each node needs:
|
||||
|
||||
``` text
|
||||
required_workers = ceil(
|
||||
(posts_per_sec × pct_autotranslated × num_languages × avg_provider_latency_ms / 1000)
|
||||
/ num_app_nodes
|
||||
× 1.2
|
||||
)
|
||||
```
|
||||
|
||||
Where:
|
||||
|
||||
- **posts_per_sec** — average message rate across the server.
|
||||
- **pct_autotranslated** — fraction of posts in auto-translation-enabled channels (0.0–1.0).
|
||||
- **num_languages** — number of configured target languages.
|
||||
- **avg_provider_latency_ms** — mean response time from the translation provider in milliseconds.
|
||||
- **num_app_nodes** — number of Mattermost application nodes.
|
||||
- **1.2** — headroom factor (20%) to absorb traffic bursts.
|
||||
|
||||
The following table shows results from load tests with 6,500 concurrent users, 2 app nodes, ~5 posts/sec, and ~2 s mean provider latency. The provider latency distribution used in testing was realistic, with buckets ranging from 500 ms to 10 s weighted toward the 500 ms–1.5 s range, producing a ~2 s mean.
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
<col style={{width: '30%'}} />
|
||||
<col style={{width: '30%'}} />
|
||||
<col style={{width: '40%'}} />
|
||||
</colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Target languages</th>
|
||||
<th>% autotranslated</th>
|
||||
<th>Workers per node</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>7</td>
|
||||
<td>100%</td>
|
||||
<td>38</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>6</td>
|
||||
<td>100%</td>
|
||||
<td>32</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>3</td>
|
||||
<td>75%</td>
|
||||
<td>8</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<Note>
|
||||
|
||||
In the 6-language test the formula yields 33, but workers were capped at 32 due to the configured maximum. Adjust the [Translation workers](/administration-guide/configure/site-configuration-settings#translation-workers) setting to match your calculated value.
|
||||
|
||||
</Note>
|
||||
|
||||
### Scaling considerations
|
||||
|
||||
- **Target languages are the biggest multiplier.** Each additional language increases both worker time per post and the number of websocket broadcasts per post. Reducing the number of target languages is the most effective way to reduce load.
|
||||
- **Websocket traffic scales with languages.** Each target language produces one channel-wide websocket broadcast per translated post. Under high load, the main symptom of saturation is websocket disconnects caused by per-connection send queues filling up.
|
||||
- **Provider latency shapes traffic patterns.** Lower latency means translations complete in quicker bursts, concentrating websocket traffic. Higher latency spreads events over time. Monitor provider response times and factor them into your capacity planning.
|
||||
|
||||
### Monitor with Prometheus
|
||||
|
||||
Mattermost exposes the following Prometheus metrics for auto-translation:
|
||||
|
||||
- `mattermost_autotranslation_queue_depth_total` *(Gauge)* — current tasks waiting in the queue. A steadily rising value means workers can't keep up with incoming posts.
|
||||
|
||||
- `mattermost_autotranslation_provider_call_duration_seconds` *(Histogram; labels: provider, result)* — translation provider latency. This is the `avg_provider_latency_ms` value used in the formula above. Calculate the average with the following PromQL query:
|
||||
|
||||
``` promql
|
||||
rate(mattermost_autotranslation_provider_call_duration_seconds_sum{result="success"}[10m])
|
||||
/
|
||||
rate(mattermost_autotranslation_provider_call_duration_seconds_count{result="success"}[10m])
|
||||
```
|
||||
|
||||
- `mattermost_autotranslation_worker_task_duration_seconds` *(Histogram)* — total time for a worker to process one post across all target languages.
|
||||
|
||||
### Configuration reference
|
||||
|
||||
- [Translation workers](/administration-guide/configure/site-configuration-settings#translation-workers): The number of concurrent workers per node. Default is **6**. Increase this value for high-traffic deployments or decrease it to reduce resource consumption.
|
||||
- [Translation timeout](/administration-guide/configure/site-configuration-settings#translation-timeout): The maximum time in milliseconds for a single translation request. Default is **5000** ms (5 seconds). Increase this value if your translation provider is experiencing timeouts due to network latency or high load.
|
||||
|
||||
You can also update the worker count from the command line using mmctl:
|
||||
|
||||
``` shell
|
||||
mmctl config set AutoTranslationSettings.Workers <number>
|
||||
```
|
||||
|
||||
## Frequently asked questions
|
||||
|
||||
### Why aren't messages being translated?
|
||||
|
||||
- Verify auto-translation is enabled globally in **System Console \> Site Configuration \> Localization**.
|
||||
- Verify auto-translation is enabled for the specific channel.
|
||||
- Confirm a translation provider is selected and properly configured.
|
||||
- Check that the Mattermost server can reach the translation provider (LibreTranslate URL or Agents plugin).
|
||||
- Review Mattermost server logs for translation errors.
|
||||
|
||||
### What happens when the translation provider is unavailable?
|
||||
|
||||
Messages are still posted normally. Translations that fail due to provider downtime are skipped, and users see the original untranslated message. When the provider recovers, new messages are translated as expected.
|
||||
|
||||
### What languages are supported?
|
||||
|
||||
Supported languages depend on the translation provider:
|
||||
|
||||
- **LibreTranslate**: Supports the languages available in your LibreTranslate deployment. See the [LibreTranslate language list](https://libretranslate.com/languages) for details.
|
||||
- **Agents**: Language support depends on the capabilities of the configured LLM. Most modern LLMs support a wide range of languages.
|
||||
|
||||
Configure the [Languages allowed](/administration-guide/configure/site-configuration-settings#languages-allowed) setting to specify which languages all messages are translated into.
|
||||
218
docs/main/administration-guide/manage/admin/content-flagging.mdx
Normal file
218
docs/main/administration-guide/manage/admin/content-flagging.mdx
Normal file
@@ -0,0 +1,218 @@
|
||||
---
|
||||
title: "Data Spillage Handling"
|
||||
---
|
||||
<PlanAvailability slug="entry-adv" />
|
||||
|
||||
Data Spillage Handling helps prevent accidental data spillage and helps system administrators respond quickly to potential leaks without disrupting collaboration. Enabling this feature empowers Mattermost users to report messages that may contain sensitive, regulated, or inappropriate information, and enables designated content reviewers to assess and take appropriate action by removing or dismissing quarantined messages.
|
||||
|
||||
By making every team member a first line of defense against sensitive-data exposure, Data Spillage Handling strengthens mission-critical, secure deployments and supports compliance with organizational and regulatory data-handling standards.
|
||||
|
||||
## Before you begin
|
||||
|
||||
You must be a System Admin in Mattermost. You need to identify who will be content reviewers for quarantined messages, and you need to decide whether quarantined messages should be hidden from users in Mattermost while under review.
|
||||
|
||||
## Enable
|
||||
|
||||
Data Spillage Handling isn't enabled by default. To enable Data Spillage Handling:
|
||||
|
||||
1. Go to **System Console \> Site Configuration \> Data Spillage Handling**.
|
||||
2. Set **Enable Data Spillage Handling** to **True**.
|
||||
|
||||
Alternatively, you can configure Data Spillage Handling via the [config.json file or through environment variables](/administration-guide/configure/site-configuration-settings#content-flagging).
|
||||
|
||||
## Configure
|
||||
|
||||
1. Under **Content Reviewers**, define who should review quarantined content:
|
||||
|
||||
- **Same reviewers for all teams**: Set to **True** to apply one global reviewer list across all teams, or **False** to configure reviewers per team.
|
||||
- **Reviewers**: Start typing to search for users to assign as content reviewers.
|
||||
|
||||
<Important>
|
||||
|
||||
Choose reviewers carefully. Assigning reviewer roles grants access to potentially sensitive information and may expose data from private channels.
|
||||
|
||||
- A global reviewer can view quarantined messages from all teams and channels, including private channels they’re not a member of.
|
||||
- Team-specific reviewers can view quarantined messages from their assigned teams, including private channels within those teams they’re not members of.
|
||||
|
||||
</Important>
|
||||
|
||||
- **Additional reviewers**: Optionally include:
|
||||
- **System Administrators**: System admins receive quarantined messages for all teams they are part of.
|
||||
- **Team Administrators**: Team admins receive quarantined messages for their respective teams.
|
||||
|
||||
2. Under **Notification Settings**, specify who receives updates at each stage of the quarantine workflow when content is quarantined or reviewed:
|
||||
|
||||
- **Notify when content is quarantined**: Reviewer(s), Author.
|
||||
- **Notify when a reviewer is assigned**: Reviewer(s).
|
||||
- **Notify when content is removed**: Reviewer(s), Author, Reporter.
|
||||
- **Notify on dismissal**: Reviewer(s), Author, Reporter.
|
||||
|
||||
All notifications are sent via the **Data Spillage Bot** as direct messages.
|
||||
|
||||
3. Under **Additional Settings**, configure how the quarantine workflow behaves:
|
||||
|
||||
- **Reasons for quarantine**: Define the preset categories that appear in the quarantine dialog for users (for example: **Classification mismatch**, **Need-to-know violation**, **Personally identifiable information (PII) exposure**, **Operational security (OPSEC) concern**, **Controlled Unclassified Information (CUI) violation**).
|
||||
- **Require reporters to add comment**: Set to **True** to require users to add a short explanation when quarantining a message.
|
||||
- **Require reviewers to add comment**: Set to **True** to require reviewers to add a comment when resolving a quarantine.
|
||||
- **Hide message from channel while it is being reviewed**: Set to **True** to automatically hide quarantined messages from the channel until reviews are complete. If a root post is quarantined, the entire thread is hidden.
|
||||
|
||||
<Tip>
|
||||
|
||||
We recommend enabling **Hide message from channel while it is being reviewed** and require comments from both reporters and reviewers to maintain transparency, accountability, and an auditable record of actions.
|
||||
|
||||
</Tip>
|
||||
|
||||
## Monitor quarantined messages
|
||||
|
||||
When [a user quarantines a message](/end-user-guide/collaborate/flag-messages), the **Data Spillage Bot** sends a direct message to all content reviewers.
|
||||
|
||||
Direct messages from the **Data Spillage Bot** is a centralized moderation queue, where reviewers can view, assign, and act on quarantined messages without leaving Mattermost. Reviewers can use it to monitor potential data spills, coordinate response, and maintain an auditable record of review activity.
|
||||
|
||||
Each quarantined message appears as a card-formatted message that includes:
|
||||
|
||||
- **Quarantined by**: The user who reported the message.
|
||||
- **Status**: The current state of the review. All quarantined content starts in **Pending** status.
|
||||
- **Reason**: The reason selected by the reporter (for example, **Classification mismatch**, **Need-to-know violation**).
|
||||
- **Message preview**: A snippet of the quarantined message, including the author, timestamp, and original channel.
|
||||
- **Reviewer**: The user currently assigned to review the message (initially **Unassigned**).
|
||||
- **Channel**: The name of the channel where the message was originally posted.
|
||||
- **Team**: The team context for the quarantined message.
|
||||
- **Comment**: Any reporter-provided context.
|
||||
- **Post ID**: The system identifier for the original message for auditing purposes.
|
||||
|
||||
Reviewers can select **View details** to take action as follows:
|
||||
|
||||
- Assign a **Reviewer** responsible for reviewing the quarantined message.
|
||||
- **Remove message**: Permanently delete the quarantined message from its original channel for all users. The status of the quarantined message changes to **Removed**.
|
||||
- **Keep message**: Dismiss the quarantine and restore the message if it was hidden. The status of the quarantined message changes to **Retained**.
|
||||
- **Add a comment**: Record the reason for the decision when required.
|
||||
- **Generate a report**: Download a report of the quarantined message and review activity for record-keeping or incident response. See [Generate a quarantined message report](#generate-a-quarantined-message-report) for details.
|
||||
|
||||
Once an action is taken, the **Status** field updates automatically. The **Data Spillage Bot** sends follow-up notifications to the reporter, author, and other reviewers based on how Data Spillage Handling is configured.
|
||||
|
||||
### Generate a quarantined message report
|
||||
|
||||
Reviewers can generate a downloadable report that captures the full context of a quarantined message and the associated review activity. Reports are useful for record-keeping, incident response, and preserving evidence before a message is permanently removed.
|
||||
|
||||
A report can be generated from any of the following entry points:
|
||||
|
||||
- **From the quarantined message details**: Select **Download report** from the message details panel. This option is available regardless of the quarantine's status, including **Pending**, **Reviewer Assigned**, **Removed**, or **Retained**.
|
||||
- **From the Remove message flow**: When you select **Remove message**, the confirmation dialog includes a **Download quarantined message report** checkbox, selected by default. With the checkbox selected, Mattermost generates and downloads the report before you can permanently remove the message. This safeguard ensures the record is preserved on your device before the message contents are deleted.
|
||||
- **From the Keep message flow**: When you select **Keep message**, the confirmation dialog includes the same checkbox. With the checkbox selected, Mattermost generates and downloads the report in the background while the keep action completes.
|
||||
|
||||
If you choose to skip the report download from the **Remove message** or **Keep message** flow, Mattermost asks you to confirm that you're proceeding without a report. The skip decision is recorded in the audit log.
|
||||
|
||||
If report generation fails (for example, due to a network interruption or session timeout), the dialog displays an error and offers a retry option. You can also skip the report and proceed with the action, or cancel and download the report later from the message details.
|
||||
|
||||
Each time a reviewer generates a report, the **Data Spillage Bot** notifies all content reviewers so an auditable record exists whenever a copy of the potentially spilled data is obtained. If the report was generated without the message's file attachments, the bot sends an additional notification to the reviewer who requested it, explaining why. See [File attachments and download policies](#file-attachments-and-download-policies) for details.
|
||||
|
||||
<Tip>
|
||||
|
||||
We recommend generating a report before removing a message. Once a message is removed, its content, attachments, and edit history are permanently deleted and can't be recovered.
|
||||
|
||||
</Tip>
|
||||
|
||||
#### Report contents and format
|
||||
|
||||
Each report is a ZIP archive containing YAML metadata files and the original file attachments. YAML is used because it's both human-readable and machine-parseable, which makes the report suitable for manual review and for ingestion by downstream compliance or incident-response tooling.
|
||||
|
||||
The archive has the following structure:
|
||||
|
||||
``` text
|
||||
/
|
||||
├── report_metadata.yaml
|
||||
├── content_review.yaml
|
||||
├── ATTACHMENTS_OMITTED.txt # only when attachments are withheld
|
||||
├── post/
|
||||
│ ├── post.yaml
|
||||
│ └── attachments/
|
||||
│ └── <original attachment files>
|
||||
└── edit_history/
|
||||
└── <edit_post_id>/
|
||||
├── post.yaml
|
||||
└── attachments/
|
||||
└── <original attachment files>
|
||||
```
|
||||
|
||||
- **report_metadata.yaml**: Identifies the report itself, including the user ID and username of the reviewer who generated the report, the generation timestamp, and the report format version (used for forward compatibility if the report format changes in future releases).
|
||||
- **content_review.yaml**: Captures the data spillage event, including the reporter's user ID, username, selected reason, and comment; the report timestamp; whether the message was hidden during review; and, once the quarantine is resolved, the reviewer's user ID, username, comment, and action timestamp. For unresolved quarantines, reviewer fields are omitted.
|
||||
- **post/post.yaml**: Describes the quarantined message, including the post ID, author ID, author name, author email, message content, channel ID, channel display name, team ID, team display name, creation and update timestamps, pinned status, root ID, post properties, post metadata, reply count (for root posts), and the ordered list of edit history post IDs.
|
||||
- **post/attachments/**: The original files attached to the quarantined message, included verbatim. This directory is left out entirely when the reviewer isn't permitted to download attachments from the channel.
|
||||
- **edit_history/\<edit_post_id\>/**: One subdirectory per previous version of the message, each containing a `post.yaml` and an `attachments/` directory in the same format as the base post directory.
|
||||
- **ATTACHMENTS_OMITTED.txt**: Present only when attachments were withheld from the report. See [File attachments and download policies](#file-attachments-and-download-policies).
|
||||
|
||||
To avoid duplication, attachment files are deduplicated across the entire archive by their file ID. Each unique attachment appears exactly once — under the base post if it exists in the current version of the message, or under the earliest edit-history entry that referenced it.
|
||||
|
||||
#### File attachments and download policies
|
||||
|
||||
If your deployment restricts who can download file attachments using [channel-level permission policies](/administration-guide/manage/admin/abac-channel-access-rules#channel-level-permission-policies) or [system-wide permission policies](/administration-guide/manage/admin/abac-system-wide-policies#permission-policies), those policies apply to content reviewers generating a report as well. Being a content reviewer doesn't exempt someone from the channel's file download rules.
|
||||
|
||||
Before building the archive, Mattermost evaluates the requesting reviewer against the quarantined message's channel for the file download action:
|
||||
|
||||
- **When the reviewer satisfies the policy**, the report includes attachments as described above.
|
||||
- **When the reviewer doesn't satisfy the policy**, the report is still generated and downloaded, but the attachment files are withheld. The `post/attachments/` and `edit_history/<edit_post_id>/attachments/` directories are left out, and the attachment metadata is removed from `post.yaml` in each of those sections, so the archive carries no reference to the withheld files. Every other part of the report - message content, review activity, and report metadata - is unaffected.
|
||||
|
||||
Reports aren't blocked when attachments are withheld, so reviewers who can't access the files can still capture the message and its review history for record-keeping.
|
||||
|
||||
When attachments are withheld, Mattermost signals it in three places:
|
||||
|
||||
- **`ATTACHMENTS_OMITTED.txt`**: A plain-text file added at the root of the archive, in place of the attachment directories, reading *"The attachments on this message were omitted from this report because you do not comply with the channel's file download policy."* Its presence makes an incomplete report self-describing for anyone who receives the archive later.
|
||||
- **A notification to the requesting reviewer**: The **Data Spillage Bot** posts a message in that reviewer's content review thread for the quarantined message, explaining that the report didn't include the file attachments. Only the reviewer who generated the report receives it; the other reviewers see the usual report generation notification.
|
||||
- **The audit log**: The `generateFlaggedPostReport` audit entry records an `omitted_attachment_count` parameter holding the number of withheld attachments. The parameter is only present when attachments were actually withheld, so its absence indicates a complete report.
|
||||
|
||||
<Note>
|
||||
|
||||
Permission policies require a Mattermost Enterprise Advanced license and the `PermissionPolicies` feature flag. Where they aren't in use, reviewers who can generate a report always receive its attachments, and none of the behavior in this section applies.
|
||||
|
||||
</Note>
|
||||
|
||||
### Deleted messages
|
||||
|
||||
When a reviewer permanently removes a quarantined message, the message and all associated data are deleted from the database and file system and can't be recovered. The deletion covers:
|
||||
|
||||
- **Post record**: The text of the message and any associated post properties. The content is scrubbed before the post is deleted.
|
||||
- **File attachments**: The files stored in Mattermost's file storage (local, S3, etc.).
|
||||
- **File attachment records**: The file info database rows for the message, including file names, IDs, and links to storage.
|
||||
- **Edit history**: Every prior revision of the message, along with file metadata from each revision.
|
||||
- **Priority metadata**: Any message priority or importance settings.
|
||||
- **Persistent notifications**: Any recurring notifications attached to the message.
|
||||
- **Acknowledgements**: Records of users who acknowledged the message.
|
||||
- **Reminders**: Any reminders created for the message.
|
||||
- **Thread, replies, and reactions**: The thread record, replies, and reaction data, if any, associated with the message.
|
||||
|
||||
#### Post deletion report
|
||||
|
||||
When a reviewer selects **Remove message**, the **Data Spillage Bot** posts a **Post Deletion Report** into the reviewer's content review thread for that quarantined message. The report is delivered to every reviewer who received the original quarantine notification, and is localized to each reviewer's language. Each post includes a short summary rendered inline, and a full report attached as a Markdown file named `deletion_report_<post_id>.md`.
|
||||
|
||||
The report records every cleanup step performed against the message and its associated data. The steps map directly to the data scope listed in [Deleted messages](#deleted-messages):
|
||||
|
||||
- **File attachments**: Files removed from file storage.
|
||||
- **File attachment records**: File info database rows for the message.
|
||||
- **Edit history**: Every prior revision of the message. Each revision is reported as its own sub-step so that reviewers can see exactly which revisions were cleared.
|
||||
- **Priority metadata**: Message priority and importance settings.
|
||||
- **Persistent notifications**: Recurring notifications attached to the message.
|
||||
- **Acknowledgements**: Records of users who acknowledged the message.
|
||||
- **Reminders**: Reminders set on the message.
|
||||
- **Thread, replies, and reactions**: The thread record, replies, and reaction data associated with the message.
|
||||
- **Post record**: The post itself. The content is scrubbed before the post is deleted.
|
||||
|
||||
Each step is assigned one of the following statuses:
|
||||
|
||||
- **Removed** ✅: The data was successfully deleted.
|
||||
- **Not applicable** ➖: There was no data of this type to delete.
|
||||
- **Partial** ⚠️: Some items of this type were deleted, but at least one failed. This status most often appears under **Edit history** when one revision can't be deleted.
|
||||
- **Failed** ❌: The step didn't complete. The report includes an error log so reviewers and System Administrators can inspect what went wrong.
|
||||
|
||||
When every step is **Removed** or **Not applicable**, no further action is required. The report serves as the auditable record of the deletion.
|
||||
|
||||
When any step reports **Partial** or **Failed**, the report displays an *incomplete* warning. Reviewers should escalate to a System Administrator, who can use the attached `deletion_report_<postId>.md` file - including the full per-step error log - to perform manual remediation and confirm that the data is fully removed.
|
||||
|
||||
<Note>
|
||||
|
||||
The post deletion report is the single source of truth for post-removal auditing. It isn't stored elsewhere in the System Console, so the reviewer thread containing the report should be retained in line with your organization's audit retention policy.
|
||||
|
||||
</Note>
|
||||
|
||||
## Best practice recommendations
|
||||
|
||||
Before rolling out Data Spillage Handling organization-wide, we recommend communicating that the feature protects both users and the organization from accidental data spillage. Start with a pilot team to validate reviewer notifications and workflows, integrate the process with existing data-handling or incident-response playbooks, and require reporter and reviewer comments to ensure every decision is transparent and auditable.
|
||||
@@ -0,0 +1,8 @@
|
||||
---
|
||||
title: "Customize branding"
|
||||
---
|
||||
Whether you’re customizing the appearance of your workspace, utilizing branding tools, or managing code signing for custom builds, this section of documentation has you covered and provides everything you need to customize the branding of Mattermost to align with your organization’s identity. Use the navigation below to access detailed instructions for each customization option.
|
||||
|
||||
- [Customize Mattermost](/administration-guide/configure/customize-mattermost) - Learn how to customize the Mattermost server.
|
||||
- [Custom branding tools](/administration-guide/configure/custom-branding-tools) - Learn about custom branding tools for Mattermost.
|
||||
- [Code signing custom builds](/administration-guide/manage/code-signing-custom-builds) - Learn about code signing custom builds of Mattermost.
|
||||
36
docs/main/administration-guide/manage/admin/error-codes.mdx
Normal file
36
docs/main/administration-guide/manage/admin/error-codes.mdx
Normal file
@@ -0,0 +1,36 @@
|
||||
---
|
||||
title: "Mattermost error codes"
|
||||
---
|
||||
<PlanAvailability slug="all-commercial" />
|
||||
|
||||
Mattermost is designed to deploy in private networks which may be disconnected or “air-gapped” from the internet. In these deployments, links to Mattermost’s online documentation may be unavailable.
|
||||
|
||||
Therefore, Mattermost error codes are provided to enable administrators to use internet connected machines to look up error messages and resolutions in online resources, including Mattermost documentation and user forums, as well as providing Mattermost support teams a concise way to identify issues.
|
||||
|
||||
Mattermost error codes are used in logs, administrative tools, as well as on-screen messages to concisely identify issues and connect them with additional resources.
|
||||
|
||||
In advanced deployments, error codes can be overwritten by administrators to reference internal documentation and guides.
|
||||
|
||||
## ERROR_SAFETY_LIMITS_EXCEEDED
|
||||
|
||||
A safety limits exceeded error (`ERROR_SAFETY_LIMITS_EXCEEDED`) displays in the [free version of Mattermost](/product-overview/editions-and-offerings#mattermost-team-edition), and certain functionality may be limited, when usage grossly exceeds the recommended limit for users in a safe deployment, including more than 250 users are registered on the server.
|
||||
|
||||
250 users represents a “high upper limit” for deployments that are approximately 5 times the recommended size, which is far beyond the intended design of the product.
|
||||
|
||||
The free version of Mattermost is intended for approximately 50 users. If your Mattermost materially exceeds this recommended size, system admins should seek to either [purchase a commercial license](https://mattermost.com/pricing/), or apply for a [non-profit subscription](/product-overview/non-profit-subscriptions) license. Alternatively, admins can [deactivate users](/administration-guide/configure/user-management-configuration-settings#deactivate-users) until the user count falls below the high upper limit.
|
||||
|
||||
## ERROR_LICENSED_USERS_LIMIT_EXCEEDED
|
||||
|
||||
A licensed user limit exceeded error (`ERROR_LICENSED_USERS_LIMIT_EXCEEDED`) displays when attempting to create or activate users on a licensed Mattermost server where the user count would exceed the maximum number of users allowed by the license.
|
||||
|
||||
This error occurs when:
|
||||
|
||||
- Creating new users would exceed the license user limit.
|
||||
- Activating deactivated users would exceed the license user limit.
|
||||
|
||||
To resolve this error, system administrators can:
|
||||
|
||||
- [Deactivate users](/administration-guide/configure/user-management-configuration-settings#deactivate-users) to reduce the active user count below the license limit.
|
||||
- Contact [Mattermost Sales](https://mattermost.com/contact-sales/) to request an updated license that increases the number of licensed users.
|
||||
|
||||
[Book a live demo](https://mattermost.com/request-demo/) or [talk to a Mattermost expert](https://mattermost.com/contact-sales/) to explore tailored solutions for your organization's secure collaboration needs. Or try Mattermost yourself with a [1-hour preview](https://mattermost.com/sign-up/) for instant access to a live sandbox environment.
|
||||
145
docs/main/administration-guide/manage/admin/fips-migration.mdx
Normal file
145
docs/main/administration-guide/manage/admin/fips-migration.mdx
Normal file
@@ -0,0 +1,145 @@
|
||||
---
|
||||
title: "Migrate an existing deployment to FIPS-compliant images"
|
||||
sidebar_label: "Migrate to FIPS-compliant images"
|
||||
---
|
||||
<PlanAvailability slug="entry-ent" />
|
||||
|
||||
From Mattermost v11, each release ships in two image variants: a standard Enterprise build (`mattermost/mattermost-enterprise-edition`) and a FIPS-compliant build (`mattermost/mattermost-enterprise-fips-edition`). Migrating an existing deployment to the FIPS image is primarily a matter of replacing the image and restarting Mattermost. No data migration is required, and rollback is symmetric.
|
||||
|
||||
This guide covers migrating an existing Mattermost Server deployment running on Docker or Kubernetes. Linux package and tarball installations have no FIPS-compliant equivalent.
|
||||
|
||||
Mattermost's FIPS offering also covers the Mattermost Operator controller and a self-hosted Push Proxy. Migrating those components to their FIPS variants is out of scope for this guide.
|
||||
|
||||
For background on what the FIPS build is and how it's constructed, see the **FIPS/STIG** tab on [Deploy Mattermost using Containers](/deployment-guide/server/deploy-containers).
|
||||
|
||||
## Before you begin
|
||||
|
||||
1. **Back up your database and configuration.** Always take a full backup before changing the image. See the [backup and disaster recovery](/deployment-guide/backup-disaster-recovery) documentation.
|
||||
|
||||
2. **Confirm your deployment type.** FIPS images are supported on Docker, Docker Compose, and Kubernetes only. If you're running Mattermost from a Linux package or tarball, you can't migrate in place.
|
||||
|
||||
3. **Check your Mattermost version.** FIPS images are available from v11.0 onward and use the same release tags as the standard Enterprise images. Plan to migrate to the matching FIPS tag for your current version.
|
||||
|
||||
4. **Plan for additional plugins.** The FIPS image includes Boards, Playbooks, and Agents prepackaged and running in FIPS mode. Any additional plugins you've installed will continue to run inside the FIPS image, but they run in non-FIPS mode. This is expected behavior, not a configuration error.
|
||||
|
||||
5. **PostgreSQL password length.** Beginning with Mattermost v11.7, the Postgres password used by the Mattermost server must be at least 14 characters when running the FIPS image. If your current password is shorter, complete these steps before swapping the image:
|
||||
|
||||
a. Rotate the password in PostgreSQL. For example, connecting as a Postgres superuser and replacing `mmuser` and `<new password>` to match your deployment:
|
||||
|
||||
```sql
|
||||
ALTER USER mmuser WITH PASSWORD '<new password>';
|
||||
```
|
||||
|
||||
b. Update the password where your deployment stores it: in the official Docker deployment, the `POSTGRES_PASSWORD` value in `.env`; in Operator-managed Kubernetes deployments, the database Secret referenced by your `Mattermost` custom resource (commonly under `spec.database.external.secret`).
|
||||
|
||||
c. Proceed to the image swap procedure for your deployment type below. Recreating the container as part of the migration applies the new credentials — no separate restart is required.
|
||||
|
||||
6. **Plan for downtime.** The migration requires pulling the new image and restarting the Mattermost container or pod.
|
||||
|
||||
## Migrate a Kubernetes deployment
|
||||
|
||||
These steps assume your deployment is managed by the Mattermost Operator using a `Mattermost` custom resource.
|
||||
|
||||
In the steps below, replace `<namespace>` with the namespace your Mattermost installation runs in. If you omit `-n <namespace>`, `kubectl` uses your current context's default namespace.
|
||||
|
||||
1. Find the name of your Mattermost custom resource:
|
||||
|
||||
```sh
|
||||
kubectl -n <namespace> get mattermost
|
||||
```
|
||||
|
||||
2. Edit the `Mattermost` custom resource to point at the FIPS image. You can edit the live resource directly:
|
||||
|
||||
```sh
|
||||
kubectl -n <namespace> edit mattermost <installation-name>
|
||||
```
|
||||
|
||||
Or update your manifest file and re-apply it.
|
||||
|
||||
3. In `spec.image`, change the value from `mattermost/mattermost-enterprise-edition` to `mattermost/mattermost-enterprise-fips-edition`. Keep `spec.version` aligned with your current release tag. For example:
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
image: mattermost/mattermost-enterprise-fips-edition
|
||||
version: 11.6.1
|
||||
```
|
||||
|
||||
4. If you edited a manifest file, apply it:
|
||||
|
||||
```sh
|
||||
kubectl -n <namespace> apply -f <your-mattermost-manifest>.yaml
|
||||
```
|
||||
|
||||
5. Watch the Mattermost pods until the new ones report `Ready` and the old ones terminate. A pod showing `Running` isn't necessarily serving traffic yet — wait until its `READY` column shows all containers ready (for example, `1/1`):
|
||||
|
||||
```sh
|
||||
kubectl -n <namespace> get pods -l app=mattermost -w
|
||||
```
|
||||
|
||||
6. Verify the running pods are using the FIPS image:
|
||||
|
||||
```sh
|
||||
kubectl -n <namespace> get pods -l app=mattermost -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.containers[*].image}{"\n"}{end}'
|
||||
```
|
||||
|
||||
## Migrate a Docker or Docker Compose deployment
|
||||
|
||||
These steps are written for the official [Mattermost Docker deployment](https://github.com/mattermost/docker), which selects the Mattermost image and tag through `.env` variables (`MATTERMOST_IMAGE` and `MATTERMOST_IMAGE_TAG`) referenced from `docker-compose.yml` as `mattermost/${MATTERMOST_IMAGE}:${MATTERMOST_IMAGE_TAG}`. If you're using a custom Docker setup that hardcodes the image in `docker-compose.yml` or uses different variable names, adapt these steps accordingly.
|
||||
|
||||
1. Stop the Mattermost container:
|
||||
|
||||
```sh
|
||||
docker compose stop mattermost
|
||||
```
|
||||
|
||||
2. Edit your `.env` file. Change `MATTERMOST_IMAGE` from `mattermost-enterprise-edition` to `mattermost-enterprise-fips-edition`. Leave `MATTERMOST_IMAGE_TAG` set to your current release tag — FIPS images are published under the same tags as the standard Enterprise images.
|
||||
|
||||
```text
|
||||
MATTERMOST_IMAGE=mattermost-enterprise-fips-edition
|
||||
MATTERMOST_IMAGE_TAG=<tag>
|
||||
```
|
||||
|
||||
3. Pull the FIPS image:
|
||||
|
||||
```sh
|
||||
docker compose pull mattermost
|
||||
```
|
||||
|
||||
4. Recreate the Mattermost container so the new `.env` values are applied:
|
||||
|
||||
```sh
|
||||
docker compose up -d --force-recreate mattermost
|
||||
```
|
||||
|
||||
5. Verify the running container is using the FIPS image:
|
||||
|
||||
```sh
|
||||
docker inspect mattermost --format '{{.Config.Image}}'
|
||||
```
|
||||
|
||||
## Verify the migration
|
||||
|
||||
1. Confirm Mattermost starts cleanly. Tail the logs and watch for startup errors. On Kubernetes, target a specific Mattermost pod:
|
||||
|
||||
```sh
|
||||
kubectl -n <namespace> logs -f <pod-name>
|
||||
```
|
||||
|
||||
On Docker:
|
||||
|
||||
```sh
|
||||
docker compose logs -f mattermost
|
||||
```
|
||||
|
||||
2. Sign in and verify core functionality (sending messages, file uploads, search).
|
||||
|
||||
3. Confirm the prepackaged plugins (Boards, Playbooks, Agents) load successfully. In the System Console, go to **Plugins > Plugin Management** and confirm they're enabled and healthy.
|
||||
|
||||
4. If you have additional plugins installed, confirm they still load. They'll run in non-FIPS mode inside the FIPS image — this is expected.
|
||||
|
||||
## Roll back
|
||||
|
||||
If the migration doesn't go as planned, rolling back is symmetric: revert the image reference and redeploy. No data migration is involved.
|
||||
|
||||
- **Kubernetes:** Edit the `Mattermost` custom resource and change `spec.image` back to `mattermost/mattermost-enterprise-edition`. Re-apply or save, and watch the rollout.
|
||||
- **Docker / Docker Compose:** Restore the original `MATTERMOST_IMAGE` value in `.env` (`mattermost-enterprise-edition`) and run `docker compose pull mattermost` followed by `docker compose up -d --force-recreate mattermost`.
|
||||
@@ -0,0 +1,384 @@
|
||||
---
|
||||
title: "Generate a support packet"
|
||||
---
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
<PlanAvailability slug="all-commercial" />
|
||||
|
||||
The Support Packet is used to help customers diagnose and troubleshoot issues. Use the System Console or the [mmctl system supportpacket](/administration-guide/manage/mmctl-command-line-tool#mmctl-system-supportpacket) command to generate a zip file that includes configuration information, logs, plugin details, and data on external dependencies across all nodes in a high-availability cluster. Confidential data, such as passwords, are automatically stripped.
|
||||
|
||||
## Generate
|
||||
|
||||
<Important>
|
||||
|
||||
- Before generating a Support Packet, go to **System Console \> Environment \> Logging** and ensure **Output logs to file** is set to **true**, and set **File Log Level** to **DEBUG**
|
||||
- From Mattermost v11.4, support packet generation is recorded in the audit log (when [audit logging is enabled and configured](/administration-guide/manage/logging#audit-logging)). The audit event includes the username, timestamp, success/failure status, whether logs were included, plugin packets requested, and the output filename. This audit trail helps track access to potentially sensitive log data for compliance purposes.
|
||||
|
||||
</Important>
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="web-desktop" label="Web/Desktop">
|
||||
|
||||
1. Go to the System Console, and select **Commercial Support** from the System Console menu.
|
||||
|
||||

|
||||
|
||||
2. Select **Download Support Packet**. A zip file is downloaded to the local machine. You'll be notified if any packet files are unavailable during packet generation. See the `warning.txt` file for details.
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="mmctl" label="mmctl">
|
||||
|
||||
Run the [mmctl system supportpacket](/administration-guide/manage/mmctl-command-line-tool#mmctl-system-supportpacket) command to generate and download a Support Packet to share with Mattermost Support.
|
||||
|
||||
``` sh
|
||||
go run ./cmd/mmctl system supportpacket
|
||||
```
|
||||
|
||||
``` text
|
||||
Downloading Support Packet
|
||||
Downloaded Support Packet to mattermost_support_packet_.zip
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
## Sanitize confidential data
|
||||
|
||||
Please sanitize any confidential data you wish to exclude before sharing the packet with Mattermost.
|
||||
|
||||
When present, the following information is automatically sanitized during packet generation: `LdapSettings.BindPassword`, `FileSettings.PublicLinkSalt`, `FileSettings.AmazonS3SecretAccessKey`, `EmailSettings.SMTPPassword`, `GitLabSettings.Secret`, `GoogleSettings.Secret`, `Office365Settings.Secret`, `OpenIdSettings.Secret`, `SqlSettings.DataSource`, `SqlSettings.AtRestEncryptKey`, `ElasticsearchSettings.Password`, `All SqlSettings.DataSourceReplicas`, `All SqlSettings.DataSourceSearchReplicas`, `MessageExportSettings.GlobalRelaySettings.SmtpPassword`, `ServiceSettings.SplitKey`, `FileSettings.ExportAmazonS3SecretAccessKey`, `ServiceSettings.GoogleDeveloperKey`, and `ServiceSettings.GiphySdkKey` (from Mattermost v11.6.0).
|
||||
|
||||
<Important>
|
||||
|
||||
Plugins may not be sanitized during packet generation.
|
||||
|
||||
- From Mattermost v10.1, plugins can mark their configuration as hidden. If a plugin marks its configuration as hidden, the configuration is sanitized during packet generation.
|
||||
- Otherwise, ensure you sanitize any additional confidential details in the `plugin.json` file before sharing it with Mattermost. Replace details with example strings that contain the same special characters if possible, as special characters are common causes of configuration errors.
|
||||
|
||||
</Important>
|
||||
|
||||
## Share the packet with Mattermost
|
||||
|
||||
Add the generated Support Packet to a [standard support request](https://support.mattermost.com/hc/en-us/requests/new), or share with with the Mattermost team you're working with.
|
||||
|
||||
<Important>
|
||||
|
||||
Disable debug logging once you've generated the Support Packet. Debug logging can cause log files to expand substantially, and may adversely impact server performance. We recommend enabling it temporarily, or in development environments, but not production environments.
|
||||
|
||||
</Important>
|
||||
|
||||
## Contents of a Support Packet
|
||||
|
||||
The contents of a Mattermost Support Packet can differ by server version. Select the tab that corresponds to your Mattermost version to see the files included in the Support Packet.
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="v11-0-and-later" label="v11.0 and later">
|
||||
|
||||
### Cluster-wide files
|
||||
|
||||
The following cluster-wide files are located in the root directory of the Support Packet:
|
||||
|
||||
- [metadata.yaml](#metadata)
|
||||
- `plugins.json` (all active and inactive plugins)
|
||||
- `sanitized_config.json` (sanitized copy of the Mattermost configuration)
|
||||
- `stats.yaml` (Mattermost usage statistics)
|
||||
- `jobs.yaml` (last runs of important jobs)
|
||||
- `diagnostics.yaml` (system and plugin diagnostics)
|
||||
- `permissions.yaml` (role and scheme information)
|
||||
- `postgres_schema_dump.sql` (PostgreSQL database schema information including tables, indexes, constraints, and other metadata to assist with database configuration diagnosis)
|
||||
- `warning.txt` (present when issues are encountered during packet generation)
|
||||
- `tsdb_dump.tar.gz` (present when the Metrics plugin is installed and the **Performance metrics** option is selected when generating the Support Packet)
|
||||
|
||||
### Node-specific files
|
||||
|
||||
The following node-specific files are located in node subdirectories:
|
||||
|
||||
- `<node-id>/mattermost.log` (Mattermost logs for each node)
|
||||
- `<node-id>/audit.log` (Mattermost audit logs for each node)
|
||||
- `<node-id>/ldap.log` (AD/LDAP logs for each node)
|
||||
- `<node-id>/notifications.log` (notifications logs for each node)
|
||||
- `<node-id>/cpu.prof` ([Go performance metrics](#go-performance-metrics) for each node)
|
||||
- `<node-id>/heap.prof` ([Go performance metrics](#go-performance-metrics) for each node)
|
||||
- `<node-id>/goroutines` ([Go performance metrics](#go-performance-metrics) for each node)
|
||||
|
||||
### Diagnostics highlights
|
||||
|
||||
The Support Packet `diagnostics.yaml` file includes system and plugin diagnostics to support troubleshooting and configuration validation.
|
||||
|
||||
### Plugin diagnostic data
|
||||
|
||||
The following additional plugin diagnostic data is available when the plugin is enabled and operational:
|
||||
|
||||
- GitHub: `/github/diagnostics.yaml`
|
||||
- GitLab: `/com.github.manland.mattermost-plugin-gitlab/diagnostics.yaml`
|
||||
- Jira: `/jira/diagnostics.yaml`
|
||||
- Calls: `/com.mattermost.calls/diagnostics.yaml`
|
||||
- Boards: `/focalboard/diagnostics.yaml`
|
||||
- Playbooks: `/playbooks/diagnostics.yaml`
|
||||
- MSCalendar: `/com.mattermost.mscalendar/diagnostics.yaml`
|
||||
- Google Calendar: `/com.mattermost.gcal/diagnostics.yaml`
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="v10-11" label="v10.11">
|
||||
|
||||
From v10.11, Support Packets include PostgreSQL database schema dump information that provides comprehensive metadata to help diagnose database configuration issues, performance problems, collation mismatches, and other database-related issues.
|
||||
|
||||
**Cluster-wide files (root directory):**
|
||||
|
||||
- [metadata.yaml](#metadata)
|
||||
- `plugins.json` (all active and inactive plugins)
|
||||
- `sanitized_config.json` (sanitized copy of the Mattermost configuration)
|
||||
- `stats.yaml` (Mattermost usage statistics)
|
||||
- `jobs.yaml` (last runs of important jobs)
|
||||
- `diagnostics.yaml` (core plugin diagnostics data)
|
||||
- `permissions.yaml` (role & scheme information)
|
||||
- `postgres_schema_dump.sql` (PostgreSQL database schema information including tables, indexes, constraints, and other database metadata to assist with database configuration diagnosis)
|
||||
- `warning.txt` (present when issues are encountered during packet generation)
|
||||
- `tsdb_dump.tar.gz` (present when the Metrics plugin is installed and the **Performance metrics** option is selected when generating the Support Packet)
|
||||
|
||||
**Cluster-specific files (in node subdirectories):**
|
||||
|
||||
- `<node-id>/mattermost.log` (Mattermost logs for each node)
|
||||
- `<node-id>/audit.log` (Mattermost audit logs for each node)
|
||||
- `<node-id>/ldap.log` (AD/LDAP logs for each node)
|
||||
- `<node-id>/notifications.log` (notifications logs for each node)
|
||||
- `<node-id>/cpu.prof` ([Go performance metrics](#go-performance-metrics) for each node)
|
||||
- `<node-id>/heap.prof` ([Go performance metrics](#go-performance-metrics) for each node)
|
||||
- `<node-id>/goroutines` ([Go performance metrics](#go-performance-metrics) for each node)
|
||||
|
||||
The following additional plugin diagnostic data is included in the generated Support Packet when the plugin is enabled and operational:
|
||||
|
||||
- GitHub: `/github/diagnostics.yaml`
|
||||
- GitLab: `/com.github.manland.mattermost-plugin-gitlab/diagnostics.yaml`
|
||||
- Jira: `/jira/diagnostics.yaml`
|
||||
- Calls: `/com.mattermost.calls/diagnostics.yaml`
|
||||
- Boards: `/focalboard/diagnostics.yaml`
|
||||
- Playbooks: `/playbooks/diagnostics.yaml`
|
||||
- MSCalendar: `/com.mattermost.mscalendar/diagnostics.yaml`
|
||||
- Google Calendar: `/com.mattermost.gcal/diagnostics.yaml`
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="v10-10" label="v10.10">
|
||||
|
||||
From Mattermost v10.10, Support Packets from [high availability](/deployment-guide/server/high-availability-cluster-based-deployment) deployments organize cluster-specific files (such as log files) in subdirectories named after each cluster node, while cluster-wide files remain in the root directory.
|
||||
|
||||
Support packet file organization has been improved to make it easier to identify cluster-wide versus cluster-specific files:
|
||||
|
||||
- **Cluster-wide files** (identical across all nodes in a [high-availability cluster](/deployment-guide/server/high-availability-cluster-based-deployment)) remain in the root directory of the support packet.
|
||||
- **Cluster-specific files** (unique per node) are now organized in subdirectories named after each cluster node.
|
||||
|
||||
**Cluster-wide files (root directory):**
|
||||
|
||||
- [metadata.yaml](#metadata)
|
||||
- `plugins.json` (all active and inactive plugins)
|
||||
- `sanitized_config.json` (sanitized copy of the Mattermost configuration)
|
||||
- `stats.yaml` (Mattermost usage statistics)
|
||||
- `jobs.yaml` (last runs of important jobs)
|
||||
- `diagnostics.yaml` (core plugin diagnostics data)
|
||||
- `permissions.yaml` (role & scheme information)
|
||||
- `warning.txt` (present when issues are encountered during packet generation)
|
||||
- `tsdb_dump.tar.gz` (present when the Metrics plugin is installed and the **Performance metrics** option is selected when generating the Support Packet)
|
||||
|
||||
**Cluster-specific files (in node subdirectories):**
|
||||
|
||||
- `<node-id>/mattermost.log` (Mattermost logs for each node)
|
||||
- `<node-id>/audit.log` (Mattermost audit logs for each node)
|
||||
- `<node-id>/ldap.log` (AD/LDAP logs for each node)
|
||||
- `<node-id>/notifications.log` (notifications logs for each node)
|
||||
- `<node-id>/cpu.prof` ([Go performance metrics](#go-performance-metrics) for each node)
|
||||
- `<node-id>/heap.prof` ([Go performance metrics](#go-performance-metrics) for each node)
|
||||
- `<node-id>/goroutines` ([Go performance metrics](#go-performance-metrics) for each node)
|
||||
|
||||
The following additional plugin diagnostic data is included in the generated support packet when the plugin is enabled and operational:
|
||||
|
||||
- GitHub: `/github/diagnostics.yaml`
|
||||
- GitLab: `/com.github.manland.mattermost-plugin-gitlab/diagnostics.yaml`
|
||||
- Jira: `/jira/diagnostics.yaml`
|
||||
- Calls: `/com.mattermost.calls/diagnostics.yaml`
|
||||
- Boards: `/focalboard/diagnostics.yaml`
|
||||
- Playbooks: `/playbooks/diagnostics.yaml`
|
||||
- MSCalendar: `/com.mattermost.mscalendar/diagnostics.yaml`
|
||||
- Google Calendar: `/com.mattermost.gcal/diagnostics.yaml`
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="v10-5-to-v10-9" label="v10.5 to v10.9">
|
||||
|
||||
Prior to v10.10, each node in the cluster of a high availability deployment has its own `mattermost.log` file and advanced logging files included directly in the Support Packet.
|
||||
|
||||
From v10.5, the following Support Packet data has changed:
|
||||
|
||||
- The `support_packet.yaml` file has been removed and split into `diagnostics.yaml` and `stats.yaml` files.
|
||||
- All fields in `diagnostics.yaml` have been moved into their own objects for improved readability.
|
||||
- Field names are normalized.
|
||||
- New data includes server statistics, logs, permissions, and extended job list details.
|
||||
- Mattermost-supported plugin diagnostic data is included where applicable.
|
||||
|
||||
The contents of a support packet include:
|
||||
|
||||
- [metadata.yaml](#metadata)
|
||||
- `mattermost.log` (Mattermost logs)
|
||||
- `audit.log` (Mattermost audit logs)
|
||||
- `ldap.log` (AD/LDAP logs)
|
||||
- `notifications.log` (notifications logs)
|
||||
- `plugins.json` (all active and inactive plugins)
|
||||
- `sanitized_config.json` (sanitized copy of the Mattermost configuration)
|
||||
- `stats.yaml` (Mattermost usage statistics)
|
||||
- `jobs.yaml` (last runs of important jobs)
|
||||
- `diagnostics.yaml` (core plugin diagnostics data)
|
||||
- `permissions.yaml` (role & scheme information)
|
||||
- [Go performance metrics](#go-performance-metrics), including: `cpu.prof`, `heap.prof`, and `goroutines`
|
||||
- `warning.txt` (present when issues are encountered during packet generation)
|
||||
- `tsdb_dump.tar.gz` (present when the Metrics plugin is installed and the **Performance metrics** option is selected when generating the Support Packet)
|
||||
|
||||
The following additional plugin diagnostic data is included in the generated support packet when the plugin is enabled and operational:
|
||||
|
||||
- GitHub: `/github/diagnostics.yaml`
|
||||
- GitLab: `/com.github.manland.mattermost-plugin-gitlab/diagnostics.yaml`
|
||||
- Jira: `/jira/diagnostics.yaml`
|
||||
- Calls: `/com.mattermost.calls/diagnostics.yaml`
|
||||
- Boards: `/focalboard/diagnostics.yaml`
|
||||
- Playbooks: `/playbooks/diagnostics.yaml`
|
||||
- MSCalendar: `/com.mattermost.mscalendar/diagnostics.yaml`
|
||||
- Google Calendar: `/com.mattermost.gcal/diagnostics.yaml`
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="prior-to-v10-5" label="Prior to v10.5">
|
||||
|
||||
From Mattermost v10.4, a new `diagnostics.yaml` file includes Mattermost Calls diagostics data, including plugin version, calls and active session counts, as well as average duration and participant counts.
|
||||
|
||||
- [metadata.yaml](#metadata)
|
||||
- `mattermost.log`
|
||||
- `plugins.json`
|
||||
- `sanitized_config.json`
|
||||
- `support_packet.yaml`
|
||||
- `diagnostics.yaml` (core plugin diagnostics data)
|
||||
- [Go performance metrics](#go-performance-metrics), including: `cpu.prof`, `heap.prof`, and `goroutines`
|
||||
- `warning.txt` (present when issues are encountered during packet generation)
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
<Note>
|
||||
|
||||
- LDAP groups are not included during Support Packet generation. Only `LDAP Version` and `LDAP Vendor` are included when present. These values are included in the `support_packet.yaml` file.
|
||||
- From Mattermost v9.11, `LDAP Vendor` errors are included in the Support Packet. If fetching the LDAP Vendor name fails, the Support Packet generation includes the error in `warning.txt`. If no LDAP Vendor name is found, the Support Packet lists them as `unknown`.
|
||||
|
||||
</Note>
|
||||
|
||||
## Metadata
|
||||
|
||||
From Mattermost v9.11, generated Support Packets include a `metadata.yaml` file that contains the following information.
|
||||
|
||||
<table style={{width: '99%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '12%'}} />
|
||||
<col style={{width: '12%'}} />
|
||||
<col style={{width: '59%'}} />
|
||||
<col style={{width: '14%'}} />
|
||||
</colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th><strong>Field name</strong></th>
|
||||
<th><strong>Required/Optional</strong></th>
|
||||
<th><strong>Description</strong></th>
|
||||
<th><blockquote>
|
||||
<p><strong>Example</strong></p>
|
||||
</blockquote></th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>version</td>
|
||||
<td>Required</td>
|
||||
<td>Version of the schema that the current metadata file is compatible with. Current version is 1.</td>
|
||||
<td>1</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>type</td>
|
||||
<td>Required</td>
|
||||
<td>The type of the packet. Each type of Support Packet can be mapped to a specific component generating the Support Packet.</td>
|
||||
<td>mattermost</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>generated_at</td>
|
||||
<td>Required</td>
|
||||
<td>The date and time the packet was created. Value is in epoch (ms).</td>
|
||||
<td>1707473288731</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>server_version</td>
|
||||
<td>Required</td>
|
||||
<td>Version of the server that the Support Packet was generated at. Semver is expected.</td>
|
||||
<td>9.1.1</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>server_id</td>
|
||||
<td>Required</td>
|
||||
<td>Unique identifier of the server. Expected to be 26 characters or longer.</td>
|
||||
<td>9qpiszyjr3g8bxda35abcd1234</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>license_id</td>
|
||||
<td>Optional</td>
|
||||
<td>Unique identifier of the current server's license. Expected to be 26 characters or longer. This field is empty when there's no license.</td>
|
||||
<td>abcdejisd67yigqhmkz4ho1234</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>customer_id</td>
|
||||
<td>Optional</td>
|
||||
<td>The id of the customer, as defined in the license file. Expected to be 26 characters or longer. Empty when there's no license.</td>
|
||||
<td>a1b2c3d4qbbr5cpkbpbmef123h</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>extras</td>
|
||||
<td>Optional</td>
|
||||
<td>Key/value of any additional information, specific to the plugin/component that generated the file. Can be useful for identifying the contents of the data. Consider adding plugin (or component) versions in order to set expectation regarding the contents of this object.</td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>extras.plugin_id</td>
|
||||
<td>Required for plugins</td>
|
||||
<td>The ID of the plugin.</td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>extras.plugin_version</td>
|
||||
<td>Required for plugins</td>
|
||||
<td>The version of the plugin.</td>
|
||||
<td></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
For example:
|
||||
|
||||
``` yaml
|
||||
version: 1
|
||||
type: support-packet
|
||||
generated_at: 1622569200
|
||||
server_version: 9.1.1
|
||||
server_id: 8fqk9rti13fmpxdd5934a3xsxh
|
||||
license_id: 3g3pqn8in3brzjkozcn1kdidgr
|
||||
customer_id: 74cmws7gf3ykpj31car7zahsny
|
||||
extras:
|
||||
plugin_version: 0.1.0
|
||||
```
|
||||
|
||||
## Go performance metrics
|
||||
|
||||
The Support Packet contains 3 go runtime profiling files:
|
||||
|
||||
- `cpu.prof` contains a 5-second CPU profile
|
||||
- `heap.prof` contains a heap profile
|
||||
- `goroutines` contains a dump of all the running go routines
|
||||
|
||||
These files can be read using [pprof](https://golang.google.cn/cmd/pprof/).
|
||||
|
||||
Use `go tool pprof -web X` to open a visualization of the profile in your browser, replacing `X` with the profile's file name.
|
||||
|
||||
## Load metric
|
||||
|
||||
From Mattermost v10.10, the **Load Metric** field under **Product Menu \> About Mattermost** displays monthly active users relative to the total number of licensed users. This value gives Mattermost support teams a contextual reference point for understanding deployment active usage for troubleshooting and guidance. It isn’t a comprehensive performance monitoring tool or health indicator, but serves as a supplementary data point when traditional diagnostic methods aren’t available.
|
||||
@@ -0,0 +1,68 @@
|
||||
---
|
||||
title: "Install a license key"
|
||||
---
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
<PlanAvailability slug="all-commercial" />
|
||||
|
||||
You can use the System Console or the mmctl tools to add or change a Mattermost license key.
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="use-system-console" label="Use System Console">
|
||||
|
||||
1. Go to **System Console \> About \> Edition and License**.
|
||||
2. Upload your license key file.
|
||||
|
||||
Once the key is uploaded and installed, the details of your license are displayed.
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="use-mmctl" label="Use mmctl">
|
||||
|
||||
Use the [mmctl license upload](/administration-guide/manage/mmctl-command-line-tool#mmctl-license-upload) command to upload a new license or replace an existing license file with a new one. When complete, restart the Mattermost server. If you're running in a [High Availability](/deployment-guide/server/high-availability-cluster-based-deployment) environment, the new license file must be updated to every node.
|
||||
|
||||
``` sh
|
||||
mmctl license upload [license] [flags]
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
<Note>
|
||||
|
||||
- From Mattermost v10.11, the option to add a license is disabled when the license is set using an [environment variable](/administration-guide/configure/environment-configuration-settings#license-file-location).
|
||||
- Enterprise customers with the Premier Support add-on can request a staging license for testing.
|
||||
- Removing a Mattermost Enterprise or Professional license key won't remove the configuration for Enterprise settings; however, these features won't function until an Enterprise or Professional license key is applied.
|
||||
- When you're using [High Availability](/deployment-guide/server/high-availability-cluster-based-deployment), it's critical to ensure that all servers in the cluster have same Enterprise license properly installed to prevent multi-node clusters from failing. An Enterprise license is required for High Availability to work.
|
||||
- When you apply an Enterprise license key to a server previously licensed for Professional, Professional features retain their configuration settings in Enterprise.
|
||||
- When you apply a Professional license to a server previously licensed for Enterprise, Enterprise features retain their configuration but will no longer be accessible for use.
|
||||
|
||||
</Note>
|
||||
|
||||
## Change an existing license key
|
||||
|
||||
You don't need to wait for your current license key to expire before replacing it with a new license from Mattermost. The server only checks for seat count and license end date, not the start date, so you can apply a new license as soon as you receive it. However, ensure your new license is for a seat count that's greater than or equal to your current total number of Mattermost users.
|
||||
|
||||
<Tip>
|
||||
|
||||
To review license usage before uploading a new key, go to **System Console \> Reporting \> System Statistics**. The **Total Activated Users** field shows the primary paid seat count used for license validation. Review **Single-channel Guests** separately because guests in exactly one active channel are tracked outside the primary paid seat count, are free up to a 1:1 ratio with licensed seats, and generate warnings instead of hard enforcement when that allowance is exceeded. Only active channels count toward guest channel access for billing. Archived channels are excluded.
|
||||
|
||||
</Tip>
|
||||
|
||||
Follow these steps to change your license key:
|
||||
|
||||
1. Go to **System Console \> About \> Edition and License**.
|
||||
2. From Mattermost v6.7, simply upload your new license key file.
|
||||
|
||||
<Note>
|
||||
|
||||
If you're running a Mattermost release older than v6.7, select **Remove Enterprise License and Downgrade Server** to clear the license from the server and refresh the System Console first before uploading the new key.
|
||||
|
||||
</Note>
|
||||
|
||||
## License key storage
|
||||
|
||||
Once you've uploaded your license key to your Mattermost server, it's stored in your SQL database at `mattermost.Licenses`. You can check what keys are on your server by running `select * from mattermost.Licenses;`.
|
||||
|
||||
[Book a live demo](https://mattermost.com/request-demo/) or [talk to a Mattermost expert](https://mattermost.com/contact-sales/) to explore tailored solutions for your organization's secure collaboration needs. Or try Mattermost yourself with a [1-hour preview](https://mattermost.com/sign-up/) for instant access to a live sandbox environment.
|
||||
@@ -0,0 +1,802 @@
|
||||
---
|
||||
title: "Manually migrate from MySQL to PostgreSQL"
|
||||
---
|
||||
<PlanAvailability slug="all-commercial" />
|
||||
|
||||
Migrating a MySQL database to PostgreSQL manually involves the following steps:
|
||||
|
||||
- [install recommended tools](#tool-recommendations)
|
||||
- [familiarize yourself with system requirements and configurations](#system-requirements-and-configurations-for-manual-migrations)
|
||||
- [ensure migration prerequisites are met](#before-a-manual-migration)
|
||||
- [review schema differences](#schema-diffs)
|
||||
- [prepare a target database](#prepare-target-database)
|
||||
- [migrate the data](#migrate-the-data)
|
||||
- [complete post-migration wrap-up activities](#after-the-migration)
|
||||
|
||||
<Tip>
|
||||
|
||||
See the [plugin migrations](#plugin-migrations) section for details on migrating collaborative playbooks and Boards.
|
||||
|
||||
</Tip>
|
||||
|
||||
Not sure upgrading manually is the right path forward? Mattermost customers looking for tailored guidance based on their Mattermost deployment can contact a [Mattermost Expert](https://mattermost.com/contact-sales/).
|
||||
|
||||
## Tool recommendations
|
||||
|
||||
If you prefer to migrate to Postgres manually, we recommend the following tools for the migration process:
|
||||
|
||||
- [pgloader](#pgloader)
|
||||
- [morph](#morph)
|
||||
- [dbcmp (optional)](#dbcmp-optional)
|
||||
|
||||
This page includes instructions on how to install each of these tools, and then proceed with the database migration.
|
||||
|
||||
Once you've installed the necessary tools, review the [system requirements and configurations](#system-requirements-and-configurations-for-manual-migrations) documentation, and know what's required [before starting your migration](#before-a-manual-migration) to prepare for your migration.
|
||||
|
||||
Start your migration by [preparing your target database](#prepare-target-database), then [migrate the data](#migrate-the-data), and complete all [post-migration steps](#after-the-migration).
|
||||
|
||||
See the [plugin migrations](#plugin-migrations) documentation for details on migrating collaborative playbooks and boards.
|
||||
|
||||
### pgloader
|
||||
|
||||
Use the `pgloader` tool to migrate your data from MySQL to PostgreSQL.
|
||||
|
||||
#### Install pgloader
|
||||
|
||||
To install `pgloader`, see the official [installation guide](https://pgloader.readthedocs.io/en/latest/install.html).
|
||||
|
||||
<Note>
|
||||
|
||||
If you are using MySQL v8: Due to a [known bug](https://github.com/dimitri/pgloader/issues/1183) in pgloader-compiled binaries, you need to compile pgloader from the source. Please follow the steps [here](https://pgloader.readthedocs.io/en/latest/install.html#build-from-sources) to build from the source.
|
||||
|
||||
</Note>
|
||||
|
||||
Alternatively, you may want to use our `mattermost-pgloader` Docker image to avoid installing or building `pgloader`. See the documentation below for details.
|
||||
|
||||
#### Use pgloader
|
||||
|
||||
##### Pull the Docker image and verify pgloader
|
||||
|
||||
For a manual migration, run the following command to pull the `mattermost-pgloader` image and verify that pgloader is working correctly:
|
||||
|
||||
``` sh
|
||||
docker run -it --rm -v $(pwd):/home/migration mattermost/mattermost-pgloader:latest pgloader --version
|
||||
```
|
||||
|
||||
This command pulls the `mattermost/mattermost-pgloader:latest` image and runs `pgloader` to check its version and ensure it works as expected.
|
||||
|
||||
##### Map local directory
|
||||
|
||||
Use the `-v $(pwd):/home/migration` flag to map your current working directory to the Docker container. This allows you to use your local directory for storing logs and other files.
|
||||
|
||||
##### Set network configuration
|
||||
|
||||
Depending on your network requirements, set the `--network` flag accordingly. For example, to access localhost, you need to set the network to `host`.
|
||||
|
||||
### morph
|
||||
|
||||
The `morph` tool creates the PostgreSQL schema.
|
||||
|
||||
<Note>
|
||||
|
||||
Both `morph` and `dbcmp` requires Go toolchain. To install Go compiler, follow the [Go documentation](https://go.dev/doc/install).
|
||||
|
||||
</Note>
|
||||
|
||||
#### Install morph
|
||||
|
||||
You can install morph CLI by running the following command:
|
||||
|
||||
``` sh
|
||||
go install github.com/mattermost/morph/cmd/morph@v1
|
||||
```
|
||||
|
||||
### dbcmp (Optional)
|
||||
|
||||
The `dbcmp` tool enables you to compare the data following the migration by comparing every table and reporting whether there is a diversion between two schemas.
|
||||
|
||||
#### Install dbcmp
|
||||
|
||||
You can install [dbcmp](https://github.com/mattermost/dbcmp) by running the following command:
|
||||
|
||||
``` sh
|
||||
go install github.com/mattermost/dbcmp/cmd/dbcmp@latest
|
||||
```
|
||||
|
||||
## System requirements and configurations for manual migrations
|
||||
|
||||
Before starting a manual migration process, it's essential to ensure that your system meets the necessary requirements for a smooth and efficient migration. We strongly recommend the following system specifications and adjustments:
|
||||
|
||||
- Ensure you have enough system memory resources. 16GB of RAM is recommended as a default. In scenarios where system memory is insufficient, users can fine-tune pgloader settings, such as the `number of workers`, `prefetch rows`, and especially `rows per range` if `concurrency` is set above `1`. These adjustments can help optimize resource utilization based on available system resources. For further detail see [pgloader documentation](https://pgloader.readthedocs.io/en/latest/batches.html).
|
||||
- A multi-core processor with sufficient processing power is recommended for the migration process, especially when dealing with large datasets.
|
||||
- Ensure that there is enough disk space available for storing both the MySQL and PostgreSQL databases, as well as any temporary files generated during the migration process. The amount of required disk space depends on the size of the databases being migrated.
|
||||
- To reduce migration time further, users may choose to manually drop indexes on the target PostgreSQL database before initiating the migration process. This approach can potentially accelerate the migration by reducing overhead with index builds during data insertion.
|
||||
|
||||
### Before a manual migration
|
||||
|
||||
<Important>
|
||||
|
||||
This guide requires a schema of v7.1 ESR or later. So, if you have an earlier version and planning to migrate, please update your Mattermost Server to v7.1 at a minimum. See the [extended support releases](/product-overview/release-policy#extended-support-releases) documentation for details.
|
||||
|
||||
- Back up your MySQL data.
|
||||
- Confirm your Mattermost version. See the **About** modal for details.
|
||||
- Schedule the migration window. This process requires you to stop the Mattermost Server during the migration.
|
||||
- See the [schema-diffs](#schema-diffs) section to ensure data compatibility between schemas.
|
||||
- Prepare your PostgreSQL environment by creating a database and user. See the [database](/deployment-guide/server/prepare-database) documentation for details.
|
||||
- On [newer versions](https://www.postgresql.org/docs/release/15.0/) of PostgreSQL, newly created users do not have access to `public` schema. The access should be explicitly granted by running `GRANT ALL ON SCHEMA public to mmuser`.
|
||||
|
||||
</Important>
|
||||
|
||||
### Schema diffs
|
||||
|
||||
Before the manual migration, due to differences between the two schemas, some manual steps may be required for an error-free migration.
|
||||
|
||||
#### Text to character varying
|
||||
|
||||
We encourage you to check if the sizes are consistent within the PostgreSQL schema limits since the Mattermost MySQL schema uses the `text` column type in the various tables instead of `varchar` representation in the PostgreSQL schema.
|
||||
|
||||
You can check if there are any required deletions or updates. For example, to do so in the `Audits` table/`Action` column; run:
|
||||
|
||||
``` sql
|
||||
SELECT FROM mattermost.Audits where LENGTH(Action) > 512;
|
||||
```
|
||||
|
||||
The following table shows the deletions or updates you can proceed with that don't incur further consequences.
|
||||
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Table</th>
|
||||
<th>Column</th>
|
||||
<th>Data type casting</th>
|
||||
<th>Consequence on deletion</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>Audits</td>
|
||||
<td>Action</td>
|
||||
<td>text -> varchar(512)</td>
|
||||
<td>No side effect on how the application works (The affected row needs to be deleted).</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Audits</td>
|
||||
<td>ExtraInfo</td>
|
||||
<td>text -> varchar(1024)</td>
|
||||
<td>No side effect on how the application works (The affected row needs to be deleted).</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>ClusterDiscovery</td>
|
||||
<td>HostName</td>
|
||||
<td>text -> varchar(512)</td>
|
||||
<td>No side effect on how the application works (The affected row needs to be deleted).</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Commands</td>
|
||||
<td>IconURL</td>
|
||||
<td>text -> varchar(1024)</td>
|
||||
<td>The field can be deleted or updated with a new URL.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Commands</td>
|
||||
<td>AutoCompleteDesc</td>
|
||||
<td>text -> varchar(1024)</td>
|
||||
<td>The field can be deleted or rewritten.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Commands</td>
|
||||
<td>AutoCompleteHint</td>
|
||||
<td>text -> varchar(1024)</td>
|
||||
<td>The field can be deleted or rewritten.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>RemoteClusters</td>
|
||||
<td>Topics</td>
|
||||
<td>text -> varchar(512)</td>
|
||||
<td>The field can be removed.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Systems</td>
|
||||
<td>Value</td>
|
||||
<td>text -> varchar(1024)</td>
|
||||
<td>Edge case, ideally should never happen.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
The following table shows several occurrences where the schema can differ and data size constraints within the PostgreSQL schema can result in errors. Each table/row requires individual inspection hence we added the possible consequence of deletion.
|
||||
|
||||
<Tip>
|
||||
|
||||
Several reports have been received from our community that the `LinkMetadata` and `FileInfo` tables had some overflows, so we recommend checking these tables in particular. Please check if your data in the MySQL schema exceeds these limitations.
|
||||
|
||||
</Tip>
|
||||
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Table</th>
|
||||
<th>Column</th>
|
||||
<th>Data type casting</th>
|
||||
<th>Consequence on deletion</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>Compliances</td>
|
||||
<td>Keywords</td>
|
||||
<td>text -> varchar(512)</td>
|
||||
<td>The filter for compliance needs to be updated.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Compliances</td>
|
||||
<td>Emails</td>
|
||||
<td>text -> varchar(1024)</td>
|
||||
<td>The filter for compliance needs to be updated.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>FileInfo</td>
|
||||
<td>Path</td>
|
||||
<td>text -> varchar(512)</td>
|
||||
<td>Previous links to this file won't work (The affected row needs to be deleted).</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>FileInfo</td>
|
||||
<td>ThumbnailPath</td>
|
||||
<td>text -> varchar(512)</td>
|
||||
<td>Previous links to this file won't work (The affected row needs to be deleted).</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>FileInfo</td>
|
||||
<td>PreviewPath</td>
|
||||
<td>text -> varchar(512)</td>
|
||||
<td>Previous links to this file won't work (The affected row needs to be deleted).</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>FileInfo</td>
|
||||
<td>Name</td>
|
||||
<td>text -> varchar(256)</td>
|
||||
<td>Previous links to this file won't work (The affected row needs to be deleted).</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>FileInfo</td>
|
||||
<td>MimeType</td>
|
||||
<td>text -> varchar(256)</td>
|
||||
<td>Previous links to this file won't work (The affected row needs to be deleted).</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>LinkMetadata</td>
|
||||
<td>URL</td>
|
||||
<td>text -> varchar(2048)</td>
|
||||
<td>Previous links to this file won't work (The affected row needs to be deleted).</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>RemoteClusters</td>
|
||||
<td>SiteURL</td>
|
||||
<td>text -> varchar(512)</td>
|
||||
<td>Previous remote cluster will be removed (The affected row needs to be deleted).</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Sessions</td>
|
||||
<td>DeviceId</td>
|
||||
<td>text -> varchar(512)</td>
|
||||
<td>Users will be logged out on these devices (The affected row needs to be deleted).</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>UploadSessions</td>
|
||||
<td>FileName</td>
|
||||
<td>text -> varchar(256)</td>
|
||||
<td>The upload session will be lost (The affected row needs to be deleted).</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>UploadSessions</td>
|
||||
<td>Path</td>
|
||||
<td>text -> varchar(512)</td>
|
||||
<td>The upload session will be lost (The affected row needs to be deleted).</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
#### Full-text indexes
|
||||
|
||||
It's possible that some words in the `Posts` and `FileInfo` tables can exceed the [limits of the maximum token length](https://www.postgresql.org/docs/11/textsearch-limitations.html) for full-text search indexing. In these cases, we are dropping the `idx_posts_message_txt` and `idx_fileinfo_content_txt` indexes from the PostgreSQL schema, and creating these indexes after the migration by running the following queries:
|
||||
|
||||
To prevent errors during the migration, we have included following queries:
|
||||
|
||||
``` text
|
||||
DROP INDEX IF EXISTS {{ .source_db }}.idx_posts_message_txt;
|
||||
DROP INDEX IF EXISTS {{ .source_db }}.idx_fileinfo_content_txt;
|
||||
```
|
||||
|
||||
#### Unsupported unicode sequences
|
||||
|
||||
There is a specific unicode sequence that is [disallowed](https://www.postgresql.org/docs/16/datatype-json.html#DATATYPE-JSON) in PostgreSQL which is `\u0000`. There is a chance that this sequence may appear in several rows across a bunch of tables in your MySQL database. If it is the case, during the migration you will likely receive an error as following: `unsupported Unicode escape sequence: \u0000 cannot be converted to text.`. To prevent this from happening, we advise to sanitize your data before starting to the migration. You can use the following query to replace `\u0000` sequence with empty string.
|
||||
|
||||
<Note>
|
||||
|
||||
You can use this query as-is in a script, or you may need to set the delimiter to something else (e.g., `DELIMITER //`) when defining it in the MySQL console. Once you are done defining the procedure, please set the delimiter back to the original (i.e., `DELIMITER ;`).
|
||||
|
||||
</Note>
|
||||
|
||||
``` text
|
||||
CREATE PROCEDURE SanitizeUnsupportedUnicode()
|
||||
BEGIN
|
||||
DECLARE done INT DEFAULT FALSE;
|
||||
DECLARE curTableName text;
|
||||
DECLARE curColumnName text;
|
||||
DECLARE cursors CURSOR FOR
|
||||
SELECT table_name, column_name
|
||||
FROM information_schema.COLUMNS
|
||||
WHERE data_type = 'json'
|
||||
AND table_schema = DATABASE();
|
||||
DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = TRUE;
|
||||
|
||||
OPEN cursors;
|
||||
|
||||
WHILE NOT DONE DO
|
||||
FETCH cursors INTO curTableName, curColumnName;
|
||||
SET @query_string = CONCAT('UPDATE ', curTableName, ' SET ', curColumnName, ' = REPLACE(', curColumnName, ', \'\\\\u0000\', \'\') WHERE ', curColumnName, ' LIKE \'%\\u0000%\';');
|
||||
|
||||
PREPARE dynamic_query FROM @query_string;
|
||||
EXECUTE dynamic_query;
|
||||
DEALLOCATE PREPARE dynamic_query;
|
||||
END WHILE;
|
||||
|
||||
CLOSE cursors;
|
||||
END;
|
||||
|
||||
CALL SanitizeUnsupportedUnicode();
|
||||
|
||||
DROP PROCEDURE IF EXISTS SanitizeUnsupportedUnicode;
|
||||
```
|
||||
|
||||
<Note>
|
||||
|
||||
There is also a specific byte sequence value that is not allowed and will cause an `invalid byte sequence for encoding 'UTF8': 0x00"` error during the migration. To prevent this error, you can add the `remove-null-characters` clause to the text casting rules. However, since pgloader will modify the data on the fly, there may be differences between the tables (if any are affected) during the comparison phase.
|
||||
|
||||
</Note>
|
||||
|
||||
#### Artifacts may remain from previous configurations/versions
|
||||
|
||||
Prior to `v6.4`, Mattermost was using [golang-migrate](https://github.com/golang-migrate/migrate) to handle the schema migrations. Since we don't use it anymore, we exclude the table `schema_migrations`. If you were using Mattermost before `v6.4` consider dropping this table and excluding it from comparison as well.
|
||||
|
||||
``` sql
|
||||
DROP TABLE mattermost.schema_migrations;
|
||||
```
|
||||
|
||||
Some community members have reported that they had `description` and `nextsyncat` columns in their `SharedChannelRemotes` table. These columns should be removed from the table. Consider running the following DDL to drop the columns. (This migration will be added to future versions of Mattermost).
|
||||
|
||||
``` sql
|
||||
ALTER TABLE SharedChannelRemotes DROP COLUMN description, DROP COLUMN nextsyncat;
|
||||
```
|
||||
|
||||
An error has been identified in the 96th migration that was previously released. Before proceeding with the migration, it is necessary to remove a specific column. To ensure the Threads table reaches the expected state, execute the following prepared statement:
|
||||
|
||||
``` sql
|
||||
SET @preparedStatement = (SELECT IF(
|
||||
(
|
||||
SELECT COUNT(*) FROM INFORMATION_SCHEMA.COLUMNS
|
||||
WHERE table_name = 'Threads'
|
||||
AND table_schema = DATABASE()
|
||||
AND column_name = 'TeamId'
|
||||
) > 0,
|
||||
'ALTER TABLE Threads DROP COLUMN TeamId;',
|
||||
'SELECT 1'
|
||||
));
|
||||
|
||||
PREPARE alterIfExists FROM @preparedStatement;
|
||||
EXECUTE alterIfExists;
|
||||
DEALLOCATE PREPARE alterIfExists;
|
||||
```
|
||||
|
||||
#### Configuration in database
|
||||
|
||||
If you were previously utilizing a database for handling the [Mattermost configuration](/administration-guide/configure/configuration-in-your-database), those tables will not be migrated from your MySQL database with the migration [script](#migrate-the-data).
|
||||
|
||||
Two migrations are necessary:
|
||||
|
||||
- migrate database configuration to the file system
|
||||
- migrate file system configuration back to the database
|
||||
|
||||
##### Migrate database configuration to the file system
|
||||
|
||||
Use the `mmctl config migrate` command to [migrate your config](/administration-guide/manage/mmctl-command-line-tool#mmctl-config-migrate) to the file system, as follows:
|
||||
|
||||
``` sh
|
||||
mmctl config migrate "<DB_USER>:<DB_PASS>@tcp(<DB_HOST>:3306)/<DB_NAME>?charset=utf8mb4,utf8&readTimeout=30s&writeTimeout=30s&multiStatements=true" /opt/mattermost/config/config.json --local
|
||||
```
|
||||
|
||||
Where `<DB_USER>`, `<DB_PASS>`, `<DB_HOST>`, and `<DB_NAME>` are replaced with your environment values. Ensure you use `--local` when running this command. The first parameters (`<DB_USER>`, `<DB_PASS>`) is the database the configuration is stored in, the second parameter (`<DB_HOST>`, `<DB_NAME>`) is the file we are saving the configuration to.
|
||||
|
||||
In the configuration file, update the `SqlSettings.DataSource` and `SqlSettings.DriverName` fields to reflect new changes. To do so, open the `json` file and change the respective fields.
|
||||
|
||||
##### Migrate file system configuration back to the database
|
||||
|
||||
To save configuration back to the database, Use the `mmctl config migrate` command again and reverse the parameters. Ensure you use the new database credentials moving it back to the target database.
|
||||
|
||||
``` sql
|
||||
SELECT * FROM Configurations WHERE Active = 't';
|
||||
```
|
||||
|
||||
You should update the `SqlSettings.DataSource` and `SqlSettings.DriverName` fields accordingly. Also, note that the `MM_CONFIG` environment variable should point to the new DSN after the migration is completed.
|
||||
|
||||
## Prepare target database
|
||||
|
||||
It is essential to create tables and indexes to ensure that the PostgreSQL database schema is properly structured according to the required specifications. Since Mattermost repository contains all of the required SQL queries to achieve that, we can leverage this by running the following steps:
|
||||
|
||||
- Clone the `mattermost` repository for your specific version:
|
||||
|
||||
``` sh
|
||||
git clone -b <your current version (eg. release-7.8)> git@github.com:mattermost/mattermost.git --depth=1
|
||||
```
|
||||
|
||||
- Run all schema migrations\* on your PostgreSQL database using morph CLI with the following command:
|
||||
|
||||
``` sh
|
||||
morph apply up --driver postgres --dsn "postgres://user:pass@localhost:5432/<target_db_mame>?sslmode=disable" --path ./mattermost/db/migrations/postgres --number -1
|
||||
```
|
||||
|
||||
\* After `v8`, due to project re-organization, the migrations directory has been changed to `./mattermost/server/channels/db/migrations/postgres/` relative to where you cloned Mattermost repository. Please set `--path` flag accordingly.
|
||||
|
||||
## Migrate the data
|
||||
|
||||
Once we set the schema to a desired state, we can start migrating the **data** by running `pgloader`
|
||||
|
||||
<Note>
|
||||
|
||||
In the example below, the hosts for both databases are assumed to be in the same instance. Please update addresses accordingly if they are on different machines. Also you can test the `.load` file by simply running `pgloader` with `--dry-run` flag. For instance `pgloader --dry-run migration.load` command.
|
||||
|
||||
</Note>
|
||||
|
||||
Use the following configuration for the baseline of the data migration:
|
||||
|
||||
``` text
|
||||
LOAD DATABASE
|
||||
FROM mysql://{{ .mysql_user }}:{{ .mysql_password }}@{{ .mysql_address }}/{{ .source_db }}
|
||||
INTO pgsql://{{ .pg_user }}:{{ .pg_password }}@{{ .postgres_address }}/{{ .target_db }}
|
||||
|
||||
WITH data only,
|
||||
workers = 8, concurrency = 1,
|
||||
multiple readers per thread, rows per range = 10000,
|
||||
prefetch rows = 10000, batch rows = 2500,
|
||||
create no tables, create no indexes,
|
||||
preserve index names
|
||||
|
||||
SET PostgreSQL PARAMETERS
|
||||
maintenance_work_mem to '128MB',
|
||||
work_mem to '12MB'
|
||||
|
||||
SET MySQL PARAMETERS
|
||||
net_read_timeout = '120',
|
||||
net_write_timeout = '120'
|
||||
|
||||
CAST column Channels.Type to "channel_type" drop typemod,
|
||||
column Teams.Type to "team_type" drop typemod,
|
||||
column UploadSessions.Type to "upload_session_type" drop typemod,
|
||||
column ChannelBookmarks.Type to "channel_bookmark_type" drop typemod,
|
||||
column Drafts.Priority to text,
|
||||
type int when (= precision 11) to integer drop typemod,
|
||||
type bigint when (= precision 20) to bigint drop typemod,
|
||||
type text to varchar drop typemod using remove-null-characters,
|
||||
type tinyint when (<= precision 4) to boolean using tinyint-to-boolean,
|
||||
type json to jsonb drop typemod using remove-null-characters
|
||||
|
||||
EXCLUDING TABLE NAMES MATCHING ~<IR_>, ~<focalboard>, 'schema_migrations', 'db_migrations', 'db_lock',
|
||||
'Configurations', 'ConfigurationFiles', 'db_config_migrations', 'calls'
|
||||
|
||||
BEFORE LOAD DO
|
||||
$$ ALTER SCHEMA public RENAME TO {{ .source_db }}; $$,
|
||||
$$ TRUNCATE TABLE {{ .source_db }}.systems; $$,
|
||||
$$ DROP INDEX IF EXISTS {{ .source_db }}.idx_posts_message_txt; $$,
|
||||
$$ DROP INDEX IF EXISTS {{ .source_db }}.idx_fileinfo_content_txt; $$
|
||||
|
||||
AFTER LOAD DO
|
||||
$$ UPDATE {{ .source_db }}.db_migrations set name='add_createat_to_teamembers' where version=92; $$,
|
||||
$$ ALTER SCHEMA {{ .source_db }} RENAME TO public; $$,
|
||||
$$ SELECT pg_catalog.set_config('search_path', '"$user", public', false); $$,
|
||||
$$ ALTER USER {{ .pg_user }} SET SEARCH_PATH TO 'public'; $$;
|
||||
```
|
||||
|
||||
Once you save this configuration file, e.g. `migration.load`, you can run the `pgloader` with the following command:
|
||||
|
||||
``` sh
|
||||
pgloader migration.load > migration.log
|
||||
```
|
||||
|
||||
Feel free to contribute to and/or report your findings through your migration to us.
|
||||
|
||||
## After the migration
|
||||
|
||||
### Restore full-text indexes
|
||||
|
||||
To avoid performance regression on `Posts` and `FileInfo` table access, following queries should be executed once the migration finishes:
|
||||
|
||||
``` sql
|
||||
CREATE INDEX IF NOT EXISTS idx_posts_message_txt ON public.posts USING gin(to_tsvector('english', message));
|
||||
CREATE INDEX IF NOT EXISTS idx_fileinfo_content_txt ON public.fileinfo USING gin(to_tsvector('english', content));
|
||||
```
|
||||
|
||||
<Note>
|
||||
|
||||
If any of the entries in your `Posts` and `FileInfo` tables exceed the limit mentioned above, index creation query will warn with the `ERROR: string is too long for tsvector` log while trying to create these indexes. This means the content that didn't fit into a `tsvector` was ignored. If you still want to index the truncated content, you can use `substring()` function on the content while creating the indexes.
|
||||
|
||||
Start with a substring length of 1000000 and gradually decrease if the error persists:
|
||||
|
||||
</Note>
|
||||
|
||||
``` sql
|
||||
-- Start with 1000000
|
||||
CREATE INDEX IF NOT EXISTS idx_fileinfo_content_txt ON public.fileinfo USING gin(to_tsvector('english', substring(content,0,1000000)));
|
||||
|
||||
-- If that fails, try 800000
|
||||
CREATE INDEX IF NOT EXISTS idx_fileinfo_content_txt ON public.fileinfo USING gin(to_tsvector('english', substring(content,0,800000)));
|
||||
|
||||
-- Continue decreasing as needed (e.g., 600000, 500000) until the index creates successfully
|
||||
```
|
||||
|
||||
### Compare the data
|
||||
|
||||
We developed an internal tool called `dbcmp` to simplify database comparison. It checks every table in two databases and reports any differences in their schemas. However, `dbcmp` does not compare individual rows. Instead, it calculates checksum values based on a specified page-size and compares them. This means it cannot generate row-level diffs.
|
||||
|
||||
We recommend using `dbcmp` as an additional check to verify data integrity, especially if custom casting rules (beyond the defaults or those provided by us) were used during migration. Otherwise, running this tool is not necessary.
|
||||
|
||||
The tool includes a few flags to run a comparison:
|
||||
|
||||
``` sh
|
||||
Usage:
|
||||
dbcmp [flags]
|
||||
|
||||
Flags:
|
||||
--exclude strings exclude tables from comparison, takes comma-separated values.
|
||||
--include strings include only matching tables for comparison, takes comma-separated values.
|
||||
-h, --help help for dbcmp
|
||||
--source string source database dsn
|
||||
--target string target database dsn
|
||||
-v, --version version for dbcmp
|
||||
```
|
||||
|
||||
<Note>
|
||||
|
||||
`--exclude` and `--include` flags are mutually exclusive and they can't be used together.
|
||||
|
||||
</Note>
|
||||
|
||||
For our case, we can simply run the following command:
|
||||
|
||||
``` sh
|
||||
dbcmp --source "${MYSQL_DSN}" --target "${POSTGRES_DSN} " --include="posts,users"
|
||||
```
|
||||
|
||||
An example command would look like: `dbcmp --source "user:password@tcp(address:3306)/db_name --target "postgres://user:password@address:5432/db_name`
|
||||
|
||||
<Note>
|
||||
|
||||
`POSTGRES_DSN` should start with a `postgres://` prefix. This way `dbcmp` decides which driver to use while connecting to a database.
|
||||
|
||||
</Note>
|
||||
|
||||
Another exclusion we are making is in the `db_migrations` table which has a small difference (a typo in a single migration name) and creates a diff. Since we created the PostgreSQL schema with morph, and the official `mattermost` source, we can skip it safely without concerns. On the other hand, `systems` table may contain additional diffs if there were extra keys added during some of the migrations. Consider excluding the `systems` table if you run into issues, and perform a manual comparison as the data in the `systems` table is relatively smaller in size.
|
||||
|
||||
<Note>
|
||||
|
||||
If the `remove-null-characters` transform function is utilized during the migration and there were `0x00` byte sequences in the MySQL database, those tables will have differences during the comparison phase.
|
||||
|
||||
</Note>
|
||||
|
||||
### Restore the search path
|
||||
|
||||
If you closely examine the `pgloader` configuration file (e.g., `migration.load`), you will notice that the `search_path` of the database user is set to `public`. This is the only requirement for the Mattermost application. However, if you need to include other schemas in the search path, you should modify the `search_path` accordingly to meet your specific requirements.
|
||||
|
||||
## Plugin migrations
|
||||
|
||||
On the plugin side, we are going to take a different approach from what we have done above. We are not going to use `morph` tool to create tables and indexes this time. We are going to utilize `pgloader` to create the tables on behalf of us. The reason for doing so is that collaborative playbooks and boards leverage application logic to facilitate SQL queries. But we don't want to use any level of application at this point.
|
||||
|
||||
### Collaborative playbooks
|
||||
|
||||
The `pgloader` configuration provided for playbooks is based on `v1.38.1` and the plugin should be at least `v1.36.0` to perform the migration.
|
||||
|
||||
Once we are ready to migrate, we can start migrating the **schema** and the **data** by running `pgloader`
|
||||
|
||||
Use the following configuration for the baseline of the data migration:
|
||||
|
||||
``` text
|
||||
LOAD DATABASE
|
||||
FROM mysql://{{ .mysql_user }}:{{ .mysql_password }}@{{ .mysql_address }}/{{ .source_db }}
|
||||
INTO pgsql://{{ .pg_user }}:{{ .pg_password }}@{{ .postgres_address }}/{{ .target_db }}
|
||||
|
||||
WITH include drop, create tables, create indexes, no foreign keys,
|
||||
workers = 8, concurrency = 1,
|
||||
multiple readers per thread, rows per range = 50000,
|
||||
preserve index names
|
||||
|
||||
SET PostgreSQL PARAMETERS
|
||||
maintenance_work_mem to '128MB',
|
||||
work_mem to '12MB'
|
||||
|
||||
SET MySQL PARAMETERS
|
||||
net_read_timeout = '120',
|
||||
net_write_timeout = '120'
|
||||
|
||||
CAST column IR_ChannelAction.ActionType to text drop typemod,
|
||||
column IR_ChannelAction.TriggerType to text drop typemod,
|
||||
column IR_Incident.ChecklistsJSON to "json" drop typemod
|
||||
|
||||
INCLUDING ONLY TABLE NAMES MATCHING
|
||||
~/IR_/
|
||||
|
||||
BEFORE LOAD DO
|
||||
$$ ALTER SCHEMA public RENAME TO {{ .source_db }}; $$
|
||||
|
||||
AFTER LOAD DO
|
||||
$$ ALTER TABLE {{ .source_db }}.IR_ChannelAction ALTER COLUMN ActionType TYPE varchar(65536); $$,
|
||||
$$ ALTER TABLE {{ .source_db }}.IR_ChannelAction ALTER COLUMN TriggerType TYPE varchar(65536); $$,
|
||||
$$ ALTER TABLE {{ .source_db }}.IR_Incident ALTER COLUMN ReminderMessageTemplate TYPE varchar(65536); $$,
|
||||
$$ ALTER TABLE {{ .source_db }}.IR_Incident ALTER COLUMN ReminderMessageTemplate SET DEFAULT ''::text; $$,
|
||||
$$ ALTER TABLE {{ .source_db }}.IR_Incident ALTER COLUMN ConcatenatedInvitedUserIDs TYPE varchar(65536); $$,
|
||||
$$ ALTER TABLE {{ .source_db }}.IR_Incident ALTER COLUMN ConcatenatedInvitedUserIDs SET DEFAULT ''::text; $$,
|
||||
$$ ALTER TABLE {{ .source_db }}.IR_Incident ALTER COLUMN ConcatenatedWebhookOnCreationURLs TYPE varchar(65536); $$,
|
||||
$$ ALTER TABLE {{ .source_db }}.IR_Incident ALTER COLUMN ConcatenatedWebhookOnCreationURLs SET DEFAULT ''::text; $$,
|
||||
$$ ALTER TABLE {{ .source_db }}.IR_Incident ALTER COLUMN ConcatenatedInvitedGroupIDs TYPE varchar(65536); $$,
|
||||
$$ ALTER TABLE {{ .source_db }}.IR_Incident ALTER COLUMN ConcatenatedInvitedGroupIDs SET DEFAULT ''::text; $$,
|
||||
$$ ALTER TABLE {{ .source_db }}.IR_Incident ALTER COLUMN Retrospective TYPE varchar(65536); $$,
|
||||
$$ ALTER TABLE {{ .source_db }}.IR_Incident ALTER COLUMN Retrospective SET DEFAULT ''::text; $$,
|
||||
$$ ALTER TABLE {{ .source_db }}.IR_Incident ALTER COLUMN MessageOnJoin TYPE varchar(65536); $$,
|
||||
$$ ALTER TABLE {{ .source_db }}.IR_Incident ALTER COLUMN MessageOnJoin SET DEFAULT ''::text; $$,
|
||||
$$ ALTER TABLE {{ .source_db }}.IR_Incident ALTER COLUMN ConcatenatedWebhookOnStatusUpdateURLs TYPE varchar(65536); $$,
|
||||
$$ ALTER TABLE {{ .source_db }}.IR_Incident ALTER COLUMN ConcatenatedWebhookOnStatusUpdateURLs SET DEFAULT ''::text; $$,
|
||||
$$ ALTER TABLE {{ .source_db }}.IR_Incident ALTER COLUMN CategoryName TYPE varchar(65536); $$,
|
||||
$$ ALTER TABLE {{ .source_db }}.IR_Incident ALTER COLUMN CategoryName SET DEFAULT ''::text; $$,
|
||||
$$ ALTER TABLE {{ .source_db }}.IR_Incident ALTER COLUMN ConcatenatedBroadcastChannelIds TYPE varchar(65536); $$,
|
||||
$$ ALTER TABLE {{ .source_db }}.IR_Incident ALTER COLUMN ConcatenatedBroadcastChannelIds SET DEFAULT ''::text; $$,
|
||||
$$ ALTER TABLE {{ .source_db }}.IR_Incident ALTER COLUMN ChannelIDToRootID TYPE varchar(65536); $$,
|
||||
$$ ALTER TABLE {{ .source_db }}.IR_Incident ALTER COLUMN ChannelIDToRootID SET DEFAULT ''::text; $$,
|
||||
$$ ALTER TABLE {{ .source_db }}.IR_Playbook ALTER COLUMN ReminderMessageTemplate TYPE varchar(65536); $$,
|
||||
$$ ALTER TABLE {{ .source_db }}.IR_Playbook ALTER COLUMN ReminderMessageTemplate SET DEFAULT ''::text; $$,
|
||||
$$ ALTER TABLE {{ .source_db }}.IR_Playbook ALTER COLUMN ConcatenatedInvitedUserIDs TYPE varchar(65536); $$,
|
||||
$$ ALTER TABLE {{ .source_db }}.IR_Playbook ALTER COLUMN ConcatenatedInvitedUserIDs SET DEFAULT ''::text; $$,
|
||||
$$ ALTER TABLE {{ .source_db }}.IR_Playbook ALTER COLUMN ConcatenatedWebhookOnCreationURLs TYPE varchar(65536); $$,
|
||||
$$ ALTER TABLE {{ .source_db }}.IR_Playbook ALTER COLUMN ConcatenatedWebhookOnCreationURLs SET DEFAULT ''::text; $$,
|
||||
$$ ALTER TABLE {{ .source_db }}.IR_Playbook ALTER COLUMN ConcatenatedInvitedGroupIDs TYPE varchar(65536); $$,
|
||||
$$ ALTER TABLE {{ .source_db }}.IR_Playbook ALTER COLUMN ConcatenatedInvitedGroupIDs SET DEFAULT ''::text; $$,
|
||||
$$ ALTER TABLE {{ .source_db }}.IR_Playbook ALTER COLUMN MessageOnJoin TYPE varchar(65536); $$,
|
||||
$$ ALTER TABLE {{ .source_db }}.IR_Playbook ALTER COLUMN MessageOnJoin SET DEFAULT ''::text; $$,
|
||||
$$ ALTER TABLE {{ .source_db }}.IR_Playbook ALTER COLUMN RetrospectiveTemplate TYPE varchar(65536); $$,
|
||||
$$ ALTER TABLE {{ .source_db }}.IR_Playbook ALTER COLUMN RetrospectiveTemplate SET DEFAULT ''::text; $$,
|
||||
$$ ALTER TABLE {{ .source_db }}.IR_Playbook ALTER COLUMN ConcatenatedWebhookOnStatusUpdateURLs TYPE varchar(65536); $$,
|
||||
$$ ALTER TABLE {{ .source_db }}.IR_Playbook ALTER COLUMN ConcatenatedWebhookOnStatusUpdateURLs SET DEFAULT ''::text; $$,
|
||||
$$ ALTER TABLE {{ .source_db }}.IR_Playbook ALTER COLUMN ConcatenatedSignalAnyKeywords TYPE varchar(65536); $$,
|
||||
$$ ALTER TABLE {{ .source_db }}.IR_Playbook ALTER COLUMN ConcatenatedSignalAnyKeywords SET DEFAULT ''::text; $$,
|
||||
$$ ALTER TABLE {{ .source_db }}.IR_Playbook ALTER COLUMN CategoryName TYPE varchar(65536); $$,
|
||||
$$ ALTER TABLE {{ .source_db }}.IR_Playbook ALTER COLUMN CategoryName SET DEFAULT ''::text; $$,
|
||||
$$ ALTER TABLE {{ .source_db }}.IR_Playbook ALTER COLUMN ChecklistsJSON TYPE JSON USING ChecklistsJSON::JSON; $$,
|
||||
$$ ALTER TABLE {{ .source_db }}.IR_Playbook ALTER COLUMN ConcatenatedBroadcastChannelIds TYPE varchar(65536); $$,
|
||||
$$ ALTER TABLE {{ .source_db }}.IR_Playbook ALTER COLUMN ConcatenatedBroadcastChannelIds SET DEFAULT ''::text; $$,
|
||||
$$ ALTER TABLE {{ .source_db }}.IR_Playbook ALTER COLUMN RunSummaryTemplate TYPE varchar(65536); $$,
|
||||
$$ ALTER TABLE {{ .source_db }}.IR_Playbook ALTER COLUMN RunSummaryTemplate SET DEFAULT ''::text; $$,
|
||||
$$ ALTER TABLE {{ .source_db }}.IR_Playbook ALTER COLUMN ChannelNameTemplate TYPE varchar(65536); $$,
|
||||
$$ ALTER TABLE {{ .source_db }}.IR_Playbook ALTER COLUMN ChannelNameTemplate SET DEFAULT ''::text; $$,
|
||||
$$ ALTER TABLE {{ .source_db }}.IR_PlaybookMember ALTER COLUMN Roles TYPE varchar(65536); $$,
|
||||
$$ ALTER TABLE {{ .source_db }}.IR_Category_Item ADD CONSTRAINT ir_category_item_categoryid FOREIGN KEY (CategoryId) REFERENCES {{ .source_db }}.IR_Category(Id); $$,
|
||||
$$ ALTER TABLE {{ .source_db }}.IR_Metric ADD CONSTRAINT ir_metric_metricconfigid FOREIGN KEY (MetricConfigId) REFERENCES {{ .source_db }}.IR_MetricConfig(Id); $$,
|
||||
$$ ALTER TABLE {{ .source_db }}.IR_Metric ADD CONSTRAINT ir_metric_incidentid FOREIGN KEY (IncidentId) REFERENCES {{ .source_db }}.IR_Incident(Id); $$,
|
||||
$$ ALTER TABLE {{ .source_db }}.IR_MetricConfig ADD CONSTRAINT ir_metricconfig_playbookid FOREIGN KEY (PlaybookId) REFERENCES {{ .source_db }}.IR_Playbook(Id); $$,
|
||||
$$ ALTER TABLE {{ .source_db }}.IR_PlaybookAutoFollow ADD CONSTRAINT ir_playbookautofollow_playbookid FOREIGN KEY (PlaybookId) REFERENCES {{ .source_db }}.IR_Playbook(Id); $$,
|
||||
$$ ALTER TABLE {{ .source_db }}.IR_PlaybookMember ADD CONSTRAINT ir_playbookmember_playbookid FOREIGN KEY (PlaybookId) REFERENCES {{ .source_db }}.IR_Playbook(Id); $$,
|
||||
$$ ALTER TABLE {{ .source_db }}.IR_Run_Participants ADD CONSTRAINT ir_run_participants_incidentid FOREIGN KEY (IncidentId) REFERENCES {{ .source_db }}.IR_Incident(Id); $$,
|
||||
$$ ALTER TABLE {{ .source_db }}.IR_StatusPosts ADD CONSTRAINT ir_statusposts_incidentid FOREIGN KEY (IncidentId) REFERENCES {{ .source_db }}.IR_Incident(Id); $$,
|
||||
$$ ALTER TABLE {{ .source_db }}.IR_TimelineEvent ADD CONSTRAINT ir_timelineevent_incidentid FOREIGN KEY (IncidentId) REFERENCES {{ .source_db }}.IR_Incident(Id); $$,
|
||||
$$ CREATE UNIQUE INDEX IF NOT EXISTS ir_playbookmember_playbookid_memberid_key on {{ .source_db }}.IR_PlaybookMember(PlaybookId,MemberId); $$,
|
||||
$$ CREATE INDEX IF NOT EXISTS ir_statusposts_incidentid_postid_key on {{ .source_db }}.IR_StatusPosts(IncidentId,PostId); $$,
|
||||
$$ CREATE INDEX IF NOT EXISTS ir_playbookmember_playbookid on {{ .source_db }}.IR_PlaybookMember(PlaybookId); $$,
|
||||
$$ ALTER SCHEMA {{ .source_db }} RENAME TO public; $$,
|
||||
$$ SELECT pg_catalog.set_config('search_path', '"$user", public', false); $$,
|
||||
$$ ALTER USER {{ .pg_user }} SET SEARCH_PATH TO 'public'; $$;
|
||||
```
|
||||
|
||||
``` sh
|
||||
pgloader playbooks.load > playbooks_migration.log
|
||||
```
|
||||
|
||||
### Focalboard
|
||||
|
||||
As of `v9.0` Boards will transition to being fully community supported as the Focalboard plugin. Hence this guide covers only version `v7.10.x` of the schema. [Official announcement](/product-overview/deprecated-features#mattermost-server-v900).
|
||||
|
||||
Once we are ready to migrate, we can start migrating the **schema** and the **data** by running `pgloader`
|
||||
|
||||
Use the following configuration for the baseline of the data migration:
|
||||
|
||||
``` text
|
||||
LOAD DATABASE
|
||||
FROM mysql://{{ .mysql_user }}:{{ .mysql_password }}@{{ .mysql_address }}/{{ .source_db }}
|
||||
INTO pgsql://{{ .pg_user }}:{{ .pg_password }}@{{ .postgres_address }}/{{ .target_db }}
|
||||
|
||||
WITH include drop, create tables, create indexes, reset sequences,
|
||||
workers = 8, concurrency = 1,
|
||||
multiple readers per thread, rows per range = 50000,
|
||||
preserve index names
|
||||
|
||||
SET PostgreSQL PARAMETERS
|
||||
maintenance_work_mem to '128MB',
|
||||
work_mem to '12MB'
|
||||
|
||||
SET MySQL PARAMETERS
|
||||
net_read_timeout = '120',
|
||||
net_write_timeout = '120'
|
||||
|
||||
CAST column focalboard_blocks.fields to "json" drop typemod,
|
||||
column focalboard_blocks_history.fields to "json" drop typemod,
|
||||
column focalboard_schema_migrations.name to "varchar" drop typemod,
|
||||
column focalboard_sessions.props to "json" drop typemod,
|
||||
column focalboard_teams.settings to "json" drop typemod,
|
||||
column focalboard_users.props to "json" drop typemod,
|
||||
type int when (= precision 11) to int4 drop typemod,
|
||||
type json to jsonb drop typemod
|
||||
|
||||
INCLUDING ONLY TABLE NAMES MATCHING
|
||||
~/focalboard/
|
||||
|
||||
BEFORE LOAD DO
|
||||
$$ ALTER SCHEMA public RENAME TO {{ .source_db }}; $$
|
||||
|
||||
AFTER LOAD DO
|
||||
$$ UPDATE {{ .source_db }}.focalboard_blocks SET "fields" = '{}'::json WHERE "fields"::text = ''; $$,
|
||||
$$ UPDATE {{ .source_db }}.focalboard_blocks_history SET "fields" = '{}'::json WHERE "fields"::text = ''; $$,
|
||||
$$ UPDATE {{ .source_db }}.focalboard_sessions SET "props" = '{}'::json WHERE "props"::text = ''; $$,
|
||||
$$ UPDATE {{ .source_db }}.focalboard_teams SET "settings" = '{}'::json WHERE "settings"::text = ''; $$,
|
||||
$$ UPDATE {{ .source_db }}.focalboard_users SET "props" = '{}'::json WHERE "props"::text = ''; $$,
|
||||
$$ ALTER SCHEMA {{ .source_db }} RENAME TO public; $$,
|
||||
$$ SELECT pg_catalog.set_config('search_path', '"$user", public', false); $$,
|
||||
$$ ALTER USER {{ .pg_user }} SET SEARCH_PATH TO 'public'; $$;
|
||||
```
|
||||
|
||||
``` sh
|
||||
pgloader focalboard.load > focalboard_migration.log
|
||||
```
|
||||
|
||||
### Calls
|
||||
|
||||
If you are running a version of Mattermost that is greater than `v9.9` or the Calls plugin above `v0.27`, you can opt to migrate the data for the plugin. We are going to take a similar approach with Boards and Playbooks migration and let pgloader create the tables.
|
||||
|
||||
Once we are ready to migrate, we can start migrating the **schema** and the **data** by running `pgloader`
|
||||
|
||||
Use the following configuration for the baseline of the data migration:
|
||||
|
||||
``` text
|
||||
LOAD DATABASE
|
||||
FROM mysql://{{ .mysql_user }}:{{ .mysql_password }}@{{ .mysql_address }}/{{ .source_db }}
|
||||
INTO pgsql://{{ .pg_user }}:{{ .pg_password }}@{{ .postgres_address }}/{{ .target_db }}
|
||||
|
||||
WITH include drop, create tables, create indexes, reset sequences,
|
||||
workers = 8, concurrency = 1,
|
||||
multiple readers per thread, rows per range = 50000,
|
||||
preserve index names
|
||||
|
||||
SET PostgreSQL PARAMETERS
|
||||
maintenance_work_mem to '128MB',
|
||||
work_mem to '12MB'
|
||||
|
||||
SET MySQL PARAMETERS
|
||||
net_read_timeout = '120',
|
||||
net_write_timeout = '120'
|
||||
|
||||
CAST type json to jsonb drop typemod
|
||||
|
||||
INCLUDING ONLY TABLE NAMES MATCHING
|
||||
~/calls/
|
||||
|
||||
BEFORE LOAD DO
|
||||
$$ ALTER SCHEMA public RENAME TO {{ .source_db }}; $$
|
||||
|
||||
AFTER LOAD DO
|
||||
$$ ALTER SCHEMA {{ .source_db }} RENAME TO public; $$,
|
||||
$$ SELECT pg_catalog.set_config('search_path', '"$user", public', false); $$,
|
||||
$$ ALTER USER {{ .pg_user }} SET SEARCH_PATH TO 'public'; $$;
|
||||
```
|
||||
|
||||
``` sh
|
||||
pgloader calls.load > calls_migration.log
|
||||
```
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
See [troubleshooting errors during migration from MySQL to PostgreSQL](/administration-guide/manage/admin/postgres-migration#troubleshooting)
|
||||
12
docs/main/administration-guide/manage/admin/migration.mdx
Normal file
12
docs/main/administration-guide/manage/admin/migration.mdx
Normal file
@@ -0,0 +1,12 @@
|
||||
---
|
||||
title: "Migrate"
|
||||
---
|
||||
Getting data in and out of a Mattermost deployment, moving onto Mattermost from another platform, and moving an existing deployment onto different infrastructure.
|
||||
|
||||
- [Bulk import data](/administration-guide/onboard/bulk-loading-data) - Import users, teams, channels, and posts from a JSONL file.
|
||||
- [Bulk export data](/administration-guide/manage/bulk-export-tool) - Export users, teams, channels, and posts to a JSONL file.
|
||||
- [Migrate from MySQL to PostgreSQL](/administration-guide/manage/admin/postgres-migration) - Move your database, using the migration assist tool or by hand.
|
||||
- [Migrate to FIPS-compliant images](/administration-guide/manage/admin/fips-migration) - Switch an existing Docker or Kubernetes deployment to the FIPS-compliant Mattermost images.
|
||||
- [Migrate from another platform](/administration-guide/onboard/migrating-to-mattermost) - Move from Slack, Rocket.Chat, or GitLab Omnibus, with the [migration announcement email template](/administration-guide/onboard/migration-announcement-email) for telling your users.
|
||||
|
||||
Import and export share the same JSONL format, so the [bulk import data](/administration-guide/onboard/bulk-loading-data) page is also the format reference for export files.
|
||||
@@ -0,0 +1,31 @@
|
||||
---
|
||||
title: "Monitoring and performance"
|
||||
---
|
||||
Keeping a running deployment healthy: what to measure, where to send it, and what to collect when something goes wrong.
|
||||
|
||||
## Metrics and dashboards
|
||||
|
||||
- [Collect performance metrics](/administration-guide/scale/collect-performance-metrics) - Turn on the metrics endpoint and decide what to scrape.
|
||||
- [Deploy Prometheus and Grafana for performance monitoring](/administration-guide/scale/deploy-prometheus-grafana-for-performance-monitoring) - Stand up the monitoring stack.
|
||||
- [Performance monitoring metrics](/administration-guide/scale/performance-monitoring-metrics) - What each metric means.
|
||||
- [Performance alerting](/administration-guide/scale/performance-alerting) - Alert thresholds worth setting, and why.
|
||||
- [Push notification health targets](/administration-guide/scale/push-notification-health-targets) - Healthy delivery latency and failure rates.
|
||||
|
||||
## Logging
|
||||
|
||||
- [Mattermost logging](/administration-guide/manage/logging) - Configure what the server logs and where.
|
||||
- [Deploy Grafana Loki for centralized logging](/administration-guide/scale/deploy-grafana-loki-for-centralized-logging) - Aggregate logs across servers.
|
||||
|
||||
## Health and diagnostics
|
||||
|
||||
- [Optimize your Mattermost workspace](/administration-guide/configure/optimize-your-workspace) - Run the System Console health check and act on what it finds.
|
||||
- [Statistics](/administration-guide/manage/statistics) - Site and team usage statistics.
|
||||
- [Configure server health check probes](/administration-guide/manage/configure-health-check-probes) - Liveness and readiness endpoints for your orchestrator.
|
||||
- [Request a server health check](/administration-guide/manage/request-server-health-check) - Have Mattermost review your deployment.
|
||||
- [Generate a support packet](/administration-guide/manage/admin/generating-support-packet) - Collect logs and configuration for a support ticket.
|
||||
- [Mattermost error codes](/administration-guide/manage/admin/error-codes) - Look up an error a user reported.
|
||||
|
||||
## Telemetry
|
||||
|
||||
- [Telemetry](/administration-guide/manage/telemetry) - What Mattermost collects, and how to turn it off.
|
||||
- [Ensure releases perform at scale](/administration-guide/scale/ensuring-releases-perform-at-scale) - How Mattermost load-tests each release.
|
||||
@@ -0,0 +1,206 @@
|
||||
---
|
||||
title: "Automated PostgreSQL migration"
|
||||
---
|
||||
<PlanAvailability slug="all-commercial" />
|
||||
|
||||
Migrating databases can be a daunting task, and it can be easy to overlook or misinterpret some of the required steps if you haven't performed a migration before. Our `migration-assist` tool provides an efficient, error-free migration experience that automates the [tasks to be executed](/administration-guide/manage/admin/manual-postgres-migration), even in air-gapped deployment environments.
|
||||
|
||||
Not sure this tool is right for your Mattermost deployment? Mattermost customers looking for tailored guidance based on their Mattermost deployment can contact a [Mattermost Expert](https://mattermost.com/contact-sales/).
|
||||
|
||||
## Install
|
||||
|
||||
Download the Mattermost `migration-assist` tool from the GitHub repository [releases page](https://github.com/mattermost/migration-assist/releases).
|
||||
|
||||
While you can run the `migration-assist` tool on the same server as your Mattermost deployment, we recommend running the tool in a virtual machine on the same network as your Mattermost server instead. The tool itself is lightweight and does not require a large server. A server with 2 CPU cores and 16 GB of RAM should be sufficient. If preferred, you can download and [compile](#compile-the-migration-assist-tool) the `migration-assist` tool yourself.
|
||||
|
||||
You'll also need to install the `pgloader` tool to migrate your data from MySQL to PostgreSQL. We recommend running `pgloader` in a virtual machine on the same network as your Mattermost server. You can use our official Mattermost Docker image for pgloader (`mattermost/pgloader:latest`); please note that it does **not** currently support MySQL’s `caching_sha2_password` authentication plugin. If you require `caching_sha2_password` support, you’ll need to build your own image and include the [qitab/qmynd](https://github.com/qitab/qmynd) library. See the [pgloader](/administration-guide/manage/admin/manual-postgres-migration#install-pgloader) installation documentation for details.
|
||||
|
||||
## Usage
|
||||
|
||||
<Important>
|
||||
|
||||
- If you encounter heap exhaustion errors in `pgloader`, edit your generated `migration.load` and under the `WITH` block set: `prefetch rows = 1000` and consider reducing it if the issue persists.
|
||||
- Please make sure you have the necessary environment to perform the migration. Ensure that the MySQL and PostgreSQL databases are running and accessible. To set up a PostgreSQL instance, see the [prepare your Mattermost database](/deployment-guide/server/prepare-database) documentation for details.
|
||||
- If you were previously utilizing a database for handling the [Mattermost configuration](/administration-guide/configure/configuration-in-your-database), those tables will not be migrated from your MySQL database with the migration [script](#migrate-the-data). You will need to manually migrate those configuration settings to your PostgreSQL database after completing the migration process. See the [configuration in database](/administration-guide/manage/admin/manual-postgres-migration#configuration-in-database) documentation for details.
|
||||
|
||||
</Important>
|
||||
|
||||
### Step 1 - Check the MySQL database schema
|
||||
|
||||
Run the following command to check the MySQL database schema:
|
||||
|
||||
``` sh
|
||||
migration-assist mysql "<MYSQL_DSN>" # example DSN: "user:password@tcp(address:3306)/db_name"
|
||||
```
|
||||
|
||||
This command outputs the readiness status and prints required fixes for common issues. The flags for fixes are as follows (you can combine all of them):
|
||||
|
||||
``` text
|
||||
--fix-artifacts Removes the artifacts from older versions of Mattermost
|
||||
--fix-unicode Strips unsupported Unicode characters from MySQL tables
|
||||
--fix-varchar Removes rows exceeding column lengths
|
||||
```
|
||||
|
||||
### Step 2 - Create the PostgreSQL database schema
|
||||
|
||||
Before running migrations, ensure the `public` schema is owned by your migration user:
|
||||
|
||||
``` sql
|
||||
sudo -u postgres psql -d mattermost -c "ALTER SCHEMA public OWNER TO mmuser; GRANT ALL ON SCHEMA public TO mmuser;"
|
||||
```
|
||||
|
||||
Then run:
|
||||
|
||||
``` sh
|
||||
migration-assist postgres "<POSTGRES_DSN>" \
|
||||
--run-migrations \
|
||||
--mattermost-version="<MATTERMOST_VERSION>"
|
||||
```
|
||||
|
||||
- `<POSTGRES_DSN>` example: `postgres://user:password@address:5432/db_name`
|
||||
- `<MATTERMOST_VERSION>` example: `10.5.4`
|
||||
|
||||
By default, two pre-checks run before migration:
|
||||
|
||||
- `--check-schema-owner=true`
|
||||
- `--check-tables-empty=true`
|
||||
|
||||
To disable them:
|
||||
|
||||
``` sh
|
||||
--check-schema-owner=false \
|
||||
--check-tables-empty=false
|
||||
```
|
||||
|
||||
### Step 3 - Generate a pgloader configuration
|
||||
|
||||
Run the following command to emit a pgloader configuration file:
|
||||
|
||||
``` sh
|
||||
migration-assist pgloader \
|
||||
--mysql="<MYSQL_DSN>" \
|
||||
--postgres="<POSTGRES_DSN>" \
|
||||
--remove-null-chars \
|
||||
> migration.load
|
||||
```
|
||||
|
||||
- By default, null characters in text columns are stripped. Disable with `--remove-null-chars=false`.
|
||||
|
||||
- If you run out of heap, edit `migration.load` and under the `WITH` block set:
|
||||
|
||||
``` text
|
||||
prefetch rows = 1000
|
||||
```
|
||||
|
||||
### Step 4 - Run pgloader
|
||||
|
||||
[Run pgloader](/administration-guide/manage/admin/manual-postgres-migration#pgloader) with the generated configuration file:
|
||||
|
||||
``` sh
|
||||
pgloader migration.load > migration.log
|
||||
```
|
||||
|
||||
Carefully review <code>migration.log</code> for errors (e.g., duplicate-key or missing-table warnings). Use the `mattermost/pgloader:latest` Docker image to avoid build/auth issues.
|
||||
|
||||
### Step 5 - Restore full-text indexes & create all indexes
|
||||
|
||||
Run:
|
||||
|
||||
``` sh
|
||||
migration-assist postgres post-migrate --create-indexes "<POSTGRES_DSN>"
|
||||
```
|
||||
|
||||
- The `--create-indexes` flag rebuilds full-text indexes on `Posts` and `FileInfo`, plus all other Mattermost indexes.
|
||||
- Omitting that flag only restores full-text indexes for `Posts` and `FileInfo`.
|
||||
|
||||
See the [Restore full-text indexes](/administration-guide/manage/admin/manual-postgres-migration#restore-full-text-indexes) documentation for details.
|
||||
|
||||
### Step 6 - Complete plugin migrations
|
||||
|
||||
Generate pgloader configs for Playbooks, Boards, and Calls:
|
||||
|
||||
``` sh
|
||||
migration-assist pgloader boards \
|
||||
--mysql="<MYSQL_DSN>" \
|
||||
--postgres="<POSTGRES_DSN>" > boards.load
|
||||
migration-assist pgloader playbooks \
|
||||
--mysql="<MYSQL_DSN>" \
|
||||
--postgres="<POSTGRES_DSN>" > playbooks.load
|
||||
migration-assist pgloader calls \
|
||||
--mysql="<MYSQL_DSN>" \
|
||||
--postgres="<POSTGRES_DSN>" > calls.load
|
||||
```
|
||||
|
||||
Run each:
|
||||
|
||||
``` sh
|
||||
pgloader boards.load > boards_migration.log
|
||||
pgloader playbooks.load > playbooks_migration.log
|
||||
pgloader calls.load > calls_migration.log
|
||||
```
|
||||
|
||||
Skip any plugin you don't use; check logs for JSON or missing-table errors. See the [Plugin migrations](/administration-guide/manage/admin/manual-postgres-migration#plugin-migrations) guide for more.
|
||||
|
||||
### Step 7 - Configure Mattermost to use PostgreSQL
|
||||
|
||||
In your `config.json` or via environment variables, update:
|
||||
|
||||
``` json
|
||||
"SqlSettings": {
|
||||
"DriverName": "postgres",
|
||||
"DataSource": "postgres://mmuser:pass@db:5432/mattermost?sslmode=disable"
|
||||
}
|
||||
```
|
||||
|
||||
If your config was stored in the database, update `MM_CONFIG` accordingly. See the [environment configuration settings](/administration-guide/configure/environment-configuration-settings#database) documentation for details.
|
||||
|
||||
<Note>
|
||||
|
||||
If your Mattermost deployment was initially configured with MySQL, there's a good chance your systemd service file has a `BindsTo=mysql.service` directive in it. This will cause the Mattermost server to be shut down if you deactivate your MySQL service. To fix this, update all references to `mysql.service` in your service file to use `postgresql.service` instead. This is only an issue if your Database and Mattermost are running on the same system.
|
||||
|
||||
</Note>
|
||||
|
||||
## Air-gapped environments
|
||||
|
||||
Follow these steps to migrate within an air-gapped environment:
|
||||
|
||||
1. **Verify** that the <code>migration-assist</code> binary is the latest version available to benefit from improvements and fixes.
|
||||
|
||||
2. **Transfer** the latest <code>migration-assist</code> binary into the air-gapped environment (e.g., via secure media).
|
||||
|
||||
3. **Generate** the MySQL schema+data output using fix flags. This produces `mysql.output`:
|
||||
|
||||
``` sh
|
||||
migration-assist mysql "user:pass@tcp(localhost:3306)/mattermost" \
|
||||
--fix-artifacts --fix-unicode --fix-varchar > mysql.output
|
||||
```
|
||||
|
||||
4. **Apply** migrations using the generated output:
|
||||
|
||||
``` sh
|
||||
migration-assist postgres \
|
||||
"postgres://mmuser:pass@localhost:5432/imported?sslmode=disable" \
|
||||
--run-migrations --applied-migrations="./mysql.output"
|
||||
```
|
||||
|
||||
5. **Continue** from **Step 3** through **Step 7** above to complete data transfer and configuration.
|
||||
|
||||
## Tool commands
|
||||
|
||||
The `migration-assist` tool offers 3 core commands:
|
||||
|
||||
1. `migration-assist mysql` — Checks MySQL schema readiness and offers fixes.
|
||||
2. `migration-assist postgres` — Builds the PostgreSQL schema and applies migrations.
|
||||
3. `migration-assist pgloader` — Generates a pgloader config for data transfer.
|
||||
|
||||
## Compile the migration-assist tool
|
||||
|
||||
Requires Go ≥ v1.22. Install with:
|
||||
|
||||
``` shell
|
||||
go install github.com/mattermost/migration-assist/cmd/migration-assist@latest
|
||||
```
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
See [troubleshooting errors during migration from MySQL to PostgreSQL](/administration-guide/manage/admin/postgres-migration#troubleshooting).
|
||||
@@ -0,0 +1,234 @@
|
||||
---
|
||||
title: "Migration guidelines from MySQL to PostgreSQL"
|
||||
---
|
||||
<PlanAvailability slug="all-commercial" />
|
||||
|
||||
From Mattermost v8.0, [PostgreSQL](/deployment-guide/software-hardware-requirements#database-software) is our database of choice for Mattermost to enhance the platform’s performance and capabilities. Recognizing the importance of supporting the community members who are interested in migrating from a MySQL database, we have taken proactive measures to provide guidance and best practices.
|
||||
|
||||
- [Automated migration from MySQL to PostgreSQL](/administration-guide/manage/admin/postgres-migration-assist-tool) - A comprehensive set of guidelines and a `migration-assist` tool to streamline the migration process, alleviate potential challenges, and faciliate a smooth transition.
|
||||
- [Manually migrate from MySQL to PostgreSQL](/administration-guide/manage/admin/manual-postgres-migration) - A good option if your organization has database administrators to own the migration process, or if you want to learn what the `migration-assist` tool automates for you.
|
||||
|
||||
## Frequently asked questions
|
||||
|
||||
### Why is Mattermost dropping support for MySQL?
|
||||
|
||||
Mattermost has decided to drop support for MySQL databases to streamline development and focus on delivering more efficient and optimized features. By supporting only PostgreSQL, which is generally considered more advanced and better-suited for enterprise environments, Mattermost can reduce complexity, improve performance, and better allocate resources to enhance the product. This change helps ensure more consistent, robust, and scalable database interactions for all Mattermost deployments.
|
||||
|
||||
### Is migrating to PostgreSQL before upgrading Mattermost recommended?
|
||||
|
||||
Yes. We also recommend upgrading to Mattermost server v8.x or later before migrating to PostgreSQL.
|
||||
|
||||
### Can the migration-assist be run on the Mattermost server?
|
||||
|
||||
Technically, yes. The `migration-assist` tool can be run on the Mattermost server. However, it is recommended to run the tool on a separate server to avoid any performance issues. We advise running the migration against a copy of the MySQL database to ensure that the migration process does not impact the production environment.
|
||||
|
||||
### How large should the PostgreSQL server be?
|
||||
|
||||
The size of the PostgreSQL server should match that of the MySQL server initially. We recommend monitoring the performance of the PostgreSQL server and adjusting the resources as needed.
|
||||
|
||||
### How large should the server running `migration-assist` server be?
|
||||
|
||||
The tool itself is lightweight and does not require a large server. A server with 2 CPU cores and 16 GB of RAM should be sufficient for default configurations. However, you may need to adjust the resources based on the size of the MySQL database, your downtime limitations, and the configuration of `pgloader`.
|
||||
|
||||
### Do we/will Mattermost bundle pgloader or is that a separate install?
|
||||
|
||||
Mattermost doesn't bundle pgloader with the Mattermost server. You will need to install pgloader separately. For more information, see the [install pgloader](/administration-guide/manage/admin/manual-postgres-migration#install-pgloader) documentation.
|
||||
|
||||
### Are there any other migrations available for plugins, or just Boards, Playbooks, and Calls?
|
||||
|
||||
We're developing migrations for other plugins, such as NPS-plugin. Please stay tuned for updates.
|
||||
|
||||
### Do these processes support AWS RDS databases?
|
||||
|
||||
Yes, the processes support AWS RDS databases. However, you may need to adjust the security group settings to allow the migration process to access the databases.
|
||||
|
||||
### Does Mattermost support MariaDB? If not, why not?
|
||||
|
||||
Mattermost does not support MariaDB. The primary reason for this decision is to streamline development and maintenance by focusing on a single database technology. By standardizing on PostgreSQL, Mattermost can deliver optimized features, improved performance, and a more focused engineering effort. PostgreSQL is well-regarded for its robustness, advanced features, and suitability for enterprise use, making it the chosen database for Mattermost.
|
||||
|
||||
MariaDB, while compatible with MySQL to a large extent, introduces additional complexity and potential inconsistency, which the Mattermost development team aims to avoid by limiting database support.
|
||||
|
||||
Because of these reasons we also don't support migrations directly from MariaDB to PostgreSQL. Oracle provides documentation on \[how to migrate from MariaDB to MySQL\]([https://blogs.oracle.com/mysql/post/how-to-migrate-from-mariadb-to-mysql-80](https://blogs.oracle.com/mysql/post/how-to-migrate-from-mariadb-to-mysql-80)) which can be used as a starting point for the migration to PostgreSQL.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Unsupported authentication for MySQL
|
||||
|
||||
If you are facing an error due to authentication with MySQL v8, it may be related to a [known issue](https://github.com/dimitri/pgloader/issues/782) with pgloader. The fix is to set the default authentication method to `mysql_native_password` in your MySQL configuration. To do so, add the `default-authentication-plugin=mysql_native_password` value to your `mysql.cnf` file. Also, do not forget to update your user to use this authentication method.
|
||||
|
||||
``` sql
|
||||
ALTER USER '<mysql_user>'@'%' IDENTIFIED WITH mysql_native_password BY '<mysql_password>';
|
||||
```
|
||||
|
||||
### Errors during the pgloader command execution
|
||||
|
||||
If you encounter errors during the execution of the `pgloader` command, ensure that both of the databases are accessible and that the users have the necessary permissions to access the database. Do not continue with the migration if there are errors during the execution of the `pgloader` command.
|
||||
|
||||
<Note>
|
||||
|
||||
For experienced users, it is recoverable to run the `pgloader` without requiring a restart of the migration from scratch. In this case, you will need to manually fix the issues with the table, and run the `pgloader` command with a tailored configuration specifically for those tables. Also ensure that the schema name is reverted back to `public`, and the `search_path` is restored (or remove necessary clauses from the configuration).
|
||||
|
||||
</Note>
|
||||
|
||||
The following sections detail how to resolve some common errors you may encounter during the execution of the `pgloader` command:
|
||||
|
||||
#### Invalid input syntax for type JSON
|
||||
|
||||
If you receive an error message similar to the following:
|
||||
|
||||
``` text
|
||||
ERROR Database error 22P02: invalid input syntax for type json
|
||||
```
|
||||
|
||||
The data in the MySQL database is not in a valid JSON format. You can fix this issue by updating the data in the MySQL database to be in a valid JSON format. To find out which row is causing the issue, run the following query (where `<table_name>` and `<column_name>` should be replaced with the actual table and column names indicated in the `pgloader` output):
|
||||
|
||||
``` sql
|
||||
SELECT * FROM <table_name> WHERE JSON_VALID(<column_name>) = 0;
|
||||
```
|
||||
|
||||
You can find and update the data in the MySQL database to be in a valid JSON format with the query above. After updating the data, you can run the `pgloader` command again.
|
||||
|
||||
#### Failed to find column or table
|
||||
|
||||
If you receive an error message similar to the following:
|
||||
|
||||
``` text
|
||||
pgloader failed to find column
|
||||
```
|
||||
|
||||
The column or table is missing in the PostgreSQL database. You can fix this issue by checking whether you have created the correct version of Postgres schema. After re-creating the schema, you can run the `pgloader` command again.
|
||||
|
||||
#### Fell through ECASE expression
|
||||
|
||||
If you receive an error message similar to the following:
|
||||
|
||||
``` text
|
||||
ERROR mysql: 76 fell through ECASE expression.
|
||||
```
|
||||
|
||||
It is a [known issue](https://github.com/dimitri/pgloader/issues/1183) with pgloader. You can fix this issue by either compiling `pgloader` from source or simply avoid this by running `pgloader` with our docker image. See: [install pgloader](/administration-guide/manage/admin/manual-postgres-migration#install-pgloader) for more information.
|
||||
|
||||
<Note>
|
||||
|
||||
Also, there may be cases where pgloader continues to migrate remaining tables and skip one or more tables during migration. In such cases, we recommend identifying issues with the table and fixing them before running the `pgloader` command again with a clean database. It is possible to run the `pgloader` command with the `--debug` flag to get more information about the errors.
|
||||
|
||||
</Note>
|
||||
|
||||
### Mattermost can't connect to the PostgreSQL database
|
||||
|
||||
If you are facing an issue where Mattermost can't connect to the PostgreSQL database, ensure that the PostgreSQL server is running and that the database is accessible. If there were errors during the execution of the `pgloader` command, it can fail to revert the schema name back to `public`, or potentially fail to restore the `search_path`. You can manually revert the schema name back to `public` and restore the `search_path` by running the following commands:
|
||||
|
||||
1. Connect to PostgreSQL using `sudo -u postgres psql`.
|
||||
2. Select the `mattermost` database using `\c mattermost`. Verify you are using the right database by running `SELECT current_database();`. The command should output `mattermost`.
|
||||
3. Revert the schema name change (optional)
|
||||
|
||||
``` sql
|
||||
ALTER SCHEMA <schema_name> RENAME TO public;
|
||||
```
|
||||
|
||||
Also ensure that the database user has the necessary settings to have default access to the `public` schema. You can do this by running the following commands:
|
||||
|
||||
4. Set the search_path for the mmuser:
|
||||
|
||||
``` sql
|
||||
ALTER USER mmuser SET search_path TO "$user", public;
|
||||
```
|
||||
|
||||
5. Terminate the connection and connect again to your psql server.
|
||||
|
||||
6. Verify the search_path is set correctly:
|
||||
|
||||
``` sh
|
||||
SHOW search_path;
|
||||
```
|
||||
|
||||
This should return `"$user", public`.
|
||||
|
||||
7. If the issue persists, also run:
|
||||
|
||||
``` sql
|
||||
SELECT pg_catalog.set_config('search_path', '"$user", public', false);
|
||||
```
|
||||
|
||||
### Permission issues when accessing the schema in PostgreSQL
|
||||
|
||||
If you run into a permission issue during step 2 where the command reports a permission issue similar to the following:
|
||||
|
||||
``` text
|
||||
An Error Occurred: could not check schema owner: the user “mmuser” is not owner of the “public” schema
|
||||
```
|
||||
|
||||
Ensure that the `mmuser` user in PostgreSQL is the owner of the schema.
|
||||
|
||||
1. Connect to PostgreSQL using `sudo -u postgres psql`.
|
||||
|
||||
2. Select the `mattermost` database using `\c mattermost`. Verify you are using the right database by running `SELECT current_database();`. The command should output `mattermost`.
|
||||
|
||||
3. Run the following commands:
|
||||
|
||||
``` sql
|
||||
ALTER SCHEMA public OWNER TO mmuser;
|
||||
GRANT USAGE, CREATE ON SCHEMA public TO mmuser;
|
||||
```
|
||||
|
||||
Then, re-run the command from step 2.
|
||||
|
||||
### Incoming webhook channel names become case-sensitive after migration
|
||||
|
||||
After migrating from MySQL to PostgreSQL, incoming webhooks that previously worked with mixed-case channel names (e.g., `"Tech-Talk"`) will fail with the following error:
|
||||
|
||||
``` text
|
||||
GetChannelByName: Channel does not exist.
|
||||
```
|
||||
|
||||
This occurs because Mattermost doesn't allow the creation of channels with uppercase characters. All new channels names must only contain lowercase characters. Additionally, MySQL is case-insensitive when matching channel names, while PostgreSQL is case-sensitive. This means that webhook payloads that worked with MySQL's forgiving case-insensitive matching will fail with PostgreSQL's strict case-sensitive matching. In rare cases, older channels may still exist with mixed-case names in your database. These channels are considered invalid and may cause issues when performing operations like updating channel headers.
|
||||
|
||||
**Solution:**
|
||||
|
||||
Update all webhook payloads to use only lowercase channel names.
|
||||
|
||||
**Prevention:**
|
||||
|
||||
Before migrating to PostgreSQL:
|
||||
|
||||
1. Audit your incoming webhooks and update any that use mixed-case channel names in their payloads.
|
||||
2. Check for any legacy channels with mixed-case names that may have been created in earlier versions.
|
||||
3. Consider renaming any mixed-case channels to lowercase to prevent issues.
|
||||
|
||||
This is expected behavior with PostgreSQL and reflects Mattermost's channel naming requirements.
|
||||
|
||||
### Legacy Boards tables causing migration errors
|
||||
|
||||
During database migration from MySQL to PostgreSQL, while using schema comparison tools (such as dbcmp) you may encounter the following error:
|
||||
|
||||
``` text
|
||||
error during comparison: no pk defined for table: focalboard_file_info
|
||||
```
|
||||
|
||||
This typically relates to legacy tables from older versions of Boards that are no longer in use. If you're using Boards version 8.0.0 or later, these tables are no longer required and can be ignored in the migration process.
|
||||
|
||||
**Applies To:**
|
||||
|
||||
- Boards version 8.0.0 and above
|
||||
- All staging, UAT, QA, or production environments
|
||||
|
||||
<Note>
|
||||
|
||||
Does not apply to standalone Boards versions prior to v8.0.0
|
||||
|
||||
</Note>
|
||||
|
||||
**Solution:**
|
||||
|
||||
If you're using Boards version 8.0.0 or higher, the following legacy tables which were used only in the standalone version and can be safely ignored:
|
||||
|
||||
- `focalboard_file_info` - Used in standalone version; no longer relevant in plugin and later versions. Stores uploaded files and attachments for boards.
|
||||
- `focalboard_sessions` - Used in standalone version. Tracks user login sessions for boards.
|
||||
- `focalboard_teams` - Used in standalone version. Legacy team mapping not used in later versions. Stores team board settings and permissions.
|
||||
- `focalboard_users` - Used in standalone version. Stores user preferences and settings for boards.
|
||||
|
||||
These tables may be empty or unused in your current environment. If so, they do not need to be migrated to PostgreSQL.
|
||||
|
||||
## Contact Support
|
||||
|
||||
Mattermost customers looking for guidance tailored to their Mattermost deployment can contact a [Mattermost Expert](https://mattermost.com/contact-sales/) for guidance.
|
||||
@@ -0,0 +1,14 @@
|
||||
---
|
||||
title: "Self-hosted billing"
|
||||
---
|
||||
<PlanAvailability slug="all-commercial" />
|
||||
|
||||
Mattermost commercial plans are offered as an annual subscription service. With your purchase you're provided with a license key. Depending on which version of Mattermost you're on, you may have to download and apply this license manually via the System Console.
|
||||
|
||||
When you upgrade to commercial plan, the number of user seats you need has to be equal to or greater than your current number of activated users (formerly called active users).
|
||||
|
||||
You can add new users to your deployment at any time. Every quarter, during the true-up review (section 3.5 License True-up Review of Software License Agreement, also referenced in docs), we check the license license seat count relative to number of activated users. If there's a difference, we'll provide you with a new invoice which is payable immediately.
|
||||
|
||||
Please see the [self-hosted subscriptions documentation](/product-overview/self-hosted-subscriptions#buy-a-subscription) for more detailed information.
|
||||
|
||||
[Book a live demo](https://mattermost.com/request-demo/) or [talk to a Mattermost expert](https://mattermost.com/contact-sales/) to explore tailored solutions for your organization's secure collaboration needs. Or try Mattermost yourself with a [1-hour preview](https://mattermost.com/sign-up/) for instant access to a live sandbox environment.
|
||||
@@ -0,0 +1,32 @@
|
||||
---
|
||||
title: "Manage Mattermost"
|
||||
---
|
||||
Running Mattermost day to day: who has access to what, the tools you operate the server with, your license and billing, the notices your users see, and getting your data out.
|
||||
|
||||
## Access control
|
||||
|
||||
- [Access control](/administration-guide/manage/admin/user-management) - Permissions, roles, user attributes, team and channel membership, and attribute-based access control.
|
||||
|
||||
## Server operations
|
||||
|
||||
- [mmctl command line tool](/administration-guide/manage/mmctl-command-line-tool) - Administer the server from the command line.
|
||||
- [Command line tools](/administration-guide/manage/command-line-tools) - The `mattermost` binary's own commands.
|
||||
- [Mattermost logging](/administration-guide/manage/logging) - Customize logging options based on your business practices and needs.
|
||||
|
||||
## Licensing and billing
|
||||
|
||||
- [Self-hosted billing](/administration-guide/manage/admin/self-hosted-billing) - Billing and payment options for self-hosted deployments.
|
||||
- [Install a license key](/administration-guide/manage/admin/installing-license-key) - Apply a license to a self-hosted deployment.
|
||||
|
||||
## Cloud, notices, and data
|
||||
|
||||
- [Cloud workspace management](/administration-guide/manage/cloud-workspace-management) - Data residency, IP filtering, encryption keys, and workspace export.
|
||||
- [Data import, export, and migration](/administration-guide/manage/admin/migration) - Bulk import and export, database migration, and FIPS-compliant images.
|
||||
- [Product limits](/administration-guide/manage/product-limits) and [feature labels](/administration-guide/manage/feature-labels) - What each plan includes, and what a feature label means.
|
||||
|
||||
## Related
|
||||
|
||||
- [Backup and disaster recovery](/deployment-guide/backup-disaster-recovery) - Back up and restore a Mattermost deployment.
|
||||
- [Upgrade Mattermost Server](/administration-guide/upgrade/upgrade-index) - Upgrade, downgrade, and post-upgrade rollout.
|
||||
- [Secure Mattermost](/security-guide/secure-mattermost) - Harden your deployment.
|
||||
- [Monitor and troubleshoot](/administration-guide/manage/admin/monitoring-and-performance) - Metrics, health checks, support packets, and error codes.
|
||||
180
docs/main/administration-guide/manage/admin/user-attributes.mdx
Normal file
180
docs/main/administration-guide/manage/admin/user-attributes.mdx
Normal file
@@ -0,0 +1,180 @@
|
||||
---
|
||||
title: "User attributes"
|
||||
---
|
||||
import useBaseUrl from '@docusaurus/useBaseUrl';
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
<PlanAvailability slug="ent-plus" />
|
||||
|
||||
From Mattermost v10.8, ensure your teams always have the critical information they need to collaborate effectively by defining and managing organization-specific user profile attributes as system attributes that you can synchronize with your AD/LDAP or SAML identity provider.
|
||||
|
||||
System attributes enable you to customize user profile attributes to match your organization's unique needs and streamline collaboration while keeping user data centralized and consistent.
|
||||
|
||||
From Mattermost v11, you have enhanced control over these user attributes through admin-managed vs user-editable settings. By default, attributes are admin-managed for security, but you can explicitly allow user editing for specific attributes that don't impact access control or sensitive organizational data. These user attributes supplement existing user details visible from the user's profile picture.
|
||||
|
||||

|
||||
|
||||
## Before you begin
|
||||
|
||||
If you plan to synchronize system properties with your AD/LDAP or SAML identity provider, ensure AD/LDAP or SAML synchronization is already enabled and configured. See the [AD/LDAP groups](/administration-guide/onboard/ad-ldap-groups-synchronization) product documentation or [SAML 2.0](/administration-guide/configure/authentication-configuration-settings#saml-20) configuration settings documentation for details.
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="mattermost-v11-or-later" label="Mattermost v11 or later">
|
||||
|
||||
From Mattermost v11, user attributes have enhanced admin controls with a security-first approach. All attributes are admin-managed by default, providing better security and governance. System administrators can explicitly enable user editing for specific attributes through the System Console interface.
|
||||
|
||||
If your organization uses [attribute-based access control (ABAC)](/administration-guide/manage/admin/attribute-based-access-control), which requires an Enterprise Edition Advanced license, attributes used in access control policies should remain admin-managed for security reasons. You can enable user-managed attributes for ABAC by setting `EnableUserManagedAttributes` in `config.json`, or via an environment variable as noted below, but this should be done with caution:
|
||||
|
||||
- `config.json` setting: `".AccessControlSettings.EnableUserManagedAttributes: false",` with options `true` and `false`.
|
||||
- Environment variable: `MM_ACCESSCONTROLSETTINGS_ENABLEUSERMANAGEDATTRIBUTES`
|
||||
|
||||
This configuration setting isn't managed using the System Console, and is disabled by default to ensure that access control policies remain secure and can't be circumvented by users modifying their own profile attributes. Learn more about [admin-managed versus user-editable attributes](#admin-managed-vs-user-editable-attributes).
|
||||
|
||||
Additionally, from mobile app v2.31.0, user attributes are fully supported on mobile devices. Mobile users can both view and manage profile attributes (if allowed by admin settings) directly from the mobile app. Mobile attribute support requires the same server-side configuration, and no additional mobile-specific setup is required.
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="mattermost-v10-11-or-later" label="Mattermost v10.11 or later">
|
||||
|
||||
From Mattermost v10.11, user-managed attributes are excluded from ABAC rules for security reasons. If your organization uses ABAC (which requires Enterprise Edition Advanced), a system admin can explicitly enable user-managed attributes for ABAC by setting `EnableUserManagedAttributes` in `config.json` or via an environment variable as noted below. This configuration setting isn't managed using the System Console, and is disabled by default to ensure that access control policies remain secure and can't be circumvented by users modifying their own profile attributes.
|
||||
|
||||
- `config.json` setting: `".AccessControlSettings.EnableUserManagedAttributes: false",` with options `true` and `false`.
|
||||
- Environment variable: `MM_ACCESSCONTROLSETTINGS_ENABLEUSERMANAGEDATTRIBUTES`
|
||||
|
||||
Additionally, from mobile app v2.31.0, user attributes are fully supported on mobile devices. Mobile users can both view and manage profile attributes directly from the mobile app. Mobile attribute support requires the same server-side configuration, and no additional mobile-specific setup is required.
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="mattermost-v10-9-or-later" label="Mattermost v10.9 or later">
|
||||
|
||||
From Mattermost Enterprise v10.9, the ability to create and manage system properties as a Mattermost system admin requires no manual setup.
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="mattermost-v10-8" label="Mattermost v10.8">
|
||||
|
||||
You'll need Mattermost Enterprise v10.8 or later, and be a Mattermost system admin to enable the system properties feature flag, `MM_FEATUREFLAGS_CUSTOMPROFILEATTRIBUTES` to create and manage system properties. See the Mattermost developer documentation for details on [enabling feature flags in a self-hosted deployment](https://developers.mattermost.com/contribute/more-info/server/feature-flags/#self-hosted-and-local-development). Mattermost Cloud customers can request this feature flag be enabled by contacting their Mattermost Account Manager or by [creating a support ticket](https://support.mattermost.com/hc/en-us/requests/new?ticket_form_id=11184911962004) request.
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
## Admin-managed vs user-editable attributes
|
||||
|
||||
From Mattermost v11, system administrators have enhanced control over user attributes through admin-managed vs user-editable settings. This distinction provides better security and governance for organizational profile data.
|
||||
|
||||
**Admin-managed attributes** (default behavior):
|
||||
|
||||
- Controlled exclusively by system administrators
|
||||
- Users cannot edit these values in their profiles
|
||||
- Recommended for security-sensitive information like roles, clearance levels, or organizational identifiers
|
||||
- Ideal for attributes used in ABAC (Attribute-Based Access Control) policies
|
||||
- Values can only be updated by admins or through identity provider synchronization
|
||||
|
||||
**User-editable attributes**:
|
||||
|
||||
- Users can update these values in their own profiles
|
||||
- System administrators can still modify these attributes
|
||||
- Appropriate for non-sensitive information like personal preferences, skills, or contact details
|
||||
- Should not be used for attributes that impact security access controls
|
||||
|
||||
<Note>
|
||||
|
||||
For security reasons, attributes used in ABAC policies are admin-managed by default and cannot be edited by users unless explicitly enabled by a system administrator through the **Allow user editing** option.
|
||||
|
||||
</Note>
|
||||
|
||||
**Best practices:**
|
||||
|
||||
- Keep attributes that affect access control or contain sensitive organizational data as admin-managed
|
||||
- Only enable user editing for attributes that don't impact security policies
|
||||
- Regularly review user-editable attributes to ensure they remain appropriate for user management
|
||||
- Consider your organization's data governance requirements when determining attribute editability
|
||||
|
||||
## Add attributes
|
||||
|
||||
You can define and manage up to 20 system attributes using the System Console. Each attribute becomes a user profile option users can populate, unless you disable the **Editable by Users** option, available from Mattermost v11. Once you reach the maximum of 20 attributes, you can't create new attributes until you [delete attributes](#manage-attributes) you no longer need.
|
||||
|
||||
From Mattermost v11.8, user attributes include both a **Display Name** and a **Name**. The Display Name is the label shown to users and admins in Mattermost. The Name is the internal attribute identifier used in API references and [attribute-based access control (ABAC)](/administration-guide/manage/admin/attribute-based-access-control) policy expressions. When you create a new user attribute, Mattermost can generate the Name from the Display Name, formatted as a CEL-safe identifier. Saved ABAC policies continue to reference the internal name using `user.attributes.<name>`.
|
||||
|
||||
<Note>
|
||||
|
||||
When you disable the **Editable by Users** option for an attribute, only admins can set its value using [mmctl cpa](/administration-guide/manage/mmctl-command-line-tool#mmctl-cpa) commands.
|
||||
|
||||
</Note>
|
||||
|
||||
1. In the System Console, go to **Site Configuration \> System Attributes \> User Attributes** and select **Add Attribute**.
|
||||
|
||||
2. Enter the following details:
|
||||
|
||||
> - **Display Name**: Enter a display name for the attribute that will be shown in any user facing UI.
|
||||
> - **Attribute name**: Attribute name will be automatically generated from the provided Display Name. It can be overriden and with a preferred unique name for the attribute. Attribute names can be up to 40 characters long. The attribute name is used as the Common Expression Language (CEL) identifier in access control policies. It must start with a letter or underscore, and can contain only letters, numbers, and underscores. Reserved CEL words aren't allowed, including `true`, `false`, `null`, `in`, `as`, `break`, `const`, `continue`, `else`, `for`, `function`, `if`, `import`, `let`, `loop`, `package`, `namespace`, `return`, `var`, `void`, and `while`.
|
||||
> - **Type**: Specify the type of attribute as one of the following:
|
||||
> - **Text** for text-based profile attributes.
|
||||
> - **Phone** for phone number-based profile attributes.
|
||||
> - **URL** for web site address-based profile attributes.
|
||||
> - **Select** for a list of profile attribute values users can choose from. Specify each value followed by pressing **TAB** or **ENTER**. Values can be up to 64 characters long, and users can choose a single value.
|
||||
> - **Multi-select** for a list of profile attribute values users can select from. Specify each value followed by pressing **TAB** or **ENTER**. Values can be up to 64 characters long, and users can choose multiple values.
|
||||
> - **Ranked** for an ordered list of values, where each value ranks higher or lower than the others - for example, clearance or classification levels such as *Public*, *Secret*, and *Top Secret*. Specify each value, then order the values from lowest to highest rank. Users can choose a single value. Because the values are ordered, [access control policies](/administration-guide/manage/admin/abac-system-wide-policies) can compare a ranked attribute against a threshold - for example, clearance *is at least* Secret - rather than only checking for an exact match.
|
||||
|
||||
3. Specify the attribute's visibility as one of the following:
|
||||
|
||||
> - **Always show**: The attribute is always visible in user profiles.
|
||||
> - **Hide when empty**: The attribute is only visible in user profiles when it has a value.
|
||||
> - **Always hide**: The attribute is never visible in user profiles.
|
||||
|
||||
<Note>
|
||||
|
||||
If an attribute is created or updated without explicit visibility or sort order (for example via API or automation), Mattermost returns default values in responses even if those attributes weren't stored. Visibility defaults to the server's default visibility, and sort order defaults to `0`.
|
||||
|
||||
</Note>
|
||||
|
||||
4. Configure user editing permissions (Mattermost v11 or later) by enabling or disabling the **Editable by users** option.
|
||||
5. Save your changes.
|
||||
|
||||
<Tip>
|
||||
|
||||
Duplicate existing attributes by selecting **More** <img src={useBaseUrl('/img/ui/dots-horizontal_F01D8.svg')} alt="Use the More icon to access additional message options." className="theme-icon" /> and selecting **Duplicate attribute**. This creates a new attribute with the same name and type as the original attribute. You can then edit the new attribute to change its name, type, and visibility as needed.
|
||||
|
||||
</Tip>
|
||||
|
||||
## Manage attributes
|
||||
|
||||
- **Modify**: Select the attribute fields to make inline changes to the attribute's name, type, or values. Select **More** <img src={useBaseUrl('/img/ui/dots-horizontal_F01D8.svg')} alt="Use the More icon to access additional message options." className="theme-icon" /> to change a attribute's visibility.
|
||||
|
||||
<Note>
|
||||
|
||||
From Mattermost v11.8, existing user attributes are backfilled so the Display Name initially matches the Name. If the Display Name is empty or unavailable, Mattermost falls back to showing the Name. Duplicate display names are permitted, but internal names remain unique.
|
||||
|
||||
</Note>
|
||||
|
||||
- **Order**: Control the order you want attributes to appear in user profiles by dragging and dropping them in the list.
|
||||
- **Delete**: Delete attributes you no longer need or want by selecting **More** <img src={useBaseUrl('/img/ui/dots-horizontal_F01D8.svg')} alt="Use the More icon to access additional message options." className="theme-icon" /> and selecting **Delete property**.
|
||||
|
||||
<Note>
|
||||
|
||||
When updating user attributes via API or automation, the `attrs` object replaces existing attribute settings rather than merging. If you send only visibility, the sort order resets to `0` unless you include `sort_order` in the same request. If a patch fails, the API may return the error string "Unable to patch User Attribute field".
|
||||
|
||||
</Note>
|
||||
|
||||
- **User Edit Permissions**: From Mattermost v11, all user attributes are admin-managed by default for enhanced security. To allow user editing for specific attributes, administrators can enable this through the **More** <img src={useBaseUrl('/img/ui/dots-horizontal_F01D8.svg')} alt="Use the More icon to access additional message options." className="theme-icon" /> menu and selecting **Allow user editing**. This should only be enabled for attributes that do not impact security access controls or organizational policies. Attributes used in ABAC policies should remain admin-managed unless there's a specific business need and the security implications are fully understood.
|
||||
- **Edit User Attribute Values**: From Mattermost v11.1, you can view and update user attribute values for individual users through the System Console. See the [Manage user attributes](/administration-guide/configure/user-management-configuration-settings#manage-user-attributes) documentation for details.
|
||||
|
||||
In cases where multiple system admins manage system attributes, refresh your web browser instance to see real-time updates to system attributes made by other admins.
|
||||
|
||||
## Attribute access modes
|
||||
|
||||
Each user attribute has an **access mode** that controls who can see its values when those values appear in access control policies. The access mode is set per attribute and determines whether an admin editing a policy can see the raw attribute values referenced in its rules.
|
||||
|
||||
Access modes are not configurable through the System Console. They can only be set programmatically by a Mattermost plugin using the [Property Fields API](https://api.mattermost.com/#tag/properties). Attributes created by system admins through the System Console always use the `public` access mode. A plugin that needs to restrict attribute visibility must create the field with `protected: true` and set the desired `access_mode` — this is typically done by plugins that sync sensitive attributes from an external identity source and need to control which admins can read those values.
|
||||
|
||||
- **Public** (default): The attribute value is visible to all admins editing policies that reference it. No masking is applied.
|
||||
- **Shared only**: The attribute value is only visible to admins who personally hold that same value. Admins who don't hold the value see it masked (`--------`) in the policy editor.
|
||||
- **Source only**: The attribute value is only visible to the system source that set it (for example, the identity provider). All admins see it masked in the policy editor regardless of their own attribute values.
|
||||
|
||||
Masking in the policy editor only applies to attributes with `shared_only` or `source_only` access mode. See [Attribute value masking](/administration-guide/manage/admin/abac-system-wide-policies#attribute-value-masking) for the editor behavior when masked values are present.
|
||||
|
||||
## Sync attributes with your identity provider
|
||||
|
||||
1. Synchronize a attribute with AD/LDAP or SAML by selecting **More** <img src={useBaseUrl('/img/ui/dots-horizontal_F01D8.svg')} alt="Use the More icon to access additional message options." className="theme-icon" /> and selecting **Link attribute to AD/LDAP** or **Link attribute to SAML**. Mattermost takes you directly to the **AD/LDAP** or **SAML 2.0** configuration settings page in the System Console where you can map the attributes you want to synchronize.
|
||||
2. Scroll to the **User attributes sync** section to specify the attribute used to populate the attribute in user profiles.
|
||||
3. Specify the attribute mapping for the attribute by entering the attribute name in the system attribute's **Attribute** field. The attribute name must match the attribute name in your identity provider.
|
||||
4. Save your changes.
|
||||
@@ -0,0 +1,17 @@
|
||||
---
|
||||
title: "Access control"
|
||||
---
|
||||
Who can do what in a workspace that's already running: the roles and permissions you grant, the attributes you record about people, and the policies that decide which teams and channels they can reach.
|
||||
|
||||
- [Manage team and channel members](/administration-guide/manage/team-channel-members) - Add, remove, and change the roles of members.
|
||||
- [Advanced permissions](/administration-guide/onboard/advanced-permissions) - Customize what each role is allowed to do.
|
||||
- [Advanced permissions: backend infrastructure](/administration-guide/onboard/advanced-permissions-backend-infrastructure) - How the permissions system is structured.
|
||||
- [Delegated granular administration](/administration-guide/onboard/delegated-granular-administration) - Grant admin access to part of the System Console.
|
||||
- [Attribute-based access control](/administration-guide/manage/admin/attribute-based-access-control) - Grant access based on user attributes rather than membership lists.
|
||||
- [User attributes](/administration-guide/manage/admin/user-attributes) - Define the custom attributes that access rules are written against.
|
||||
- [System-wide attribute-based access policies](/administration-guide/manage/admin/abac-system-wide-policies) - Organization-wide policies System Admins assign to teams and channels.
|
||||
- [Team membership policies](/administration-guide/manage/admin/abac-team-membership) - Control who can join a team.
|
||||
- [Team channel policies](/administration-guide/manage/admin/abac-team-channel-policies) - Channel membership policies Team Admins manage from Team Settings.
|
||||
- [Channel-specific access rules](/administration-guide/manage/admin/abac-channel-access-rules) - Access rules Channel Admins manage from Channel Settings.
|
||||
|
||||
Setting up authentication and creating accounts in the first place is covered in [onboard users](/administration-guide/onboard/onboard-index), including [guest accounts](/administration-guide/onboard/guest-accounts).
|
||||
677
docs/main/administration-guide/manage/bulk-export-tool.mdx
Normal file
677
docs/main/administration-guide/manage/bulk-export-tool.mdx
Normal file
@@ -0,0 +1,677 @@
|
||||
---
|
||||
title: "Bulk export data"
|
||||
---
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
<PlanAvailability slug="all-commercial" />
|
||||
|
||||
Moving data from one Mattermost instance into another begins with exporting data to a [JSONL](https://jsonlines.org) file, in the same format used to [bulk import data](/administration-guide/onboard/bulk-loading-data). This is useful if you have created a server for a proof of concept, have created another server for production use, and now want to retain the history from the proof of concept instance.
|
||||
|
||||
You can export the following data types:
|
||||
|
||||
- Teams
|
||||
- Channels (public, private, and direct)
|
||||
- Messages (regular, non-reply, and direct messages)
|
||||
- Threaded discussions and message replies
|
||||
- Message reactions
|
||||
- Users
|
||||
- Users' preferences, including pinned and saved messages
|
||||
- Users' team memberships
|
||||
- Users' channel memberships
|
||||
- Users' notification preferences
|
||||
- Custom emoji
|
||||
- Direct message and group message channels, including read/unread status
|
||||
- Roles
|
||||
- Permissions schemes
|
||||
- Bot users
|
||||
|
||||
<Note>
|
||||
|
||||
Configuration for data types such as exporting specific areas of the server, exporting additional types of posts, file attachments, webhooks, and bot messages is not yet supported. Deleted objects are also not yet supported.
|
||||
|
||||
For requests to add additional attributes or objects to our exporter, please add a feature request on our [feature idea forum](https://portal.productboard.com/mattermost/33-what-matters-to-you).
|
||||
|
||||
</Note>
|
||||
|
||||
## Bulk export data
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="use-mmctl" label="Use mmctl">
|
||||
|
||||
1. Create a full export file including attachments by running the [mmctl export create -- attachments](/administration-guide/manage/mmctl-command-line-tool#mmctl-export-create) command. See the [Mattermost data migration](/administration-guide/manage/cloud-data-export#create-the-export) documentation for details.
|
||||
2. While the job is running, you can check its status by running the [mmctl export job show](/administration-guide/manage/mmctl-command-line-tool#mmctl-export-job-show) command.
|
||||
3. When the export job status is successful:
|
||||
|
||||
> 1. Identify the name of the completed export file by running the [mmctl export list](/administration-guide/manage/mmctl-command-line-tool#mmctl-export-list) command.
|
||||
> 2. Download the export file to your local machine by running the [mmctl export download](/administration-guide/manage/mmctl-command-line-tool#mmctl-export-download) command.
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="use-cli" label="Use CLI">
|
||||
|
||||
<Note>
|
||||
|
||||
From Mattermost v6.0, this command has been deprecated in favor of [mmctl export commands](/administration-guide/manage/mmctl-command-line-tool#mmctl-export) as the supported way to export data out of Mattermost.
|
||||
|
||||
</Note>
|
||||
|
||||
The export command runs in the [CLI](/administration-guide/manage/command-line-tools). It has permissions to access all information in the Mattermost database.
|
||||
|
||||
To run the export command:
|
||||
|
||||
1. Navigate to the directory where the Mattermost server is installed. On a default install of Mattermost, the directory is `/opt/mattermost`.
|
||||
|
||||
2. Run the following command to extract data from all teams on the server. Note that you can change the file name and specify an absolute or relative path to dictate where the file is exported:
|
||||
|
||||
`sudo -u mattermost bin/mattermost export bulk file.json --all-teams`
|
||||
|
||||
`sudo -u mattermost bin/mattermost export bulk /home/user/bulk_data.json --all-teams`
|
||||
|
||||
3. Retrieve your file from the location you specified.
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
All Mattermost bulk export data files will begin with a `Version` object as the first line of the file. This indicates the version of the Mattermost bulk import file format with which the exported data is compatible.
|
||||
|
||||
## Version object
|
||||
|
||||
<table width="100%" border="1" cellpadding="5px" style={{marginBottom: '20px'}}>
|
||||
<tr class="row-odd">
|
||||
<th class="head">Field name</th>
|
||||
<th class="head">Type</th>
|
||||
<th class="head">Description</th>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">type</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>The string "version"</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">version</td>
|
||||
<td valign="middle">number</td>
|
||||
<td>The number 1.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">info</td>
|
||||
<td valign="middle">object</td>
|
||||
<td>Optional VersionInfo object</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
## VersionInfo object
|
||||
|
||||
<table width="100%" border="1" cellpadding="5px" style={{marginBottom: '20px'}}>
|
||||
<tr class="row-odd">
|
||||
<th class="head">Field name</th>
|
||||
<th class="head">Type</th>
|
||||
<th class="head">Description</th>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">generator</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>The name of the tool this export was generated with. Well known tools are:<br /> <kbd>"mattermost-server"</kbd> for the Mattermost Server.<br /> <kbd>"mmetl"</kbd> for the Slack export converter "mmetl".</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">version</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>The version of the tool this export was generated with. This may contain multiple pieces of version info, separated by spaces. The first one should be a semantic version.<br /> <kbd>"7.6.0 (29bb1e53ef5a439c73065f47de2972f9bbcb09a4, enterprise: true)"</kbd> is an example of such a version string.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">created</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>The timestamp of the file creation. This should be formatted as an RFC 3339 timestamp. The nanosecond part is optional.<br /> <kbd>"2022-11-22T16:40:51.019582328+01:00"</kbd></td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">additional</td>
|
||||
<td valign="middle">any</td>
|
||||
<td>Any additional information the generator wants to include into the file header. May be omitted. Be aware that the size of each line is limited to a few MiB.</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
## Team object
|
||||
|
||||
<table width="100%" border="1" cellpadding="5px" style={{marginBottom: '20px'}}>
|
||||
<tr class="row-odd">
|
||||
<th class="head">Field name</th>
|
||||
<th class="head">Type</th>
|
||||
<th class="head">Description</th>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">name</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>The team name.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">display_name</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>The display name for the team.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">type</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>The type of team. Will have one of the following values:<br /> <kbd>"O"</kbd> for an open team<br /> <kbd>"I"</kbd> for an invite-only team.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">description</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>The team description.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">allow_open_invite</td>
|
||||
<td valign="middle">bool</td>
|
||||
<td>Whether to allow open invitations. Will have one of the following values:<br /> <kbd>"true"</kbd><br /> <kbd>"false"</kbd></td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">scheme</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>The name of the permissions scheme that applies to this team.</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
## Channel object
|
||||
|
||||
<table width="100%" border="1" cellpadding="5px" style={{marginBottom: '20px'}}>
|
||||
<tr class="row-odd">
|
||||
<th class="head">Field name</th>
|
||||
<th class="head">Type</th>
|
||||
<th class="head">Description</th>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">team</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>The name of the team this channel belongs to.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">name</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>The name of the channel.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">display_name</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>The display name for the channel.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">type</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>The type of channel. Will have one the following values:<br /> <kbd>"O"</kbd> for a public channel.<br /> <kbd>"P"</kbd> for a private channel.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">header</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>The channel header.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">purpose</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>The channel purpose.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">scheme</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>The name of the permissions scheme that applies to this team.</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
## User object
|
||||
|
||||
<table width="100%" border="1" cellpadding="5px" style={{marginBottom: '20px'}}>
|
||||
<tr class="row-odd">
|
||||
<th class="head">Field name</th>
|
||||
<th class="head">Type</th>
|
||||
<th class="head">Description</th>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">username</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>The user’s username. This is the unique identifier for the user.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">email</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>The user’s email address.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">auth_service</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>The authentication service used for this user account. This field will be absent for user/password authentication.<br /> <kbd>"gitlab"</kbd> - GitLab authentication.<br /> <kbd>"ldap"</kbd> - LDAP authentication (Enterprise and Professional)<br /> <kbd>"saml"</kbd> - Generic SAML based authentication (Enterprise)<br /> <kbd>"google"</kbd> - Google OAuth authentication (Enterprise)<br /> <kbd>"entra id"</kbd> - Microsoft Entra ID OAuth Authentication (Enterprise)</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">auth_data</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>The authentication data if <kbd>auth_service</kbd> is used. The value depends on the <kbd>auth_service</kbd> that is specified.<br /> The data comes from the following fields for the respective auth_services:<br /> <kbd>"gitlab"</kbd> - The value of the Id attribute provided in the GitLab auth data.<br /> <kbd>"ldap"</kbd> - The value of the LDAP attribute specified as the "ID Attribute" in the Mattermost LDAP configuration.<br /> <kbd>"saml"</kbd> - The value of the SAML email address attribute.<br /> <kbd>"google"</kbd> - The value of the OAuth Id attribute.<br /> <kbd>"office365"</kbd> - The value of the OAuth Id attribute.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">nickname</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>The user’s nickname.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">first_name</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>The user’s first name.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">last_name</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>The user’s last name.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">position</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>The user’s position.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">roles</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>The user’s roles. </td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">locale</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>The user’s localization configuration.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">use_markdown_preview</td>
|
||||
<td valign="middle">bool</td>
|
||||
<td><kbd>"true"</kbd> if the user has enabled markdown preview in the message input box.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">use_formatting</td>
|
||||
<td valign="middle">bool</td>
|
||||
<td><kbd>"true"</kbd> if the user has enabled post formatting for links, emoji, text styles, and line breaks.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">show_unread_section</td>
|
||||
<td valign="middle">string</td>
|
||||
<td><kbd>"true"</kbd> if the user has enabled showing unread messages at top of channel sidebar.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">theme</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>The user’s theme. Formatted as a Mattermost theme string.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">military_time</td>
|
||||
<td valign="middle">string</td>
|
||||
<td><kbd>"true"</kbd> if the user has enabled a 24-hour clock. <kbd>"false"</kbd> if using a 12-hour clock.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">collapse_previews</td>
|
||||
<td valign="middle">string</td>
|
||||
<td><kbd>"true"</kbd> if user collapses link preview by default. <kbd>"false"</kbd> if user expands link previews by default.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">message_display</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>The style the user prefers for displayed messages. Options are <kbd>"clean"</kbd> if the user uses the standard style or <kbd>"compact"</kbd> if the user uses compact style.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">channel_display_mode</td>
|
||||
<td valign="middle">string</td>
|
||||
<td><kbd>"full"</kbd> if the users displays channel messages at the full width of the screen or <kbd>"centered"</kbd> if the user uses a fixed width, centered block.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">tutorial_step</td>
|
||||
<td valign="middle">string</td>
|
||||
<td><kbd>"1"</kbd>, <kbd>"2"</kbd>, or <kbd>"3"</kbd> indicates which specified tutorial step to start with for the user. <kbd>"999"</kbd> skips the tutorial.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">email_interval</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>Email batching interval to use during bulk import. </td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">delete_at</td>
|
||||
<td valign="middle">int64</td>
|
||||
<td>Timestamp of when the user was deactivated.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">teams</td>
|
||||
<td valign="middle">array</td>
|
||||
<td>The teams which the user is member of. Is an array of <b>UserTeamMembership</b> objects.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">notify_props</td>
|
||||
<td valign="middle">object</td>
|
||||
<td>The user’s notify preferences, as defined by the <b>UserNotifyProps</b> object.</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
## UserNotifyProps object
|
||||
|
||||
This object is a member of the User object.
|
||||
|
||||
<table width="100%" border="1" cellpadding="5px" style={{marginBottom: '20px'}}>
|
||||
<tr class="row-odd">
|
||||
<th class="head">Field name</th>
|
||||
<th class="head">Type</th>
|
||||
<th class="head">Description</th>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">desktop</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>Preference for sending desktop notifications. Will be one of the following values:<br /> <kbd>"all"</kbd> - For all activity.<br /> <kbd>"mention"</kbd> - Only for mentions.<br /> <kbd>"none"</kbd> - Never.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">desktop_sound</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>Preference for whether desktop notification sound is played. Will be one of the following values:<br /> <kbd>"true"</kbd> - Sound is played.<br /> <kbd>"false"</kbd> - Sound is not played.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">email</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>Preference for email notifications. Will be one of the following values:<br /> <kbd>"true"</kbd> - Email notifications are sent immediately.<br /> <kbd>"false"</kbd> - Email notifications are not sent.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">mobile</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>Preference for sending mobile push notifications. Will be one of the following values:<br /> <kbd>"all"</kbd> - For all activity.<br /> <kbd>"mention"</kbd> - Only for mentions.<br /> <kbd>"none"</kbd> - Never.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">mobile_push_status</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>Preference for when push notifications are triggered. Will be one of the following values:<br /> <kbd>"online"</kbd> - When online, away or offline.<br /> <kbd>"away"</kbd> - When away or offline.<br /> <kbd>"offline"</kbd> - When offline.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">channel</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>Preference for whether @all, @channel, and @here trigger mentions. Will be one of the following values:<br /> <kbd>"true"</kbd> - Mentions are triggered.<br /> <kbd>"false"</kbd> - Mentions are not triggered.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">comments</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>Preference for reply mention notifications. Will be one of the following values:<br /> <kbd>"any"</kbd> - Trigger notifications on messages in reply threads that the user starts or participates in.<br /> <kbd>"root"</kbd> - Trigger notifications on messages in threads that the user starts.<br /> <kbd>"never"</kbd> - Do not trigger notifications on messages in reply threads unless the user is mentioned.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">mention_keys</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>Preference for custom non-case sensitive words that trigger mentions. Words are separated by commas.</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
## UserTeamMembership object
|
||||
|
||||
<table width="100%" border="1" cellpadding="5px" style={{marginBottom: '20px'}}>
|
||||
<tr class="row-odd">
|
||||
<th class="head">Field name</th>
|
||||
<th class="head">Type</th>
|
||||
<th class="head">Description</th>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">name</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>The name of the team this user is a member of.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">roles</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>The roles the user has within this team. </td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">theme</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>The user’s theme for this team. Formatted as a Mattermost theme string.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">channels</td>
|
||||
<td valign="middle">array</td>
|
||||
<td>The channels within this team that the user is a member of. Listed as an array of <b>UserChannelMembership</b> objects.</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
## UserChannelMembership object
|
||||
|
||||
<table width="100%" border="1" cellpadding="5px" style={{marginBottom: '20px'}}>
|
||||
<tr class="row-odd">
|
||||
<th class="head">Field name</th>
|
||||
<th class="head">Type</th>
|
||||
<th class="head">Description</th>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">name</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>The name of the channel in the parent team that this user is a member of.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">roles</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>The roles the user has within this channel. </td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">notify_props</td>
|
||||
<td valign="middle">object</td>
|
||||
<td>The notify preferences for this user in this channel as defined by the <b>ChannelNotifyProps</b> object.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">favorite</td>
|
||||
<td valign="middle">boolean</td>
|
||||
<td>Whether the channel is marked as a favorite for this user. Will be one of the following values:<br /> <kbd>"true"</kbd> - Yes.<br /> <kbd>"false"</kbd> - No.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">mention_count</td>
|
||||
<td valign="middle">int64</td>
|
||||
<td>The mention preferences for this user in this channel as defined by the <b>ChannelMentionCount</b> object.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">mention_count_root</td>
|
||||
<td valign="middle">int64</td>
|
||||
<td>The mention preferences for this user in this channel as defined by the <b>ChannelMentionCountRoot</b> object.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">urgent_mention_count</td>
|
||||
<td valign="middle">int64</td>
|
||||
<td>The mention preferences for this user in this channel as defined by the <b>UrgendMentionCount</b> object.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">msg_count</td>
|
||||
<td valign="middle">int64</td>
|
||||
<td>The mention preferences for this user in this channel as defined by the <b>MsgCount</b> object.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">msg_count_root</td>
|
||||
<td valign="middle">int64</td>
|
||||
<td>The mention preferences for this user in this channel as defined by the <b>MsgCountRoot</b> object.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">last_viewed_at</td>
|
||||
<td valign="middle">int64</td>
|
||||
<td>The mention preferences for this user in this channel as defined by the <b>LastViewedAt</b> object.</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
### ChannelNotifyProps object
|
||||
|
||||
This object is a member of the ChannelMembership object.
|
||||
|
||||
<table width="100%" border="1" cellpadding="5px" style={{marginBottom: '20px'}}>
|
||||
<tr class="row-odd">
|
||||
<th class="head">Field name</th>
|
||||
<th class="head">Type</th>
|
||||
<th class="head">Description</th>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">desktop</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>Preference for sending desktop notifications. Will be one of the following values:<br /> <kbd>"default"</kbd> - Global default.<br /> <kbd>"all"</kbd> - For all activity.<br /> <kbd>"mention"</kbd> - Only for mentions.<br /> <kbd>"none"</kbd> - Never.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">mobile</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>Preference for sending mobile notifications. Will be one of the following values:<br /> <kbd>"default"</kbd> - Global default.<br /> <kbd>"all"</kbd> - For all activity.<br /> <kbd>"mention"</kbd> - Only for mentions.<br /> <kbd>"none"</kbd> - Never.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">mark_unread</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>Preference for marking channel as unread. Will be one of the following values:<br /> <kbd>"all"</kbd> - For all unread messages.<br /> <kbd>"mention"</kbd> - Only for mentions.</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
## Post object
|
||||
|
||||
<table width="100%" border="1" cellpadding="5px" style={{marginBottom: '20px'}}>
|
||||
<tr class="row-odd">
|
||||
<th class="head">Field name</th>
|
||||
<th class="head">Type</th>
|
||||
<th class="head">Description</th>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">team</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>The name of the team that this post is in.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">channel</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>The name of the channel that this post is in.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">user</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>The username of the user for this post.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">message</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>The message that the post contains.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">props</td>
|
||||
<td valign="middle">object</td>
|
||||
<td>The props for a post. Contains additional formatting information used by integrations and bot posts. For a more detailed explanation see the <a href="https://docs.mattermost.com/developer/message-attachments.html">message attachments documentation</a>.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">create_at</td>
|
||||
<td valign="middle">int</td>
|
||||
<td>The timestamp for the post, in milliseconds since the Unix epoch.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">reactions</td>
|
||||
<td valign="middle">array</td>
|
||||
<td>The emoji reactions to this post. Will be an array of Reaction objects.</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
## Reply object
|
||||
|
||||
<table width="100%" border="1" cellpadding="5px" style={{marginBottom: '20px'}}>
|
||||
<tr class="row-odd">
|
||||
<th class="head">Field name</th>
|
||||
<th class="head">Type</th>
|
||||
<th class="head">Description</th>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">user</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>The username of the user for this reply.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">message</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>The message that the reply contains.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">create_at</td>
|
||||
<td valign="middle">int</td>
|
||||
<td>The timestamp for the reply, in milliseconds since the Unix epoch.</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
## Reaction object
|
||||
|
||||
This object is a member of the Post object.
|
||||
|
||||
<table width="100%" border="1" cellpadding="5px" style={{marginBottom: '20px'}}>
|
||||
<tr class="row-odd">
|
||||
<th class="head">Field name</th>
|
||||
<th class="head">Type</th>
|
||||
<th class="head">Description</th>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">user</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>The username of the user for this reply.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">emoji_name</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>The emoji of the reaction.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">create_at</td>
|
||||
<td valign="middle">int</td>
|
||||
<td>The timestamp for the reply, in milliseconds since the Unix epoch.</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
## Emoji object
|
||||
|
||||
<table width="100%" border="1" cellpadding="5px" style={{marginBottom: '20px'}}>
|
||||
<tr class="row-odd">
|
||||
<th class="head">Field name</th>
|
||||
<th class="head">Type</th>
|
||||
<th class="head">Description</th>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">name</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>The emoji name.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">image</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>The path (either absolute or relative to the current working directory) to the image file for this emoji.</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
## DirectChannel object
|
||||
|
||||
<table width="100%" border="1" cellpadding="5px" style={{marginBottom: '20px'}}>
|
||||
<tr class="row-odd">
|
||||
<th class="head">Field name</th>
|
||||
<th class="head">Type</th>
|
||||
<th class="head">Description</th>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">members</td>
|
||||
<td valign="middle">array</td>
|
||||
<td>List of channel members.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">favorited_by</td>
|
||||
<td valign="middle">array</td>
|
||||
<td>List of channel members who have favorited the direct channel.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">header</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>The channel header.</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
## DirectPost object
|
||||
|
||||
<table width="100%" border="1" cellpadding="5px" style={{marginBottom: '20px'}}>
|
||||
<tr class="row-odd">
|
||||
<th class="head">Field name</th>
|
||||
<th class="head">Type</th>
|
||||
<th class="head">Description</th>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">user</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>The username of the user for this post.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">message</td>
|
||||
<td valign="middle">string</td>
|
||||
<td>The message that the post contains.</td>
|
||||
</tr>
|
||||
<tr class="row-odd">
|
||||
<td valign="middle">create_at</td>
|
||||
<td valign="middle">int</td>
|
||||
<td>The timestamp for the post, in milliseconds since the Unix epoch.</td>
|
||||
</tr>
|
||||
</table>
|
||||
76
docs/main/administration-guide/manage/cloud-byok.mdx
Normal file
76
docs/main/administration-guide/manage/cloud-byok.mdx
Normal file
@@ -0,0 +1,76 @@
|
||||
---
|
||||
title: "Cloud Dedicated Bring Your Own Key"
|
||||
---
|
||||
Bring Your Own Key (BYOK) provides Enterprise Cloud customers with autonomy over their encryption key life cycle. BYOK supports encryption at rest with custom KMS keys that the enterprise provides and maintains.
|
||||
|
||||
**BYOK requires a subscription to Mattermost Cloud Enterprise Dedicated**, which offers enhanced data security and compliance by ensuring that enterprises have full control over their data encryption processes.
|
||||
|
||||
In Mattermost Cloud Enterprise Dedicated, you can use KMS keys in 2 ways:
|
||||
|
||||
- One KMS key for all services; or,
|
||||
|
||||
- Per-service KMS keys (EBS, RDS, S3)
|
||||
- Keys do not need to be unique to each service.
|
||||
- All services must be encrypted at rest.
|
||||
- Selective enablement of this feature can be supported.
|
||||
- In cases where a global database is needed, we recommend providing 2 KMS keys (1 per region).
|
||||
|
||||
## Configure BYOK
|
||||
|
||||
1. Enterprise customer provides their AWS KMS ARN to the Mattermost Infrastructure SRE team.
|
||||
2. Enterprise customer adds the following blocks to their KMS Policy for the AWS KMS ARN provided:
|
||||
|
||||
``` json
|
||||
{
|
||||
"Sid": "Allow use of the key",
|
||||
"Effect": "Allow",
|
||||
"Principal": {
|
||||
"AWS": "arn:aws:iam::<MATTERMOST_AWS_ACCOUNT_ID>:user/mattermost-cloud-<environment>-provisioning-<VPC_ID>"
|
||||
},
|
||||
"Action": [
|
||||
"kms:Encrypt",
|
||||
"kms:Decrypt",
|
||||
"kms:ReEncrypt*",
|
||||
"kms:GenerateDataKey*",
|
||||
"kms:DescribeKey"
|
||||
],
|
||||
"Resource": "<CUSTOM_CUSTOMER_KMS_ID>"
|
||||
},
|
||||
{
|
||||
"Sid": "Allow use of the key role nodes",
|
||||
"Effect": "Allow",
|
||||
"Principal": {
|
||||
"AWS": "arn:aws:iam::<MATTERMOST_AWS_ACCOUNT_ID>:role/nodes.<CLUSTER_ID>-kops.k8s.local"
|
||||
},
|
||||
"Action": [
|
||||
"kms:Encrypt",
|
||||
"kms:Decrypt",
|
||||
"kms:ReEncrypt*",
|
||||
"kms:GenerateDataKey*",
|
||||
"kms:DescribeKey"
|
||||
],
|
||||
"Resource": "<CUSTOM_CUSTOMER_KMS_ID>"
|
||||
},
|
||||
```
|
||||
|
||||
3. The Mattermost Infrastructure SRE team updates the kops cluster and S3, RDS resources after the KMS policy is updated on the customer's end.
|
||||
|
||||
Alternatively, the Enterprise customer can provide an external key (non-KMS) to the Mattermost Infrastructure SRE team that Mattermost maintains on behalf of the customer. This path offers less control to customers but simplifies the setup process.
|
||||
|
||||
### Requirements
|
||||
|
||||
- Customers must own their AWS Account. (In the alternative path mentioned above this is delegated to Mattermost.)
|
||||
- Customers oversee the maintenance life cycle of their custom KMS key.
|
||||
- A valid AWS KMS ARN for encrypting storage and databases should be provided to the Infrastructure SRE team.
|
||||
- The customer should incorporate the provided policy blocks from the Infrastructure SRE team into their KMS key policy.
|
||||
|
||||
### Considerations
|
||||
|
||||
- Changing the AWS KMS key in the database necessitates downtime due to AWS Aurora's encryption [limitations.](https://repost.aws/knowledge-center/update-encryption-key-rds)
|
||||
- Proper communication is essential for setting expectations and scheduling changes.
|
||||
|
||||
## Conclusion
|
||||
|
||||
If you are a large enterprise with compliance requirements, or are working in highly-regulated industries, using Mattermost Cloud Dedicated with BYOK ensures full data control.
|
||||
|
||||
For any further assistance or queries, talk to a [Mattermost Expert](https://mattermost.com/contact-sales/)
|
||||
377
docs/main/administration-guide/manage/cloud-data-export.mdx
Normal file
377
docs/main/administration-guide/manage/cloud-data-export.mdx
Normal file
@@ -0,0 +1,377 @@
|
||||
---
|
||||
title: "Migrate between self-hosted and Cloud"
|
||||
---
|
||||
This document outlines the process for migrating an existing Mattermost instance [from self-hosted to Cloud](#migrate-from-self-hosted-to-cloud), and [from Cloud to self-hosted](#migrate-from-cloud-to-self-hosted).
|
||||
|
||||
<Note>
|
||||
|
||||
Migrating an existing Mattermost instance to another using the same deployment method follows the same process that's documented below, regardless as to whether the source or destination of the migration is in the Cloud or self-hosted. **These steps will work for both Cloud and self-hosted Mattermost instances**.
|
||||
|
||||
</Note>
|
||||
|
||||
## Migrate from self-hosted to Cloud
|
||||
|
||||
When you migrate from self-hosted to Cloud, you'll need to open a ticket with the Mattermost Support team so they can assist you with the process. The information below describes the migration process. Before you get started, visit our [Support site](https://support.mattermost.com/hc/en-us/requests/new) to open a ticket.
|
||||
|
||||
<Important>
|
||||
|
||||
- This migration process is only available to customers using paid Mattermost editions.
|
||||
- We recommend reviewing the knowledge base article on [migrating from self-hosted to Cloud](https://support.mattermost.com/hc/en-us/articles/4412503667604-Migrating-from-Self-hosted-Mattermost-Instance-to-Cloud-Mattermost-Instance) before starting a migration to familiarize yourself with key considerations, required prerequisites, and our guidance on testing your export.
|
||||
|
||||
</Important>
|
||||
|
||||
Before you begin your migration, take note of the following information before you begin:
|
||||
|
||||
**User Authentication**
|
||||
|
||||
If you are using the email login method, users will need to reset their passwords after the migration has been completed. Other authentication methods, such as LDAP and GitLab SSO, required changes to your infrastructure allowing the specific authentication method to function in Mattermost cloud.
|
||||
|
||||
**Plugins**
|
||||
|
||||
If you’re using plugins that aren’t listed on the Marketplace, they won’t be included in the export and you won’t have access to them going forward. See the list of supported plugins by visiting the [integrations overview](/integrations-guide/integrations-guide-index#plugins) documentation.
|
||||
|
||||
**Data**
|
||||
|
||||
The migration only includes data from Channels. No Playbooks data is exported.
|
||||
|
||||
### Migration process
|
||||
|
||||
**Export from your self-hosted instance**
|
||||
|
||||
Use your administrator credentials to log into your self-hosted Mattermost server. Once you're logged in, run:
|
||||
|
||||
```
|
||||
mmctl export create --attachments
|
||||
```
|
||||
|
||||
This creates a full export of the server, and includes attached files. If you don’t want to export attached files, leave out `--attachments`.
|
||||
|
||||
This process can take some time, so `mmctl` will return immediately, and the job will run in the background until the export is fully created. If successful, the command will immediately output a job ID, like this:
|
||||
|
||||
```
|
||||
Export process job successfully created, ID: yfrr9ku5i7fjubeshs1ksrknzc
|
||||
```
|
||||
|
||||
While the job is running, its status can be checked using the ID that was provided when it was created, and when it's done the output will look similar to this:
|
||||
|
||||
```
|
||||
mmctl export job show yfrr9ku5i7fjubeshs1ksrknzc
|
||||
ID: yfrr9ku5i7fjubeshs1ksrknzc
|
||||
Status: success
|
||||
Created: 2021-11-03 10:44:13 -0500 CDT
|
||||
Started: 2021-11-03 10:44:23 -0500 CDT
|
||||
```
|
||||
|
||||
The completed file will be downloaded to your desktop as a `.zip` file.
|
||||
|
||||
<Note>
|
||||
|
||||
Do not rename the file as the file name is referenced in log files, which are used by the Support team to validate the exported file.
|
||||
|
||||
</Note>
|
||||
|
||||
The Support team will provide you with S3 credentials so you can upload the exported file. Once you’ve uploaded the file, please contact the Support team and let them know.
|
||||
|
||||
### Create a new workspace on the Mattermost Cloud
|
||||
|
||||
In the meantime, you can log into Mattermost Cloud with your Mattermost credentials and create a Cloud workspace.
|
||||
|
||||
<Note>
|
||||
|
||||
Do not create any users in your Mattermost Cloud instance as the migration process performs this task for you.
|
||||
|
||||
</Note>
|
||||
|
||||
### Importing your data into your Mattermost Cloud instance
|
||||
|
||||
Once the export upload to the provided S3 bucket is complete and you’ve shared your Mattermost Cloud instance name/URL, Support can begin the import step.
|
||||
|
||||
Depending on the size of the export this process can take some time. Support will contact you as soon as the import is complete. During this time it is highly recommended you do not use your Mattermost Cloud instance.
|
||||
|
||||
### Start using your Mattermost Cloud instance
|
||||
|
||||
When the export is complete, you can log into your Cloud instance and can invite your users to log in.
|
||||
|
||||
<Note>
|
||||
|
||||
We recommend that you keep your self-hosted Mattermost server until you’ve been using your Cloud instance for a while and all is verified as is as expected.
|
||||
|
||||
</Note>
|
||||
|
||||
## Migrate from Cloud to self-hosted
|
||||
|
||||
You can migrate your Cloud workspace data to a self-hosted deployment at any time.
|
||||
|
||||
### How does the process work?
|
||||
|
||||
Before you export and migrate your data, you must [install Mattermost](/deployment-guide/deployment-guide-index) on the server you’ll be using to run Mattermost. The migration is done using the mmctl CLI tool, which is a remote CLI tool for Mattermost that's installed locally and uses the Mattermost API. `mmctl` is pre-installed.
|
||||
|
||||
The [mmctl usage notes](/administration-guide/manage/mmctl-command-line-tool#mmctl-usage-notes) provide some additional context and information which you can reference before and during the process.
|
||||
|
||||
You'll be using the [mmctl export](/administration-guide/manage/mmctl-command-line-tool#mmctl-export) commands to export your Cloud data for channels, messages, users, etc. The export file is downloaded to a location specified in the export commands. Once the export is complete, you'll import the data into your self-hosted instance.
|
||||
|
||||
Alternatively, you can export the data to an Amazon S3 cloud storage location in cases where an export is quite large and challenging to download from the Mattermost server. See the [create the export](#create-the-export) section below for details.
|
||||
|
||||
<Note>
|
||||
|
||||
Prior to migrating your data from Cloud, please ensure you have the appropriate permissions within your organization to carry out the data export which may contain sensitive information. Mattermost is not liable for any actions taken after the data export.
|
||||
|
||||
Moreover, the export process doesn’t include integrations or any custom data. Other aspects of your instance, such as specific security settings and requirements, are also not included. For assistance with migrating additional data and settings, see our support options: [https://mattermost.com/support/](https://mattermost.com/support/).
|
||||
|
||||
</Note>
|
||||
|
||||
Once `mmctl` is authenticated, you can generate the export from the source instance.
|
||||
|
||||
## Authenticate
|
||||
|
||||
Authentication is done with either Mattermost login credentials or an authentication token. First, use your administrator credentials to log into the instance with mmctl, replacing <code>example-source-domain.com</code> with the network address of the source instance:
|
||||
|
||||
```
|
||||
mmctl auth login https://yourdomain.cloud.mattermost.com
|
||||
```
|
||||
|
||||
You'll be prompted for a username (use your admin user), password, and for a connection name. The connection name can be anything you want, and it's used to identify this set of credentials in the future, for your convenience. Then you will be able to start the export process.
|
||||
|
||||
## Create the export
|
||||
|
||||
<Important>
|
||||
|
||||
If your Mattermost Cloud deployment includes plugins that aren't listed on the Cloud Marketplace, those plugins won't be included in the export, and you won't have access to those plugins going forward. See the [integrations](/integrations-guide/integrations-guide-index#plugins) documentation for a list of Cloud-supported integrations.
|
||||
|
||||
</Important>
|
||||
|
||||
Once you're logged in, run the following `mmctl` command:
|
||||
|
||||
```
|
||||
mmctl export create
|
||||
```
|
||||
|
||||
Running this command creates a full export of the server, including attached files. Append `--no-attachments` if you do not wish to export attached files from your instance, and append `--with-archived-channels` to include archived channels in the export file. This process can take some time, so `mmctl` will return immediately, and the job will run in the background on the Mattermost instance until the export is fully created. If successful, the command will immediately output a job ID, like this:
|
||||
|
||||
```
|
||||
Export process job successfully created, ID: yfrr9ku5i7fjubeshs1ksrknzc
|
||||
```
|
||||
|
||||
While the job is running, its status can be checked using the ID that was provided when it was created, and when it's done the output will look similar to this:
|
||||
|
||||
```
|
||||
mmctl export job show yfrr9ku5i7fjubeshs1ksrknzc
|
||||
ID: yfrr9ku5i7fjubeshs1ksrknzc
|
||||
Status: success
|
||||
Created: 2021-11-03 10:44:13 -0500 CDT
|
||||
Started: 2021-11-03 10:44:23 -0500 CDT
|
||||
```
|
||||
|
||||
Once the status is `success`, download the export onto your local machine. First, discover the name of the completed export file with `mmctl export list`:
|
||||
|
||||
```
|
||||
mmctl export list
|
||||
r3kcj8yuwbramdt714doafi3oo_export.zip
|
||||
```
|
||||
|
||||
This will show all of the exports on the server, so be sure to download the latest one and to delete it when you're done to save storage. Generate a link to download the file with a command like the following, but with the filename of the export on your server:
|
||||
|
||||
```
|
||||
mmctl export generate-presigned-url r3kcj8yuwbramdt714doafi3oo_export.zip
|
||||
```
|
||||
|
||||
<Tip>
|
||||
|
||||
- As an alternative to this last step, from your Mattermost Cloud web instance, you can retrieve the file download link to the export by using the Mattermost slash command `/exportlink [job-id|zip file|latest]`. Use the `latest` option to automatically pull the latest export available, or specify the download link by `job-id` or `zip file`.
|
||||
- Mattermost v8.1.0-RC1 is required to use the `mmctl export generate-presigned-url` command on a self-hosted Mattermost instance. Access the [Mattermost Enterprise v8.1.0-RC1 binary](https://releases.mattermost.com/8.1.0-rc1/mattermost-enterprise-8.1.0-rc1-linux-amd64.tar.gz) or the [Mattermost Team Edition v8.1.0-RC1 binary](https://releases.mattermost.com/8.1.0-rc1/mattermost-team-8.1.0-rc1-linux-amd64.tar.gz).
|
||||
|
||||
</Tip>
|
||||
|
||||
## Upload the export to the new server
|
||||
|
||||
Finally, it's time to take our export from the source server and use it as an import into the destination server. Before proceeding, review and modify the following self-hosted Mattermost configuration settings, where applicable, to ensure a smooth and successful import.
|
||||
|
||||
<table style={{width: '100%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '39%'}} />
|
||||
<col style={{width: '51%'}} />
|
||||
<col style={{width: '8%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><strong>Mattermost configuration setting</strong></td>
|
||||
<td><strong>Large file import recommendation</strong></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan="3"><a href="/administration-guide/configure/site-configuration-settings#max-users-per-team">Maximum Users Per Team | Increase this value to a number that **exceeds** the maximum number of users, per team, in the import file. |</a> |</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan="3"><a href="/administration-guide/configure/environment-configuration-settings#maximum-file-size">Maximum File Size | Temporarily increase this value to be **larger** than the size of the import file. |</a> | Following a successful import, we strongly recommend reverting this value to a reasonable limit for daily expected usage. |</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan="3"><dl>
|
||||
<dt><a href="/administration-guide/configure/environment-configuration-settings#write-timeout">Write Timeout | Temporarily adjust this value based on import file speed and network path to enable the file to upload without timeouts. |</a> | Start with a value of <strong>3600</strong> and adjust if needed. |</dt>
|
||||
<dd>
|
||||
<div class="line-block">Following a successful import, we strongly recommend reverting this setting to its initial or previous value. |</div>
|
||||
</dd>
|
||||
</dl></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan="3"><dl>
|
||||
<dt><a href="/administration-guide/configure/environment-configuration-settings#read-timeout">Read Timeout | Temporarily adjust this value based on import file speed and network path to enable the file to upload without timeouts. |</a> | Start with a value of <strong>3600</strong> and adjust if needed. |</dt>
|
||||
<dd>
|
||||
<div class="line-block">Following a successful import, we strongly recommend reverting this setting to its initial or previous value. |</div>
|
||||
</dd>
|
||||
</dl></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan="3"><a href="/administration-guide/configure/environment-configuration-settings#amazon-s3-request-timeout">Amazon S3 Request Timeout | If using cloud-based file storage, adjust this value to ensure your storage requests don't time out too soon. |</a> |</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
Next, log into the destination server using `mmctl` the same way you logged into the source server:
|
||||
|
||||
```
|
||||
mmctl auth login https://localinstance.company.com
|
||||
```
|
||||
|
||||
Use the following command to upload the export to the destination server. The speed of the upload may vary based on connection speed. When the upload is complete the command will return with the ID of the import:
|
||||
|
||||
```
|
||||
mmctl import upload r3kcj8yuwbramdt714doafi3oo_export.zip
|
||||
Upload session successfully created, ID: cfuq6q9kkjrqfgnph1pew3db4e
|
||||
Import file successfully uploaded, name: xrzs9wrzufntbfcxpy39mdq9hy
|
||||
```
|
||||
|
||||
## Complete the import into the new server
|
||||
|
||||
```
|
||||
mmctl import list available
|
||||
cfuq6q9kkjrqfgnph1pew3db4e_r3kcj8yuwbramdt714doafi3oo_export.zip
|
||||
```
|
||||
|
||||
Run the import job to process to import the export file into the server. The speed of this process may vary based on connection speed. First, start the import process:
|
||||
|
||||
```
|
||||
mmctl import process cfuq6q9kkjrqfgnph1pew3db4e_r3kcj8yuwbramdt714doafi3oo_export.zip
|
||||
```
|
||||
|
||||
Once you've marked the file for processing, you can check the status of the job using `mmctl import job list`:
|
||||
|
||||
```
|
||||
mmctl --local import job list
|
||||
ID: f93jxu1hzty79enwa1xy6f1tbr
|
||||
Status: pending
|
||||
Created: 2021-10-28 13:32:55 +0200 CEST
|
||||
```
|
||||
|
||||
When the job is complete, the `success` status is displayed:
|
||||
|
||||
```
|
||||
mmctl --local import job list
|
||||
ID: f93jxu1hzty79enwa1xy6f1tbr
|
||||
Status: success
|
||||
Created: 2021-10-28 13:32:55 +0200 CEST
|
||||
Started: 2021-10-28 13:33:05 +0200 CEST
|
||||
```
|
||||
|
||||
Then extract the export file to use it by running the following mmctl command:
|
||||
|
||||
```
|
||||
mmctl extract run [flags].
|
||||
```
|
||||
|
||||
Once your migration is complete and you’ve imported your data into your self-hosted instance we recommend that you take a few days to validate your data and ensure everything is working as expected before taking down your Cloud instance.
|
||||
|
||||
<Note>
|
||||
|
||||
If you are using email/password authentication, your users must reset their passwords.
|
||||
|
||||
</Note>
|
||||
|
||||
If you encounter any issues or problems, [contact our support team](https://mattermost.com/support/), or visit the [Mattermost Help Center](https://support.mattermost.com/).
|
||||
|
||||
## Migrate from self-hosted to Cloud
|
||||
|
||||
When you migrate from self-hosted to Cloud, you'll need to open a ticket with the Mattermost Support team so they can assist you with the process. The information below describes the migration process. Before you get started, visit our [Support site](https://support.mattermost.com/hc/en-us/requests/new) to open a ticket.
|
||||
|
||||
<Note>
|
||||
|
||||
This migration process is only available to customers using paid Mattermost editions.
|
||||
|
||||
</Note>
|
||||
|
||||
Before you begin your migration, take note of the following information before you begin:
|
||||
|
||||
**User Authentication**
|
||||
|
||||
If you are using the email login method, users will need to reset their passwords after the migration has been completed. Other authentication methods, such as LDAP and GitLab SSO, required changes to your infrastructure allowing the specific authentication method to function in Mattermost cloud.
|
||||
|
||||
**Plugins**
|
||||
|
||||
If you’re using plugins that aren’t listed on the Marketplace, they won’t be included in the export and you won’t have access to them going forward. You can view the list of plugins [in the Support knowledgebase](https://support.mattermost.com/hc/en-us/articles/5346624843924-Mattermost-Plugin-Marketplace-List-as-of-November-12th-2024).
|
||||
|
||||
**Data**
|
||||
|
||||
The migration only includes channel data. No collaborative playbooks data is exported.
|
||||
|
||||
### Migration process
|
||||
|
||||
**Export from your self-hosted instance**
|
||||
|
||||
Use your administrator credentials to log into your self-hosted Mattermost server. Once you're logged in, run:
|
||||
|
||||
```
|
||||
mmctl export create --attachments
|
||||
```
|
||||
|
||||
This creates a full export of the server, and includes attached files. If you don’t want to export attached files, leave out `--attachments`.
|
||||
|
||||
This process can take some time, so `mmctl` will return immediately, and the job will run in the background until the export is fully created. If successful, the command will immediately output a job ID, like this:
|
||||
|
||||
```
|
||||
Export process job successfully created, ID: yfrr9ku5i7fjubeshs1ksrknzc
|
||||
```
|
||||
|
||||
While the job is running, its status can be checked using the ID that was provided when it was created, and when it's done the output will look similar to this:
|
||||
|
||||
```
|
||||
mmctl export job show yfrr9ku5i7fjubeshs1ksrknzc
|
||||
ID: yfrr9ku5i7fjubeshs1ksrknzc
|
||||
Status: success
|
||||
Created: 2021-11-03 10:44:13 -0500 CDT
|
||||
Started: 2021-11-03 10:44:23 -0500 CDT
|
||||
```
|
||||
|
||||
The completed file will be downloaded to your desktop as a `.zip` file.
|
||||
|
||||
<Note>
|
||||
|
||||
Do not rename the file as the file name is referenced in log files, which are used by the Support team to validate the exported file.
|
||||
|
||||
</Note>
|
||||
|
||||
The Support team will provide you with S3 credentials so you can upload the exported file. Once you’ve uploaded the file, please [contact our support team](https://mattermost.com/support/) and let them know.
|
||||
|
||||
### Create a new workspace on the Mattermost Cloud
|
||||
|
||||
In the meantime, you can log into Mattermost Cloud with your Mattermost credentials and create a Cloud workspace.
|
||||
|
||||
<Note>
|
||||
|
||||
Do not create any users in your Mattermost Cloud instance as the migration process performs this task for you.
|
||||
|
||||
</Note>
|
||||
|
||||
### Importing your data into your Mattermost Cloud instance
|
||||
|
||||
Once the export upload to the provided S3 bucket is complete and you’ve shared your Mattermost Cloud instance name/URL, Support can begin the import step.
|
||||
|
||||
Depending on the size of the export this process can take some time. Support will contact you as soon as the import is complete. During this time it is highly recommended you do not use your Mattermost Cloud instance.
|
||||
|
||||
### Start using your Mattermost Cloud instance
|
||||
|
||||
When the export is complete, you can log into your Cloud instance and can invite your users to log in.
|
||||
|
||||
<Note>
|
||||
|
||||
We recommend that you keep your self-hosted Mattermost server until you’ve been using your Cloud instance for a while and all is verified as is as expected.
|
||||
|
||||
</Note>
|
||||
@@ -0,0 +1,15 @@
|
||||
---
|
||||
title: "Cloud data residency"
|
||||
---
|
||||
Mattermost Cloud resides in the `aws-us-east-1` region, located in Virginia, United States. The following customer data will be stored at rest in this data center when using Mattermost Cloud:
|
||||
|
||||
- Channels, messages, replies, and channel membership information
|
||||
- Collaborative playbooks and event runs
|
||||
- User accounts and profiles
|
||||
- Files (e.g., images, docs, etc.) uploaded to the Mattermost Service
|
||||
- Plugin, app- or bot-generated messages and files
|
||||
- Data used to measure user count, usage, and revenue
|
||||
- Data used for analytics and to measure quality of service, e.g., sanitized logs
|
||||
- IDs generated by Mattermost on behalf of the customer
|
||||
|
||||
If you require your data to reside in an area outside of the United States, talk to a [Mattermost Expert](https://mattermost.com/contact-sales/), or consider [deploying one of our self-hosted options](https://mattermost.com/download/) that provides full control of your data. You may also work with [one of our partners](https://mattermost.com/partners) for deploying and hosting your Mattermost server.
|
||||
86
docs/main/administration-guide/manage/cloud-ip-filtering.mdx
Normal file
86
docs/main/administration-guide/manage/cloud-ip-filtering.mdx
Normal file
@@ -0,0 +1,86 @@
|
||||
---
|
||||
title: "Cloud IP filtering"
|
||||
---
|
||||
import useBaseUrl from '@docusaurus/useBaseUrl';
|
||||
|
||||
IP filtering is a powerful security feature that allows system admins to control access to their workspace by defining approved IP ranges. Only users within these specified IP ranges can access the workspace, ensuring enhanced security for your workspace.
|
||||
|
||||
**IP filtering requires a subscription to Mattermost Cloud Enterprise.**
|
||||
|
||||
## Configure IP filtering
|
||||
|
||||
1. **Log in as system admin**: As a system admin, access the System Console of your workspace by selecting the **Product** <img src={useBaseUrl('/img/ui/products_E82F.svg')} alt="Navigate between Channels, collaborative playbooks, and boards using the product menu icon." className="theme-icon" /> menu and selecting **System Console**.
|
||||
|
||||
2. **Go to Site Configuration**: Go to the **Site Configuration** section.
|
||||
|
||||
3. **Access IP Filtering Settings**: Under **Site Configuration**, select **IP Filtering** to access the IP Filtering settings.
|
||||
|
||||

|
||||
|
||||
## About CIDR notation
|
||||
|
||||
CIDR (Classless Inter-Domain Routing) notation is used to specify a range of IP addresses. It consists of an IP address followed by a forward slash and a number indicating the network's prefix length. For example:
|
||||
|
||||
- `192.168.0.0/24` represents the IP range from `192.168.0.0` to `192.168.0.255`.
|
||||
- The `/24` signifies that the first 24 bits are the network address, leaving 8 bits for host addresses.
|
||||
|
||||
<Tip>
|
||||
|
||||
For a more in-depth explanation of CIDR notation, refer to [this article](https://aws.amazon.com/what-is/cidr/).
|
||||
|
||||
</Tip>
|
||||
|
||||
## Configure IP filters
|
||||
|
||||
### Enable/disable IP filtering
|
||||
|
||||
System admins have the option to enable or disable IP filtering:
|
||||
|
||||
- **Enable:** To activate IP filtering, ensure at least one IP range is added to the whitelist.
|
||||
- **Disable:** Temporarily disable IP filtering by removing all IP ranges from the whitelist, or by flipping the global IP Filtering toggle in the System Console.
|
||||
|
||||

|
||||
|
||||
### Add an IP range
|
||||
|
||||
To add an IP range to the whitelist, follow these steps:
|
||||
|
||||
1. Select the **Add Filter** button within the IP Filtering settings page in the System Console.
|
||||
2. Enter the IP range using CIDR notation. For example, `192.168.1.0/24`.
|
||||
3. Provide a descriptive name or label for the IP range to ease identification in the future.
|
||||
4. Save the changes.
|
||||
|
||||

|
||||
|
||||
<Note>
|
||||
|
||||
The System Console will restrict you from saving changes if the IP address you are accessing your workspace on is not within the ranges you have specified at the time you save your changes.
|
||||
|
||||

|
||||
|
||||
</Note>
|
||||
|
||||
### Edit or remove an existing IP range
|
||||
|
||||
To edit or remove an existing IP range from the whitelist:
|
||||
|
||||
1. Locate the IP range you want to modify within the **IP Filtering** settings.
|
||||
2. Hover over the rule you'd like to edit or delete, and select the respective edit or delete option beside the IP range.
|
||||
3. Make necessary changes or confirm the removal of the IP range.
|
||||
4. Save your changes by selecting **Save**.
|
||||
|
||||
### Unable to access your workspace?
|
||||
|
||||
If you are unable to access your workspace due to previously set IP filters, and you need to regain access to your workspace, [contact our support team](https://mattermost.com/support/).
|
||||
|
||||
<Note>
|
||||
|
||||
Going through this process will disable **all** existing rules applied to your workspace. This means that any IP address will now be able to access it.
|
||||
|
||||
</Note>
|
||||
|
||||
## Conclusion
|
||||
|
||||
By configuring IP filters using CIDR notation, system admins can effectively manage access to the workspace, enhancing security by allowing access only from specified IP ranges.
|
||||
|
||||
For any further assistance or queries, [contact our support team](https://mattermost.com/support/).
|
||||
@@ -0,0 +1,17 @@
|
||||
---
|
||||
title: "Cloud workspace management"
|
||||
---
|
||||
This section of the guide is for system admins of Mattermost Cloud deployments.
|
||||
|
||||
<Tip>
|
||||
|
||||
If you're the system admin for a Mattermost self-hosted workspace, see the [Self-hosted administration](/administration-guide/manage/admin/server-maintenance) documentation.
|
||||
|
||||
</Tip>
|
||||
|
||||
- [Workspace migration](/administration-guide/manage/cloud-data-export) - Migrate your workspace using the mmctl tool.
|
||||
- [Cloud data residency](/administration-guide/manage/cloud-data-residency) - Find information about your data in the Cloud.
|
||||
- [Cloud IP filtering](/administration-guide/manage/cloud-ip-filtering) - Restrict access to your Mattermost Cloud workspace to a specific IP address range.
|
||||
- [Cloud Bring Your Own Key (BYOK)](/administration-guide/manage/cloud-byok) - Learn how to manage data encryption processes within a Mattermost Cloud Enterprise Dedicated deployment.
|
||||
|
||||
[Book a live demo](https://mattermost.com/request-demo/) or [talk to a Mattermost expert](https://mattermost.com/contact-sales/) to explore tailored solutions for your organization's secure collaboration needs. Or try Mattermost yourself with a [1-hour preview](https://mattermost.com/sign-up/) for instant access to a live sandbox environment.
|
||||
@@ -0,0 +1,128 @@
|
||||
---
|
||||
title: "Code signing custom builds"
|
||||
---
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
<PlanAvailability slug="all-commercial" />
|
||||
|
||||
Code signing is an essential process for ensuring the authenticity and integrity of your custom `Mattermost` builds. This guide provides steps on how to code sign a build using your own certificates for Windows, Mac, and Linux.
|
||||
|
||||
<Important>
|
||||
|
||||
Make sure to follow each operating system's guidelines and best practices for signing applications.
|
||||
|
||||
</Important>
|
||||
|
||||
## Prerequisites
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="windows" label="Windows">
|
||||
|
||||
1. **Code Signing Certificate**: Obtain a certificate from a Certificate Authority (CA) or use a self-signed certificate if suitable.
|
||||
2. **SignTool**: Available as part of the Windows SDK.
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="linux" label="Linux">
|
||||
|
||||
1. **GPG Key**: Create a GPG key if you don't have one.
|
||||
2. **GnuPG**: Install [GnuPG](https://gnupg.org/howtos/card-howto/en/ch02.html) if not already installed.
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="mac" label="Mac">
|
||||
|
||||
1. **Developer ID Application Certificate**: Obtain from Apple. It requires an Apple Developer account.
|
||||
2. **Xcode**: Ensure [Xcode](https://developer.apple.com/xcode/) is installed.
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
## Process
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="windows" label="Windows">
|
||||
|
||||
1. **Install SignTool**: Install the Windows SDK to access the `SignTool` utility.
|
||||
|
||||
2. **Obtain a Code Signing Certificate**: Purchase or create a certificate (`.pfx` file) via a CA.
|
||||
|
||||
3. **Import the Certificate**: Open the `.pfx` file and import it into the Windows Certificate Store.
|
||||
|
||||
4. **Sign the Executable**
|
||||
|
||||
- Open the command prompt as Administrator.
|
||||
- Use `SignTool` to sign your executable:
|
||||
|
||||
``` sh
|
||||
signtool sign /v /s "My" /sha1 <cert hash> /fd SHA256 /tr http://timestamp.digicert.com /td SHA256 <path-to-your-executable>
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="linux" label="Linux">
|
||||
|
||||
1. **Create or Import Your GPG Key**: If you don't have a GPG key, create one:
|
||||
|
||||
``` sh
|
||||
gpg --full-generate-key
|
||||
```
|
||||
|
||||
Alternatively, import an existing GPG key, if you have one:
|
||||
|
||||
``` sh
|
||||
gpg --import /path/to/your-key.asc
|
||||
```
|
||||
|
||||
2. **Sign the Package**: Use `dpkg-sig` to sign a Debian package:
|
||||
|
||||
``` sh
|
||||
dpkg-sig --sign builder your-package.deb
|
||||
```
|
||||
|
||||
Use `rpmsign` to sign an RPM package:
|
||||
|
||||
``` sh
|
||||
rpmsign --addsign your-package.rpm
|
||||
```
|
||||
|
||||
3. **Verify the Signature**: Verify the signature of a `.deb` package:
|
||||
|
||||
``` sh
|
||||
dpkg-sig --verify your-package.deb
|
||||
```
|
||||
|
||||
Verify the signature of an `.rpm` package:
|
||||
|
||||
``` sh
|
||||
rpm --checksig your-package.rpm
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="mac" label="Mac">
|
||||
|
||||
1. **Obtain a Code Signing Certificate**: Create a `Developer ID Application` certificate in your Apple Developer account and download it.
|
||||
|
||||
2. **Import the Certificate**: Double-click the certificate to import it into the Keychain.
|
||||
|
||||
3. **Sign the Application**: Use the `codesign` tool from Xcode to sign your application:
|
||||
|
||||
``` sh
|
||||
codesign --deep --force --verify --verbose --sign "Developer ID Application: Your Name (TeamID)" /path/to/your.app
|
||||
```
|
||||
|
||||
4. \[Optional\] **Verify the Signature**: Verify the signature to ensure everything is correctly signed:
|
||||
|
||||
``` sh
|
||||
spctl --assess --verbose=4 /path/to/your.app
|
||||
codesign -dv --verbose=4 /path/to/your.app
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
## Summary
|
||||
|
||||
- **Windows**: Use `SignTool` from the Windows SDK with your imported code signing certificate.
|
||||
- **Mac**: Use `codesign` and `spctl` tools from Xcode with your Apple Developer ID certificate.
|
||||
- **Linux**: Use `GnuPG` to create/sign with your GPG key, `dpkg-sig` for `.deb` packages, and `rpmsign` for `.rpm` packages.
|
||||
385
docs/main/administration-guide/manage/command-line-tools.mdx
Normal file
385
docs/main/administration-guide/manage/command-line-tools.mdx
Normal file
@@ -0,0 +1,385 @@
|
||||
---
|
||||
title: "Command line tools"
|
||||
---
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
<PlanAvailability slug="all-commercial" />
|
||||
|
||||
In self-managed deployments, a `mattermost` command is available for configuring the system from the directory where the Mattermost server is installed. For an overview of the Mattermost command line interface (CLI), [read this article](https://medium.com/@santosjs/plugging-in-to-the-mattermost-cli-8cdcef2bd1f6) from Santos.
|
||||
|
||||
<Important>
|
||||
|
||||
From Mattermost v6.0, the majority of these CLI commands have been replaced with equivalents available using the [mmctl command line tool](/administration-guide/manage/mmctl-command-line-tool). However, [mattermost import](/administration-guide/manage/command-line-tools#mattermost-import) commands, [mattermost export](/administration-guide/manage/command-line-tools#mattermost-export) commands, and related subcommands, remain available and fully supported from Mattermost v6.0.
|
||||
|
||||
</Important>
|
||||
|
||||
These `mattermost` commands include the following functionality:
|
||||
|
||||
**Compliance Export**
|
||||
|
||||
- Export data
|
||||
- Schedule an export job
|
||||
|
||||
**Database**
|
||||
|
||||
- Initialize the database, execute migrations, and load custom defaults
|
||||
- Migrate the database schema for unapplied migrations
|
||||
- Reset the database to its initial state
|
||||
- Return the most recently applied version number
|
||||
- Roll back database migrations
|
||||
|
||||
**Server Operations**
|
||||
|
||||
- Start the Mattermost job server
|
||||
- Run the Mattermost server
|
||||
- Display Mattermost version information
|
||||
|
||||
## Use the CLI
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="via-mattermost" label="Via Mattermost">
|
||||
|
||||
To run the CLI commands, you must be in the Mattermost root directory. On a default installation of Mattermost, the root directory is `/opt/mattermost`. If you followed our standard [installation process](/deployment-guide/deployment-guide-index), you must run the commands as the user `mattermost`. The name of the executable is `mattermost`, and it can be found in the `/opt/mattermost/bin` directory.
|
||||
|
||||
For example, to get the Mattermost version on a default installation of Mattermost:
|
||||
|
||||
``` sh
|
||||
cd /opt/mattermost/
|
||||
sudo -u mattermost bin/mattermost version
|
||||
```
|
||||
|
||||
<Note>
|
||||
|
||||
- Ensure you run the Mattermost binary as the `mattermost` user. Running it as `root` user (for example) may cause complications with permissions as the binary initiates plugins and accesses various files when running CLI commands. Running the server as `root` may result in ownership of the plugins and files to be overwritten as well as other potential permissions errors.
|
||||
|
||||
- When running CLI commands on a Mattermost installation that has the configuration stored in the database, you might need to pass the database connection string as:
|
||||
|
||||
``` sh
|
||||
bin/mattermost --config="postgres://mmuser:mostest_password@localhost:5432/mattermost_test?sslmode=disable\u0026connect_timeout=10"
|
||||
```
|
||||
|
||||
</Note>
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="via-gitlab-omnibus" label="Via GitLab Omnibus">
|
||||
|
||||
On GitLab Omnibus, you must be in the following directory when you run CLI commands: `/opt/gitlab/embedded/service/mattermost`. Also, you must run the commands as the user *mattermost* and specify the location of the configuration file. The executable is `/opt/gitlab/embedded/bin/mattermost`.
|
||||
|
||||
For example, to get the Mattermost version on GitLab Omnibus:
|
||||
|
||||
``` sh
|
||||
cd /opt/gitlab/embedded/service/mattermost
|
||||
sudo /opt/gitlab/embedded/bin/chpst -e /opt/gitlab/etc/mattermost/env -P -U mattermost:mattermost -u mattermost:mattermost /opt/gitlab/embedded/bin/mattermost version
|
||||
```
|
||||
|
||||
<Note>
|
||||
|
||||
The example commands on this documentation page are for a default installation of Mattermost. You must modify the commands so that they work on GitLab Omnibus.
|
||||
|
||||
</Note>
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="via-docker-install" label="Via Docker Install">
|
||||
|
||||
On Docker install, the `/mattermost/bin` directory was added to `PATH`, so you can use the CLI directly with the `docker exec` command. Note that the container name may be `mattermostdocker_app_1` if you installed Mattermost with `docker-compose.yml`.
|
||||
|
||||
For example, to get the Mattermost version on a Docker Install:
|
||||
|
||||
``` sh
|
||||
docker exec -it <your-mattermost-container-name> mattermost version
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="via-docker-preview" label="Via Docker Preview">
|
||||
|
||||
The Docker Install tab details and command references below also apply to the [Mattermost docker preview image](https://github.com/mattermost/mattermost-docker-preview).
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
<Note>
|
||||
|
||||
\- The CLI is run in a single node which bypasses the mechanisms that a [High Availability environment](/deployment-guide/server/high-availability-cluster-based-deployment) uses to perform actions across all nodes in the cluster. As a result, when running [CLI commands](/administration-guide/manage/command-line-tools) in a High Availability environment, tasks that change configuration settings require a server restart. - Parameters in CLI commands are order-specific. - If special characters (`!`, `|`, `(`, `)`, `\`, `'`, or `"`) are used, the entire argument needs to be surrounded by single quotes, or the individual characters need to be escaped out.
|
||||
|
||||
</Note>
|
||||
|
||||
## mattermost CLI commands
|
||||
|
||||
Description
|
||||
Commands for configuring and managing your Mattermost instance and users.
|
||||
|
||||
Options
|
||||
``` text
|
||||
-c, --config {string} Configuration file to use. (default "config.json")
|
||||
--disableconfigwatch {boolean} When true, the config.json file will not be reloaded automatically when another process changes it (default "false")
|
||||
```
|
||||
|
||||
Child Commands
|
||||
- [mattermost db](#mattermost-db) - Database commands
|
||||
- [mattermost export](#mattermost-export) - Compliance export commands
|
||||
- [mattermost help](#mattermost-help) - Generate full documentation for the CLI
|
||||
- [mattermost import](#mattermost-import) - Legacy import command
|
||||
- [mattermost jobserver](#mattermost-jobserver) - Start the Mattermost job server
|
||||
- [mattermost server](#mattermost-server) - Run the Mattermost server
|
||||
- [mattermost version](#mattermost-version) - Display version information
|
||||
|
||||
## mattermost db
|
||||
|
||||
Description
|
||||
Commands related to the database
|
||||
|
||||
Child Commands
|
||||
- [mattermost db downgrade](#mattermost-db-downgrade) - Roll back database migrations. Requires either an update plan to roll back to, or comma-separated version numbers to be rolled back.
|
||||
- [mattermost db init](#mattermost-db-init) - Initialize the database, execute migrations, and load custom defaults
|
||||
- [mattermost db migrate](/administration-guide/manage/command-line-tools#mattermost-db-migrate) - Migrate the database schema for unapplied migrations
|
||||
- [mattermost db reset](#mattermost-db-reset) - Reset the database to its initial state
|
||||
- [mattermost db version](#mattermost-db-version) - Return the most recently applied version number
|
||||
|
||||
Options
|
||||
``` text
|
||||
-h, --help help for db
|
||||
-c, --config string Configuration file to use
|
||||
```
|
||||
|
||||
### mattermost db downgrade
|
||||
|
||||
Description
|
||||
Rolls back database migrations. Requires either an update plan to roll back to, or comma-separated version numbers to be rolled back.
|
||||
|
||||
Format
|
||||
``` sh
|
||||
mattermost db downgrade
|
||||
```
|
||||
|
||||
Example
|
||||
``` sh
|
||||
mattermost db downgrade 99,100,101
|
||||
```
|
||||
|
||||
Options
|
||||
``` text
|
||||
--<plan-file> string Runs the rollback migrations defined in the plan file.
|
||||
```
|
||||
|
||||
### mattermost db init
|
||||
|
||||
Description
|
||||
Initializes the database for a given data source name (DSN), executes migrations, and loads custom defaults when specified.
|
||||
|
||||
Format
|
||||
``` sh
|
||||
mattermost db init
|
||||
```
|
||||
|
||||
Examples
|
||||
Use the `config` flag to pass the DSN:
|
||||
|
||||
``` sh
|
||||
mattermost db init --config postgres://localhost/mattermost
|
||||
```
|
||||
|
||||
Run this command to use the `MM_CONFIG` environment variable:
|
||||
|
||||
``` sh
|
||||
MM_CONFIG=postgres://localhost/mattermost mattermost db init
|
||||
```
|
||||
|
||||
Run this command to set a custom defaults file to be loaded into the database:
|
||||
|
||||
``` sh
|
||||
MM_CUSTOM_DEFAULTS_PATH=custom.json MM_CONFIG=postgres://localhost/mattermost mattermost db init
|
||||
```
|
||||
|
||||
### mattermost db migrate
|
||||
|
||||
Description
|
||||
Migrates the database schema if there are any unapplied migrations.
|
||||
|
||||
Child Commands
|
||||
- [mattermost db downgrade](#mattermost-db-downgrade) - Roll back database migrations.
|
||||
|
||||
Format
|
||||
``` sh
|
||||
mattermost db migrate
|
||||
```
|
||||
|
||||
Example
|
||||
``` sh
|
||||
mattermost db migrate
|
||||
```
|
||||
|
||||
Options
|
||||
``` text
|
||||
--auto-recover bool If the migration plan receives an error during migrations, this command will try to rollback migrations already applied within the plan. Not recommended without reviewing migration plan by combining --save-plan and --dry-run options.
|
||||
--save-plan bool Saves the plan for the migration into the file store so that it can be used for reviewing the plan or for downgrading.
|
||||
--dry-run bool Does not apply the migrations, but it validates how the migration would run based on the given conditions.
|
||||
```
|
||||
|
||||
### mattermost db reset
|
||||
|
||||
Description
|
||||
Resets the database to its initial state. Doesn't start the application server. Only starts the store layer and truncates the tables, excluding the `migrations` table.
|
||||
|
||||
Format
|
||||
``` sh
|
||||
mattermost db reset
|
||||
```
|
||||
|
||||
Example
|
||||
``` sh
|
||||
bin/mattermost db reset
|
||||
```
|
||||
|
||||
### mattermost db version
|
||||
|
||||
Description
|
||||
Returns the most recently applied version number.
|
||||
|
||||
Format
|
||||
``` sh
|
||||
mattermost db version
|
||||
```
|
||||
|
||||
------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
## mattermost export
|
||||
|
||||
<PlanAvailability slug="ent-plus" />
|
||||
|
||||
Description
|
||||
Commands for exporting data for compliance and for merging multiple Mattermost instances.
|
||||
|
||||
Child Commands
|
||||
- [mattermost export actiance](#mattermost-export-actiance) - Deprecated from Mattermost v10.5 in favor of [mattermost export schedule](#mattermost-export-schedule).
|
||||
- [mattermost export csv](#mattermost-export-csv) - Deprecated from Mattermost v10.5.
|
||||
- [mattermost export global-relay-zip](#mattermost-export-global-relay-zip) - Deprecated from Mattermost v10.5.
|
||||
- [mattermost export schedule](#mattermost-export-schedule) - Schedule a compliance export job.
|
||||
- [mattermost export bulk](#mattermost-export-bulk) - Export data to a file compatible with the Mattermost [bulk import format](/administration-guide/onboard/bulk-loading-data). Deprecated in favor of [mmctl export commands](/administration-guide/manage/mmctl-command-line-tool#mmctl-export).
|
||||
|
||||
### mattermost export actiance
|
||||
|
||||
From Mattermost v10.5, this command has been deprecated. It will be added to the mmctl command line tool in a future version. Until then, please use [mattermost export schedule](#mattermost-export-schedule).
|
||||
|
||||
### mattermost export csv
|
||||
|
||||
From Mattermost v10.5, this command has been deprecated. It will be added to the mmctl command line tool in a future version.
|
||||
|
||||
### mattermost export global-relay-zip
|
||||
|
||||
From Mattermost v10.5, this command has been deprecated. It will be added to the mmctl command line tool in a future version.
|
||||
|
||||
### mattermost export schedule
|
||||
|
||||
Description
|
||||
Schedule an export job in a format suitable for importing into a third-party archive system.
|
||||
|
||||
Format
|
||||
``` sh
|
||||
mattermost export schedule
|
||||
```
|
||||
|
||||
Example
|
||||
``` sh
|
||||
bin/mattermost export schedule --exportFrom=1513102632
|
||||
```
|
||||
|
||||
Options
|
||||
``` text
|
||||
--exportFrom string Unix timestamp (seconds since epoch, UTC) to export data from.
|
||||
--timeoutSeconds string Set how long the export should run for before timing out.
|
||||
```
|
||||
|
||||
### mattermost export bulk
|
||||
|
||||
From Mattermost v6.0, this command has been deprecated in favor of [mmctl export commands](/administration-guide/manage/mmctl-command-line-tool#mmctl-export) as the supported way to export data out of Mattermost.
|
||||
|
||||
------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
## mattermost help
|
||||
|
||||
Description
|
||||
Generate full documentation in Markdown format for the Mattermost command line tools.
|
||||
|
||||
Format
|
||||
``` sh
|
||||
mattermost help {outputdir}
|
||||
```
|
||||
|
||||
<div id="command-line-tools-mattermost-jobserver">
|
||||
|
||||
------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
</div>
|
||||
|
||||
## mattermost import
|
||||
|
||||
Description
|
||||
Import data into Mattermost.
|
||||
|
||||
Child Command
|
||||
- [mattermost import bulk](#mattermost-import-bulk) - Import a Mattermost bulk import file. Deprecated in favor of [mmctl import commands](/administration-guide/manage/mmctl-command-line-tool#mmctl-import).
|
||||
|
||||
### mattermost import bulk
|
||||
|
||||
From Mattermost v6.0, this command has been deprecated in favor of [mmctl import commands](/administration-guide/manage/mmctl-command-line-tool#mmctl-import) as the supported way to import data into Mattermost.
|
||||
|
||||
------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
## mattermost jobserver
|
||||
|
||||
Description
|
||||
Start the Mattermost job server.
|
||||
|
||||
Format
|
||||
``` sh
|
||||
mattermost jobserver
|
||||
```
|
||||
|
||||
Example
|
||||
``` sh
|
||||
bin/mattermost jobserver
|
||||
```
|
||||
|
||||
------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
## mattermost server
|
||||
|
||||
Description
|
||||
Runs the Mattermost server.
|
||||
|
||||
Format
|
||||
``` sh
|
||||
mattermost server
|
||||
```
|
||||
|
||||
------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
## mattermost version
|
||||
|
||||
<Note>
|
||||
|
||||
From Mattermost v6.5, this CLI command no longer interacts with the database. The [mattermost db migrate](/administration-guide/manage/command-line-tools#mattermost-db-migrate) CLI command has been introduced to trigger schema migrations.
|
||||
|
||||
</Note>
|
||||
|
||||
Desription
|
||||
Displays Mattermost version information.
|
||||
|
||||
Format
|
||||
``` sh
|
||||
mattermost version
|
||||
```
|
||||
|
||||
------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Executing a command hangs and doesn't complete
|
||||
|
||||
If you have Bleve search indexing enabled, temporarily disable it in **System Console \> Experimental \> Bleve** and run the command again. You can also optionally use the new [mmctl Command Line Tool](/administration-guide/manage/mmctl-command-line-tool).
|
||||
|
||||
Bleve does not support multiple processes opening and manipulating the same index. Therefore, if the Mattermost server is running, an attempt to run the CLI will lock when trying to open the indeces.
|
||||
|
||||
If you aren't using the Bleve search indexing, feel free to post in our [Troubleshooting forum](https://forum.mattermost.com/c/trouble-shoot/16) to get help.
|
||||
@@ -0,0 +1,48 @@
|
||||
---
|
||||
title: "Configure server health check probes"
|
||||
---
|
||||
<PlanAvailability slug="entry-ent" />
|
||||
|
||||
This page describes how to configure health check probes for a Mattermost server.
|
||||
|
||||
Before you begin, you should have a running Mattermost server. If you don't, you can [install Mattermost on various distributions](/deployment-guide/deployment-guide-index).
|
||||
|
||||
<Note>
|
||||
|
||||
[Highly available Mattermost cluster support](/deployment-guide/server/high-availability-cluster-based-deployment) requires Mattermost Enterprise.
|
||||
|
||||
</Note>
|
||||
|
||||
You can perform a health check with the following 2 methods:
|
||||
|
||||
- [ping the APIv4 endpoint](#ping-the-apiv4-endpoint)
|
||||
- [ping the Mattermost server](#ping-the-mattermost-server)
|
||||
|
||||
## Ping the APIv4 endpoint
|
||||
|
||||
You can use the [GET /system/ping APIv4 endpoint](https://api.mattermost.com/#tag/system%2Fpaths%2F~1system~1ping%2Fget) to check for system health.
|
||||
|
||||
A sample request is included below. The endpoint checks if the server is up and healthy based on the configuration setting `GoRoutineHealthThreshold`.
|
||||
|
||||
- If `GoRoutineHealthThreshold` and the number of goroutines on the server exceeds that threshold, the server is considered unhealthy.
|
||||
- If `GoRoutineHealthThreshold` is not set or the number of goroutines is below the threshold the server is considered healthy.
|
||||
|
||||
This endpoint can also be provided to schedulers like [Kubernetes](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/).
|
||||
|
||||
``` go
|
||||
import "github.com/mattermost/mattermost/server/public/model"
|
||||
|
||||
Client := model.NewAPIv4Client("https://your-mattermost-url.com")
|
||||
Client.Login("email@domain.com", "Password1")
|
||||
|
||||
// GetPing
|
||||
status, err := Client.GetPing()
|
||||
```
|
||||
|
||||
## Ping the Mattermost server
|
||||
|
||||
The [Mattermost Probe](https://github.com/csduarte/mattermost-probe) constantly pings a Mattermost server using a variety of probes.
|
||||
|
||||
These probes can be configured to verify core features, including sending and receiving messages, joining channels, pinging a login page, and searching of users and channels.
|
||||
|
||||
The project is contributed by the Mattermost open source community. Suggestions and contributions for the project are welcome.
|
||||
22
docs/main/administration-guide/manage/feature-labels.mdx
Normal file
22
docs/main/administration-guide/manage/feature-labels.mdx
Normal file
@@ -0,0 +1,22 @@
|
||||
---
|
||||
title: "Mattermost feature labels"
|
||||
---
|
||||
<PlanAvailability slug="all-commercial" />
|
||||
|
||||
Mattermost’s feature labels serve as indicators of the status, maturity, and support level of each feature, helping users and system administrators navigate product feature adoption with clarity and confidence. Feature labels communicate the stage of development, level of readiness, and potential risks associated with a feature for customers seeking to adopt new value.
|
||||
|
||||
## Experimental
|
||||
|
||||
Feature is an early Proof of Concept (POC) with an unstable codebase, minimal QA covering a small or specific set of use cases, and potential UI issues. Security reviews are incomplete, making it unsuitable for production. Distribution of the solution is limited, and our Cloud environments are typically not eligible to use experimental features. Data loss can occur as data schemas and configurations may change, and minimal documentation is available. Caution is advised as the solution may be discarded if its value is not proven.
|
||||
|
||||
## Beta
|
||||
|
||||
Feature is in active development towards General Availability. Not fully complete, but reviewed by our security team, adoption is suitable for a small set of customers behind a feature flag. Identified bugs are fixed on a best effort basis, and no major breaking changes are anticipated, full testing is in progress, and detailed documentation may not be available. Beta is a transitional stage, meaning the solution is maturing but requires careful consideration in a full production deployment as scale and client availability may vary. [Premier Support](https://mattermost.com/support/) is recommended when using beta features in production environments.
|
||||
|
||||
## General Availability
|
||||
|
||||
Feature has undergone thorough validation and testing and has production-level quality. It is feature-complete, meets quality standards, has successfully passed security reviews, and has detailed product documentation available. General Availability features are suitable for widespread production deployment and adoption, and are eligible for commercial support, as they offer stability and reliability, with no expected changes that could disrupt functionality or scalability.
|
||||
|
||||
## Deprecated
|
||||
|
||||
Feature is officially marked for removal from the product. It is no longer supported or actively maintained by the development team. If the feature is still in use in your deployed version, we recommend users discontinue its use and migrate to alternative functionalities.
|
||||
39
docs/main/administration-guide/manage/in-product-notices.mdx
Normal file
39
docs/main/administration-guide/manage/in-product-notices.mdx
Normal file
@@ -0,0 +1,39 @@
|
||||
---
|
||||
title: "In-product notices"
|
||||
---
|
||||
<PlanAvailability slug="all-commercial" />
|
||||
|
||||
Mattermost in-product notices keep users and administrators informed of the newest product improvements, features, and releases.
|
||||
|
||||
## Administrator notices
|
||||
|
||||
Administrator notices inform system admins when a new server version is available, when external dependencies are being deprecated, or when server upgrades are recommended due to ending support life cycles. System admins may also receive notices about recommended server configuration options to optimize the user experience of their deployment.
|
||||
|
||||

|
||||
|
||||
System admins can disable end user notices by going to **System Console \> Site Configuration \> Notices**.
|
||||
|
||||
## End user notices
|
||||
|
||||
End user notices are used to inform all users when:
|
||||
|
||||
- New desktop app versions and feature enhancements are available for users.
|
||||
- Mattermost is gathering user feedback to improve the product and user experience.
|
||||
|
||||
System admins can disable end user notices by going to **System Console \> Site Configuration \> Notices**.
|
||||
|
||||

|
||||
|
||||
## Frequently asked questions (FAQs)
|
||||
|
||||
### Are notices enabled by default?
|
||||
|
||||
Yes. Notices are enabled by default for all Mattermost users. System admins may choose to disable admin or end user notices in **System Console \> Site Configuration \> Notices**.
|
||||
|
||||
### Will I still receive notices if my server is air-gapped?
|
||||
|
||||
No, the Mattermost server requires a connection to the internet to receive notices.
|
||||
|
||||
### How often will users receive notices?
|
||||
|
||||
Notices will be used to raise awareness of new features as part of our monthly release cadence. Users will only receive notices that specifically apply to them. For example, if a user is already running the latest Desktop App version, they will not receive an upgrade notice.
|
||||
1211
docs/main/administration-guide/manage/logging.mdx
Normal file
1211
docs/main/administration-guide/manage/logging.mdx
Normal file
File diff suppressed because it is too large
Load Diff
150
docs/main/administration-guide/manage/product-limits.mdx
Normal file
150
docs/main/administration-guide/manage/product-limits.mdx
Normal file
@@ -0,0 +1,150 @@
|
||||
---
|
||||
title: "Product limits"
|
||||
---
|
||||
<PlanAvailability slug="all-commercial" />
|
||||
|
||||
This page describes some of the product limits that apply to Mattermost, including hard and recommended limits.
|
||||
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Feature</th>
|
||||
<th>Hard Limit</th>
|
||||
<th>Recommended Limit</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><a href="/end-user-guide/collaborate/create-channels">Group messages</a></td>
|
||||
<td>8 participants</td>
|
||||
<td>If 8 isn't enough, create a private channel</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><a href="/end-user-guide/collaborate/make-calls">Call participants</a></td>
|
||||
<td>Unlimited</td>
|
||||
<td>50</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><a href="/administration-guide/configure/custom-branding-tools#custom-brand-text">Custom brand text</a></td>
|
||||
<td>500</td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><a href="/administration-guide/configure/custom-branding-tools#site-description">Custom site description</a></td>
|
||||
<td>1024</td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><a href="/administration-guide/manage/logging#advanced-logging">Advanced log output</a></td>
|
||||
<td>500 MB file size, 1000 audit records</td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><a href="/end-user-guide/preferences/set-your-status-availability#set-a-custom-status">Custom status</a></td>
|
||||
<td>100 characters</td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><a href="/end-user-guide/collaborate/channel-header-purpose#channel-name">Channel name</a></td>
|
||||
<td>64 characters</td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><a href="/end-user-guide/collaborate/channel-header-purpose#channel-purpose">Channel purpose</a></td>
|
||||
<td>250 characters</td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><a href="/end-user-guide/collaborate/channel-header-purpose#channel-header">Channel header</a></td>
|
||||
<td>1024 characters</td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><a href="/end-user-guide/collaborate/manage-channel-bookmarks">Bookmarked links & files</a></td>
|
||||
<td>50</td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><a href="/end-user-guide/collaborate/message-priority#request-acknowledgements">Message acknowledgement</a> response time</td>
|
||||
<td>5 minutes</td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><a href="/end-user-guide/collaborate/organize-using-custom-user-groups">Custom user group</a> notifications</td>
|
||||
<td>256 users per group</td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><a href="/end-user-guide/collaborate/react-with-emojis-gifs#quick-emoji-reactions">Emoji reactions</a> per message</td>
|
||||
<td>50</td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><a href="/end-user-guide/collaborate/react-with-emojis-gifs#upload-custom-emojis">Custom emoji uploads</a></td>
|
||||
<td>6000</td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><a href="/end-user-guide/collaborate/team-settings#team-description">Team description</a></td>
|
||||
<td>50 characters</td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><a href="/administration-guide/configure/environment-configuration-settings#session-length-for-sso">SSO user session duration</a></td>
|
||||
<td>30 days</td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><a href="/administration-guide/configure/environment-configuration-settings#session-length-for-mobile">Mobile user session duration</a></td>
|
||||
<td>30 days</td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><a href="/end-user-guide/collaborate/share-files-in-messages">Attachments per message</a> (files or images)</td>
|
||||
<td>10</td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><a href="/end-user-guide/collaborate/share-files-in-messages#attachment-limits-and-sizes">Attachment file size</a></td>
|
||||
<td>100 MB</td>
|
||||
<td>Configurable</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><a href="/end-user-guide/collaborate/share-files-in-messages#attachment-limits-and-sizes">Attachment image file size</a></td>
|
||||
<td>253 MB</td>
|
||||
<td>Configurable</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><a href="/end-user-guide/collaborate/share-files-in-messages#attachment-limits-and-sizes">Attachment dimensions</a></td>
|
||||
<td>7680 pixels x 4320 pixels</td>
|
||||
<td>Configurable</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><a href="/end-user-guide/collaborate/share-files-in-messages#attachment-limits-and-sizes">Attachment image resolution size</a></td>
|
||||
<td>33 MP (mega pixels) or 8K resolution</td>
|
||||
<td>Configurable</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><a href="/end-user-guide/preferences/manage-your-profile">User nickname</a></td>
|
||||
<td>64 characters</td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><a href="/end-user-guide/collaborate/send-messages">Message length</a></td>
|
||||
<td>16,383 characters</td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><a href="/end-user-guide/collaborate/organize-using-teams#create-a-team">Teams per deployment</a></td>
|
||||
<td>10,000</td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><a href="/end-user-guide/collaborate/invite-people">Users per team</a></td>
|
||||
<td>No enforced limit</td>
|
||||
<td>Dependent on infrastructure</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
[Book a live demo](https://mattermost.com/request-demo/) or [talk to a Mattermost expert](https://mattermost.com/contact-sales/) to explore tailored solutions for your organization's secure collaboration needs. Or try Mattermost yourself with a [1-hour preview](https://mattermost.com/sign-up/) for instant access to a live sandbox environment.
|
||||
@@ -0,0 +1,39 @@
|
||||
---
|
||||
title: "Request a server health check"
|
||||
---
|
||||
<PlanAvailability slug="entry-ent" />
|
||||
|
||||
The Mattermost Health Check is a comprehensive evaluation of your system's current operational health available to Mattermost Enterprise customers.
|
||||
|
||||
This evaluation provides you with insights based on your system’s configuration, user activity, and log events that helps you proactively identify issues, enhance collaboration security, optimize resource utilization and scalability which leads to minimized downtime, improved performance, and significant cost savings for your Enterprise organization.
|
||||
|
||||
<Tip>
|
||||
|
||||
Want to configure your own server health check probes for your self-hosted Mattermost deployment? See the [configure server health check probes](/administration-guide/manage/configure-health-check-probes) documentation for details.
|
||||
|
||||
</Tip>
|
||||
|
||||
## Why request a Mattermost Health Check?
|
||||
|
||||
Regularly assessing the health of your Mattermost environment ensures that:
|
||||
|
||||
- System performance remains optimal, with minimal delays or downtime.
|
||||
- User experience is consistently reliable, preventing missed messages or slow load times.
|
||||
- Security and compliance settings are up-to-date and effective.
|
||||
- Scalability aligns with your evolving usage patterns, supporting growth without issues.
|
||||
|
||||
## Get started
|
||||
|
||||
Getting started with a Mattermost Health Check is simple and involves 3 steps:
|
||||
|
||||
1. [Generate a Support Packet](/administration-guide/manage/admin/generating-support-packet): The Mattermost Support Packet contains critical information about your Mattermost environment, including logs, configurations, and usage data.
|
||||
2. Submit Your Support Packet: Once you’ve generated the Support Packet, submit it through our Support System as a [standard support request](https://support.mattermost.com/hc/en-us/requests/new). Please include “Health Check Provided” in the subject line.
|
||||
3. Receive Your Health Check Report: Within 2 weeks of submitting your Support Packet, you will receive a comprehensive performance report. This report will include:
|
||||
|
||||
- Detailed analysis of your current system health.
|
||||
- Actionable recommendations to enhance performance, reliability, and security.
|
||||
- Guidance on best practices for future system maintenance.
|
||||
|
||||
## Get help
|
||||
|
||||
If you have any questions or need assistance, contact your Customer Success Manager or Technical Account Manager, the [Mattermost Support Team](https://mattermost.com/support/), or visit the [Mattermost Help Center](https://support.mattermost.com/).
|
||||
150
docs/main/administration-guide/manage/statistics.mdx
Normal file
150
docs/main/administration-guide/manage/statistics.mdx
Normal file
@@ -0,0 +1,150 @@
|
||||
---
|
||||
title: "Statistics"
|
||||
---
|
||||
<PlanAvailability slug="all-commercial" />
|
||||
|
||||
Statistics on users, posts, and channels are tracked for each system and team. Enterprise Editions have access to advanced system statistics.
|
||||
|
||||
<Note>
|
||||
|
||||
To maximize performance for large enterprise deployments, statistics for total messages, total hashtag messages, total file messages, messages per day, and activated users with messages per day is configurable by changing the `MaxUsersForStatistics` value [in config.json](/administration-guide/configure/reporting-configuration-settings#maximum-users-for-statistics).
|
||||
|
||||
</Note>
|
||||
|
||||
For advanced metrics for Entry, Enterprise, and Enterprise deployments, [see performance monitoring documentation to learn more](/administration-guide/scale/deploy-prometheus-grafana-for-performance-monitoring).
|
||||
|
||||
## System statistics
|
||||
|
||||
System statistics are viewable under **System Console \> Reporting**. The data shown here is a cumulative sum across all teams on the system.
|
||||
|
||||
Total Users
|
||||
The total number of active accounts created on your system. Excludes deactivated accounts and single-channel guests.
|
||||
|
||||
Single-channel Guests
|
||||
The number of active guest accounts that belong to exactly one active channel on the server. Direct messages and group messages don't affect whether a guest is counted as a single-channel guest. Archived channels are excluded. Single-channel guests are counted separately from the primary paid seat count and are free up to a 1:1 ratio with licensed seats. When this count exceeds the allowance, the statistic is highlighted as a warning for system admins.
|
||||
|
||||
Total Teams
|
||||
The total number of teams created on your system.
|
||||
|
||||
Total Channels
|
||||
The total number of public channels and private channels created in all the teams on your system, including deleted channels. Doesn't include direct message channels.
|
||||
|
||||
Total Posts
|
||||
The total number of posts made in all the teams on your system, including deleted posts and posts made using automation.
|
||||
|
||||
Daily Active Users
|
||||
The total number of users who viewed the Mattermost site in the last 24 hours. Excludes bot users.
|
||||
|
||||
Monthly Active Users
|
||||
The total number of users who viewed the Mattermost site in the last 30 days. Excludes bot users.
|
||||
|
||||
Total Posts (graph)
|
||||
The total number of posts made on a certain day in all the teams on your system, including deleted posts and posts made using automation.
|
||||
|
||||
Total Posts from Bots (graph)
|
||||
The total number of posts made by a [bot account](https://developers.mattermost.com/integrate/admin-guide/admin-bot-accounts/) on a certain day in all the teams on your system, including deleted posts and posts made using automation.
|
||||
|
||||
Active Users with Posts (graph)
|
||||
Users who made a post on a certain day in all the teams on your system, including system messages posted from the user's account.
|
||||
|
||||
### Advanced system statistics
|
||||
|
||||
<PlanAvailability slug="entry-ent" />
|
||||
|
||||
Self-hosted deployments include additional system statistics.
|
||||
|
||||
Total Sessions
|
||||
The number of active user sessions connected to your system. Expired sessions are not counted.
|
||||
|
||||
Total Commands
|
||||
The number of active slash commands currently set up on your system. Slash commands that are created and then removed in the **Integrations** menu are not counted.
|
||||
|
||||
Incoming Webhooks
|
||||
The number of active incoming webhooks currently setup on your system. Incoming webhooks that are created and then removed in the **Integrations** menu are not counted.
|
||||
|
||||
Outgoing Webhooks
|
||||
The number of active outgoing webhooks currently set up on your system. Outgoing webhooks that are created and then removed in the **Integrations** menu are not counted.
|
||||
|
||||
WebSocket Conns
|
||||
The number of active WebSocket connections currently on your server.
|
||||
|
||||
Master DB Conns
|
||||
The number of active connections currently on your master database.
|
||||
|
||||
Replica DB Conns
|
||||
The number of active connections currently on one or more of [your read replica databases](/deployment-guide/server/high-availability-cluster-based-deployment#database).
|
||||
|
||||
Total Playbooks
|
||||
The total number of collaborative playbooks on this server.
|
||||
|
||||
Total Playbook Runs
|
||||
The total number of runs (active and complete) on this server.
|
||||
|
||||
Channel Types
|
||||
This chart displays the number of public channels and private channels in a visual format, including channels that might have been deleted.
|
||||
|
||||
Posts, Files and Hashtags
|
||||
This chart displays the number of posts containing files, hashtags, or only text. Posts containing both files and hashtags are counted in both categories, and deleted posts are included.
|
||||
|
||||
## Team statistics
|
||||
|
||||
Team Statistics are viewable under **System Console \> Team Statistics**. The data shown here is a cumulative sum across this team only, and excludes posts made in Direct Message channels, which are not tied to a team.
|
||||
|
||||
Total Users
|
||||
The total number of active accounts on this team. Excludes deactivated accounts.
|
||||
|
||||
Public Channels
|
||||
The number of public channels created in this team. Excludes deleted channels.
|
||||
|
||||
Private Channels
|
||||
The number of private channels created in this team. Excludes deleted channels.
|
||||
|
||||
Total Posts
|
||||
The total number of posts made in this team, including deleted posts and posts made using automation. Excludes posts made in Direct Message channels, which are not tied to a team.
|
||||
|
||||
Total Posts (graph)
|
||||
The total number of posts made on a certain day in this team, including deleted posts and posts made using automation.
|
||||
|
||||
Active Users with Posts (graph)
|
||||
Users who made a post on a certain day in this team, including system messages posted from the user's account.
|
||||
|
||||
Recent Active Users
|
||||
Twenty most recent users who have logged in and had recent browser activity in Mattermost.
|
||||
|
||||
Newly Created Users
|
||||
Most recent users who have joined the team.
|
||||
|
||||
## Troubleshooting/FAQ
|
||||
|
||||
### I see an error: "Not enough data for a meaningful representation"
|
||||
|
||||
If the statistics page is loading endlessly and you get an error message saying "Not enough data for a meaningful representation", check whether you're using an ad blocker. An ad blocker can prevent this page from loading data. To test this, temporarily disable your ad blocker, or view the page in a browser without an ad blocker installed.
|
||||
|
||||
### Can team admins review their own team's statistics?
|
||||
|
||||
<PlanAvailability slug="entry-ent" />
|
||||
|
||||
Yes. With self-hosted deployments, you can enable team admins to see their team's statistics by modifying available delegated granular administration system roles. See the [delegated granular administration](/administration-guide/onboard/delegated-granular-administration) documentation to learn more about these admin roles, including how to manage privileges and assign roles.
|
||||
|
||||
To enable team admins to access their team's statistics:
|
||||
|
||||
1. Go to **System Console \> User Management \> System Roles**, then edit the **Viewer** system admin role.
|
||||
|
||||

|
||||
|
||||
2. Under **Privileges**, expand the **Reporting** section, set **Team Statistics** to **Read only**, then set **System Statistics** and **Server Logs** to **No access**.
|
||||
3. Set all other privileges to **No access** to restrict all users with the **Viewer** role to access only the **Team Statistics** page in the System Console.
|
||||
|
||||

|
||||
|
||||
4. Under **Assigned People**, select **Add People** to assign team admins to the **Viewer** role, and enable them to access their team's statistics.
|
||||
|
||||

|
||||
|
||||
5. Select **Save**.
|
||||
|
||||
<Note>
|
||||
|
||||
System admins must manually add people to or remove people from the **Viewer** system admin role to address team admin changes, such as promotions or demotions.
|
||||
|
||||
</Note>
|
||||
@@ -0,0 +1,18 @@
|
||||
---
|
||||
title: "System-wide notifications"
|
||||
---
|
||||
<PlanAvailability slug="all-commercial" />
|
||||
|
||||
System admins can configure system-wide notifications visibile in all channels for all users across all teams.
|
||||
|
||||

|
||||
|
||||
1. Enable system-wide notifications by going to **System Console \> Site Configuration \> System-wide notifications**, and setting **Enable system-wide notifications** to **true**.
|
||||
2. In the **Banner Text** field, enter the notification text you want to share in channels.
|
||||
3. Specify the background and text colors for the banner.
|
||||
4. By default, users can dismiss the banner until they log in again or until you update the banner. To prevent users from dismissing the banner, set **Allow Banner Dismissal** to **false**.
|
||||
5. Select **Save**.
|
||||
|
||||
Update the banner by either changing the text of the banner or by re-enabling the banner after it's been disabled.
|
||||
|
||||
To disable the banner, set **Enable Announcement Banner** to **false**.
|
||||
145
docs/main/administration-guide/manage/team-channel-members.mdx
Normal file
145
docs/main/administration-guide/manage/team-channel-members.mdx
Normal file
@@ -0,0 +1,145 @@
|
||||
---
|
||||
title: "Manage team and channel members"
|
||||
---
|
||||
<PlanAvailability slug="all-commercial" />
|
||||
|
||||
System admins can manage channel configuration in the System Console, including:
|
||||
|
||||
- **Management:** Manage synchronization, moderation, and membership settings.
|
||||
- **Promoting/demoting Team and Channel Admins:** Team admins and channel admins can be demoted via the System Console.
|
||||
- **View channel members:** System admins can view members of a channel without having to join the channel.
|
||||
- **Member count:** Total member count in a team or channel.
|
||||
- **Archive channels:** System admins can archive channels without having to join the channel.
|
||||
|
||||
## Teams
|
||||
|
||||
To view and manage team information, navigate to **System Console \> Teams**. Teams can be managed by **Group Sync** or **Invite Only**. The type of management in use may affect the management options available for that team.
|
||||
|
||||
Select a team to view its configuration options.
|
||||
|
||||
### Team profile
|
||||
|
||||
The name and description of the team.
|
||||
|
||||
System admins can archive or unarchive the team from within **User Management \> Teams \> Team Management**. Archiving a team makes its contents inaccessible for all users. All related information is archived, including posts from the database. Before archiving a team, we recommend that you perform a database backup.
|
||||
|
||||
### Archive a team
|
||||
|
||||
Select **Archive Team**, then select **Save**. Select **Archive** when prompted to confirm the team archive.
|
||||
|
||||
Alternatively, system admins can use the mmctl `mmctl team archive` to archive teams. See the [mmctl product documentation](/administration-guide/manage/mmctl-command-line-tool#mmctl-team-archive) for details.
|
||||
|
||||
### Unarchive a team
|
||||
|
||||
Select **Unarchive Team**, then select **Save**.
|
||||
|
||||
Alternatively, system admins can use the mmctl `mmctl team restore` to archive teams. See the [mmctl product documentation](/administration-guide/manage/mmctl-command-line-tool#mmctl-team-restore) for details.
|
||||
|
||||
### Team management
|
||||
|
||||
<PlanAvailability slug="entry-adv" />
|
||||
|
||||
- When **Sync Group Members** is enabled, the **Synced Groups** list is visible and additional groups can be added.
|
||||
- When **Sync Group Members** is not enabled, invitation limitations can be selected.
|
||||
|
||||
### Groups
|
||||
|
||||
<PlanAvailability slug="entry-adv" />
|
||||
|
||||
You can add and remove groups, as well as promote or demote group members to team admin/member roles.
|
||||
|
||||
### Members
|
||||
|
||||
A list of all members in a channel is visible to system admins. Members can be added and removed from the team members and be promoted or demoted to a team admin/member role. Use the role **Filter** to refine your search results. You can use one filter, or combine filters to search by multiple roles:
|
||||
|
||||
- Guest
|
||||
- Member
|
||||
- Team admin
|
||||
- System admin
|
||||
|
||||
## Channels
|
||||
|
||||
To view and manage channel information, navigate to **System Console \> Channels**. Channels can be managed by **Group Sync** or **Manual Invites**. The type of management in use may affect the management options available for that channel. Use the **Filter** to refine your search results. You can use one filter, or combine filters to search by channel and management type:
|
||||
|
||||
- Public channels
|
||||
- Private channels
|
||||
- Archived channels
|
||||
- Channels that are synchronized to an AD/LDAP Group
|
||||
- Channels with users who were invited manually (not synced from LDAP)
|
||||
|
||||
Select a channel to view its configuration options.
|
||||
|
||||
### Profile
|
||||
|
||||
The name and description of the channel. To archive the channel, select **Archive Channel \> Save**. The channel is still searchable in the **Channels** list. To unarchive the channel, select **Unarchive Channel** and **Save**.
|
||||
|
||||
### Channel management
|
||||
|
||||
<PlanAvailability slug="entry-adv" />
|
||||
|
||||
- When **Sync Group Members** is enabled, the **Synced Groups** list is visible and additional groups can be added.
|
||||
- When **Sync Group Members** is not enabled, you can select whether the channel is **Private** or **Public**.
|
||||
|
||||
### Advanced access controls
|
||||
|
||||
<PlanAvailability slug="entry-adv" />
|
||||
|
||||
Advanced access control settings enable system admins to restrict actions within specific channels. These actions include:
|
||||
|
||||
- **Make channel read-only:** [Read-only channels](/administration-guide/onboard/advanced-permissions#read-only-channels) enable system admins to turn off posting in specified channels.
|
||||
- **Restrict reactions:** Turn off the ability for members and guests to post reactions.
|
||||
- **Restrict channel mentions:** Turn off the ability for users to post channel wide mentions (@all/@channel/@here) in specified channels.
|
||||
- **Channel member management:** Only admins have the ability to add and remove channel members in the specified channels.
|
||||
- **Bookmarks management:** Only channel and system admins can [manage channel bookmarks](/end-user-guide/collaborate/manage-channel-bookmarks).
|
||||
|
||||
These settings are modified in **System Console \> User Management \> Channels**.
|
||||
|
||||
<Note>
|
||||
|
||||
These settings are applicable only to Guests and Members. System, team, and channel admins aren't affected. If you wish to grant posting ability to a specific member, you must first promote that member to channel admin.
|
||||
|
||||
</Note>
|
||||
|
||||
The availability of advanced access control settings can also be affected by existing system and team permissions configurations. If there are existing configurations that override the channel settings you would like to apply, it will be indicated in the user interface. These settings can then be adjusted in the relevant panel in the **Permissions** section of the System Console.
|
||||
|
||||
**Configure a channel so that members can post/reply/react but guests can only read and react.**
|
||||
|
||||
1. Navigate to **System Console \> User Management \> Channels**.
|
||||
2. Select **Edit** next to the name of the channel you want to configure.
|
||||
3. In the **Create Posts** panel, uncheck **Guests**.
|
||||
4. In the **Post Reactions** panel, uncheck **Guests** if required.
|
||||
5. Select **Save**.
|
||||
|
||||
The channel is available for all members and guests to access, but guests can only read messages and react to them.
|
||||
|
||||
**Create an Announcement Channel where only Channel Admins are able to post (read-only).**
|
||||
|
||||
1. Create a new channel (either Public or Private).
|
||||
2. Navigate to **System Console \> User Management \> Channels**.
|
||||
3. Select **Edit** next to the name of the channel you just created (you may need to search for it).
|
||||
4. In the **Create Posts** panel, uncheck **Guests** and **Members**.
|
||||
5. In the **Post Reactions** panel, uncheck **Guests** and **Members**.
|
||||
6. Select **Save**.
|
||||
|
||||
The channel is available for all members and guests to access but only Admins can post to the channel.
|
||||
|
||||
### Groups
|
||||
|
||||
<PlanAvailability slug="entry-adv" />
|
||||
|
||||
You can add and remove groups, as well as promote or demote group members to team admin/member roles.
|
||||
|
||||
### Members
|
||||
|
||||
A list of all members in a channel is visible to system admins. Members can be added and removed from the team members and be promoted or demoted to a team admin/member role. Use the role **Filter** to refine your search results. You can use one filter, or combine filters to search by multiple roles:
|
||||
|
||||
- Guest
|
||||
- Member
|
||||
- Channel admin
|
||||
- System admin
|
||||
|
||||
<Note>
|
||||
|
||||
From Mattermost v11.5.2, system admins can set the complete membership of a channel in a single API call. The server computes the diff against the current membership and adds or removes users as needed. See the [API documentation](https://api.mattermost.com/#tag/channels/operation/SetChannelMembers) for details.
|
||||
|
||||
</Note>
|
||||
103
docs/main/administration-guide/manage/telemetry.mdx
Normal file
103
docs/main/administration-guide/manage/telemetry.mdx
Normal file
@@ -0,0 +1,103 @@
|
||||
---
|
||||
title: "Telemetry"
|
||||
---
|
||||
As described in the privacy policy in each Mattermost server, telemetry data optionally shared from your Mattermost servers is used to identify security and reliability issues, to analyze and fix software problems, to help improve the quality of Mattermost software and related services, and to make design decisions for future releases.
|
||||
|
||||
Telemetry data is encrypted in transit, does not include personally identifiable information or message contents, and details of how the information is used and processed is available in our [Privacy Policy](https://mattermost.com/privacy-policy/).
|
||||
|
||||
We use the data for the following purposes to:
|
||||
|
||||
- Identify security and reliability issues.
|
||||
- Analyze and fix software problems.
|
||||
- Help improve the quality of Mattermost software and related services.
|
||||
- Make design decisions for future releases.
|
||||
|
||||
<Note>
|
||||
|
||||
Telemetry data collection is enabled by default for all Mattermost deployments. Self-hosted system admins can opt out of sharing telemetry data from Mattermost self-hosted servers within the System Console. Cloud system admins can't disable telemetry for Mattermost Cloud deployments.
|
||||
|
||||
</Note>
|
||||
|
||||
## Security update check feature
|
||||
|
||||
New threats to system security constantly arise. To alert you of relevant, high priority security updates, Mattermost servers are configured to share diagnostic information with Mattermost Inc. so that we can provide appropriate alerts.
|
||||
|
||||
The following data is collected once every 24 hours:
|
||||
|
||||
- Mattermost server build number and version
|
||||
- Type of build (Enterprise Edition or Team Edition)
|
||||
- Server operating system
|
||||
- The server diagnostic ID (same as the ID accessing the push notification proxy, and is used to prevent double-counting of telemetry data)
|
||||
- Database type
|
||||
- Database version
|
||||
- Number of teams
|
||||
- Number of users
|
||||
- Number of activated users
|
||||
- Whether or not the unit tests have been run
|
||||
- Date and time of the last check for security updates
|
||||
|
||||
### Opt out
|
||||
|
||||
To opt out, you can disable this security update check feature for self-hosted deployments in the System Console by going to **Environment \> SMTP \> Enable Security Alerts**. See the [enable security alerts](/administration-guide/configure/environment-configuration-settings#enable-security-alerts) documentation for details. When this feature is disabled, you will not receive any security alerts.
|
||||
|
||||
## Error and diagnostics reporting feature
|
||||
|
||||
When enabled, server errors and panics are automatically sent to the Mattermost-hosted [Sentry](https://sentry.io/welcome/) endpoint for diagnosis. No message content or personally identifiable information is included.
|
||||
|
||||
Mattermost error and diagnostic data is collected for the following purposes:
|
||||
|
||||
- To add improvements that are specific to your usage, upgrade, and deployment patterns, including identifying security and reliability issues.
|
||||
- To analyze and fix software problems.
|
||||
- To help improve the quality of Mattermost software and related services.
|
||||
- To make design decisions for future releases.
|
||||
|
||||
### Opt out
|
||||
|
||||
To opt out, you can disable the error and diagnostics reporting feature for self-hosted deployments in the System Console by going to **Environment \> Logging \> Enable Diagnostics and Error Reporting**. See the [enable diagnostics and error reporting](/administration-guide/configure/environment-configuration-settings#enable-diagnostics-and-error-reporting) documentation for details.
|
||||
|
||||
## Android Mobile App performance monitoring
|
||||
|
||||
To improve Android app performance, we are collecting trace events and device information, collectively known as metrics, to identify slow performing key areas. Those metrics will be sent only from users using the Android app Beta build starting in version v1.20, who are logged in to servers that allow sending [diagnostic information](/administration-guide/configure/environment-configuration-settings#enable-diagnostics-and-error-reporting).
|
||||
|
||||
Trace events
|
||||
Includes duration on how long the action took place like startup, team/channel switch, posts loading/update and channel drawer open/close. The naming convention is interpreted as `[start observation]:[end observation]`, e.g. `start:overall` as from app start until fully rendered or `post_list:thread` as on press of post at post list until thread is opened. Complete list of trace events are the following:
|
||||
|
||||
- start:overall
|
||||
- start:process_packages
|
||||
- start:content_appeared
|
||||
- start:select_server_screen
|
||||
- start:channel_screen
|
||||
- team:switch
|
||||
- channel:loading
|
||||
- channel:switch_loaded
|
||||
- channel:switch_initial
|
||||
- channel:close_drawer
|
||||
- channel:open_drawer
|
||||
- posts:loading
|
||||
- post_list:thread
|
||||
- post_list:permalink
|
||||
|
||||
Device information
|
||||
The information being collected is non-personally identifiable. Except for system_version, device information is based from [react-native-device-info](https://github.com/mattermost/react-native-device-info#react-native-device-info) library. Refer to the linked documentation to learn more. Complete list of device information are the following:
|
||||
|
||||
- api_level
|
||||
- build_number
|
||||
- bundle_id
|
||||
- brand
|
||||
- country
|
||||
- device_id
|
||||
- device_locale
|
||||
- device_type
|
||||
- device_unique_id
|
||||
- height
|
||||
- is_emulator
|
||||
- is_tablet
|
||||
- manufacturer
|
||||
- max_memory
|
||||
- model
|
||||
- server_version
|
||||
- system_name
|
||||
- system_version
|
||||
- timezone
|
||||
- version
|
||||
- width
|
||||
@@ -0,0 +1,85 @@
|
||||
---
|
||||
title: "User satisfaction surveys"
|
||||
---
|
||||
<PlanAvailability slug="all-commercial" />
|
||||
|
||||
Feedback is used to measure user satisfaction and improve product quality by hearing directly from users. Please refer to our [privacy policy](https://mattermost.com/privacy-policy/) for information on the collection and use of information received through our services.
|
||||
|
||||
<Important>
|
||||
|
||||
**Mattermost User Satisfaction Surveys are deprecated from Mattermost v10.11** and are no longer included as a pre-packaged plugin for new Mattermost deployments. Existing deployments that have this plugin enabled will continue to work, but we strongly recommend migrating to [user surveys](/administration-guide/configure/manage-user-surveys) for enhanced customization options, and local data storage, without telemetry data transmission back to Mattermost.
|
||||
|
||||
</Important>
|
||||
|
||||
## Administration
|
||||
|
||||
### Is the survey enabled by default?
|
||||
|
||||
**For Mattermost Server versions prior to v10.11**: The user satisfaction survey is a pre-packaged plugin, and surveys are enabled by default on all servers. However, the plugin will not be activated on any servers that have [Error and Diagnostic Reporting](/administration-guide/manage/telemetry) disabled, meaning no surveys or data collection occurs.
|
||||
|
||||
**For Mattermost Server v10.11 and later**: The User Satisfaction Survey Plugin is no longer included as a pre-packaged plugin for new deployments. We recommend using the [Mattermost User Survey integration](/administration-guide/configure/manage-user-surveys) instead.
|
||||
|
||||
### How can surveys be disabled?
|
||||
|
||||
Disabling the **User Satisfaction Surveys** plugin from **System Console \> Plugins \> Plugin Management** will disable surveys and all data collection by the plugin.
|
||||
|
||||
<Note>
|
||||
|
||||
- If surveys have been disabled from the plugin configuration in **System Console \> Plugins \> User Satisfaction Surveys**, but the plugin itself is still enabled, surveys won't be scheduled but users can still send written feedback by messaging Surveybot.
|
||||
- When the plugin or surveys in the plugin configuration are disabled, they remain disabled for subsequent server upgrades.
|
||||
|
||||
</Note>
|
||||
|
||||
### When is the survey scheduled?
|
||||
|
||||
Users will receive surveys 21 days after every server upgrade, assuming the following conditions are true:
|
||||
|
||||
- User Satisfaction Surveys plugin is enabled in **System Console \> Plugins \> Plugin Management**.
|
||||
- Surveys are enabled in the plugin configuration in **System Console \> Plugins \> User Satisfaction Surveys**.
|
||||
- User account is greater than 21 days old.
|
||||
- User has not completed a survey in the last 90 days.
|
||||
- User has not been sent a survey in the last 90 days.
|
||||
- Current server version is greater than the server version of the last survey, excluding dot releases.
|
||||
|
||||
The above conditions mean that at maximum frequency a user will receive a survey every 90 days, assuming the server is upgraded within that time period.
|
||||
|
||||
### How will I be notified when a survey is scheduled?
|
||||
|
||||
System admins will receive an email notification and in-product direct message from "Surveybot" mentioning the scheduled date the survey will be triggered.
|
||||
|
||||

|
||||
|
||||
## Survey Data
|
||||
|
||||
### How is the survey received?
|
||||
|
||||
Once the survey is triggered on the server, all users will receive an in-product direct messages from "Surveybot" on their next login or page refresh in Mattermost.
|
||||
|
||||
Users can optionally select a 0-10 score on how likely they are to recommend Mattermost and then provide written feedback about their experience. Selecting a score and providing feedback are optional, and the survey can be ignored without interrupting usage of Mattermost.
|
||||
|
||||

|
||||
|
||||
### What data is collected?
|
||||
|
||||
Data is only collected when a user selects a score or provides written feedback in response to survey questions. Please refer to our [privacy policy](https://mattermost.com/privacy-policy/) for more information on the collection and use of information received through our services. The following **non-personally identifiable information** is collected:
|
||||
|
||||
- Survey information:
|
||||
- Score (0-10) submitted by the user
|
||||
- Written feedback submitted by the user (if applicable)
|
||||
- Timestamp of the survey submission
|
||||
|
||||
- Server information:
|
||||
- Server/Web App version the survey was submitted on
|
||||
- Installation date of the server
|
||||
- Diagnostic ID used for error and diagnostics reporting
|
||||
- License ID used for error and diagnostics reporting (if applicable)
|
||||
- Enterprise or Professional (if applicable)
|
||||
|
||||
- User information:
|
||||
- User role (system admin, team admin, or member)
|
||||
- Account creation timestamp
|
||||
- User ID of the surveyed user
|
||||
|
||||
### Will this data be sent through my firewall?
|
||||
|
||||
If Mattermost is self-hosted in a private network with firewall then data from the User Satisfaction Surveys plugin is not sent unless outbound connections are allowed or specifically configured for this plugin.
|
||||
@@ -0,0 +1,357 @@
|
||||
---
|
||||
title: "AD/LDAP groups"
|
||||
---
|
||||
import useBaseUrl from '@docusaurus/useBaseUrl';
|
||||
|
||||
<PlanAvailability slug="entry-ent" />
|
||||
|
||||
## Overview
|
||||
|
||||
The groups feature is useful for organizations that have many new users to onboard or that onboard users frequently and want to ensure users are added to default teams and channels that are pertinent to them. The group feature currently supports:
|
||||
|
||||
- Creating groups by synchronization with your AD/LDAP system groups.
|
||||
- Syncing groups to pre-defined roles in Mattermost.
|
||||
- AD/LDAP nested groups.
|
||||
- Using synchronized groups to manage [membership of teams and Private channels](/administration-guide/onboard/ad-ldap-groups-synchronization#synchronize-teams-and-channels).
|
||||
|
||||
For a technical overview of the feature by Martin Kraft, who led the development of the feature, please see [this blog post](https://developers.mattermost.com/blog/ldap-nested-groups-modelling-and-representation-in-code).
|
||||
|
||||
You can also watch a video overview about adding users to Mattermost with AD/LDAP on [YouTube](https://www.youtube.com/watch?v=zyku2ibsG0M).
|
||||
|
||||
<div style={{position: 'relative', paddingBottom: '50%', height: '0', overflow: 'hidden', maxWidth: '100%', height: 'auto'}}>
|
||||
<iframe src="https://www.youtube.com/embed/zyku2ibsG0M" alt="Video about adding users to Mattermost using AD/LDAP" frameborder="0" allowfullscreen style={{position: 'absolute', top: '0', left: '0', width: '100%', height: '95%'}}></iframe>
|
||||
</div>
|
||||
|
||||
## Pre-installation notes
|
||||
|
||||
If you have enabled synchronization with AD/LDAP, all groups matching the default filter `(|(objectClass=group)(objectClass=groupOfNames)(objectClass=groupOfUniqueNames))` will be available to be linked in the groups list view at **System Console \> User Management \> Groups**.
|
||||
|
||||
The group filter is an optional configuration setting available in the **User Filters** section of the AD/LDAP wizard (**System Console \> Authentication \> AD/LDAP**) and allows you to specify the groups that should have access in Mattermost. The **Group** filter is independent of the **User** filter; however, it does leverage the Base DN attribute. You may need to adjust your Base DN to ensure group objects can be searched in your AD/LDAP tree.
|
||||
|
||||
The synchronization of groups happens with the synchronization of users, during which Mattermost queries AD/LDAP for updated account information. Please see the [Active Directory/LDAP Set up documentation](/administration-guide/onboard/ad-ldap). for more information. The group feature has no effect on users' authentication to Mattermost.
|
||||
|
||||
## Enable AD/LDAP group synchronization
|
||||
|
||||
To enable this feature, go to **System Console \> User Management \> Groups**.
|
||||
|
||||
## Synchronize AD/LDAP groups to Mattermost
|
||||
|
||||
To synchronize specific AD/LDAP groups to Mattermost, specify the `Group ID Attribute` and the `Group Display Name Attribute` (e.g., "cn" for Common Name) in the **Group Synchronization** section of the AD/LDAP wizard (**System Console \> Authentication \> AD/LDAP**).
|
||||
|
||||
Additionally, you can specify the **Group** filter used to retrieve groups. If the **Group** filter configuration is left blank, then all groups matching the default filter `(|(objectClass=group)(objectClass=groupOfNames)(objectClass=groupOfUniqueNames))` are returned. Attribute values for **Group ID** and **Group Display Name** are case-sensitive.
|
||||
|
||||

|
||||
|
||||
Group synchronization occurs after user synchronization and results for group synchronization are available on the synchonization status table (located at the bottom of the **AD/LDAP** configuration page). After the AD/LDAP groups have been synchronized, go to **System Console \> User Management \> Groups** to link and configure Mattermost groups.
|
||||
|
||||
<Note>
|
||||
|
||||
The synchronization process doesn't create Mattermost groups. Mattermost groups are created when you “link” the AD/LDAP group as outlined in the next section **Linking AD/LDAP groups to Mattermost groups**. Existing AD/LDAP users are added to the Mattermost groups on the next synchronization and new users are added on their first login.
|
||||
|
||||
</Note>
|
||||
|
||||
On subsequent synchronizations and once groups are linked:
|
||||
|
||||
> - Users that have been added to an AD/LDAP group will be added to the linked Mattermost group and to teams and channels configured for that group.
|
||||
> - Mattermost groups that are linked to AD/LDAP groups no longer included in your filter are deleted.
|
||||
> - Users removed from an AD/LDAP group are removed from the linked Mattermost group, but their channel and team membership is only revoked when the channel or team is synchronized to an AD/LDAP group.
|
||||
|
||||

|
||||
|
||||
## Link AD/LDAP groups to Mattermost groups
|
||||
|
||||
Groups that have been returned from the default filter or your AD/LDAP group filter will be available in a list view on the Groups page. The link action will create Mattermost groups corresponding to the AD/LDAP group. AD/LDAP groups linked to a Mattermost group will display the **Linked** icon. AD/LDAP groups that have not been linked to a Mattermost group will display the **Not Linked** icon. An AD/LDAP group that is not linked does not create a Mattermost group.
|
||||
|
||||

|
||||
|
||||
You can link groups individually by the inline **Linked** button and use the checkbox next to the group name to select multiple groups and choose **Link Selected Groups**. When selecting multiple groups with a mix of **Linked** and **Not Linked** states, the bulk action of the button will be **Link Selected Groups** until all selected are marked **Linked**. Using the bulk action speeds the process of creating Mattermost groups from your AD/LDAP Groups.
|
||||
|
||||
If you see a **Link Failed** message, either select the message, or check the box alongside the group name to expose the inline link message and try again.
|
||||
|
||||

|
||||
|
||||
## Configure the linked group
|
||||
|
||||
AD/LDAP groups that have been linked to Mattermost groups can be configured to add team and channels. To configure the group, select **Configure \> Group Configuration** and view the group profile which includes the group name. This name is automatically mapped from the AD/LDAP group common name attribute and is read-only.
|
||||
|
||||
## Add default teams or channels for the group
|
||||
|
||||
To add the teams and channels that you want the group members to default in, select either **Add Team** or **Add Channel** from the **Add Team or Channel** button. You can assign roles to group members using the options provided in the **Assigned Roles** column. Roles are updated on the next scheduled AD/LDAP synchronization.
|
||||
|
||||

|
||||
|
||||
Channels are nested below the team they belong to in the team and channel list. The following table describes the icons available on this page and what they indicate:
|
||||
|
||||
<table style={{width: '59%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '27%'}} />
|
||||
<col style={{width: '31%'}} />
|
||||
</colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th><strong>Icon</strong></th>
|
||||
<th><strong>Description</strong></th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><img src={useBaseUrl('/images/open_team.png')} alt="image" /></td>
|
||||
<td>Team is open for anyone to join.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><img src={useBaseUrl('/images/private_team.png')} alt="image" /></td>
|
||||
<td>Team isn't open for anyone to join.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><img src={useBaseUrl('/images/public_channel.png')} alt="image" /></td>
|
||||
<td>Public channel.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><img src={useBaseUrl('/images/private_channel.png')} alt="image" /></td>
|
||||
<td>Private channel.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<Note>
|
||||
|
||||
- When a team is added, the `Town Square` and `Off-Topic` channels will also be created automatically, as well as any default channels set in the [ExperimentalDefaultChannels config setting](/administration-guide/configure/experimental-configuration-settings#default-channels).
|
||||
- When a channel is added without setting the team explicitly, the team will be shown in the **Team and Channel Membership** listing, but it won't be added to the group specifically. Because of this dependency, when the channel is removed, the team will also be removed. Teams are listed in parentheses after the channel name in the channel selector.
|
||||
|
||||
</Note>
|
||||
|
||||
## Synchronize teams and channels
|
||||
|
||||
For new users, default teams and channels will be added when they log in for the first time. For existing users, default teams and channels will be added after the next scheduled AD/LDAP sychronization.
|
||||
|
||||
It may take a few seconds to load all team and channel memberships for a user depending on the number of teams and channels the group is defaulted to. In our testing, it took six seconds for an organization with 200,000 users and 30,000 linked groups.
|
||||
|
||||
<Note>
|
||||
|
||||
Users aren't removed from the team or channel on subsequent synchronizations of the AD/LDAP groups. Users need to be manually removed from the team or channel per the existing functionality. They won't be automatically re-added if they were manually removed or removed themselves. To manage a team or Private channel membership with synchronized groups, please see the section below on **Disable and re-activate AD/LDAP users** for details.
|
||||
|
||||
</Note>
|
||||
|
||||

|
||||
|
||||
## Remove configured teams and channels from a group
|
||||
|
||||
To remove a team or channel configured for a group, select **Remove** to the right of the team or channel name. Users already part of the team and channel won't be removed from that channel by this action.
|
||||
|
||||
## View users belonging to the group
|
||||
|
||||
Users who have logged in and accessed Mattermost will be visible in the members list on the group object. Members are read-only at this time and new members can be added through management in your AD/LDAP system.
|
||||
|
||||

|
||||
|
||||
Users can be removed from the Mattermost group on subsequent synchronizations. However, they won't be removed from teams and channels unless the team or channel is group-synchronized.
|
||||
|
||||
<Note>
|
||||
|
||||
When a member removes themselves manually from a channel, that action is tracked in the **Channel Member History** table. If a system admin manually forces all members in a specific LDAP group to join the teams and channels synchronized to that group, members can potentially be re-added to channels from which they were previously removed.
|
||||
|
||||
</Note>
|
||||
|
||||
## Disable and re-activate AD/LDAP users
|
||||
|
||||
If a member is removed from an AD/LDAP group, deactivated in AD/LDAP, or filtered from the AD/LDAP user filter, that member loses access to Mattermost.
|
||||
|
||||
From Mattermost v7.7, system admins can add members back to all of the member's default teams and channels in the System Console by going to **User Management \> Users**, selecting the user's role, then selecting the **Re-sync user via LDAP groups** option.
|
||||
|
||||
<Tip>
|
||||
|
||||
Using the Mattermost API, system admins can manually re-add all group members back into synchronized teams or channels by forcing members in an LDAP group to join the teams and channels synchronized to that group, even if members left on their own, were removed, were filtered out, or were deactivated. See our [Mattermost API documentation](https://api.mattermost.com/#operation/SyncLdap) for details on synchronizing user attribute changes in the configured AD/LDAP server with Mattermost.
|
||||
|
||||
</Tip>
|
||||
|
||||
## Manage groups
|
||||
|
||||
Once a group has been configured, the default teams and channels can be changed via the **Edit** option on the group list view.
|
||||
|
||||
## Delete groups
|
||||
|
||||
Mattermost groups can be deleted by adjusting your AD/LDAP group filter to remove the group or by unlinking the group on the Groups listing page. If you add the group back by re-adjusting the AD/LDAP group filter and link the group again on the group configuration page, the previous team and channel configurations will be available.
|
||||
|
||||
## Use AD/LDAP synchronized groups to manage team or private channel membership
|
||||
|
||||
Mattermost groups created with synchronized AD/LDAP groups can be used to manage the membership of private teams and private channels. When a team or private channel is managed by synchronized groups, member users will be added and removed based on their membership to the synchronized AD/LDAP group.
|
||||
|
||||
<Note>
|
||||
|
||||
It is not possible to add guests to teams and channels that are managed using groups.
|
||||
|
||||
</Note>
|
||||
|
||||
For instance, you may have an AD/LDAP group that contains your development team that you want to synchronize to a developer team. By using this feature, new developers will get added to the team when they are added to the synchronized AD/LDAP group and they will be removed from the team when removed from the AD/LDAP group.
|
||||
|
||||
Similarly, you may have an AD/LDAP group that contains your leadership team that you want to synchronize to a private channel for coordination and updates.
|
||||
|
||||
This feature helps control the membership of the channel so that guests and member users outside of the synchronized group are prevented from being added to the channel mistakenly.
|
||||
|
||||
On teams that are managed by synchronized groups, guests, and member users outside of the group are restricted from:
|
||||
|
||||
> - Invitation through a team invite link.
|
||||
> - Invitations through an email invite.
|
||||
|
||||
Similarly on private channels that are managed by synchronized groups, guests and member users outside of the group are restricted from:
|
||||
|
||||
> - Invitation through a mention.
|
||||
> - Invitation through the `/invite` slash command.
|
||||
> - Being added to the channel via the **Add Members** menu option.
|
||||
|
||||
Users can remove themselves from teams and Private channels managed by synchronized groups.
|
||||
|
||||
### Manage membership of a team or channel with synchronized groups
|
||||
|
||||
To manage membership of a private team with synchronized groups:
|
||||
|
||||
1. Go to **System Console \> User Management \> Teams**. Select the team you want to manage with group synchronization.
|
||||
2. Under **Team Management**, enable **Sync Group Members**. If **Anyone can join this team** is enabled or if specific email domains are set, they will be disabled by the Sync Group Members feature.
|
||||
3. Add one or more groups to the team. If there are groups already associated with default users in the team, they'll be listed.
|
||||
4. Review the notice in the footer of the screen for any users that are not part of groups who will be removed from the team on the next synchronization.
|
||||
5. Select **Save**. Members will be updated on the next scheduled AD/LDAP synchronization.
|
||||
|
||||
Alternatively, you can use the mmctl tools to set the team to be managed by groups:
|
||||
|
||||
1. Ensure there is at least one group already associated to the team. You can view and add default teams to a group via **System Console \> User Management \> Groups \> Group Configuration**. Please see more information on adding default teams and channels [here](/administration-guide/onboard/ad-ldap-groups-synchronization#add-default-teams-or-channels-for-the-group). Additionally, you can use the mmctl to confirm if there is already a group associated to the team by running the [mmctl group team list](/administration-guide/manage/mmctl-command-line-tool#mmctl-group-team-list) command.
|
||||
2. Ensure **Team Settings \> General \> Allow any user with an account on this server to join this team** is set to **No**.
|
||||
3. Convert the team to have its membership managed by synchronized groups by running the [mmctl group team enable](/administration-guide/manage/mmctl-command-line-tool#mmctl-group-team-enable) command.
|
||||
|
||||
To manage membership of a private channel with synchronized groups:
|
||||
|
||||
1. Go to **System Console \> User Management \> Channels**. Select the channel you want to manage with group synchronization.
|
||||
2. Under **Channel Management**, enable **Sync Group Members**. Please ensure the channel is set to **private**.
|
||||
3. Add one or more groups to the channel. If there are groups already associated with default users in the team, they'll be listed.
|
||||
4. Review the notice in the footer of the screen for any users that are not part of groups who will be removed from the channel on the next synchronization.
|
||||
5. Select **Save**.
|
||||
|
||||
Members will be updated on the next scheduled AD/LDAP synchronization. Alternatively, you can use the mmctl to set a private channel to be managed by groups:
|
||||
|
||||
1. Ensure there is at least one group already associated to the channel. You can view and add default channels to a group via **System Console \> User Management \> Groups \> Group Configuration**. Please see more information on adding default teams and channels [here](/administration-guide/onboard/ad-ldap-groups-synchronization#add-default-teams-or-channels-for-the-group). Additionally, you can use the mmctl to view if there is already a group associated to the channel by running the [mmctl group channel list](/administration-guide/manage/mmctl-command-line-tool#mmctl-group-channel-list) command.
|
||||
2. Convert the team to have its membership managed by synchronized groups by running the [mmctl group channel enable](/administration-guide/manage/mmctl-command-line-tool#mmctl-group-channel-enable) command.
|
||||
|
||||
### Assign roles to group members
|
||||
|
||||
Group members can be assigned predefined roles by system admins, which are applied across the group during the scheduled sychronization. The roles are:
|
||||
|
||||
- Member (default)
|
||||
- Team admin (in teams)
|
||||
- Channel admin (in channels)
|
||||
|
||||
The permissions for each role can be viewed and modified in **System Console \> Permissions**.
|
||||
|
||||
**To set the Team admin role in a synced group**
|
||||
|
||||
1. Go to **System Console \> User Management \> Teams**.
|
||||
2. Select **Edit** next to the team you want to configure.
|
||||
3. Ensure that **Sync Group Members** is enabled.
|
||||
4. Choose **Add Group** to add one or more groups to the team. If there are groups already associated to default users into the team, they will already be present.
|
||||
5. Select the arrow next to the current role in the **Roles** column to display and select the **Team Admin** option.
|
||||
6. Repeat as needed for any other synced groups you have added.
|
||||
7. Select **Save**.
|
||||
|
||||
Roles are updated on the next scheduled AD/LDAP synchronization.
|
||||
|
||||
**To set the Channel Admin role in a synced group**
|
||||
|
||||
1. Go to **System Console \> User Management \> Channels**.
|
||||
2. Select **Edit** next to the team you want to configure.
|
||||
3. Ensure that **Sync Group Members** is enabled.
|
||||
4. Choose **Add Group** to add one or more groups to the team. If there are groups already associated with default users in the team, they'll be listed.
|
||||
5. Select the arrow next to the current role in the **Roles** column to display and select the **Channel Admin** option.
|
||||
6. Repeat as needed for any other synced groups you have added.
|
||||
7. Select **Save**.
|
||||
|
||||
Roles are updated on the next scheduled AD/LDAP synchronization.
|
||||
|
||||
<Note>
|
||||
|
||||
Members who have been synced as part of a group cannot have their role changed via **View Members** in Mattermost.
|
||||
|
||||
</Note>
|
||||
|
||||
### Add or remove groups from teams
|
||||
|
||||
Once team management is converted to use synchronized groups, team admins and system admins can add additional groups from **Main Menu \> Add Groups to Team**. This will add users to the next AD/LDAP synchronization, and any new users to the group will be added to the team on subsequent synchronizations. Team admins will be prevented from converting the team to a public space by enabling **Team Settings \> Allow any user with an account on this server to join this team**.
|
||||
|
||||
Team admins and system admins can also remove groups from a team from **Main Menu \> Manage Groups**. This will disassociate the group from the team. Users are removed on the next AD/LDAP synchronization.
|
||||
|
||||
The system admin can remove groups from **System Console \> User Management \> Teams \> Team Configuration \> Synced Groups**.
|
||||
|
||||
### Add or remove groups from private channels
|
||||
|
||||
Once the management of the channel is converted to be managed by synchronized groups, team admins and system admins can add additional groups from **Channel Menu \> Add Groups to Channel**. This will add users on the next AD/LDAP synchronization and any new users to the group will be added to the channel on subsequent synchronizations.
|
||||
|
||||
Team admins and system admins can also remove groups from a team from **Main Menu \> Manage Groups**. This will disassociate the group from the team. Users are removed on the next AD/LDAP synchronization.
|
||||
|
||||
The system admin can remove groups from **System Console \> User Management \> Channels \> Channel Configuration \> Synced Groups**.
|
||||
|
||||
### Manage members
|
||||
|
||||
Users are automatically removed from the team or private channel when removed from a synchronized AD/LDAP group that is managing the membership of that team or channel. Additionally, users who are not in the synchronized groups are prevented from being added through the `/invite` and mention flows within a channel.
|
||||
|
||||
A user can remove themselves from the team or from the private channel when it is managed by synchronized groups. They can be added back by users who have permission to manage members for a team or private channel by using the `/invite` slash command or by mentioning the user in a channel.
|
||||
|
||||
If the user is removed from a synchronized group and later re-added to the group, they can be manually added back to the team or Private channel as noted above.
|
||||
|
||||
<Note>
|
||||
|
||||
Users won't be added back by the AD/LDAP synchronization automatically once they remove themselves or are removed by the LDAP synchronized group.
|
||||
|
||||
</Note>
|
||||
|
||||
### Disable group-synchronized management of teams and private channels
|
||||
|
||||
To remove the management of members by synchronized groups in a team, disable **Sync Group Members** under **System Console \> User Management \> Teams \> Team Management**. Alternatively, you can also run the [mmctl group team disable](/administration-guide/manage/mmctl-command-line-tool#mmctl-group-team-disable) command.
|
||||
|
||||
To remove the management of members by synchronized groups in a channel, disable **Sync Group Members** under **System Console \> User Management \> Channels \> Channel Management**. Alternatively, you can also run the [mmctl group channel disable](/administration-guide/manage/mmctl-command-line-tool#mmctl-group-channel-disable) command.
|
||||
|
||||
## Frequently asked questions
|
||||
|
||||
### Why do my LDAP users and groups exist in Mattermost, but my groups have no members?
|
||||
|
||||
In order for Mattermost to detect group membership correctly, and to automatically add users to the group configured in the System Console, you must use one of the following AD/LDAP attributes to represent group members in Mattermost: `member` or `uniqueMember`. These attributes use a `Distinguished Name` as the value on groups.
|
||||
|
||||
<Note>
|
||||
|
||||
LDAP installations that use `memberUid` to indicate group membership are not supported because `memberUid` is an attribute of an object class `posixGroup` that does not use `Distinguished Names` as the value on groups.
|
||||
|
||||
</Note>
|
||||
|
||||
### Why can't my existing users see the teams and channels they have been synced to?
|
||||
|
||||
Existing Mattermost users that are members of linked Mattermost groups will be added to teams and channels on the next scheduled synchronization job that is run after teams and channels are added to the Mattermost group. You can manually initiate a synchronization from the **Sync History** section of the AD/LDAP wizard (**System Console \> Authentication \> AD/LDAP \> AD/LDAP Synchronize Now**).
|
||||
|
||||
### How do nested groups work with AD/LDAP Group Sync?
|
||||
|
||||
Users within nested groups are included as members of parent groups. The group filter that you specify can include any type of AD/LDAP group on your system. The `member` AD/LDAP attribute is used to determine nested groups that belong to a parent group.
|
||||
|
||||
### How do I manage a team or private channel membership with synchronized groups?
|
||||
|
||||
You can do this by setting the team or channel management to synced groups instead defaulting a group to a team or channel. See the section above on synchronizing teams and channels to learn more.
|
||||
|
||||
### How do I use AD/LDAP group sync with SAML?
|
||||
|
||||
You can use AD/LDAP group sync with SAML by enabling [SAML Synchronization with AD/LDAP](/administration-guide/onboard/sso-saml-okta#configure-saml-synchronization-with-ad-ldap). You do not need to enable sign-in with LDAP for this feature to work.
|
||||
|
||||
However, it's critical that the unique Mattermost ID identifier that you have chosen as your attribute in your directory service (AD/LDAP) is the same for both the SAML and AD/LDAP configurations.
|
||||
|
||||
For instance, if `ObjectGUID` has been chosen as the Mattermost ID in your AD/LDAP configuration, then an attribute that has the same value should also be mapped to the ID attribute in your SAML assertion. We also recommend that the ID attribute you select is unique and unchanging (such as a `GUID`).
|
||||
|
||||
### Why aren’t public channels supported with synchronized groups?
|
||||
|
||||
Public channels are available to all members to discover and join. Managing membership with synchronized groups removes the ability for Public channels to be accessible to users on the team. Private channels typically require more controlled membership management, which is why this feature applies to Private channels. Groups can be assigned to public teams and public channels as described in [this documentation](/administration-guide/onboard/ad-ldap-groups-synchronization#add-default-teams-or-channels-for-the-group).
|
||||
|
||||
### Does a team with its membership managed by groups have any effect on public channel access?
|
||||
|
||||
Only users that are members of groups synchronized to team are able to discover and join public channels. Private channels can also be managed by synchronized groups when a team is managed by synchronized groups.
|
||||
|
||||
### Why don't users get readded to teams or channels once they have been removed from and then later re-added to the LDAP group?
|
||||
|
||||
The implementation of group removals does not currently differentiate between users who have removed themselves or have been removed by the LDAP synchronization process. Our design optimizes for users who have removed themselves from a team or channel. In the future, we may add the ability for Admins to re-add users who have been removed and even prevent users from leaving a team or channel.
|
||||
|
||||
Additionally, LDAP users who are not accessible to Mattermost based on filters will be removed from the groups and from group synced teams and channels. If they were removed from teams and channels then they would not be re-added to those teams and channels upon becoming subsequently reaccessible to Mattermost.
|
||||
|
||||
### How can I use LDAP attributes or Groups with OpenID?
|
||||
|
||||
At this time, LDAP data isn't compatible with OpenID. If you currently rely on LDAP to manage your users' teams, channels, groups, or attributes, you won't be able to do this automatically with users who have logged in with OpenID. If you need LDAP synced to each user, we suggest using SAML or LDAP as the login provider. Some OpenID providers can use SAML instead, like Keycloak.
|
||||
329
docs/main/administration-guide/onboard/ad-ldap.mdx
Normal file
329
docs/main/administration-guide/onboard/ad-ldap.mdx
Normal file
@@ -0,0 +1,329 @@
|
||||
---
|
||||
title: "AD/LDAP setup"
|
||||
---
|
||||
<PlanAvailability slug="all-commercial" />
|
||||
|
||||
## Overview
|
||||
|
||||
Mattermost offers “Same Sign-On” with Microsoft AD/LDAP (formerly known as Active Directory/LDAP). Enable the same credentials used in on-prem AD/LDAP deployments to be reused in Mattermost, with optional [multi-factor authentication](/administration-guide/onboard/multi-factor-authentication).
|
||||
|
||||
AD/LDAP is a service that stores authentication and authorization details of users on your organization's network. When you integrate your AD/LDAP system with Mattermost, users can log into Mattermost without having to create new credentials. User accounts are managed in AD/LDAP, and changes are synchronized with Mattermost.
|
||||
|
||||
Mattermost provides a step-by-step AD/LDAP setup wizard in the System Console that guides you through the configuration process with sections and incremental testing to ensure each part of your setup works correctly before proceeding to the next step.
|
||||
|
||||
Benefits of integrating AD/LDAP with Mattermost include:
|
||||
|
||||
- **Single sign-on.** Users can log in to Mattermost with their AD/LDAP credentials.
|
||||
- **Centralized identity management.** Mattermost accounts can display user information from AD/LDAP, such as first and last name, email, and username.
|
||||
- **Automatic account provisioning.** A Mattermost user account is automatically created the first time a user signs in with their AD/LDAP credentials.
|
||||
- **Sync groups to predefined roles in Mattermost.** Assign team and channel roles to groups via AD/LDAP Group Sync.
|
||||
- **Compliance alignment with administrator management.** Manage Administrator access to Mattermost in the System Console using AD/LDAP filters.
|
||||
|
||||
## Pre-installation notes
|
||||
|
||||
If you're using AD/LDAP with **nested security groups** you need to write a PowerShell script, or similar, to flatten and aggregate the tree into a single security group to map into Mattermost.
|
||||
|
||||
We strongly recommend the following as you prepare to set up AD/LDAP:
|
||||
|
||||
Attribute Naming and Case Sensitivity:
|
||||
|
||||
- Attribute names in both AD/LDAP and Mattermost configurations are **case-sensitive**.
|
||||
- Ensure that the attribute names in the AD/LDAP claim rules **exactly match** the expected attribute names in Mattermost. Case deviations will result in issues.
|
||||
|
||||
Essential attributes:
|
||||
|
||||
- The `NameID` element is required for user identification in SAML assertions.
|
||||
- All required attributes (e.g., `Email`, `Username`, `FirstName`, and `LastName`) must be included and correctly mapped.
|
||||
|
||||
How to choose a stable unique identifier for `NameID`:
|
||||
|
||||
- Using a stable and unique identifier (`EmployeeID` or `ObjectGUID`) for the `NameID` helps prevent issues in cases where user details could change over time (e.g., `LastName` or `Email`).
|
||||
- If stable, unique attributes aren't available in AD, using attributes that might change over time can result in future issues.
|
||||
|
||||
## Getting started
|
||||
|
||||
There are two ways to set up AD/LDAP:
|
||||
|
||||
1. **Configure AD/LDAP using the System Console setup wizard**
|
||||
|
||||
> - Log in to your workspace and create a new account using email and password. This is assigned the system admin role as the first user created.
|
||||
> - Next, use the AD/LDAP setup wizard to configure AD/LDAP step-by-step, testing each section as you go, and then convert your system admin account to use the AD/LDAP login method.
|
||||
|
||||
2. **Configure AD/LDAP by editing \`\`config.json\`\`**
|
||||
|
||||
> - Edit `config.json` to enable AD/LDAP based on the [AD/LDAP settings documentation](/administration-guide/configure/authentication-configuration-settings#adldap). When you log in to Mattermost the first user to log in with valid AD/LDAP credentials will be assigned the system admin role.
|
||||
|
||||
## Configure AD/LDAP login
|
||||
|
||||
1. **Create a system admin account using email authentication.**
|
||||
|
||||
> - Create a new workspace and create an account using email and password, which is automatically assigned the **system admin** role since it is the first account created. You may also assign the role to another account.
|
||||
|
||||
2. **Configure AD/LDAP using the setup wizard.**
|
||||
|
||||
> - Go to **System Console \> Authentication \> AD/LDAP** to open the AD/LDAP setup wizard. The wizard is organized into sections that you can navigate through using the sidebar:
|
||||
> - **Connection Settings**: Configure server connection details
|
||||
> - **User Filters**: Set up user identification and filtering
|
||||
> - **Account sync**: Map AD/LDAP attributes to Mattermost user fields
|
||||
> - **Group Synchronization**: Configure group settings and group attributes (if using LDAP groups)
|
||||
> - **Sync Performance**: Adjust synchronization timing and performance settings
|
||||
> - **Sync History**: View synchronization status and manually trigger syncs
|
||||
> - Each section includes a test button that allows you to verify your configuration before proceeding to the next step. This incremental testing helps identify and resolve issues early in the setup process.
|
||||
|
||||
3. **Confirm that AD/LDAP sign-on is enabled.**
|
||||
|
||||
> - After configuring AD/LDAP through the wizard, confirm that users can log in using AD/LDAP credentials.
|
||||
|
||||
4. **Switch your system admin account from email to AD/LDAP authentication.**
|
||||
|
||||
> - Navigate to your profile, and select **Security \> Sign-in Method \> Switch to AD/LDAP** and log in with your AD/LDAP credentials to complete the switch.
|
||||
|
||||
5. **(Optional) Restrict authentication to AD/LDAP.**
|
||||
|
||||
> - Go to **System Console \> Authentication \> Email** and set **Enable sign-in with email** to **false** and **Enable sign-in with username** to **false**.
|
||||
> - Then choose **Save** to save the changes. This should leave AD/LDAP as the only login option.
|
||||
|
||||
6. **(Optional) If you configured \`First Name Attribute\` and \`Last Name Attribute\` in the System Console.**
|
||||
|
||||
> - Navigate to **System Console \> Site Configuration \> Users and Teams** and set **Teammate Name Display** to **Show first and last name**. This is recommended for a better user experience.
|
||||
|
||||
<Note>
|
||||
|
||||
If you've made a mistake and lock yourself out of the system somehow, you can set an existing account to system admin using the [mmctl roles](/administration-guide/manage/mmctl-command-line-tool#mmctl-roles) command.
|
||||
|
||||
</Note>
|
||||
|
||||
## Configure AD/LDAP synchronization
|
||||
|
||||
<PlanAvailability slug="entry-ent" />
|
||||
|
||||
In addition to configuring AD/LDAP sign-in, you can also configure AD/LDAP synchronization. When synchronizing, Mattermost queries AD/LDAP for relevant account information and updates Mattermost accounts based on changes to attributes (first name, last name, and nickname). When accounts are disabled in AD/LDAP users are deactivated in Mattermost, and their active sessions are revoked once Mattermost synchronizes the updated attributes.
|
||||
|
||||
The AD/LDAP synchronization depends on email. Make sure all users on your AD/LDAP server have an email address, or ensure their account is deactivated in Mattermost.
|
||||
|
||||
When Mattermost is configured to use AD/LDAP for user authentication, the following user attribute changes can't be made through the API: first name, last name, position, nickname, email, profile picture, or username. LDAP must be the authoritative source for these user attributes.
|
||||
|
||||
To configure AD/LDAP synchronization with AD/LDAP sign-in:
|
||||
|
||||
1. Go to **System Console \> Authentication \> AD/LDAP** to open the AD/LDAP wizard and navigate to the **Connection Settings** section. Set **Enable Synchronization with AD/LDAP** to **true**.
|
||||
2. Navigate to the **Sync Performance** section and configure the **Synchronization Interval (minutes)** to specify how often Mattermost accounts synchronize attributes with AD/LDAP. The default setting is 60 minutes.
|
||||
|
||||
<Note>
|
||||
|
||||
- The profile picture attribute is only synchronized when the user logs in.
|
||||
- From Mattermost v11, if a profile picture in AD/LDAP is removed, the next time the user logs in, their Mattermost profile picture is also removed and returns to the default image.
|
||||
- Additionally, after configuring profile pictures in AD/LDAP configuration, all AD/LDAP user accounts in Mattermost will synchronize to use the profile picture from AD/LDAP on their next login.
|
||||
- If you want to synchronize immediately after disabling an account, use the **AD/LDAP Synchronize Now** button in the **Sync History** section of the wizard.
|
||||
- To configure AD/LDAP synchronization with SAML sign-in, see the [SAML documentation](/administration-guide/onboard/sso-saml).
|
||||
|
||||
</Note>
|
||||
|
||||
<Note>
|
||||
|
||||
- Ensure at least one AD/LDAP user is in Mattermost or the sync won't complete.
|
||||
- Synchronization with AD/LDAP settings in the System Console can be used to determine the connectivity and availability of arbitrary hosts. System admins concerned about this can use custom admin roles to limit access to modifying these settings. See the [delegated granular administration](/administration-guide/onboard/delegated-granular-administration#edit-privileges-of-admin-roles-advanced)) documentation for details.
|
||||
|
||||
</Note>
|
||||
|
||||
3. From Mattermost v10.9, you can configure Mattermost to automatically [re-add members of an LDAP group to group-synchronized teams or channels](/administration-guide/configure/authentication-configuration-settings#re-add-removed-members-on-sync) during LDAP synchronization, even if those members were previously removed. This option enables you to maintain uninterrupted collaboration and address specific organizational needs, ensuring users who were unintentionally removed due to changes in LDAP group membership, synchronization errors, or exceptions to the standard group sync rules can be seamlessly restored.
|
||||
|
||||
> <div class="note">
|
||||
>
|
||||
> <div class="title">
|
||||
>
|
||||
> Note
|
||||
>
|
||||
> </div>
|
||||
>
|
||||
> The [mmctl ldap sync](/administration-guide/manage/mmctl-command-line-tool#mmctl-ldap-sync) command takes precedence over this server configuration setting. If you have this setting disabled, and run the mmctl command with the `--include-removed-members` flag, removed members will be re-added during LDAP synchronization.
|
||||
>
|
||||
> </div>
|
||||
|
||||
## Configure AD/LDAP sign-in using filters
|
||||
|
||||
Using filters assigns roles to specified users on login. To access AD/LDAP filter settings, navigate to **System Console \> Authentication \> AD/LDAP** to open the AD/LDAP wizard and go to the **User Filters** section.
|
||||
|
||||
### User filter
|
||||
|
||||
(Optional) Enter an AD/LDAP filter to use when searching for user objects. Only the users selected by the query will be able to access Mattermost. For AD/LDAP, the query to filter out disabled users is `(&(objectCategory=Person)(!(UserAccountControl:1.2.840.113556.1.4.803:=2)))`.
|
||||
|
||||
1. Navigate to **System Console \> Authentication \> AD/LDAP** to open the AD/LDAP wizard.
|
||||
2. Go to the **User Filters** section and complete the **User Filter** field.
|
||||
3. Use the **Test Filters** button to verify your filter works correctly.
|
||||
4. Choose **Save**.
|
||||
|
||||
When the user accesses Mattermost, they log in with same username and password that they use for organizational logins.
|
||||
|
||||
Filters can also be used for excluding users who belong to certain groups. For AD/LDAP, the query to filter out groups is `(&(memberof=cn=ACME_ALL,ou=Users,dc=sademo,dc=com)(!(memberof=cn=DEV_OPS,ou=Users,dc=sademo,dc=com)))`.
|
||||
|
||||
### Guest filter
|
||||
|
||||
(Optional) When enabled, the Guest Filter in Mattermost identifies external users whose AD/LDAP role is guest and who are invited to join your Mattermost workspace. These users will have the Guest role applied immediately upon first login instead of the default member user role. This eliminates having to manually assign the role in the System Console.
|
||||
|
||||
If this filter is removed/changed, active guests will not be promoted to a member and will retain their Guest role. Guests can be promoted in **System Console \> User Management**.
|
||||
|
||||
1. Navigate to **System Console \> Authentication \> Guest Access** and set Guest Access to `true`.
|
||||
2. Navigate to **System Console \> Authentication \> AD/LDAP** to open the AD/LDAP wizard.
|
||||
3. Go to the **User Filters** section and expand **Configure additional filters**.
|
||||
4. Complete the **Guest Filter** field.
|
||||
5. Use the **Test Filters** button to verify your filter works correctly.
|
||||
6. Choose **Save**.
|
||||
|
||||
When a guest logs in for the first time they are presented with a default landing page until they are added to channels.
|
||||
|
||||
See the [Guest Accounts documentation](/administration-guide/onboard/guest-accounts) for more information about this feature.
|
||||
|
||||
### Admin filter
|
||||
|
||||
(Optional) Enter an AD/LDAP filter to use for designating system admins. The users selected by the query will have access to your Mattermost workspace as system admins. By default, system admins have complete access to the Mattermost System Console. Existing members that are identified by this attribute will be promoted from member to system admin upon next login.
|
||||
|
||||
The next login is based upon Session lengths set in **System Console \> Session Lengths**. It is recommended that users are demoted to members manually in **System Console \> User Management** to ensure access is restricted immediately.
|
||||
|
||||
1. Navigate to **System Console \> Authentication \> AD/LDAP** to open the AD/LDAP wizard.
|
||||
2. Go to the **User Filters** section and expand **Configure additional filters**.
|
||||
3. Set **Enable Admin Filter** to **true**.
|
||||
4. Complete the **Admin Filter** field.
|
||||
5. Use the **Test Filters** button to verify your filter works correctly.
|
||||
6. Choose **Save**.
|
||||
|
||||
<Note>
|
||||
|
||||
If the Admin Filter is set to `false`, the member's role as system admin is retained. However if this filter is removed/changed, system admins that were promoted via this filter will be demoted to members and won't retain access to the System Console.
|
||||
|
||||
</Note>
|
||||
|
||||
When this filter isn't in use, members can be manually promoted/demoted via **System Console \> User Management**.
|
||||
|
||||
<Note>
|
||||
|
||||
The Admin Filter is evaluated only when a user signs in with AD/LDAP credentials. It isn't evaluated during scheduled AD/LDAP synchronization, and it doesn't apply to users who authenticate with SAML, even when **Enable Synchronizing SAML Accounts With AD/LDAP** is enabled. To designate system admins for SAML-authenticated users, use the [SAML Admin Attribute](/administration-guide/onboard/sso-saml#admin-attribute) instead.
|
||||
|
||||
</Note>
|
||||
|
||||
## Configure AD/LDAP deployments with multiple domains
|
||||
|
||||
Organizations using multiple domains can integrate with Mattermost using a "Forest" configuration to bring together multiple domains. Please see [Forests as Collections of Domain Controllers that Trust Each Other](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc759073(v=ws.10)?redirectedfrom=MSDN) for more information.
|
||||
|
||||
For forest configurations that contain multiple domains which do NOT share a common root, you can search across all of the domains using the Global Catalog. To do so, update your `config.json` as follows:
|
||||
|
||||
- Set the LdapPort to 3268 (instead of 389)
|
||||
- Set the BaseDN to " " (A single space character)
|
||||
|
||||
See [Global Catalog and LDAP Searches](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/cc978012(v=technet.10)?redirectedfrom=MSDN) for additional details.
|
||||
|
||||
## Troubleshooting/FAQ
|
||||
|
||||
The following are frequently asked questions and troubleshooting suggestions on common error messages and issues. It is recommended that you check your logs for errors as they can provide an idea of what the issue is.
|
||||
|
||||
### If the **Test Connection** button fails, how can I troubleshoot the connection?
|
||||
|
||||
Check that your AD/LDAP connection settings are correct by running an AD/LDAP user query in an external system. See [LDAP Connection Test Example](https://ldaptool.sourceforge.net/). If the AD/LDAP connection is verified to be working outside of Mattermost, try the following:
|
||||
|
||||
- Check your AD/LDAP system to verify your `Bind Username` format.
|
||||
- Check your **AD/LDAP Port** and **Connection Security** settings in the System Console. (**AD/LDAP Port** set to 389 typically uses **Connection Security** set to `None`. **AD/LDAP Port** set to 636 typically ties to **Connection Security** set to **TLS**).
|
||||
- If you're seeing `x509: certificate signed by unknown authority` in your logs, try installing an intermediate SSL certificate or have your LDAP server send the complete certificate chain.
|
||||
|
||||
If these options don't work, please [contact our support team](https://mattermost.com/support/).
|
||||
|
||||
### When I first set up and synchronize AD/LDAP, are the users automatically created in Mattermost?
|
||||
|
||||
No, each user is created on their first login.
|
||||
|
||||
### When I try to synchronize AD/LDAP, why does the status show as `Pending` and not complete?
|
||||
|
||||
Go to **System Console \> Authentication \> AD/LDAP** to open the AD/LDAP wizard, navigate to the **Connection Settings** section, and make sure that the **Enable Synchronization with AD/LDAP** setting is set to **true**.
|
||||
|
||||
If the issue persists, try selecting the **Test Filters** button to test that the User Filter is correctly formatted. Refer to this [document](/administration-guide/configure/authentication-configuration-settings#user-filter) for guidance on setting a correct syntax format.
|
||||
|
||||
Make sure that you also have at least one AD/LDAP user in Mattermost or the synchronization will not complete.
|
||||
|
||||
### What's the difference between the Username Attribute, ID Attribute, and Login ID Attribute?
|
||||
|
||||
There are three AD/LDAP attributes that apear to be similar but serve a different purpose:
|
||||
|
||||
1. **Username Attribute:** Used within the Mattermost user interface to identify and mention users. For example, if **Username Attribute** is set to `john.smith`, a user typing `@john` will see `@john.smith` in their autocomplete options and posting a message with `@john.smith` will send a notification to that user that they’ve been mentioned.
|
||||
2. **ID Attribute:** Used as the unique identifier in Mattermost. It should be an AD/LDAP attribute with a value that does not change, such as `ObjectGUID`. If a user's ID attribute changes, it will create a new Mattermost account unassociated with their old one. If you need to change this field after users have already logged in, use the [mattermost ldap idmigrate mmctl tool](/administration-guide/manage/mmctl-command-line-tool#mmctl-ldap-idmigrate).
|
||||
3. **Login ID Attribute:** The attribute in the AD/LDAP server used to log in to Mattermost. Normally this attribute is the same as the **Username Attribute** field above, or another field that users can easily remember.
|
||||
|
||||
### How do I deactivate users?
|
||||
|
||||
If a user has logged into Mattermost through AD/LDAP or SAML, you can choose how they are deactivated, whether manually or automatically.
|
||||
|
||||
There are three main ways to do this:
|
||||
|
||||
1. **User deletion:** If the user is completely removed from the AD/LDAP server, they will be deactivated in Mattermost on the next synchronization.
|
||||
2. **User filter:** Set the [user filter](/administration-guide/configure/authentication-configuration-settings#user-filter) to only select the subset of AD/LDAP users you want to have access to Mattermost. When someone is removed from the selected group, they will be deactivated in Mattermost on the next synchronization.
|
||||
3. **Manually deactivate**: Go to **System Console \> User Management \> Users**, select a user's role, and select **Deactivate**. When you manually deactivate a user, they can reactivate themselves by logging back in.
|
||||
|
||||
For AD/LDAP, to filter out deactivated users you must set the user filter to:
|
||||
|
||||
`(&(objectCategory=Person)(!(UserAccountControl:1.2.840.113556.1.4.803:=2)))`
|
||||
|
||||
Filters can also be used for excluding users who belong to certain groups. For AD/LDAP, the query to filter out groups is:
|
||||
|
||||
`(&(memberof=cn=ACME_ALL,ou=Users,dc=sademo,dc=com)`
|
||||
|
||||
`(!(memberof=cn=DEV_OPS,ou=Users,dc=sademo,dc=com)))`
|
||||
|
||||
When a user is deactivated in Mattermost via options one or two above, all the user's current sessions are revoked and they will be unable to log in or access Mattermost.
|
||||
|
||||
### Can I connect to multiple AD/LDAP servers?
|
||||
|
||||
There is currently no built-in way to connect to multiple AD/LDAP servers. You will need to connect the instances in a forest before connecting to Mattermost. Consider upvoting the [feature request](https://portal.productboard.com/mattermost/33-what-matters-to-you) on our forum.
|
||||
|
||||
### When trying to log in, I see the error `AD/LDAP not available on this server`
|
||||
|
||||
This indicates that there is a problem somewhere with your configuration. We recommend that you check your Mattermost configuration settings to ensure that AD/LDAP is enabled, and the settings are correct.
|
||||
|
||||
If you're still having issues, you can [contact support](https://mattermost.com/support/) for additional troubleshooting.
|
||||
|
||||
### I see the error `User not registered on AD/LDAP server`
|
||||
|
||||
This means the query sent back to the AD/LDAP server returned no results. We recommend that you:
|
||||
|
||||
1. Check that the user credentials were entered properly - you should log in with the field set as the [\*ID Attribute\*](/administration-guide/configure/authentication-configuration-settings#id-attribute).
|
||||
2. Check that the user account exists in the AD/LDAP server.
|
||||
3. Check the AD/LDAP configuration settings are correct.
|
||||
|
||||
If you're still having issues, you can [contact Mattermost Support](https://mattermost.com/support/) for additional troubleshooting.
|
||||
|
||||
### I updated a user account in AD/LDAP, and they can no longer log in to Mattermost
|
||||
|
||||
If the user can no longer log in to Mattermost with their AD/LDAP credentials - for example, they get an error message `An account with that email already exists`, or a new Mattermost account is created when they try to log in - this means the **ID Attribute** for their account has changed.
|
||||
|
||||
The issue can be fixed by changing the value of the field used for the **ID Attribute** back to the old value. If you're currently using a field that sometimes changes for an **ID Attribute** (e.g. username, email that changes when someone gets married), we recommend you switch to using a non-changing field such as a GUID.
|
||||
|
||||
To do this, you can set the [Login ID Attribute](/administration-guide/configure/authentication-configuration-settings#id-attribute) to whatever you would like users to log in with (e.g. username or email).
|
||||
|
||||
<Note>
|
||||
|
||||
Currently the value is case sensitive. If the **ID Attribute** is set to the username and the username changes from `John.Smith` to `john.smith`, the user will experience problems logging in.
|
||||
|
||||
</Note>
|
||||
|
||||
### I see the log error `LDAP Result Code 4 "Size Limit Exceeded"`
|
||||
|
||||
This indicates that your AD/LDAP server configuration has a maximum page size set and the query coming from Mattermost is returning a result set in excess of that limit.
|
||||
|
||||
To address this issue you can set the [max page size](/administration-guide/configure/authentication-configuration-settings#maximum-page-size) in your Mattermost configuration to match the limit on your AD/LDAP server. This will return a sequence of result sets that do not exceed the max page size, rather than returning all results in a single query. A max page size setting of 1500 is recommended.
|
||||
|
||||
If the error is still occurring, it is likely that no AD/LDAP users have logged into Mattermost yet. Ensure that at least one AD/LDAP user has logged into Mattermost and re-run the synchronization. The error should disappear at that point.
|
||||
|
||||
### I see the log error `Missing NameID Element`
|
||||
|
||||
This indicates that the AD/LDAP server configuration doesn't include the `NameID` element in the SAML assertion. The `NameID` element is required for user identification in SAML assertions. Ensure the `NameID` is mapped to a unique user identifier, such as the user's email address or another stable attribute that isn't subject to change over time.
|
||||
|
||||
### I see the log error `Username Attribute is Missing`
|
||||
|
||||
The `Username` attribute in the SAML assertion was either missing or is incorrectly named. Verify that all required attributes are included in the SAML assertion. Attribute names are case-sensitive and must match exactly what Mattermost expects. Update the claim rules in AD/LDAP to correctly map LDAP attributes to the expected outgoing claim types, ensuring proper casing (e.g., `Username` instead of `UserName`).
|
||||
|
||||
### Can the Enter ID User Filter read security groups?
|
||||
|
||||
Yes it can, but make sure that:
|
||||
|
||||
- Permissions are correctly configured on the service account you are using.
|
||||
- Each user object is a direct member of the security group.
|
||||
|
||||
### How do I know if an AD/LDAP sync job fails?
|
||||
|
||||
Mattermost provides the status of each AD/LDAP sync job in the **Sync History** section of the AD/LDAP wizard (**System Console \> Authentication \> AD/LDAP**). Here you can see the number of users updated and if the job succeeded or failed.
|
||||
File diff suppressed because it is too large
Load Diff
232
docs/main/administration-guide/onboard/advanced-permissions.mdx
Normal file
232
docs/main/administration-guide/onboard/advanced-permissions.mdx
Normal file
@@ -0,0 +1,232 @@
|
||||
---
|
||||
title: "Advanced permissions"
|
||||
---
|
||||
<PlanAvailability slug="all-commercial" />
|
||||
|
||||
Mattermost system admins using Mattermost Cloud or Mattermost Server can use Advanced Permissions to customize which users can perform specific actions, such as creating teams, managing channels, and configuring webhooks. The Mattermost permission system is based on a modified RBAC (role-based access control) architecture, using roles to determine which users have the ability to perform various actions.
|
||||
|
||||
Two permission schemes are provided in Mattermost:
|
||||
|
||||
- **System Scheme**: Applies permissions universally across all teams and channels.
|
||||
- **Team Override Schemes**: Allow admins to customize permissions for each team.
|
||||
|
||||
This document describes the types of permissions that can be given to users of Mattermost using schemes as well as channel settings and roles. The [permissions backend documentation](/administration-guide/onboard/advanced-permissions-backend-infrastructure) provides additional technical details around permissions.
|
||||
|
||||
## Permissions structure
|
||||
|
||||
The Mattermost System Console provides a number of elements for Admins to control the permissions in their system.
|
||||
|
||||
### System scheme
|
||||
|
||||
You can set the default permissions granted to system admins, team admins, channel admins, guests (if enabled), and all members. The permissions granted in the System Scheme apply system-wide, meaning:
|
||||
|
||||
- **Guests:** If Guest Accounts are enabled, permissions apply to guest users in all channels, in all teams.
|
||||
- **All Members:** Permissions apply to all members, including admins, in all channels, in all teams.
|
||||
- **Channel Administrators:** Permissions apply to all channel admins in all channels, in all teams.
|
||||
- **Team Administrators:** Permissions apply to all team admins, in all teams.
|
||||
|
||||
To override the System Scheme default permissions in a specific team, you must set up a Team Override Scheme.
|
||||
|
||||
You can access the System Scheme interface by going to **System Console \> User Management \> Permissions \> System Scheme**.
|
||||
|
||||

|
||||
|
||||
### Team override scheme
|
||||
|
||||
<PlanAvailability slug="entry-adv" />
|
||||
|
||||
On systems with multiple [Mattermost teams](/end-user-guide/collaborate/organize-using-teams#single-team-versus-multiple-teams), each team may operate and collaborate in a unique way. Team Override Schemes give Admins the flexibility to tailor permissions to the needs of each team.
|
||||
|
||||
When you use this permission scheme:
|
||||
|
||||
- The permissions granted in a Team Override Scheme apply only in the teams which are assigned to the scheme.
|
||||
- The System Scheme does not apply to teams that are added to a Team Override Scheme.
|
||||
- Teams can only belong to one Team Override Scheme.
|
||||
|
||||
You can access the Team Override Scheme interface by going to **System Console \> User Management \> Permissions \> Team Override Schemes**.
|
||||
|
||||

|
||||
|
||||
## Channel permissions
|
||||
|
||||
The channel permissions interface is accessed in **System Console \> User Management \> Channels**.
|
||||
|
||||
### Advanced access controls
|
||||
|
||||
<PlanAvailability slug="entry-adv" />
|
||||
|
||||
See the [team and channel management](/administration-guide/manage/team-channel-members#advanced-access-controls) documentation for details on available channel access controls.
|
||||
|
||||
## Recipes
|
||||
|
||||
This section provides some examples of common permissions use cases for team management, channel management, and overall permissions.
|
||||
|
||||
### Team management
|
||||
|
||||
<PlanAvailability slug="entry-adv" />
|
||||
|
||||
#### Ensure users only see each other when in the same team or channel
|
||||
|
||||
Example: A classified organization wants to use Mattermost teams for classified projects. In each project, team members can't know about members outside of their project, and [@mentions](/end-user-guide/collaborate/mention-people) can't disclose the names of people outside of a classified project.
|
||||
|
||||
Use the [mmctl permissions remove](/administration-guide/manage/mmctl-command-line-tool#mmctl-permissions-remove) command to revoke the `view_member` permission from the `system_user` role: `mmctl permissions remove system_user view_member`.
|
||||
|
||||
#### Only allow admins, in a specific team, to add members
|
||||
|
||||
Example: In Team A, only allow system and team admins to add new team members. As the default for all other teams, allow all users to add and invite new members.
|
||||
|
||||
1. Go to **System Console \> User Management \> Permissions**.
|
||||
2. Select **Edit Scheme**.
|
||||
3. In the **All Members \> Teams** panel, check the box for **Add Team Members**. This sets the system default for all teams.
|
||||
4. Select **Save**.
|
||||
5. Select the back arrow to return to the **Permission Schemes** menu.
|
||||
6. Select **New Team Override Scheme**.
|
||||
|
||||
> 1. Name and describe the scheme. For example, `Authorized Personnel Only` with description `Restrict adding team members to eam and System Admins.`
|
||||
> 2. Select **Add Teams** to add Team B to the **Select teams to override permissions** list, locate Team B, then select **Add**.
|
||||
> 3. In the **All Members** panel, uncheck the box for **Add Team Members**.
|
||||
> 4. In the **Team Administrators** panel, check the box for **Add Team Members**.
|
||||
|
||||
7. Select **Save**.
|
||||
8. Select the back arrow to return to the **Permission Schemes** menu.
|
||||
|
||||
### Public and private channel management
|
||||
|
||||
<PlanAvailability slug="entry-adv" />
|
||||
|
||||
#### Restrict who can rename & edit channels
|
||||
|
||||
Example: As the default for the entire system, restrict renaming channels and editing headers and purposes to admins only.
|
||||
|
||||
1. Go to **System Console \> User Management \> Permissions**.
|
||||
2. Select **Edit Scheme**.
|
||||
3. In the **All Members** panel, uncheck the box for **Manage Public Channels \> Manage Channel Settings**.
|
||||
|
||||
The **Manage Channel Settings** option is now only available to channel admins, team admins, and system admins.
|
||||
|
||||
#### Restrict who can create channels in specific teams
|
||||
|
||||
Example: In Team C, restrict public channel creation to admins. As the default for all other teams, allow everyone to create public channels.
|
||||
|
||||
1. Go to **System Console \> User Management \> Permissions**.
|
||||
2. Select **Edit Scheme**.
|
||||
3. In the **All Members** panel, in the **Manage Public Channels** menu, check the box for **Create Channels**. This sets the system default to allow creation of public channels on all teams.
|
||||
4. Select **Save**.
|
||||
5. Select the arrow to return to the **Permission Schemes** interface.
|
||||
6. Select **New Team Override Scheme**.
|
||||
|
||||
> 1. Name and describe the scheme. For example, `Contractor Scheme` with description `Restrict public channel creation to Admins only`.
|
||||
> 2. Select **Add Teams** to add Team B to the **Select teams to override permissions** list, locate Team B, then select **Add**.
|
||||
> 3. In the **All Members** panel, in the **Manage Public Channels** section, uncheck the box for **Create Channels**.
|
||||
> 4. In the **Team Administrators** panel, in the **Manage Public Channels** section, check the box for **Create Channels**.
|
||||
|
||||
### Convert public channels to private channels
|
||||
|
||||
#### Allow anyone to convert public channels to private channels
|
||||
|
||||
Example: Set the default setting to allow all members, team admins, and channel admins to convert public channels to private.
|
||||
|
||||
1. Go to **System Console \> User Management \> Permissions**.
|
||||
2. Select **Edit Scheme**.
|
||||
3. In the **All Members** panel, uncheck the box for **Manage Public Channels \> Convert Channels**.
|
||||
|
||||
This permission is applied to all other roles (excluding the Guest role). When this permission is not enabled for all members, it must be manually applied to team admins and channel admins if required.
|
||||
|
||||
### Read-only channels
|
||||
|
||||
<PlanAvailability slug="entry-adv" />
|
||||
|
||||
#### Members can participate but guests can only read and react
|
||||
|
||||
1. Go to **System Console \> User Management \> Channels**.
|
||||
2. Select **Edit** next to the name of the channel you want to configure.
|
||||
3. In the **Create Posts** panel, uncheck **Guests**.
|
||||
4. In the **Post Reactions** panel, uncheck **Guests** if required.
|
||||
5. Select **Save**.
|
||||
|
||||
The channel is available for all members and guests to access, but guests can only read messages and react to them.
|
||||
|
||||
#### Create an announcement channel where only channel admins can post
|
||||
|
||||
1. Create a new channel (either public or private).
|
||||
2. Navigate to **System Console \> User Management \> Channels**.
|
||||
3. Select **Edit** next to the name of the channel you just created (you may need to search for it).
|
||||
4. In the **Create Posts** panel, uncheck **Guests** and **Members**.
|
||||
5. In the **Post Reactions** panel, uncheck **Guests** and **Members**.
|
||||
6. Select **Save**.
|
||||
|
||||
The channel is available for all members and guests to access but only admins can post.
|
||||
|
||||
### Message management
|
||||
|
||||
#### Restrict who can delete messages
|
||||
|
||||
Example: As the default for the entire system, restrict deleting posts to only system and team admins.
|
||||
|
||||
1. Go to **System Console \> User Management \> Permissions**.
|
||||
2. Select **Edit Scheme**.
|
||||
3. In the **All Members** and **Channel Administrators** panels, in the **Delete Posts** section, uncheck the boxes for **Delete Own Posts** and **Delete Others' Posts**.
|
||||
4. In the **Channel Administrators** and **Team Administrators** panels, in the **Delete Posts** section, check the boxes for **Delete Own Posts** and **Delete Others' Posts**.
|
||||
|
||||
#### Restrict who can edit messages
|
||||
|
||||
Example: As the default for the entire system, only allow users to edit their own posts for five minutes after posting.
|
||||
|
||||
1. Go to **System Console \> User Management \> Permissions**.
|
||||
2. Select **Edit Scheme**.
|
||||
3. In the **All Members**, **Channel Administrators**, and **Team Administrators** panels, in the **Manage Posts** section, check the box for **Edit Posts**.
|
||||
4. From any panel, select the gear button to set the global time limit to `300` seconds.
|
||||
|
||||
#### Restrict who can edit post attachments
|
||||
|
||||
From Mattermost v11.8, system admins can use the **Edit Attachments** permission to control whether users can add or remove file attachments when editing posts.
|
||||
|
||||
The **Edit Attachments** permission is separate from **Edit Own Posts**. Users with permission to edit a post can still update the post text, but they can't add or remove file attachments unless **Edit Attachments** is also enabled.
|
||||
|
||||
By default, **Edit Attachments** is granted to users who have permission to edit posts.
|
||||
|
||||
To allow users to edit post text without changing attachments:
|
||||
|
||||
1. Go to **System Console \> User Management \> Permissions**.
|
||||
2. Select **Edit Scheme**.
|
||||
3. In the applicable role panel, go to **Manage Posts**.
|
||||
4. Enable **Edit Own Posts**.
|
||||
5. Disable **Edit Attachments**.
|
||||
6. Select **Save**.
|
||||
|
||||
If a user sees **Post attachments cannot be edited** when editing a post, they don't have permission to add or remove attachments for that post.
|
||||
|
||||
### Integration management
|
||||
|
||||
From Mattermost v11.2, the System Console provides enhanced controls for managing integrations (webhooks, slash commands, OAuth apps), including separate permissions for managing your own integrations versus other users' integrations.
|
||||
|
||||
#### Restrict who can manage webhooks and slash commands
|
||||
|
||||
Example: As the default for the entire system, only allow system admins to create, edit and delete integrations.
|
||||
|
||||
1. Go to **System Console \> User Management \> Permissions**.
|
||||
2. Select **Edit Scheme**.
|
||||
3. In the **All Members** and **Team Administrators** panels, in the **Integrations & Customizations** section, uncheck the boxes for **Manage Incoming Webhooks**, **Manage Outgoing Webhooks**, and **Manage Slash Commands**.
|
||||
|
||||
## Administration tools
|
||||
|
||||
There are a number of API and mmctl tools available for admins to help in configuring and troubleshooting the permissions system:
|
||||
|
||||
1. Reset all permissions to the default on new installations using the [mmctl permissions reset](/administration-guide/manage/mmctl-command-line-tool#mmctl-permissions-reset) command.
|
||||
2. Use the [GetAllRoles](https://api.mattermost.com/#tag/roles/operation/GetAllRoles) API endpoint to get a list of all roles.
|
||||
3. Add permissions to a role using the [mmctl permissions add](/administration-guide/manage/mmctl-command-line-tool#mmctl-permissions-add) command.
|
||||
|
||||
## Backend infrastructure
|
||||
|
||||
Technical admins or developers looking for a deeper understanding of the permissions backend can refer to our [permissions backend documentation](/administration-guide/onboard/advanced-permissions-backend-infrastructure).
|
||||
|
||||
## Glossary
|
||||
|
||||
- **Permission:** The ability to execute certain actions. Permissions are granted to roles.
|
||||
- **Roles:** A set of permissions. Users or groups are assigned to roles.
|
||||
- **Group:** A set of users, usually synced from AD/LDAP. Groups are assigned to roles in the context of teams, channels, or system-wide.
|
||||
- **Default Roles:** All Members, Guests (if enabled), channel admins, team admins, system admins.
|
||||
- **System Scheme:** A set of default roles that apply system-wide.
|
||||
- **Team Override Scheme:** A set of default roles that apply only in the team specified. Permissions granted to roles in a Team Override Scheme overrides roles in the System Scheme.
|
||||
- **System-wide:** Applies across the entire system, including all teams of which the user is a member.
|
||||
- **Team-wide:** Applies in a specific team only.
|
||||
1521
docs/main/administration-guide/onboard/bulk-loading-data.mdx
Normal file
1521
docs/main/administration-guide/onboard/bulk-loading-data.mdx
Normal file
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,43 @@
|
||||
---
|
||||
title: "Certificate-based authentication (Experimental)"
|
||||
unlisted: true
|
||||
---
|
||||
<PlanAvailability slug="ent-plus" />
|
||||
|
||||
<Important>
|
||||
|
||||
**Experimental certificate-based authentication has been deprecated from Mattermost v11.0.** From Mattermost v11, you must [disable this feature](/administration-guide/configure/experimental-configuration-settings#enable-client-side-certification) to start the server. Enabling this setting will prevent the server from starting.
|
||||
|
||||
</Important>
|
||||
|
||||
Prior to v11, certificate-based authentication (CBA) is available as an experimental feature to identify a user or a device before granting access to Mattermost and provide an additional layer of security to access the system.
|
||||
|
||||
Before you begin, follow the [official guides to install Mattermost](/deployment-guide/deployment-guide-index) on your system, including NGINX configuration as a proxy with SSL and HTTP/2, and a valid SSL certificate such as Let's Encrypt.
|
||||
|
||||
Then, follow the steps below to configure user CBA for your browser and Mattermost Desktop Apps. You can manage certificate distribution for each personal device (BYOD) and their life cycle management with a service like [OpenSSL](https://www.openssl.org/).
|
||||
|
||||
## Set up mutual TLS authentication for the Web App
|
||||
|
||||
[Setting up mutual TLS authentication](/administration-guide/onboard/ssl-client-certificate) is the first step to set up certificate-based authentication.
|
||||
|
||||
## Set up Mattermost server to log in with a client certificate
|
||||
|
||||
1. Make sure your Mattermost server is licensed with a valid Enterprise license.
|
||||
2. In `ExperimentalSettings` of the `config.json` file, set `ClientSideCertEnable` to `true` and `ClientSideCertCheck` to one of the following values:
|
||||
|
||||
- `primary` - After the client side certificate is verified, user's email is retrieved from the certificate and is used to log in without a password.
|
||||
- `secondary` - After the client side certificate is verified, user's email is retrieved from the certificate and matched against the one supplied by the user.
|
||||
|
||||
If they match, the user logs in with regular email/password credentials.
|
||||
|
||||
The `config.json` file should then have the following lines
|
||||
|
||||
``` text
|
||||
"ExperimentalSettings": {
|
||||
"ClientSideCertEnable": true,
|
||||
"ClientSideCertCheck": "secondary"
|
||||
},
|
||||
```
|
||||
|
||||
3. Restart the Mattermost server.
|
||||
4. Go to `https://example.mattermost.com` and try to log in. The server should require the x.509 cert to have an `emailAddress` equal to the Mattermost user's email.
|
||||
@@ -0,0 +1,14 @@
|
||||
---
|
||||
unlisted: true
|
||||
---
|
||||
{/* Snippet include; not intended to be a standalone page */}
|
||||
|
||||
Using the System Console, Mattermost Enterprise and Professional customers can migrate OAuth configuration to the OpenID Connect standard. A one-time, one-click conversion tool is available within the existing **OAuth 2.0** page. You can also go to **System Console \> Authentication \> OpenID Connect**.
|
||||
|
||||
Select **Convert to OpenID Connect** to migrate your active service provider configuration to the new standard. No further changes are required.
|
||||
|
||||
<Note>
|
||||
|
||||
\- Inactive service providers configured for OAuth 2.0 are also migrated to the new OpenID Connect standard.
|
||||
|
||||
</Note>
|
||||
356
docs/main/administration-guide/onboard/connected-workspaces.mdx
Normal file
356
docs/main/administration-guide/onboard/connected-workspaces.mdx
Normal file
@@ -0,0 +1,356 @@
|
||||
---
|
||||
title: "Connected workspaces"
|
||||
---
|
||||
import useBaseUrl from '@docusaurus/useBaseUrl';
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
<PlanAvailability slug="entry-ent" />
|
||||
|
||||
Communicate across organizations, as well as external partners and vendors using Mattermost by synchronizing messages, emoji reactions, and file sharing in real-time through secured, connected Mattermost workspaces.
|
||||
|
||||
Connected workspaces in Mattermost behave like regular public and private channels and offer the same user experience and functionality. All members using secure connections, including local members and remote members, can [send and receive channel messages](/end-user-guide/collaborate/send-messages), [use emojis](/end-user-guide/collaborate/react-with-emojis-gifs) to react to messages, [share files](/end-user-guide/collaborate/share-files-in-messages), and [search message history](/end-user-guide/collaborate/search-for-messages). Content is synchronized across all participating Mattermost instances.
|
||||
|
||||
A channel's permissions and access continues to be governed by each server separately. [Advanced access control](/administration-guide/manage/team-channel-members#advanced-access-controls) permissions can be applied to a shared channel, and be in effect on the local Mattermost server while not being in effect on a remote Mattermost server.
|
||||
|
||||
## Set up connected workspaces
|
||||
|
||||
The process of connecting Mattermost workspaces involves the following 5 steps:
|
||||
|
||||
1. Ensure that all Mattermost Enterprise servers are running v10.2 or later.
|
||||
2. [Enable the connected workspaces functionality](#enable-connected-workspaces) for each Mattermost Enterprise instance you want to connect.
|
||||
3. System admins must [create a secure and trusted connection](#create-a-secure-connection) with other Mattermost Enterprise instances using the System Console or slash commands. This process involves creating a password-protected, encrypted invitation, creating a strong decryption password, then sending the invitation and password to the admin of a remote Mattermost instance. From Mattermost v11.0, remote cluster invitations use PBKDF2 key derivation for enhanced security.
|
||||
4. When a remote system admin receives the invitation, they must [accept the invitation](#accept-a-connection-invitation) using the System Console or slash commands.
|
||||
5. Once a trusted relationship is established between 2 Mattermost servers, system admins or users with the **Shared Channel Manager** role can [share specific public or private channels](#share-channels-with-secure-connections) with secure connections.
|
||||
|
||||
<Note>
|
||||
|
||||
- System admins can create secure connections with other Mattermost Enterprise instances. System admins or users with the **Shared Channel Manager** [delegated administration role](/administration-guide/onboard/delegated-granular-administration) can share channels with secured connections.
|
||||
- System admins creating secure connections must use Mattermost to generate a password-protected encrypted invitation code. However, sending secure connection invitations is not completed using Mattermost. System admins must have an independent way to extend the secure connection invitation, such as by email.
|
||||
- A channel shared by a host organization cannot be shared from the receiving organization to another organization. Organizations can't share a channel originating from another organization.
|
||||
|
||||
</Note>
|
||||
|
||||
## Enable connected workspaces
|
||||
|
||||
System admins must enable connected workspaces functionality for their Mattermost instance. Ensure the following configuration settings are set to `true` in `config.json`:
|
||||
|
||||
- `ConnectedWorkspacesSettings.EnableRemoteClusterService = true`
|
||||
- `ConnectedWorkspacesSettings.EnableSharedChannels = true`
|
||||
|
||||
See the [Site Configuration Settings](/administration-guide/configure/site-configuration-settings#enable-connected-workspaces) documentation for details.
|
||||
|
||||
<Note>
|
||||
|
||||
Following an upgrade to Mattermost v10.2 or later, existing configuration values for shared channels, including `EnableSharedChannels` and `EnableRemoteClusterService` are automatically converted to [connected workspace configuration settings](/administration-guide/configure/site-configuration-settings#enable-connected-workspaces) in the `config.json` file. The [deprecated shared channels experimental settings](/administration-guide/configure/deprecated-configuration-settings#shared-channels-settings) remain in the `config.json` file to support backwards compatibility.
|
||||
|
||||
</Note>
|
||||
|
||||
## Create a secure connection
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="system-console" label="System Console">
|
||||
|
||||
Only system admins can create workspace connections using the System Console.
|
||||
|
||||
1. Go to **Site Configuration \> Connected Workspaces**.
|
||||
2. Under **Connected Workspaces**, select **Add a connection**, and then select **Create a connection**.
|
||||
3. Specify the **Organization Name** for this connection. The remote system admin must specify this name when accepting a connection invitation.
|
||||
4. Select the **Destination Team** as the default team where shared channels will be added. This team will be used as the default location for organizing shared channels from this connected workspace.
|
||||
5. Select **Save**.
|
||||
|
||||
An invitation consisting of a password-protected AES 256-bit encrypted code blob is generated. From Mattermost v11.0, password protection uses PBKDF2 key derivation for enhanced security. The connection is labeled as **Connection Pending** until the remote system admin accepts the invitation.
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="slash-commands" label="Slash Commands">
|
||||
|
||||
By default, only system admins can use slash commands to create workspace connections. You can delegate channel sharing capabilities using the built-in **Shared Channel Manager** [delegated administration role](/administration-guide/onboard/delegated-granular-administration). Alternatively, you can grant the ability to **Manage Shared Channels** to Mattermost users by modifying permissions of the [system scheme](/administration-guide/onboard/advanced-permissions#system-scheme) or [team override scheme](/administration-guide/onboard/advanced-permissions#team-override-scheme).
|
||||
|
||||
System admins can [run the following slash command](/integrations-guide/run-slash-commands) to create a secure connection invitation:
|
||||
|
||||
`/secure-connection create --name <--displayname> --password`
|
||||
|
||||
For example:
|
||||
|
||||
`/secure-connection create --name AcmeUS --displayname "AcmeUSA" --password examplepassword`
|
||||
|
||||
This slash command creates an invitation consisting of a password-protected AES 256-bit encrypted code blob for a remote Mattermost entity known locally as `AcmeUS` with a password of `examplepassword`. From Mattermost v11.0, password protection uses PBKDF2 key derivation for enhanced security. Within Mattermost, this shared connection displays to the local system admin based on the `name` and `displayname` provided.
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
### Extend the invitation
|
||||
|
||||
You must use a system, other than Mattermost, to share invitation codes and passwords. We strongly recommend sharing invitation codes separately from passwords to ensure that no one has all of the data necessary to take action if the message were compromised. Ensure the remote Mattermost instance can access your Mattermost workspace URL.
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="system-console" label="System Console">
|
||||
|
||||
Once you've created a connection in the System Console, you're prompted to share the invitation code and password with the system admin of the remote Mattermost server you want to connect with. Copy both the invitation code and password to a safe location, then select **Done**.
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="slash-commands" label="Slash Commands">
|
||||
|
||||
Copy the invitation code blob in the System message, then share the code blob and the decryption password to the remote Mattermost system admin you want to securely connect with.
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
## Accept a connection invitation
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="system-console" label="System Console">
|
||||
|
||||
1. Go to **Site Configuration \> Connected Workspaces**.
|
||||
2. Under **Connected Workspaces**, select **Add a connection**, and then select **Accept an invitation**.
|
||||
3. Specify the **Organization Name** for this invitation. This must be the same name specified when creating the connection.
|
||||
4. Select the **Destination Team** where shared channels will be added. This team will serve as the default location for organizing shared channels from this connected workspace.
|
||||
5. Paste the encrypted invitation code and password you've been provided to connect with the remote workspace.
|
||||
6. Select **Accept**.
|
||||
|
||||
The system admin who accepts the connection invitation is automatically added to all shared channels.
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="slash-commands" label="Slash Commands">
|
||||
|
||||
Run the following slash command to accept a secure connection invitation from a remote Mattermost instance:
|
||||
|
||||
`/secure-connection accept --name --displayname --password --invite [code blob]`
|
||||
|
||||
For example:
|
||||
|
||||
`/secure-connection accept --name AcmeUS --displayname "AcmeUSA" --password examplepassword --invite [code-blob]`
|
||||
|
||||
This slash command accepts a secure connection invitation from `AcmeUS`.
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
## Share channels with secure connections
|
||||
|
||||
Once a connection is established between two Mattermost servers, system admins or users with the **Shared Channel Manager** role can share channels across secured workspaces.
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="system-console" label="System Console">
|
||||
|
||||
1. Under **Shared Channels**, select **Add channels**.
|
||||
2. Specify the channels you want to share between Mattermost servers.
|
||||
|
||||
Shared channels and members of those shared channels display a shared <img src={useBaseUrl('/img/ui/circle-multiple-outline_F0695.svg')} alt="Shared icon indicates channels and their members that are shared across connected Mattermost servers." /> icon to distinguish them from channels and channel members of the local server.
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="slash-commands" label="Slash Commands">
|
||||
|
||||
Run the following slash command to specify the public or private channels to share:
|
||||
|
||||
`/share-channel invite --connectionID <--readonly>`
|
||||
|
||||
You can extend an invitation that permits remote members to participate in the channel based on their channel and member permissions.
|
||||
|
||||
Alternatively, you can extend a read-only invitation to a secure connection by appending the optional `--readonly` parameter to this command. Remote members can't post or reply to messages within shared read-only channels.
|
||||
|
||||
<Tip>
|
||||
|
||||
To convert a read-only shared channel to a participation channel, remove the original secured connection from the channel, then re-extend an invitation to that secure connection while omitting the optional `--readonly` parameter. For example:
|
||||
|
||||
`/share-channel invite --connectionID`
|
||||
|
||||
This slash command invites the shared connection to the current channel based on its `connectionID`.
|
||||
|
||||
See [Reviewing Secure Connection Status](#review-connection-status) to find the `connectionID` for a shared connection.
|
||||
|
||||
</Tip>
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
## Direct message delivery
|
||||
|
||||
From Mattermost v10.10, creating a direct or group message with remote users across connected workspaces is only available when the feature flag `EnableSharedChannelsDMs` is enabled.
|
||||
|
||||
When `EnableSharedChannelsDMs` is disabled, the direct message option on a user's profile is disabled and unavailable to ensure users can't attempt direct messages with remote users when connected workspaces isn't enabled on the other Mattermost instance.
|
||||
|
||||
## Plugin component interaction
|
||||
|
||||
From Mattermost v10.10, plugin interactions such as slash commands, interactive buttons, and other plugin-generated components aren't displayed or accessible in shared channels by default to ensure a consistent experience across different Mattermost instances.
|
||||
|
||||
System admins can enable the `EnableSharedChannelsPlugins` feature flag to enable these plugin interactions in shared channels. When plugin components are enabled in shared channels, we recommend ensuring that all connected Mattermost instances have the same plugins installed and configured to avoid inconsistent user experiences. Plugin behaviors can vary between instances if different plugin versions or configurations are used.
|
||||
|
||||
## Remote user discovery
|
||||
|
||||
From Mattermost v10.10, remote users across connected workspaces can be discovered for direct or group messages when the feature flag `EnableSyncAllUsersForRemoteCluster` is enabled. This feature implements global user synchronization between connected Mattermost instances, making remote users discoverable without requiring them to post in a shared channel first. When enabled, Mattermost uses cursor-based synchronization to efficiently sync user information between connected instances. The system:
|
||||
|
||||
- Synchronizes users in configurable batch sizes to prevent timeouts and reduce memory usage
|
||||
- Tracks synchronization progress using timestamps to enable efficient resumption
|
||||
- Filters out users from their original cluster to prevent syncing users back to their home instance
|
||||
- Only syncs users that have been updated since the last synchronization
|
||||
|
||||
The feature includes configuration options for [automatically syncing users when connections are established](/administration-guide/configure/site-configuration-settings#sync-users-on-connection-open) and [controlling batch processing sizes](/administration-guide/configure/site-configuration-settings#global-user-sync-batch-size) for optimal performance.
|
||||
|
||||
When `EnableSyncAllUsersForRemoteCluster` is disabled, remote users are only discoverable in the DM/GM creation modal after they have participated in a shared channel.
|
||||
|
||||
<Note>
|
||||
|
||||
Enabling these features can increase the load on your Mattermost server’s CPU, memory, and database due to frequent updates, database queries, and API communication. Excessive sync frequency and retries can overwhelm system resources, potentially causing performance degradation or instability. Monitor your system carefully when enabling these features.
|
||||
|
||||
</Note>
|
||||
|
||||
## Channel membership synchronization
|
||||
|
||||
From Mattermost v10.10, channel membership synchronization between connected workspaces is controlled by the feature flag `EnableSharedChannelsMemberSync`. When this feature flag is enabled, channel membership changes are automatically synchronized across all connected workspaces that share the same channel.
|
||||
|
||||
When `EnableSharedChannelsMemberSync` is enabled:
|
||||
|
||||
- Users added to a shared channel on one workspace are automatically added to the corresponding shared channel on all connected workspaces
|
||||
- Users removed from a shared channel on one workspace are automatically removed from the corresponding shared channel on all connected workspaces
|
||||
- Membership changes are processed in configurable batch sizes to optimize performance and prevent timeouts
|
||||
- The system uses cursor-based synchronization to efficiently track and sync membership changes
|
||||
|
||||
The feature includes a configuration option for [controlling batch processing sizes for member synchronization](/administration-guide/configure/site-configuration-settings#member-sync-batch-size) to ensure optimal performance during large membership changes.
|
||||
|
||||
When `EnableSharedChannelsMemberSync` is disabled, channel membership changes are not synchronized between connected workspaces, and users must be manually added or removed from shared channels on each workspace.
|
||||
|
||||
<Note>
|
||||
|
||||
Enabling these features can increase the load on your Mattermost server’s CPU, memory, and database due to frequent updates, database queries, and API communication. Excessive sync frequency and retries can overwhelm system resources, potentially causing performance degradation or instability. Monitor your system carefully when enabling these features.
|
||||
|
||||
</Note>
|
||||
|
||||
## Manage connections and invitations
|
||||
|
||||
System admins can [edit](#edit-a-connected-workspace) or [delete](#delete-a-connected-workspace) a connected workspace, [review connection status](#review-connection-status), and [regenerate invitation codes and passwords](#regenerate-invitation-codes-for-pending-connections) for pending connections.
|
||||
|
||||
### Edit a connected workspace
|
||||
|
||||
In the System Console, system admins can change the **Organization Name**, the **Destination Team** (which serves as the default location for organizing shared channels from this connected workspace), or channels shared with a remote Mattermost instance as well as channels shared with your local Mattermost instance.
|
||||
|
||||
1. Under **Connected Workspaces**, identify the connected workspace you want to change.
|
||||
2. Select the **More** <img src={useBaseUrl('/img/ui/dots-horizontal_F01D8.svg')} alt="Use the More icon to access additional message options." className="theme-icon" /> icon to the right of the connected workspace, and then select **Edit**.
|
||||
|
||||
### Remove all connections from the current channel
|
||||
|
||||
Run the following slash command to remove all secure connections from the current channel:
|
||||
|
||||
`/share-channel unshare`
|
||||
|
||||
This slash command removes all secure connections from the current channel. A System message notifies you that the channel is no longer shared. Secure connections may continue to be invited to other shared channels.
|
||||
|
||||
### Delete a connected workspace
|
||||
|
||||
Deleting a connected server severs the trust relationship between the local Mattermost server and the remote Mattermost server.
|
||||
|
||||
From Mattermost v10.10, removing a shared channel from a connected workspace removes the channel from all connected workspaces. The channel is deleted from both the local and remote Mattermost servers. Prior to Mattermost v10.10, removing a shared channel from a connected workspace stops synchronizing the channel with the remote Mattermost server; however, the channel continues to function for local users.
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="system-console" label="System Console">
|
||||
|
||||
1. Under **Connected Workspaces**, identify the connected workspace you want to remove.
|
||||
2. Select the **More** <img src={useBaseUrl('/img/ui/dots-horizontal_F01D8.svg')} alt="Use the More icon to access additional message options." className="theme-icon" /> icon to the right of the connected workspace, and then select **Delete**.
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="slash-commands" label="Slash Commands">
|
||||
|
||||
Using slash commands, you can uninvite or delete a secure connection from your Mattermost instance.
|
||||
|
||||
Run the following slash command to uninvite a secure connection:
|
||||
|
||||
`/share-channel uninvite --connectionID`
|
||||
|
||||
This slash command removes a secure connection from the current channel based on its `connectionID`. The secure connection may continue to be invited to other shared channels.
|
||||
|
||||
Run the following slash command to delete a secure connection:
|
||||
|
||||
`/secure-connection remove --connectionID`
|
||||
|
||||
For example:
|
||||
|
||||
`/secure-connection remove --connectionID`
|
||||
|
||||
This slash command severs the trust relationship between the local Mattermost server and a remote Mattermost server based on its `connectionID` and removes the secure connection from all shared Mattermost channels.
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
### Review connection status
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="system-console" label="System Console">
|
||||
|
||||
Under **Connected Workspaces**, you can review all connected workspaces and their current status as one of: **Connected**, **Offline**, or **Connection Pending**.
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="slash-commands" label="Slash Commands">
|
||||
|
||||
Run the following slash command to review the current status of all secure connections established for your Mattermost instance:
|
||||
|
||||
`/secure-connection status`
|
||||
|
||||
Status details include:
|
||||
|
||||
- Connection ID
|
||||
- Connection URL
|
||||
- Description
|
||||
- Invite accepted (Yes/No)
|
||||
- Online (Yes/No)
|
||||
- Last ping timestamp (UTC)
|
||||
- Deleted
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
### Regenerate invitation codes for pending connections
|
||||
|
||||
When using the System Console to manage connected workspaces, system admins can re-generate invitation codes and passwords for pending connections.
|
||||
|
||||
1. Under **Connected Workspaces**, identify the pending connection whose invitation and password you want to regenerate.
|
||||
2. Select the **More** <img src={useBaseUrl('/img/ui/dots-horizontal_F01D8.svg')} alt="Use the More icon to access additional message options." className="theme-icon" /> icon to the right of the connected workspace, and then select **Regenerate invitation code**.
|
||||
|
||||
<Note>
|
||||
|
||||
Regenerating doesn't invalidate the existing password, and the existing password can continue to be used in addition to the newly-generated password. Once a connection invitation is accepted and the workspace displays a status of **Connected**, invitation codes and passwords can't be regenerated.
|
||||
|
||||
</Note>
|
||||
|
||||
## Frequently Asked Questions
|
||||
|
||||
### Are special characters supported in secure connection names?
|
||||
|
||||
No. When using slash commands, `--name` can include periods, hyphens, and/or underscores. You must surround `--name` using quotation marks (") when the value contains spaces.
|
||||
|
||||
### What happens if two Mattermost instances contain different emojis?
|
||||
|
||||
In cases where one Mattermost instance has different emojis than another instance, emoji text displays in place of a missing emoji image.
|
||||
|
||||
### Is a Display Name required for all secure connections?
|
||||
|
||||
No. When using slash commands, `--displayname` is optional. When omitted, `--name` is displayed and used instead.
|
||||
|
||||
### What information is synchronized between connected workspaces?
|
||||
|
||||
By default, member status and availability for all members of shared channels is synchronized between connected workspaces.
|
||||
|
||||
When a user is added to a shared channel, member status is synchronized within a few seconds of the member's status changing. Status updates aren't immediate and don't necessarily display in real-time.
|
||||
|
||||
When using Mattermost in a web browser, Mattermost polls the server every minute. Refreshing the browser page triggers immediate synchronization.
|
||||
|
||||
By default, a maximum of 50 messages are synchronized at a time, and [this value is configurable](/administration-guide/configure/site-configuration-settings#default-maximum-posts-per-sync).
|
||||
|
||||
Channel as well as member status and availability synchronization [can be disabled](/administration-guide/configure/site-configuration-settings#disable-shared-channel-status-sync).
|
||||
|
||||
From Mattermost v10.10, channel membership can be synchronized between connected workspaces when the feature flag `EnableSharedChannelsMemberSync` is enabled. When a user is added to or removed from a shared channel on one workspace, that membership change is automatically applied to the corresponding shared channel on all connected workspaces. This ensures consistent channel membership across all participating Mattermost instances. Additionally, connected workspaces also synchronize message priority, message acknowledgements, and persistent notifications between connected servers. This ensures that important message indicators and user interactions are consistently reflected across all connected workspace instances.
|
||||
|
||||
### Do connection interruptions affect message synchronization?
|
||||
|
||||
Yes. A System message is posted in the channel visible to all channel members when message synchronization is interrupted for more than 5 minutes. Once connectivity is restored, a full synchronization will happen for all missed messages, including direct messages and channel links.
|
||||
|
||||
### What happens if two secure connections share the same usernames?
|
||||
|
||||
In cases where members share the same usernames across Mattermost secure connections, usernames on the local server instance are appended with the secure connection name of the remote server.
|
||||
|
||||
For example, if multiple members named John Smith exist after two Mattermost instances establish a secure connection with one another, all remote John Smith members include their Secure Connection ID following their username to help differentiate members across multiple Mattermost instances.
|
||||
@@ -0,0 +1,17 @@
|
||||
---
|
||||
title: "Convert OAuth 2.0 service providers to OpenID Connect"
|
||||
---
|
||||
import Inc0_common_converting_oauth_to_openidconnect from './common-converting-oauth-to-openidconnect.mdx';
|
||||
|
||||
<PlanAvailability slug="all-commercial" />
|
||||
|
||||
<Inc0_common_converting_oauth_to_openidconnect />
|
||||
|
||||
## Configuring OpenID Connect Single Sign-On
|
||||
|
||||
For details on configuring Mattermost to use a service provider as a Single Sign-on (SSO) service for team creation, account creation, and user sign-in using OpenID Connect in your self-hosted deployment, refer to the following documentation:
|
||||
|
||||
- [OpenID Connect Single Sign-On](/administration-guide/onboard/sso-openidconnect)
|
||||
- [GitLab Single Sign-On](/administration-guide/onboard/sso-gitlab)
|
||||
- [Google Apps Single Sign-On](/administration-guide/onboard/sso-google)
|
||||
- [Entra ID Single Sign-On](/administration-guide/onboard/sso-entraid)
|
||||
@@ -0,0 +1,61 @@
|
||||
---
|
||||
title: "Corporate directory integration"
|
||||
---
|
||||
Mattermost offers advanced security and authentication options for integrating with corporate directories. This guide outlines the options available.
|
||||
|
||||
## Basic authentication
|
||||
|
||||
By default, Mattermost offers authentication via email and password, which offers basic features including:
|
||||
|
||||
- Account sign up using email and password.
|
||||
- Password reset via email.
|
||||
- Ability to use the same credentials to log into web, desktop, and mobile app experiences.
|
||||
- Ability to use a username and password in place of email and password.
|
||||
|
||||
## Security features for authentication
|
||||
|
||||
A core set of features is available with all authentication options to help increase security:
|
||||
|
||||
- Ability to [set session length](/administration-guide/configure/environment-configuration-settings#session-lengths) to define how long a user can use Mattermost before needing to re-enter credentials.
|
||||
- Ability for users to remotely sign out of devices.
|
||||
- Ability for IT admin to force sign out of a user from devices.
|
||||
- Ability to set rate limits on authentication API calls to deter password-guessing attacks.
|
||||
- Ability to require multi-factor authentication on log in.
|
||||
- For advanced deployments, password requirements for length and special characters can be added.
|
||||
|
||||
## AD/LDAP authentication
|
||||
|
||||
[AD/LDAP](/administration-guide/onboard/ad-ldap) is the most popular corporate directory integration option for deploying Mattermost behind a corporate firewall. Features include:
|
||||
|
||||
- Account creation using AD/LDAP credentials.
|
||||
- AD/LDAP user filters to define which users get access to Mattermost in the form of a query.
|
||||
- Ability to use a low-privileged AD/LDAP account to run queries over a secure TLS or STARTTLS connection.
|
||||
- Attribute mapping to place First Name, Last Name, Nickname, and other attributes from AD/LDAP into Mattermost.
|
||||
- Customization of login screen to specify whether users are logging in with email, username, or other attribute.
|
||||
- Synchronization with AD/LDAP to disable, enable, and update Mattermost users based on AD/LDAP.
|
||||
|
||||
<Note>
|
||||
|
||||
\- New user accounts are created when new users log in with their AD/LDAP credentials. You can optionally pre-create user accounts using the [bulk import](/administration-guide/onboard/bulk-loading-data) tool. - If you're using email or username and password authentication [users can switch to AD/LDAP manually](/administration-guide/onboard/ad-ldap#getting-started), and the conversion to AD/LDAP can also be done using the [mmctl user migrate auth](/administration-guide/manage/mmctl-command-line-tool#mmctl-user-migrate-auth) command by an IT admin.
|
||||
|
||||
</Note>
|
||||
|
||||
For very large AD/LDAP instances you can also configure max page size to divide a Mattermost AD/LDAP query into several pieces to not overtax the authentication server when synchronizing.
|
||||
|
||||
## Authentication options outside of a private network
|
||||
|
||||
When deploying Mattermost to a DMZ location outside the security of a private network, additional authentication options include:
|
||||
|
||||
- [Okta integration via SAML](/administration-guide/onboard/sso-saml-okta)
|
||||
- [OneLogin integration via SAML](/administration-guide/onboard/sso-saml-onelogin)
|
||||
- [Active Directory Federation Services via SAML](/administration-guide/onboard/sso-saml-adfs)
|
||||
- [SAML 2.0 authentication](/administration-guide/onboard/sso-saml)
|
||||
- [Google Apps](/administration-guide/onboard/sso-google)
|
||||
- [Entra ID](/administration-guide/onboard/sso-entraid)
|
||||
- [OpenID Connect](/administration-guide/onboard/sso-openidconnect)
|
||||
|
||||
Generic OAuth is not currently supported.
|
||||
|
||||
## Future authentication methods
|
||||
|
||||
Mattermost releases new improvements monthly. Several additional authentication methods are planned, but not yet scheduled. If you're an enterprise interested in deploying with an option not yet provided in our documentation, talk to a [Mattermost Expert](https://mattermost.com/contact-sales/) to discuss further.
|
||||
@@ -0,0 +1,299 @@
|
||||
---
|
||||
title: "Delegated granular administration"
|
||||
---
|
||||
<PlanAvailability slug="ent-plus" />
|
||||
|
||||
Mattermost supports the creation and customization of system administration roles with specific granular permissions and System Console access. This allows senior administrators in large organizations to delegate and de-centralize specialized administration and administrative tasks with specific admin roles.
|
||||
|
||||
These admin roles permit granular access to specific areas of the System Console and related API endpoints. These roles enable users to perform certain administrative tasks without requiring access to all system administration areas. These system roles never supersede the user's original role or the user's permissions configured by the Permissions scheme.
|
||||
|
||||
<Warning>
|
||||
|
||||
Even when a role is set to **No Access** or **Read Only** for a System Console page, granting **Can Edit** on any System Console page enables access to the underlying configuration endpoint (`PUT /api/v4/config/patch`). This means a user with write access in one area can modify configuration values across all areas. Administrators should assign **Can Edit** permissions with caution.
|
||||
|
||||
</Warning>
|
||||
|
||||
## Available roles
|
||||
|
||||
A system admin can configure the following delegated granular administration roles in the System Console. Each role has a set of default permissions, which can be adjusted as needed.
|
||||
|
||||
- **System Manager:** This role can be configured to have read/write permissions in different management areas.
|
||||
- **User Manager:** This role can be configured to have read/write to all the user management areas and to authentication
|
||||
- **Custom Group Manager** This role has permissions to [create, edit, restore, and delete custom user groups](/end-user-guide/collaborate/organize-using-custom-user-groups). This role can be used to assign individual users the ability to manage custom groups when **Custom Groups** permissions are removed for **All Members** via **System Console \> Permissions \> Edit Scheme \> Custom Groups**.
|
||||
- **Shared Channel Manager** This role has the `manage_shared_channels` permission, allowing assigned users to share and unshare channels with existing connections to remote servers.
|
||||
- **Viewer:** The Viewer role can view all areas of the System Console, and can be configured with write access where needed.
|
||||
|
||||
When a user is assigned a system role, they have role-based access to the System Console and the underlying API endpoints. Each role has a different set of default permissions, and what users can access or view depends on the role they've been assigned.
|
||||
|
||||
The table below lists the default permissions for each role. Admins should carefully review and configure these settings to align with their organization's needs. Particular caution should be exercised with Permissions write access, as it enables modifications to the permissions of any role, except for the delegated granular administrator roles.
|
||||
|
||||
<table style={{width: '73%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '19%'}} />
|
||||
<col style={{width: '20%'}} />
|
||||
<col style={{width: '33%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><strong>System role</strong></td>
|
||||
<td><strong>Read/Write access</strong></td>
|
||||
<td><strong>Read Only access</strong></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>System Manager</td>
|
||||
<td><ul><li>User Management<ul><li>Groups</li><li>Teams</li><li>Channels</li><li>Permissions</li></ul></li><li>Environment</li><li>Site Configuration</li><li>Integrations</li></ul></td>
|
||||
<td><ul><li>Edition/License</li><li>Reporting</li><li>Authentication</li><li>Plugins</li></ul></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>User Manager</td>
|
||||
<td><ul><li>User Management<ul><li>Groups</li><li>Teams</li><li>Channels</li></ul></li></ul></td>
|
||||
<td><ul><li>(User Management) Permissions</li><li>Authentication</li></ul></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Custom Group Manager</td>
|
||||
<td>Custom User Groups</td>
|
||||
<td>N/A</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Shared Channel Manager</td>
|
||||
<td>Shared Channels</td>
|
||||
<td>N/A</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Viewer</td>
|
||||
<td>N/A</td>
|
||||
<td><ul><li>All pages within the System Console</li></ul></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
## Assign admin roles
|
||||
|
||||
There are two ways to assign roles:
|
||||
|
||||
1. In the System Console under **User Management \> Delegated Granular Administration**.
|
||||
2. Using the [mmctl tool](/administration-guide/manage/mmctl-command-line-tool). This can be done either locally or remotely.
|
||||
|
||||
<table style={{width: '99%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '18%'}} />
|
||||
<col style={{width: '47%'}} />
|
||||
<col style={{width: '30%'}} />
|
||||
<col style={{width: '2%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><strong>You want to</strong></td>
|
||||
<td><strong>Using the System Console</strong></td>
|
||||
<td><strong>Using mmctl</strong></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Assign roles</td>
|
||||
<td>Go to <strong>System Console > User Management > Delegated Granular Administration > Assigned People</strong></td>
|
||||
<td><code>mmctl permissions role assign [role_name] [username...]</code></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Grant the System Manager role to a user</td>
|
||||
<td><ol type="1"><li>Go to <strong>System Console > User Management > Delegated Granular Administration</strong>, then select the <strong>System Manager</strong> role.</li><li>Under <strong>Assigned People</strong>, select <strong>Add People</strong>.</li><li>Search for and select the user name, then select <strong>Add</strong> to grant the System Manager role to that user.</li></ol></td>
|
||||
<td><code>mmctl permissions role assign system_manager user-name</code></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Grant the User Manager role to two users</td>
|
||||
<td><ol type="1"><li>Go to <strong>System Console > User Management > Delegated Granular Administration</strong>, then select the <strong>User Manager</strong> role.</li><li>Under <strong>Assigned People</strong>, select <strong>Add People</strong>.</li><li>Search for and select the two users, then select <strong>Add</strong> to grant the User Manager role to those users.</li></ol></td>
|
||||
<td><code>mmctl permissions role assign system_user_manager user-name1 user-name2</code></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Grant the Viewer role to a user</td>
|
||||
<td><ol type="1"><li>Go to <strong>System Console > User Management > Delegated Granular Administration</strong>, then select the <strong>Viewer</strong> role.</li><li>Under <strong>Assigned People</strong>, select <strong>Add People</strong>.</li><li>Search for and select the user name, then select <strong>Add</strong> to grant the Viewer role to that user.</li></ol></td>
|
||||
<td><code>mmctl permissions role assign system_read_only_admin user-name</code></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Grant the Custom Group Manager role to two users</td>
|
||||
<td><ol type="1"><li>Go to <strong>System Console > User Management > Delegated Granular Administration</strong>, then select the <strong>Custom Group Manager</strong> role.</li><li>Under <strong>Assigned People</strong>, select <strong>Add People</strong>.</li><li>Search for and select the two users, then select <strong>Add</strong> to grant the Custom Group Manager role to those users.</li><li>All users have the ability to create custom user groups by default. When you assign users to the Custom Group Manager role, you must manually remove these permissions from all users by going to <strong>System Console > User Management > Permissions > Edit Scheme</strong>. Under <strong>All Members</strong>, clear all of the <strong>Custom Groups</strong> permissions, including <strong>Create</strong>, <strong>Manage members</strong>, <strong>Edit</strong>, and <strong>Delete</strong>.</li></ol></td>
|
||||
<td><code>mmctl permissions role assign system_custom_group_admin user-name1 user-name2</code></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Grant the Shared Channel Manager role to a user</td>
|
||||
<td><ol type="1"><li>Go to <strong>System Console > User Management > Delegated Granular Administration</strong>, then select the <strong>Shared Channel Manager</strong> role.</li><li>Under <strong>Assigned People</strong>, select <strong>Add People</strong>.</li><li>Search for and select the user name, then select <strong>Add</strong> to grant the Shared Channel Manager role to that user.</li></ol></td>
|
||||
<td colspan="2"><dl><dt><code>mmctl permissions role assign system_shared_channel_manager user-name</code></dt><dd><h3 id="section">|</h3></dd></dl></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Remove the System Manager role from a single user</td>
|
||||
<td><ol type="1"><li>Go to <strong>System Console > User Management > Delegated Granular Administration</strong>, then select the <strong>System Manager</strong> role.</li><li>Under <strong>Assigned People</strong>, search for the user, then select <strong>Remove</strong>.</li></ol></td>
|
||||
<td><code>mmctl permissions role unassign system_manager bob-smith</code></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
## Edit privileges of admin roles (advanced)
|
||||
|
||||
System admins can grant read/write access to other areas of the System Console, as well as remove read/write access (including default access), for all system roles except the Custom Group Manager and Shared Channel Manager roles.
|
||||
|
||||
There are two ways to assign roles:
|
||||
|
||||
1. In the System Console under **User Management \> Delegated Granular Administration**.
|
||||
2. Using the [mmctl tool](/administration-guide/manage/mmctl-command-line-tool). This can be done either locally or remotely.
|
||||
|
||||
<table style={{width: '100%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '18%'}} />
|
||||
<col style={{width: '49%'}} />
|
||||
<col style={{width: '31%'}} />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><strong>You want to</strong></td>
|
||||
<td><strong>Using the System Console</strong></td>
|
||||
<td><strong>Using mmctl</strong></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Edit role privileges</td>
|
||||
<td><ol type="1"><li>Go to <strong>System Console > User Management > Delegated Granular Administration</strong>, then select the <strong>System Manager</strong>, <strong>User Manager</strong>, or <strong>Viewer</strong> role.</li><li>For each set of privileges, select the access level as <strong>Can edit</strong>, <strong>Read only</strong>, or <strong>No access</strong>.</li></ol><div class="note"><p>If you set privilege subsections to different access levels, then the privilege access level displays as <strong>Mixed Access</strong>.</p></div></td>
|
||||
<td><code>mmctl permissions add [role_name] [permission...]</code> <code>mmctl permissions reset system_read_only_admin</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Grant write access to the Authentication section of the System Console for all users with the User Manager role</td>
|
||||
<td><ol type="1"><li>Go to <strong>System Console > User Management > Delegated Granular Administration</strong>, then select the <strong>User Manager</strong> role.</li><li>Under <strong>Privileges > Authentication</strong> select <strong>Can edit</strong>, then select <strong>Save</strong>.</li></ol></td>
|
||||
<td><code>mmctl permissions add system_user_manager sysconsole_write_authentication</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Grant read-only access to the Authentication section of the System Console for all users with the User Manager role</td>
|
||||
<td><ol type="1"><li>Go to <strong>System Console > User Management > Delegated Granular Administration</strong>. then select the <strong>User Manager</strong> role.</li><li>Under <strong>Privileges > Authentication</strong> select <strong>Read only</strong>, then select <strong>Save</strong>.</li></ol></td>
|
||||
<td><code>mmctl permissions remove system_user_manager sysconsole_read_authentication</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Remove write access to the Authentication section of the System Console for all users with the User Manager role</td>
|
||||
<td><ol type="1"><li>Go to <strong>System Console > User Management > Delegated Granular Administration</strong>, then select the <strong>User Manager</strong> role.</li><li>Under <strong>Privileges > Authentication</strong> select <strong>No access</strong>, then choose <strong>Save</strong>.</li></ol></td>
|
||||
<td><code>mmctl permissions remove system_user_manager sysconsole_write_authentication</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Reset a role to its default set of permissions</td>
|
||||
<td>This is completed using the mmctl tool only.</td>
|
||||
<td><code>mmctl permissions reset [role_name]</code> For example, to reset the permissions of the <code>system_read_only_admin</code> role: <code>mmctl permissions reset system_read_only_admin</code></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
## Admin roles and privileges
|
||||
|
||||
#### Roles
|
||||
|
||||
- `system_manager`
|
||||
- `system_user_manager`
|
||||
- `system_custom_group_admin`
|
||||
- `system_shared_channel_manager`
|
||||
- `system_read_only_admin`
|
||||
|
||||
#### Privileges
|
||||
|
||||
<table style={{width: '83%'}}>
|
||||
<colgroup>
|
||||
<col style={{width: '20%'}} />
|
||||
<col style={{width: '62%'}} />
|
||||
</colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>System Console section</th>
|
||||
<th>Permissions</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>About</td>
|
||||
<td><blockquote><ul><li>PERMISSION_SYSCONSOLE_READ_ABOUT_EDITION_AND_LICENSE</li><li>PERMISSION_SYSCONSOLE_WRITE_ABOUT_EDITION_AND_LICENSE</li></ul></blockquote></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Reporting</td>
|
||||
<td><dl><dt><strong>System Statistics</strong></dt><dd><ul><li>PERMISSION_SYSCONSOLE_READ_REPORTING_SITE_STATISTICS</li><li>PERMISSION_SYSCONSOLE_WRITE_REPORTING_SITE_STATISTICS</li></ul></dd><dt><strong>Team Statistics</strong></dt><dd><ul><li>PERMISSION_SYSCONSOLE_READ_REPORTING_TEAM_STATISTICS</li><li>PERMISSION_SYSCONSOLE_WRITE_REPORTING_TEAM_STATISTICS</li></ul></dd><dt><strong>Server Logs</strong></dt><dd><ul><li>PERMISSION_SYSCONSOLE_READ_REPORTING_SERVER_LOGS</li><li>PERMISSION_SYSCONSOLE_WRITE_REPORTING_SERVER_LOGS</li></ul></dd></dl></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>User Management</td>
|
||||
<td><dl><dt><strong>Users</strong></dt><dd><ul><li>PERMISSION_SYSCONSOLE_READ_USERMANAGEMENT_USERS</li><li>PERMISSION_SYSCONSOLE_WRITE_USERMANAGEMENT_USERS</li></ul></dd><dt><strong>Groups</strong></dt><dd><ul><li>PERMISSION_SYSCONSOLE_READ_USERMANAGEMENT_GROUPS</li><li>PERMISSION_SYSCONSOLE_WRITE_USERMANAGEMENT_GROUPS</li></ul></dd><dt><strong>Teams</strong></dt><dd><ul><li>PERMISSION_SYSCONSOLE_READ_USERMANAGEMENT_TEAMS</li><li>PERMISSION_SYSCONSOLE_WRITE_USERMANAGEMENT_TEAMS</li></ul></dd><dt><strong>Channels</strong></dt><dd><ul><li>PERMISSION_SYSCONSOLE_READ_USERMANAGEMENT_CHANNELS</li><li>PERMISSION_SYSCONSOLE_WRITE_USERMANAGEMENT_CHANNELS</li></ul></dd><dt><strong>Permissions</strong></dt><dd><ul><li>PERMISSION_SYSCONSOLE_READ_USERMANAGEMENT_PERMISSIONS</li><li>PERMISSION_SYSCONSOLE_WRITE_USERMANAGEMENT_PERMISSIONS</li></ul></dd></dl></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Environment</td>
|
||||
<td><dl><dt><strong>Web Server</strong></dt><dd><ul><li>PERMISSION_SYSCONSOLE_READ_ENVIRONMENT_WEB_SERVER</li><li>PERMISSION_SYSCONSOLE_WRITE_ENVIRONMENT_WEB_SERVER</li></ul></dd><dt><strong>Database</strong></dt><dd><ul><li>PERMISSION_SYSCONSOLE_READ_ENVIRONMENT_DATABASE</li><li>PERMISSION_SYSCONSOLE_WRITE_ENVIRONMENT_DATABASE</li></ul></dd><dt><strong>Elasticsearch</strong></dt><dd><ul><li>PERMISSION_SYSCONSOLE_READ_ENVIRONMENT_ELASTICSEARCH</li><li>PERMISSION_SYSCONSOLE_WRITE_ENVIRONMENT_ELASTICSEARCH</li></ul></dd><dt><strong>File Storage</strong></dt><dd><ul><li>PERMISSION_SYSCONSOLE_READ_ENVIRONMENT_FILE_STORAGE</li><li>PERMISSION_SYSCONSOLE_WRITE_ENVIRONMENT_FILE_STORAGE</li></ul></dd><dt><strong>Image Proxy</strong></dt><dd><ul><li>PERMISSION_SYSCONSOLE_READ_ENVIRONMENT_IMAGE_PROXY</li><li>PERMISSION_SYSCONSOLE_WRITE_ENVIRONMENT_IMAGE_PROXY</li></ul></dd><dt><strong>SMTP</strong></dt><dd><ul><li>PERMISSION_SYSCONSOLE_READ_ENVIRONMENT_SMTP</li><li>PERMISSION_SYSCONSOLE_WRITE_ENVIRONMENT_SMTP</li></ul></dd><dt><strong>Push Notification Server</strong></dt><dd><ul><li>PERMISSION_SYSCONSOLE_READ_ENVIRONMENT_PUSH_NOTIFICATION_SERVER</li><li>PERMISSION_SYSCONSOLE_WRITE_ENVIRONMENT_PUSH_NOTIFICATION_SERVER</li></ul></dd><dt><strong>High Availability</strong></dt><dd><ul><li>PERMISSION_SYSCONSOLE_READ_ENVIRONMENT_HIGH_AVAILABILITY</li><li>PERMISSION_SYSCONSOLE_WRITE_ENVIRONMENT_HIGH_AVAILABILITY</li></ul></dd><dt><strong>Rate Limiting</strong></dt><dd><ul><li>PERMISSION_SYSCONSOLE_READ_ENVIRONMENT_RATE_LIMITING</li><li>PERMISSION_SYSCONSOLE_WRITE_ENVIRONMENT_RATE_LIMITING</li></ul></dd><dt><strong>Logging</strong></dt><dd><ul><li>PERMISSION_SYSCONSOLE_READ_ENVIRONMENT_LOGGING</li><li>PERMISSION_SYSCONSOLE_WRITE_ENVIRONMENT_LOGGING</li></ul></dd><dt><strong>Session Lengths</strong></dt><dd><ul><li>PERMISSION_SYSCONSOLE_READ_ENVIRONMENT_SESSION_LENGTHS</li><li>PERMISSION_SYSCONSOLE_WRITE_ENVIRONMENT_SESSION_LENGTHS</li></ul></dd><dt><strong>Performance Monitoring</strong></dt><dd><ul><li>PERMISSION_SYSCONSOLE_READ_ENVIRONMENT_PERFORMANCE_MONITORING</li><li>PERMISSION_SYSCONSOLE_WRITE_ENVIRONMENT_PERFORMANCE_MONITORING</li></ul></dd><dt><strong>Developer</strong></dt><dd><ul><li>PERMISSION_SYSCONSOLE_READ_ENVIRONMENT_DEVELOPER</li><li>PERMISSION_SYSCONSOLE_WRITE_ENVIRONMENT_DEVELOPER</li></ul></dd></dl></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Site Configuration</td>
|
||||
<td><dl><dt><strong>Customization</strong></dt><dd><ul><li>PERMISSION_SYSCONSOLE_READ_SITE_CUSTOMIZATION</li><li>PERMISSION_SYSCONSOLE_WRITE_SITE_CUSTOMIZATION</li></ul></dd><dt><strong>Localization</strong></dt><dd><ul><li>PERMISSION_SYSCONSOLE_READ_SITE_LOCALIZATION</li><li>PERMISSION_SYSCONSOLE_WRITE_SITE_LOCALIZATION</li></ul></dd><dt><strong>Users and Teams</strong></dt><dd><ul><li>PERMISSION_SYSCONSOLE_READ_SITE_USERS_AND_TEAMS</li><li>PERMISSION_SYSCONSOLE_WRITE_SITE_USERS_AND_TEAMS</li></ul></dd><dt><strong>Notifications</strong></dt><dd><ul><li>PERMISSION_SYSCONSOLE_READ_SITE_NOTIFICATIONS</li><li>PERMISSION_SYSCONSOLE_WRITE_SITE_NOTIFICATIONS</li></ul></dd><dt><strong>Announcement Banner</strong></dt><dd><ul><li>PERMISSION_SYSCONSOLE_READ_SITE_ANNOUNCEMENT_BANNER</li><li>PERMISSION_SYSCONSOLE_WRITE_SITE_ANNOUNCEMENT_BANNER</li></ul></dd><dt><strong>Emoji</strong></dt><dd><ul><li>PERMISSION_SYSCONSOLE_READ_SITE_EMOJI</li><li>PERMISSION_SYSCONSOLE_WRITE_SITE_EMOJI</li></ul></dd><dt><strong>Posts</strong></dt><dd><ul><li>PERMISSION_SYSCONSOLE_READ_SITE_POSTS</li><li>PERMISSION_SYSCONSOLE_WRITE_SITE_POSTS</li></ul></dd><dt><strong>File Sharing and Downloads</strong></dt><dd><ul><li>PERMISSION_SYSCONSOLE_READ_SITE_FILE_SHARING_AND_DOWNLOADS</li><li>PERMISSION_SYSCONSOLE_WRITE_SITE_FILE_SHARING_AND_DOWNLOADS</li></ul></dd><dt><strong>Public Links</strong></dt><dd><ul><li>PERMISSION_SYSCONSOLE_READ_SITE_PUBLIC_LINKS</li><li>PERMISSION_SYSCONSOLE_WRITE_SITE_PUBLIC_LINKS</li></ul></dd><dt><strong>Notices</strong></dt><dd><ul><li>PERMISSION_SYSCONSOLE_READ_SITE_NOTICES</li><li>PERMISSION_SYSCONSOLE_WRITE_SITE_NOTICES</li></ul></dd></dl></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Authentication</td>
|
||||
<td><dl><dt><strong>Signup</strong></dt><dd><ul><li>PERMISSION_SYSCONSOLE_READ_AUTHENTICATION_SIGNUP</li><li>PERMISSION_SYSCONSOLE_WRITE_AUTHENTICATION_SIGNUP</li></ul></dd><dt><strong>Email</strong></dt><dd><ul><li>PERMISSION_SYSCONSOLE_READ_AUTHENTICATION_EMAIL</li><li>PERMISSION_SYSCONSOLE_WRITE_AUTHENTICATION_EMAIL</li></ul></dd><dt><strong>Password</strong></dt><dd><ul><li>PERMISSION_SYSCONSOLE_READ_AUTHENTICATION_PASSWORD</li><li>PERMISSION_SYSCONSOLE_WRITE_AUTHENTICATION_PASSWORD</li></ul></dd><dt><strong>MFA</strong></dt><dd><ul><li>PERMISSION_SYSCONSOLE_READ_AUTHENTICATION_MFA</li><li>PERMISSION_SYSCONSOLE_WRITE_AUTHENTICATION_MFA</li></ul></dd><dt><strong>AD/LDAP</strong></dt><dd><ul><li>PERMISSION_SYSCONSOLE_READ_AUTHENTICATION_MFA</li><li>PERMISSION_SYSCONSOLE_WRITE_AUTHENTICATION_MFA</li></ul></dd><dt><strong>SAML 2.0</strong></dt><dd><ul><li>PERMISSION_SYSCONSOLE_READ_AUTHENTICATION_SAML</li><li>PERMISSION_SYSCONSOLE_WRITE_AUTHENTICATION_SAML</li></ul></dd><dt><strong>OpenID Connect</strong></dt><dd><ul><li>PERMISSION_SYSCONSOLE_READ_AUTHENTICATION_OPENID</li><li>PERMISSION_SYSCONSOLE_WRITE_AUTHENTICATION_OPENID</li></ul></dd><dt><strong>Guest Access</strong></dt><dd><ul><li>PERMISSION_SYSCONSOLE_READ_AUTHENTICATION_GUEST_ACCESS</li><li>PERMISSION_SYSCONSOLE_WRITE_AUTHENTICATION_GUEST_ACCESS</li></ul></dd></dl></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Plugin</td>
|
||||
<td><blockquote><ul><li>PERMISSION_SYSCONSOLE_READ_PLUGINS</li><li>PERMISSION_SYSCONSOLE_WRITE_PLUGINS</li></ul></blockquote></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Integrations</td>
|
||||
<td><dl><dt><strong>Integration Management</strong></dt><dd><ul><li>PERMISSION_SYSCONSOLE_READ_INTEGRATIONS_INTEGRATION_MANAGEMENT</li><li>PERMISSION_SYSCONSOLE_WRITE_INTEGRATIONS_INTEGRATION_MANAGEMENT</li></ul></dd><dt><strong>Bot Accounts</strong></dt><dd><ul><li>PERMISSION_SYSCONSOLE_READ_INTEGRATIONS_BOT_ACCOUNTS</li><li>PERMISSION_SYSCONSOLE_WRITE_INTEGRATIONS_BOT_ACCOUNTS</li></ul></dd><dt><strong>GIF (Beta)</strong></dt><dd><ul><li>PERMISSION_SYSCONSOLE_READ_INTEGRATIONS_GIF</li><li>PERMISSION_SYSCONSOLE_WRITE_INTEGRATIONS_GIF</li></ul></dd><dt><strong>CORS</strong></dt><dd><ul><li>PERMISSION_SYSCONSOLE_READ_INTEGRATIONS_CORS</li><li>PERMISSION_SYSCONSOLE_WRITE_INTEGRATIONS_CORS</li></ul></dd></dl></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Compliance</td>
|
||||
<td><dl><dt><strong>Data Retention Policy</strong></dt><dd><ul><li>PERMISSION_SYSCONSOLE_READ_COMPLIANCE_DATA_RETENTION_POLICY</li><li>PERMISSION_SYSCONSOLE_WRITE_COMPLIANCE_DATA_RETENTION_POLICY</li></ul></dd><dt><strong>Compliance Export</strong></dt><dd><ul><li>PERMISSION_SYSCONSOLE_READ_COMPLIANCE_COMPLIANCE_EXPORT</li><li>PERMISSION_SYSCONSOLE_WRITE_COMPLIANCE_COMPLIANCE_EXPORT</li></ul></dd><dt><strong>Compliance Monitoring</strong></dt><dd><ul><li>PERMISSION_SYSCONSOLE_READ_COMPLIANCE_COMPLIANCE_MONITORING</li><li>PERMISSION_SYSCONSOLE_WRITE_COMPLIANCE_COMPLIANCE_MONITORING</li></ul></dd><dt><strong>Custom Terms of Service</strong></dt><dd><ul><li>PERMISSION_SYSCONSOLE_READ_COMPLIANCE_CUSTOM_TERMS_OF_SERVICE</li><li>PERMISSION_SYSCONSOLE_WRITE_COMPLIANCE_CUSTOM_TERMS_OF_SERVICE</li></ul></dd></dl></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Experimental</td>
|
||||
<td><dl><dt><strong>Features</strong></dt><dd><ul><li>PERMISSION_SYSCONSOLE_READ_EXPERIMENTAL_FEATURES</li><li>PERMISSION_SYSCONSOLE_WRITE_EXPERIMENTAL_FEATURES</li></ul></dd><dt><strong>Feature Flags</strong></dt><dd><ul><li>PERMISSION_SYSCONSOLE_READ_EXPERIMENTAL_FEATURE_FLAGS</li><li>PERMISSION_SYSCONSOLE_WRITE_EXPERIMENTAL_FEATURE_FLAGS</li></ul></dd><dt><strong>Bleve</strong></dt><dd><ul><li>PERMISSION_SYSCONSOLE_READ_EXPERIMENTAL_BLEVE</li><li>PERMISSION_SYSCONSOLE_WRITE_EXPERIMENTAL_BLEVE</li></ul></dd></dl></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
## Frequently Asked Questions
|
||||
|
||||
#### Can a User Manager or System Manager reset an administrator’s email or password without their knowledge?
|
||||
|
||||
This is not possible with the default privileges of these roles. The ability to reset passwords or email addresses of administrators is limited to system admins.
|
||||
|
||||
#### Can a User Manager or System Manager access the configuration file?
|
||||
|
||||
Yes. However, they will only have access to read actual values and modify values in accordance with their permissions. If appropriate read permissions do not exist, the default key values will be displayed.
|
||||
|
||||
#### Are all actions of admin roles logged?
|
||||
|
||||
Every change made by any admin is included in the audit log.
|
||||
|
||||
#### Can a System Manager change their own permissions or elevate their role?
|
||||
|
||||
No. System Managers can't elevate their role, and aren't able to elevate other members' roles.
|
||||
|
||||
#### Can any of the new roles view API keys/passwords or other sensitive information within the System Console (such as SMTP, AWS, Elastic Search)?
|
||||
|
||||
No, password information is only visible to system admins and is obfuscated for other roles.
|
||||
|
||||
#### If download links for compliance exports are enabled in the System Console, can a Read Only Admin download the reports?
|
||||
|
||||
Only roles that are explicitly granted access to **System Console \> Compliance** have access to download compliance reports.
|
||||
|
||||
#### Can any of the new roles force-join Private channels?
|
||||
|
||||
Yes at this time they can, however, we will be improving on this behavior in the future with a prompt that lets them know they are entering a private channel. We are also planning on adding a permission which would remove the ability to access Private channels.
|
||||
|
||||
#### Can I create a new role or clone an existing role?
|
||||
|
||||
No, but we are actively seeking feedback on this capability.
|
||||
|
||||
#### Can I use an LDAP filter to assign these roles?
|
||||
|
||||
No, but we are considering this functionality for a future enhancement.
|
||||
|
||||
#### Can I rename the roles?
|
||||
|
||||
This is being considered for future development.
|
||||
|
||||
#### Can a System Manager or User Manager demote or deactivate another Admin or Manager?
|
||||
|
||||
A System or User Manager can demote or deactivate another System or User Manager, but can't demote or deactivate a system admin.
|
||||
|
||||
#### Can a System Manager or User Manager assign or unassign admin roles?
|
||||
|
||||
Only the system admin has access to edit system roles.
|
||||
176
docs/main/administration-guide/onboard/guest-accounts.mdx
Normal file
176
docs/main/administration-guide/onboard/guest-accounts.mdx
Normal file
@@ -0,0 +1,176 @@
|
||||
---
|
||||
title: "Guest accounts"
|
||||
---
|
||||
<PlanAvailability slug="all-commercial" />
|
||||
|
||||
Guest accounts in Mattermost are a way to collaborate with individuals, such as vendors and contractors, outside of your organization by controlling their access to channels and team members. For example, guest accounts can be used to collaborate with customers on a support issue or work on a website project with resources from an external design firm.
|
||||
|
||||
<Important>
|
||||
|
||||
- A system admin must [enable guest access](/administration-guide/configure/authentication-configuration-settings#guest-access) before guests can be invited.
|
||||
- Mattermost Enterprise and Professional customers can [control who can invite guests](/administration-guide/onboard/advanced-permissions) in their organization. By default, only system admins can invite guests.
|
||||
- Guest accounts don't all consume a licensed seat in the same way. Guests in exactly one active channel are treated as single-channel guests and don't count toward the primary paid seat count. They're free up to a 1:1 ratio with licensed seats. Guests in multiple active channels continue to count as activated users for billing purposes. Direct messages and group messages don't affect whether a guest is counted as a single-channel guest. Only active channels count toward guest channel access for billing. Archived channels are excluded.
|
||||
- You'll identify guest users in Mattermost based on their **GUEST** badge next to their name and profile picture. Channels that contain guests also display the message **\*This channel has guests** in the channel header.
|
||||
|
||||
</Important>
|
||||
|
||||
## Guests account limits
|
||||
|
||||
Guests can:
|
||||
|
||||
- Pin messages to channels
|
||||
- Use slash commands (excluding restricted commands such as invite members, rename channels, change headers, etc)
|
||||
- Favorite channels
|
||||
- Mute channels
|
||||
- Update their profile
|
||||
- Use different authentication methods than other users
|
||||
- Leave channels to which they were added (including Town Square).
|
||||
|
||||
Guests cannot:
|
||||
|
||||
- Discover public channels
|
||||
- Join open teams
|
||||
- Create direct messages or group messages with members who aren’t within the same channel
|
||||
- Invite people
|
||||
- Create channel checklists
|
||||
|
||||
## Guest authentication
|
||||
|
||||
Guests can access the Mattermost server via email invitation, and be authenticated using AD/LDAP, SAML 2.0, or magic link passwordless authentication.
|
||||
|
||||
Before you proceed, ensure that the authentication method you wish to use is correctly configured on your server and enabled in Mattermost. For configuration steps and technical documentation, see [Active Directory/LDAP setup](/administration-guide/onboard/ad-ldap) and [SAML Single-Sign-On](/administration-guide/onboard/sso-saml).
|
||||
|
||||
Converting a member user to a guest won't change the channels they are in. However, they will be restricted from discovering additional channels and are unable to direct message/group message users outside of the channels they are in. They can be added to channels by system admins and other roles that have the correct permissions to invite guests.
|
||||
|
||||
### Configure magic links for guests
|
||||
|
||||
<PlanAvailability slug="entry-ent" />
|
||||
|
||||
From Mattermost v11.3, magic links allow guest users to access Mattermost without a password by using a secure link sent to their email address. This provides a streamlined passwordless authentication option for guest users.
|
||||
|
||||
To configure magic link authentication for guests:
|
||||
|
||||
1. Ensure [guest access is enabled](/administration-guide/configure/authentication-configuration-settings#enable-guest-magic-link-authentication) in **System Console \> Authentication \> Guest Access**.
|
||||
2. Set **Enable passwordless authentication for guests using magic links via email** to **True**.
|
||||
3. Select **Save**.
|
||||
|
||||
When a guest is initially invited to Mattermost, they will receive an email with a link that allows them to log in without a password. The link expires in 48 hours for security purposes. When that guest returns to Mattermost and enters their email address, Mattermost sends them a new link to their email address that expires in 5 minutes. See the [magic link login for guests](/end-user-guide/access/access-your-workspace#magic-link-login-for-guests) documentation for details on how guests can use magic links to log in.
|
||||
|
||||
### Configure AD/LDAP authentication
|
||||
|
||||
When enabled, the **Guest Filter** in Mattermost identifies external users whose AD/LDAP role is `guest` and who are invited to join your Mattermost server. These users will have the `guest` role applied immediately upon first login instead of the default member user role. This eliminates having to manually assign the role in the System Console.
|
||||
|
||||
1. Go to **System Console \> Authentication \> Guest Access** to enable guest access.
|
||||
2. Go to **System Console \> Authentication \> AD/LDAP** to open the AD/LDAP wizard, navigate to the **User Filters** section, then expand **Configure additional filters**.
|
||||
3. Complete the **Guest Filter** field.
|
||||
4. Select **Save**.
|
||||
|
||||
If a Mattermost guest user has the `guest` role removed in the AD/LDAP system, the synchronization process will not automatically promote them to a member user role. This is done manually via **System Console \> User Management**. If a member user has the **Guest Attribute** added, the synchronization processes will automatically demote the member user to the guest role.
|
||||
|
||||
When a guest logs in without having any channels assigned to their account, they're advised to talk to a Mattermost system admin.
|
||||
|
||||
### Configure SAML 2.0 authentication
|
||||
|
||||
When enabled, the **Guest Attribute** in Mattermost identifies external users whose SAML assertion is guest and who are invited to join your Mattermost server. These users will have the `guest` role applied immediately upon first login instead of the default member user role. This eliminates having to manually assign the role in the System Console.
|
||||
|
||||
If a Mattermost guest user has the guest role removed in the SAML system, the synchronization processes will not automatically promote them to a member user role. This is done manually via **System Console \> User Management**. If a member user has the **Guest Attribute** added, the synchronization processes will automatically demote the member user to the guest role.
|
||||
|
||||
1. Go to **System Console \> Guest Access** to enable guest access.
|
||||
2. Go to **System Console \> Authentication \> SAML 2.0**.
|
||||
3. Complete the **Guest Attribute** field.
|
||||
4. Select **Save**.
|
||||
|
||||
When a guest logs in without having any channels assigned to their account, they're advised to talk to a Mattermost system admin.
|
||||
|
||||
## Manage guests
|
||||
|
||||
See the following documentation to learn more about managing guests:
|
||||
|
||||
- [invite people](/end-user-guide/collaborate/invite-people) to teams and channels
|
||||
- [manage channel members](/end-user-guide/collaborate/manage-channel-members#remove-other-members-from-a-channel)
|
||||
- [remove people from teams](/end-user-guide/collaborate/organize-using-teams#remove-people-from-teams)
|
||||
|
||||
<Tip>
|
||||
|
||||
You can also use the `/kick` or `/remove` slash commands to remove a guest from a channel.
|
||||
|
||||
</Tip>
|
||||
|
||||
When a guest has been removed from all channels within a team, and if they belong to other teams, they will default into the last channel on the last team they have accessed. If they are removed from all channels on all teams, they'll be taken to a screen letting them know they have no channels assigned.
|
||||
|
||||
### Promote and demote user roles
|
||||
|
||||
System admins can demote a user from a member to a guest by updating the user's role in **System Console \> User Management \> Users**. Select the member, then select **Demote to Guest**. All system and custom roles assigned to the demoted user are removed. System admins should also purge all of the demoted guest's sessions by selecting the guest user, then selecting **Revoke Sessions**.
|
||||
|
||||
The demoted guest user retains their existing channel and team memberships, but is restricted from discovering public channels and collaborating with users outside of the channels they're in. This is useful if you're already collaborating with external contractors, and want to restrict their abilities within Mattermost.
|
||||
|
||||
System admins can also promote a guest to member by updating their role in **System Console \> User Management \> Users**. Select the guest, then select **Promote to Member**.
|
||||
|
||||
<Note>
|
||||
|
||||
You can filter the list in **System Console \> User Management \> Users** to view **Guests (all)**, **Guests in a single channel**, or **Guests in multiple channels**.
|
||||
|
||||
</Note>
|
||||
|
||||
### Disable guest accounts
|
||||
|
||||
To disable the guest accounts feature, go to **System Console \> Authentication \> Guest Access**, then set **Enable Guest Access** to **False**. To deactivate individual guest accounts, go to **System Console \> User Management \> Users**. Select a user, then select **Deactivate**. You can re-activate individual guest accounts by selecting **Activate**.
|
||||
|
||||
- When a single guest account is deactivated or the guest account feature is disabled, guests are marked as `deactivated`, are logged out of Mattermost, and all guest sessions are revoked. In Mattermost Server versions prior to 5.18, disabling the guest account feature leaves current guest accounts as activated until they are manually deactivated.
|
||||
- If you're using AD/LDAP and the guest access setting is disabled, the `guest` filter and existing guest users in System Console are deactivated. Additionally, no new guests can be invited or added using the filter as an authentication method. If a previous guest's credentials match the user filter (the only filter which is active when guest access is disabled), they will be reactivated and promoted to a member user upon their next login.
|
||||
- Similarly, for SAML, when the guest access setting is disabled, the `guest` attribute and existing guest users in System Console are deactivated. Additionally, no new guests can be invited or added using the attribute as an authentication method. If a previous guest's credentials match the user attribute (the only attribute which is active when guest access is disabled), they will be reactivated and promoted to a member user upon their next login.
|
||||
|
||||
You can disable individual guest accounts in **System Console \> User Management** via **Manage Members**. When a single guest account is disabled or the feature is disabled, the guest will be marked as `deactivated`, be logged out of Mattermost, and all their sessions will be revoked.
|
||||
|
||||
### Reinstate guest accounts
|
||||
|
||||
When guest access is re-enabled for AD/LDAP, the `guest` filter is reinstated.
|
||||
|
||||
New users matching the `guest` filter will be authenticated as new guest users on login.
|
||||
|
||||
Previous guest users will be activated with the next synchronization. If their credentials still match the `guest` filter, they will retain their guest status. If they no longer match the `guest` filter but do match the `user` filter, they will be not be promoted to member user automatically on login - this must be done manually. If a previous guest was reactivated as a member user when guest access was disabled, and now are identified by the `guest` filter once again, they will automatically be demoted to Guest upon their login.
|
||||
|
||||
Similarly, for SAML, when guest access is re-enabled, the SAML `guest` attribute is reinstated. New users matching the `guest` attribute will be authenticated as new guest users on login.
|
||||
|
||||
Previous guest users will be activated with the next synchronization. If their credentials still match the `guest` attribute, they will retain their guest status. If they no longer match the `guest` attribute but do match the `user` filter, they will be not be promoted to member user automatically on login - this must be done manually. If a previous guest was reactivated as a member user when guest access was disabled, and now are identified by the `guest` attribute once again, they will automatically be demoted to guest upon their login.
|
||||
|
||||
## Frequently asked questions
|
||||
|
||||
### How am I charged for guest accounts?
|
||||
|
||||
Guest billing depends on how many channels a guest can access:
|
||||
|
||||
- Guests in exactly one active channel are treated as single-channel guests. They don't count toward the primary paid seat count and are free up to a 1:1 ratio with your licensed seats.
|
||||
- Guests in multiple active channels continue to count as activated users.
|
||||
- Direct messages and group messages don't change whether a guest is treated as a single-channel guest.
|
||||
- Only active channels count toward guest channel access for billing. Archived channels are excluded.
|
||||
|
||||
If your single-channel guest count exceeds the 1:1 allowance, Mattermost shows soft warnings to system admins. Guest creation and guest access aren't blocked.
|
||||
|
||||
### Why doesn’t Mattermost have single-channel guests?
|
||||
|
||||
Mattermost now supports single-channel guests.
|
||||
|
||||
Guests who belong to exactly one active channel are counted separately from your primary paid seat count and are free up to a 1:1 ratio with licensed seats. Guests who belong to multiple active channels continue to count as activated users. Direct messages and group messages don't change whether a guest is treated as a single-channel guest. Only active channels count toward guest channel access for billing. Archived channels are excluded.
|
||||
|
||||
If the number of single-channel guests exceeds the 1:1 allowance, Mattermost shows dismissible warning indicators to system admins on the relevant reporting and license pages. Mattermost doesn't block adding guests or starting the server when this limit is exceeded.
|
||||
|
||||
### Can I set an expiration date for guests?
|
||||
|
||||
Currently, you cannot. This feature may be added at a later stage.
|
||||
|
||||
### Can MFA be applied selectively?
|
||||
|
||||
If MFA is enforced for your users, it can be applied to guest accounts. Guests can configure MFA in by going to their profile picture and selecting **Profile \> Security**. If MFA is not enforced for your users, it can't be applied to guest accounts.
|
||||
|
||||
### Has the guest accounts feature been reviewed by an external security firm?
|
||||
|
||||
The guest account feature was reviewed by the Mattermost security team. We do not have an external firm review scheduled but will include this feature in future reviews.
|
||||
|
||||
### How can I validate my guests' identity?
|
||||
|
||||
Guests can be authenticated via SAML and/or AD/LDAP to ensure that only the named guest can log in. Alternatively, you can whitelist domains via **System Console \> Authentication \> Guest Access \> Whitelisted Guest Domains**.
|
||||
|
||||
### Can I restrict guests' ability to upload content?
|
||||
|
||||
It is not currently possible to selectively disable upload/download functionality as it is a server-wide configuration.
|
||||
@@ -0,0 +1,106 @@
|
||||
---
|
||||
title: "Manage team and channel membership with AD/LDAP sync groups"
|
||||
---
|
||||
<PlanAvailability slug="ent-plus" />
|
||||
|
||||
Mattermost groups created with [synchronized AD/LDAP groups](/administration-guide/onboard/ad-ldap-groups-synchronization) can be used to manage the membership of private teams and private channels. When a team or private channel is managed by synchronized groups, users will be added and removed based on their membership to the synchronized AD/LDAP group.
|
||||
|
||||
For instance, you may have an AD/LDAP group that contains your development team that you want to synchronize to a developer team. By using this feature, new developers will get added to the team when they are added to the synchronized AD/LDAP group and they will be removed from the team when removed from the AD/LDAP group.
|
||||
|
||||
Similarly, you may have an AD/LDAP group that contains your leadership team that you want to synchronize to a private channel for coordination and updates. This feature will help control the membership of the channel so that users outside of the synchronized group are prevented from being added to the channel mistakenly.
|
||||
|
||||
On teams that are managed by synchronized groups, users outside of the group are restricted from:
|
||||
|
||||
> - Invitation through a team invite link
|
||||
> - Invitation through an email invite
|
||||
|
||||
Similarly on private channels that are managed by synchronized groups, users outside of the group are restricted from:
|
||||
|
||||
> - Invitation through a mention
|
||||
> - Invitation through the `/invite` slash command
|
||||
> - Being added to the channel with **Add members**
|
||||
|
||||
Users can remove themselves from teams and private channels managed by synchronized groups.
|
||||
|
||||
## Managing membership of a team or channel with synchronized groups
|
||||
|
||||
To manage membership of a private team with synchronized groups:
|
||||
|
||||
1. Navigate to **System Console \> User Management \> Teams**.
|
||||
2. Select the team you want to manage with group synchronization.
|
||||
3. Under **Team Management**, enable **Sync Group Members**. If **Anyone can join this team** is enabled or if specific email domains are set, they will be disabled by the sync group members feature.
|
||||
4. Add one or more groups to the team. If there are groups already associated to default users into the team, they will already be present.
|
||||
5. Review the notice in the footer of the screen for any users that are not part of groups who will be removed from the team on the next synchronization.
|
||||
6. Select **Save**. Members will be updated on the next scheduled AD/LDAP synchronization.
|
||||
|
||||
Alternatively you can use the mmctl tools to set the team to be managed by groups:
|
||||
|
||||
1. Ensure there's at least one group already associated to the team. You can view and add default teams to a group via **System Console \> User Management \> Groups \> Group Configuration**. See the [mmctl group team list](/administration-guide/manage/mmctl-command-line-tool#mmctl-group-team-list) documentation for more information on adding default teams and channels and confirming whether if there is already a group associated to the team.
|
||||
2. Ensure **Team Settings \> General \> Allow any user with an account on this server to join this team** is set to `No`.
|
||||
3. Convert the team to have its membership managed by synchronized groups by running the [mmctl group team enable](/administration-guide/manage/mmctl-command-line-tool#mmctl-group-team-enable) command.
|
||||
|
||||
To manage membership of a private channel with synchronized groups:
|
||||
|
||||
1. Navigate to **System Console \> User Management \> Channels**.
|
||||
2. Select the channel you want to manage with group synchronization.
|
||||
3. Under **Channel Management**, enable **Sync Group Members**. Please ensure the channel is set to `private`.
|
||||
4. Add one or more groups to the channel. If there are groups already associated to default users in the channel, they'll already be present.
|
||||
5. Review the notice in the footer of the screen for any users that are not part of groups who will be removed from the channel on the next synchronization.
|
||||
6. Select **Save**. Members will be updated on the next scheduled AD/LDAP synchronization.
|
||||
|
||||
Alternatively you can use the mmctl tool to set a private channel to be managed by groups:
|
||||
|
||||
1. Ensure there's at least one group already associated to the channel. You can view and add default channels to a group via **System Console \> User Management \> Groups \> Group Configuration**. See our [AD/LDAP](/administration-guide/onboard/ad-ldap-groups-synchronization#add-default-teams-or-channels-for-the-group) documentation for more information on adding default teams and channels. Additionally, you can use the mmctl to view if there is already a group associated to the channel by running the [mmctl group channel list](/administration-guide/manage/mmctl-command-line-tool#mmctl-group-channel-list) command.
|
||||
2. Convert the team to have its membership managed by synchronized groups by running the [mmctl group channel enable](/administration-guide/manage/mmctl-command-line-tool#mmctl-group-channel-enable) command.
|
||||
|
||||
## Add or remove groups from teams
|
||||
|
||||
Once the management of the team is converted to be managed by synchronized groups, a team admin or system admin can add additional groups from **Main Menu \> Add Groups to Team**. This will add users on the next AD/LDAP synchronization and any new users to the group will be added to the team on subsequent synchronizations. Team admins will be prevented from changing the team to public by enabling **Team Settings \> Allow any user with an account on this server to join this team**.
|
||||
|
||||
Team admins or system admins can also remove groups from a team from **Main Menu \> Manage Groups**. This will disassociate the group from the team. Users are removed on the next AD/LDAP synchronization.
|
||||
|
||||
The system admin can also remove groups from **System Console \> User Management \> Teams \> Team Configuration \> Synced Groups**.
|
||||
|
||||
## Add or remove groups from private channels
|
||||
|
||||
Once the management of the channel is converted to be managed by synchronized groups, a team admin or system admin can add additional groups from **Channel Menu \> Add Groups to Channel**. This will add users on the next AD/LDAP synchronization and any new users to the group will be added to the channel on subsequent synchronizations.
|
||||
|
||||
Team admins and system admins can also remove groups from a team from **Main Menu \> Manage Groups**. This will disassociate the group from the team. Users are removed on the next AD/LDAP synchronization.
|
||||
|
||||
The system admin can also remove groups from **System Console \> User Management \> Channels \> Channel Configuration \> Synced Groups**.
|
||||
|
||||
## Managing members
|
||||
|
||||
Users are automatically removed from the team or private channel when removed from a synchronized AD/LDAP group that is managing the membership of that team or channel. Additionally, users who are not in the synchronized groups are prevented from being added through the `/invite` and mention flows within a channel.
|
||||
|
||||
A user can remove themselves from the team or from the private channel when it is managed by synchronized groups. They can be added back by users who have permission to manage members for a team or private channel by using the `/invite` slash command or by mentioning the user in a channel.
|
||||
|
||||
If the user is removed from a synchronized group and later readded to the group, they can be manually added back to the team or private channel as noted above.
|
||||
|
||||
<Note>
|
||||
|
||||
Users will not be automatically added back by the AD/LDAP synchronization once they remove themselves or are removed by the LDAP synchronized group.
|
||||
|
||||
</Note>
|
||||
|
||||
## Disabling group synchronized management of teams and private channels
|
||||
|
||||
To remove the management of members by synchronized groups in a team, disable **Sync Group Members** under **System Console \> User Management \> Teams \> Team Management**, or run the [mmctl group team disable](/administration-guide/manage/mmctl-command-line-tool#mmctl-group-team-disable) command.
|
||||
|
||||
To remove the management of members by synchronized groups in a channel, disable **Sync Group Members** under **System Console \> User Management \> Channels \> Channel Management**, or run the [mmctl group channel disable](/administration-guide/manage/mmctl-command-line-tool#mmctl-group-channel-disable) command.
|
||||
|
||||
## Frequently asked questions
|
||||
|
||||
**Why aren’t public channels supported with this feature?**
|
||||
|
||||
Public channels are available to all members to discover and join. Managing membership with synchronized groups removes the ability for public channels to be accessible to users on the team. Private channels typically require a more controlled membership management, which is why this feature applies to Private channels. Groups can be assigned to public teams and public channels as described in [this documentation](/administration-guide/onboard/ad-ldap-groups-synchronization#add-default-teams-or-channels-for-the-group).
|
||||
|
||||
**Does a team with its membership managed by groups have any effect on Public channel access?**
|
||||
|
||||
Only users that are members of groups synchronized to team are able to discover and join public channels. Private channels can also be managed by synchronized groups when a team is managed by synchronized groups.
|
||||
|
||||
**Why don't users get readded to teams or channels once they have been removed from and then later re-added to the LDAP group?**
|
||||
|
||||
The implementation of group removals does not currently differentiate between users who have removed themselves or have been removed by the LDAP synchronization process. Our design optimizes for users who have removed themselves from a team or channel. In the future, we may add the ability for admins to re-add users who have been removed, and even prevent users from leaving a team or channel.
|
||||
|
||||
Additionally, LDAP users who aren't accessible to Mattermost based on filters will be removed from the groups and from group-synced teams and channels. If they were removed from teams and channels then they will not be re-added to those teams and channels upon becoming subsequently re-accessible to Mattermost.
|
||||
@@ -0,0 +1,303 @@
|
||||
---
|
||||
title: "Migrate from Rocket.Chat"
|
||||
---
|
||||
<PlanAvailability slug="all-commercial" />
|
||||
|
||||
## Overview
|
||||
|
||||
Mattermost provides a migration path from Rocket.Chat, bringing your users, channels, messages, threads, direct messages, reactions, and file attachments into a self-hosted Mattermost environment.
|
||||
|
||||
Rocket.Chat has no hosted "export workspace" feature. Instead, you export the underlying MongoDB database with `mongodump` and transform that dump into a Mattermost bulk import file using the `mmetl` tool. This means the export step is a database operation that typically requires access to the Rocket.Chat server and its MongoDB instance.
|
||||
|
||||
The migration is a multi-step process:
|
||||
|
||||
1. [Preparations](#1-preparations) — scope the migration, gather MongoDB and attachment-storage details, and prepare the Mattermost server.
|
||||
2. [Export your Rocket.Chat data](#2-export-your-rocketchat-data) — produce a `mongodump` of the Rocket.Chat database.
|
||||
3. [Transform the export](#3-transform-the-export-for-mattermost) — validate with `mmetl check rocketchat` and convert with `mmetl transform rocketchat`.
|
||||
4. [Import into Mattermost](#4-import-into-mattermost) — upload and process the archive with `mmctl`.
|
||||
5. [Validate, test, and go live](#5-validate-test-and-go-live) — verify the trial import before scheduling the production cutover.
|
||||
|
||||
<Note>
|
||||
|
||||
These instructions describe a *best effort* migration designed to preserve the majority of your messages, files, and channel structure. Manual adjustments are often required, and larger deployments should plan for multiple trial runs in a staging environment before a production import. Consider [talking to a Mattermost expert](https://mattermost.com/contact-sales/) if your organization needs migration support.
|
||||
|
||||
</Note>
|
||||
|
||||
## 1. Preparations
|
||||
|
||||
This guide assumes you already have a Mattermost server deployed and ready to accept your data. If not, review the [deployment documentation](/deployment-guide/server/deploy-server#deployment-options) first.
|
||||
|
||||
### Scope definition
|
||||
|
||||
- **Data history**: Decide how much history you need. Because `mongodump` captures the whole database, scoping is done mainly through what you migrate and validate rather than by trimming the export.
|
||||
- **Export size**: The size of your Rocket.Chat database and attachments directly affects processing and import time. Plan for longer iteration cycles on large deployments.
|
||||
- **File attachments**: Consider excluding very large or non-critical attachments with `--skip-attachments` for early test runs to speed up iteration.
|
||||
|
||||
### Rocket.Chat / MongoDB prerequisites
|
||||
|
||||
- You need access to the Rocket.Chat MongoDB instance and the `mongodump` tool from the [MongoDB Database Tools](https://www.mongodb.com/docs/database-tools/).
|
||||
- Identify the database name (commonly `meteor`) and the connection URI.
|
||||
- The transform reads these collections from the dump: `users`, `rocketchat_room`, `rocketchat_message`, and `rocketchat_subscription` (all required), plus `rocketchat_uploads` and `rocketchat_uploads.chunks` (for attachments).
|
||||
|
||||
<Note>
|
||||
|
||||
This tool was validated against **Rocket.Chat v8.5**. Rocket.Chat changes its MongoDB schema between versions, so exports from other versions may parse differently. If you hit unexpected parse errors, check for a newer `mmetl` release before assuming the export is at fault.
|
||||
|
||||
</Note>
|
||||
|
||||
### Attachment storage: GridFS vs. FileSystem
|
||||
|
||||
Rocket.Chat can store uploaded files in one of two ways. Confirm which your deployment uses (**Admin \> Settings \> File Upload \> Storage Type**) before you export, because it changes how you run the transform:
|
||||
|
||||
- **GridFS** (stored inside MongoDB): attachments are captured directly in the `mongodump` (`rocketchat_uploads.chunks.bson`) and extracted automatically. No extra flag needed.
|
||||
- **FileSystem** (stored on disk): the `mongodump` contains only file metadata. You must also copy the Rocket.Chat uploads directory and point `--uploads-dir` at it during the transform.
|
||||
|
||||
### Infrastructure considerations
|
||||
|
||||
- **Test environment**: Always run the migration in a development or staging environment first. Most migrations require several iterations.
|
||||
- **Operating system**: `mmetl` is supported on Linux and macOS. Windows (including WSL) is not recommended.
|
||||
- **Storage requirements**: Ensure you have room for the `mongodump` output, the transformed import file, and the extracted attachments. Plan for several times the size of your Rocket.Chat data.
|
||||
- **File storage**: Imports into AWS S3 (or S3-compatible storage) typically complete faster than local or NFS storage for large datasets.
|
||||
|
||||
### Mattermost server considerations
|
||||
|
||||
- **Fresh server**: The most reliable imports happen on a fresh installation. If importing into an existing server, never import over an existing team, and back up the database and data directory first.
|
||||
- **Server version**: Run the latest supported version of [Mattermost](/product-overview/mattermost-server-releases).
|
||||
- **The target team must already exist** in Mattermost and be set to **Public Team**.
|
||||
- **Configuration settings**: Before importing, adjust:
|
||||
- `TeamSettings.MaxChannelsPerTeam` and `TeamSettings.MaxUsersPerTeam`: set well above the number of channels/users you are migrating.
|
||||
- `EmailSettings.EnableSignUpWithEmail` and `EmailSettings.EnableSignInWithEmail`: both `true`.
|
||||
- `FileSettings.MaxFileSize`: higher than the largest file in your export.
|
||||
- `ElasticsearchSettings.EnableIndexing`, `EnableSearching`, and `EnableAutocomplete`: set to `false` during the import, then purge and reindex afterward.
|
||||
|
||||
## 2. Export your Rocket.Chat data
|
||||
|
||||
Export the Rocket.Chat MongoDB database with `mongodump`. Replace the URI and database name to match your deployment:
|
||||
|
||||
``` sh
|
||||
mongodump --uri="mongodb://localhost:3001/meteor" --out=/tmp/rc-dump
|
||||
```
|
||||
|
||||
This creates a subdirectory named after the database (for example `/tmp/rc-dump/meteor`) containing the `.bson` files. That database subdirectory — not the parent — is what you pass to `--dump-dir` in the next step.
|
||||
|
||||
If your deployment uses **FileSystem** storage for attachments, also copy the Rocket.Chat uploads directory to a known location so you can reference it with `--uploads-dir`.
|
||||
|
||||
## 3. Transform the export for Mattermost
|
||||
|
||||
[Download the latest release of mmetl](https://github.com/mattermost/mmetl/releases/) for your OS and architecture. Run `mmetl help` to learn more about the tool.
|
||||
|
||||
### Validate the export
|
||||
|
||||
Before transforming, check the integrity of the dump:
|
||||
|
||||
``` sh
|
||||
./mmetl check rocketchat --dump-dir /tmp/rc-dump/meteor
|
||||
```
|
||||
|
||||
This reports structural issues (for example, missing required collections or invalid records) that would cause the transform or import to fail. Details are written to `check-rocketchat.log`.
|
||||
|
||||
`check rocketchat` accepts the same `--guest-handling` flag as the transform, so you can preview how guest users will be treated before running the full transform.
|
||||
|
||||
### Run the transform
|
||||
|
||||
Convert the dump into a Mattermost bulk import file. Replace `<TEAM-NAME>` with your Mattermost team name, which must be one word and lowercase (a team named `My Team` becomes `my-team`):
|
||||
|
||||
``` sh
|
||||
./mmetl transform rocketchat --team <TEAM-NAME> --dump-dir /tmp/rc-dump/meteor --output mattermost_import.jsonl
|
||||
```
|
||||
|
||||
For **FileSystem** attachment storage, add `--uploads-dir`:
|
||||
|
||||
``` sh
|
||||
./mmetl transform rocketchat --team <TEAM-NAME> --dump-dir /tmp/rc-dump/meteor --uploads-dir /path/to/rocketchat/uploads --output mattermost_import.jsonl
|
||||
```
|
||||
|
||||
The tool produces a [.jsonl](https://jsonlines.org/examples) file containing your users, channels, and posts, plus a `data` folder containing the extracted attachments.
|
||||
|
||||
A successful run ends with a summary line in `transform-rocketchat.log` like:
|
||||
|
||||
``` text
|
||||
Transformation succeeded! Users: 152, Public channels: 48, Private channels: 12, Posts: 39184
|
||||
```
|
||||
|
||||
If the run stops with an error instead — for example, `the RocketChat export contains bot users but --bot-owner was not specified` — no valid import file is produced. Resolve the error (see the flags below) and re-run.
|
||||
|
||||
<Tip>
|
||||
|
||||
**Iterate incrementally.** Run a small trial first: transform, import into a fresh or restored trial target, and confirm a few channels look right before committing to a full production import. Re-running the same import avoids duplicate posts only when the records' identity fields are unchanged; not every imported entity is deduplicated. Don't rely on re-importing into a modified trial target to reset it.
|
||||
|
||||
</Tip>
|
||||
|
||||
### Useful transform flags
|
||||
|
||||
- `--uploads-dir <PATH>`: Path to the Rocket.Chat FileSystem uploads directory. Required when attachments are not stored in GridFS.
|
||||
- `--bot-owner <USERNAME>`: Username of the Mattermost user who will own all imported bots. **Required if the export contains any bot users** — the transform errors out otherwise.
|
||||
- `--guest-handling <MODE>`: How to migrate Rocket.Chat guest users (default `guest`):
|
||||
- `guest` — migrate them as Mattermost guests. Highest fidelity, but the destination server must have Guest Accounts **licensed** (Professional/Enterprise) and **enabled** (`GuestAccountsSettings.Enable`); otherwise the accounts won't behave correctly.
|
||||
- `user` — migrate them as regular Mattermost members. Works everywhere, but grants guests full member permissions.
|
||||
- `skip` — drop guest users entirely, along with their memberships and authored posts.
|
||||
- `--skip-attachments` / `-a`: Skip extracting file attachments. Useful for faster iteration while testing.
|
||||
- `--attachments-dir <PATH>`: Directory for extracted attachments (default `data`).
|
||||
- `--default-email-domain <DOMAIN>`: When a user's email is missing, generate one from their username and this domain (for example `example.com`).
|
||||
- `--skip-empty-emails`: Allow users with empty emails. Note that this produces invalid import data that must be corrected before importing.
|
||||
- `--debug`: Emit `DEBUG`-level detail to `transform-rocketchat.log` to help diagnose slow or failing runs.
|
||||
|
||||
## 4. Import into Mattermost
|
||||
|
||||
Package the `.jsonl` file and `data` folder into a single zip:
|
||||
|
||||
``` sh
|
||||
zip -r mattermost-bulk-import.zip data mattermost_import.jsonl
|
||||
```
|
||||
|
||||
Validate the archive locally before uploading:
|
||||
|
||||
``` sh
|
||||
mmctl import validate ./mattermost-bulk-import.zip
|
||||
```
|
||||
|
||||
Ensure `mmctl` is installed and [authenticated](/administration-guide/manage/mmctl-command-line-tool#mmctl-auth). Then choose an upload method.
|
||||
|
||||
### Standard upload
|
||||
|
||||
For most imports, upload through `mmctl`:
|
||||
|
||||
``` sh
|
||||
mmctl import upload ./mattermost-bulk-import.zip
|
||||
mmctl import list available
|
||||
```
|
||||
|
||||
Process the import using the name returned by `import list available`:
|
||||
|
||||
``` sh
|
||||
mmctl import process <IMPORT FILE NAME>
|
||||
```
|
||||
|
||||
Check the job status. If it shows `pending`, wait and re-run. The `--json` flag is required to see error messages:
|
||||
|
||||
``` sh
|
||||
mmctl import job show <JOB ID> --json
|
||||
```
|
||||
|
||||
### Large imports (file store method)
|
||||
|
||||
For large archives (multiple GB), uploading through `mmctl` is slow and error-prone. Instead, place the archive directly into the server's import directory and let the server process it in place:
|
||||
|
||||
1. Copy `mattermost-bulk-import.zip` (with a unique name) into `data/import` in the Mattermost file store — the local data directory, or the `import` prefix of your S3 bucket.
|
||||
2. Run `mmctl import list available` to confirm the server sees the file.
|
||||
3. Run `mmctl import process <IMPORT FILE NAME>` and monitor with `mmctl import job show <JOB ID> --json`.
|
||||
|
||||
This avoids re-uploading gigabytes through the API and is the recommended path for large migrations.
|
||||
|
||||
### Fixing unread channels and threads
|
||||
|
||||
After importing, messages may appear unread for all users. The following fix is for PostgreSQL deployments only.
|
||||
|
||||
<Important>
|
||||
|
||||
Back up the Mattermost database before running these statements. Test the backup and the SQL in a non-production environment first.
|
||||
|
||||
</Important>
|
||||
|
||||
``` sql
|
||||
begin;
|
||||
UPDATE channelmembers
|
||||
SET
|
||||
msgcount = channels.totalmsgcount,
|
||||
lastupdateat = channels.lastpostat,
|
||||
lastviewedat = channels.lastpostat,
|
||||
msgcountroot = channels.totalmsgcountroot
|
||||
FROM channels
|
||||
WHERE channelmembers.channelid = channels.id;
|
||||
|
||||
INSERT INTO preferences (UserId, Category, Name, Value)
|
||||
SELECT
|
||||
cm.userid,
|
||||
'channel_approximate_view_time',
|
||||
cm.channelid,
|
||||
cm.lastupdateat::text
|
||||
FROM
|
||||
channelmembers cm
|
||||
ON CONFLICT (userid, category, name)
|
||||
DO UPDATE SET
|
||||
Value = EXCLUDED.Value;
|
||||
|
||||
update preferences set value = 'false' where category = 'direct_channel_show';
|
||||
update preferences set value = 'false' where category = 'group_channel_show';
|
||||
|
||||
commit;
|
||||
```
|
||||
|
||||
### Placeholder emails and account activation
|
||||
|
||||
Mattermost accounts are created from the emails and usernames in the export. Where an email is missing, a placeholder (for example `username@local`) is generated and must be corrected by a system administrator. Search the final `.jsonl` file for placeholder emails before importing.
|
||||
|
||||
Users activate their accounts through Mattermost's **Password Reset** screen using their email address:
|
||||
|
||||
- **Imports performed by a system administrator**: emails are automatically verified, and users can reset their password immediately.
|
||||
- **Imports performed by a non-administrator**: users must verify their email address before resetting their password.
|
||||
|
||||
See how to [migrate user authentication to LDAP or SAML](/administration-guide/manage/mmctl-command-line-tool#mmctl-user-migrate-auth) if you use SSO.
|
||||
|
||||
## 5. Validate, test, and go live
|
||||
|
||||
Before production cutover, validate a fresh or restored trial import end to end:
|
||||
|
||||
1. Compare the transform and import logs with source counts for users, channels, posts, and attachments, and investigate errors or unexpected omissions.
|
||||
2. Sign in as representative users and verify public and private channels, direct and group messages, threads, reactions, files, mentions, permissions, and authentication.
|
||||
3. Recreate integrations and custom emoji, then purge and rebuild the search index before testing search.
|
||||
4. Back up the production Mattermost database and file store, schedule a maintenance window, stop writes in Rocket.Chat, create a final export, and repeat the validated process on a fresh or restored production target.
|
||||
5. After final verification, update DNS or client configuration, invite users to activate their accounts, and keep the Rocket.Chat deployment read-only until the migration is accepted.
|
||||
|
||||
## What migrates and what doesn't
|
||||
|
||||
For core collaboration data — posts, threads, reactions, attachments, users, and channels — you can expect high fidelity. Integrations and Rocket.Chat-specific features do not carry over.
|
||||
|
||||
| Content type | Migrates? | Notes |
|
||||
|----|----|----|
|
||||
| Posts and threads | Yes | Rocket.Chat threads become Mattermost threaded replies. Oversized posts are split into continuation replies rather than truncated. |
|
||||
| Public channels | Yes | Display name, purpose (description), and header (topic) are preserved. |
|
||||
| Private channels | Yes | |
|
||||
| Discussions | Yes (converted) | Rocket.Chat discussions are converted to standalone Mattermost channels (public or private, matching the discussion's visibility). The parent-child relationship is not preserved. |
|
||||
| 1:1 direct messages | Yes | Map directly. Self-DMs are preserved as a direct channel with yourself. |
|
||||
| Group DMs (3–8 members) | Yes (converted) | Become Mattermost **Group Messages** — functionally equivalent, different terminology. |
|
||||
| Group DMs (over 8 members) | Converted | Mattermost group messages support at most 8 members, so larger group DMs are converted to **private channels**. |
|
||||
| Reactions | Yes | Emoji skin-tone modifiers are stripped to a default rendering. Custom emoji require matching names (see below). |
|
||||
| File attachments | Yes | From GridFS or FileSystem storage. Auto-generated thumbnails are skipped to avoid duplicates. |
|
||||
| Users | Yes | Inactive Rocket.Chat users are imported as deactivated accounts. |
|
||||
| Bots | Yes | Reassigned to the `--bot-owner` user. |
|
||||
| Channel mentions | Best effort | `#channel` references are translated to Mattermost `~channel` links where the channel exists. |
|
||||
| Join / leave / add / remove events | Yes | Converted to Mattermost system messages. |
|
||||
| Custom emoji images | No | Reaction *names* are preserved, but the emoji images are not imported (see below). |
|
||||
| Guest users | Configurable | Controlled by `--guest-handling` (default `guest`). By default, Rocket.Chat guest accounts are imported as Mattermost [guest users](/administration-guide/onboard/guest-accounts) — this requires Guest Accounts to be **licensed** (Professional/Enterprise) and [guest access](/administration-guide/configure/authentication-configuration-settings#guest-access) enabled on the target server. Use `--guest-handling user` to import them as regular members instead (no guest licensing needed), or `--guest-handling skip` to drop them entirely. |
|
||||
| Encrypted (E2E) channels | No | End-to-end encrypted rooms are skipped entirely, including their messages. |
|
||||
| Apps, integrations, slash commands, webhooks | No | Recreate using Mattermost [integrations](/integrations-guide/integrations-guide-index). |
|
||||
| Avatars, user status, custom profile fields | No | Users update their profiles in Mattermost after import. |
|
||||
| Pinned/starred messages, topic-change and mute events | No | These Rocket.Chat-specific records are not migrated. |
|
||||
|
||||
### Custom emoji
|
||||
|
||||
Custom emoji images are **not** imported with your messages — only the emoji *names* used in reactions are preserved. A reaction is stored as text (`:emoji-name:`) and resolved at render time:
|
||||
|
||||
- If a custom emoji with the same name exists in Mattermost, the reaction renders correctly.
|
||||
- If not, it shows as a placeholder until the emoji is added.
|
||||
|
||||
Because resolution happens at render time, you can add custom emoji to Mattermost **at any time** — before or after the import — and reactions on historical messages will render once a matching name exists. Names must match exactly.
|
||||
|
||||
## FAQ
|
||||
|
||||
**Do I need to create users before importing?** No. `mmetl` and the import process handle user creation and ordering automatically.
|
||||
|
||||
**What happens if I run the same import twice?** Re-running the same import avoids duplicate posts when identity fields are unchanged, but not every entity is deduplicated and edits to identifying fields can create additional records. Use a fresh or restored trial target for each test run.
|
||||
|
||||
**Where do all my channels and DMs go?** Into the single team you specify with `--team`. Rocket.Chat has no multi-workspace concept, so there is no team-mapping step.
|
||||
|
||||
**How are attachments stored, and why do I need `--uploads-dir`?** Rocket.Chat stores files either in MongoDB (GridFS) or on disk (FileSystem). GridFS files are captured in the `mongodump` automatically; FileSystem files are not, so you point `--uploads-dir` at the uploads directory. See [Attachment storage](#attachment-storage-gridfs-vs-filesystem).
|
||||
|
||||
**Why are some channels missing after import?** End-to-end encrypted rooms are skipped and their messages are not migrated. Check `transform-rocketchat.log` for skipped rooms.
|
||||
|
||||
**Do I need to import custom emoji before messages?** No. Emoji resolve at render time, so you can add them whenever.
|
||||
|
||||
**How do I handle a very large import?** Use the file store method — copy the archive directly into the server's `data/import` directory rather than uploading through `mmctl`. See [Large imports](#large-imports-file-store-method).
|
||||
|
||||
**I hit a parse error. Is my export broken?** Possibly not. Rocket.Chat changes its MongoDB schema between versions (this tool was validated against v8.5). Run `mmetl check rocketchat` first, and check for a newer `mmetl` release before assuming the data is at fault.
|
||||
416
docs/main/administration-guide/onboard/migrate-from-slack.mdx
Normal file
416
docs/main/administration-guide/onboard/migrate-from-slack.mdx
Normal file
@@ -0,0 +1,416 @@
|
||||
---
|
||||
title: "Migrate from Slack"
|
||||
---
|
||||
<PlanAvailability slug="all-commercial" />
|
||||
|
||||
## Overview
|
||||
|
||||
Mattermost provides a reliable migration path from Slack, enabling you to bring your organization’s collaboration history into a secure, self-hosted Mattermost environment. The migration process supports full workspaces, including users, channels and message history, direct messages, and threads so your teams can continue working without losing valuable context.
|
||||
|
||||
This process generally involves preparing your environment, exporting data from Slack, converting that data into a compatible format, and then importing it into Mattermost. Migrating from Slack is a multi-step process that can be complex, particularly for larger organizations or those with multiple Slack workspaces.
|
||||
|
||||
Additionally, please consider that Slack's data control policies or export capabilities may change at any time, or they may charge fees to customers for exporting data stored in Slack. Support for negotiating export of customer IP from Slack Enterprise can be requested by contacting a [Mattermost Expert](https://mattermost.com/contact-sales/).
|
||||
|
||||
1. [Preparations](#1-preparations):
|
||||
- Answer key scoping questions.
|
||||
- Gather environment and export details.
|
||||
- Validate Mattermost server capacity and configuration.
|
||||
- Back up your Mattermost environment before importing.
|
||||
2. [Export Slack data](#2-export-slack-data):
|
||||
- Generate an export from Slack.
|
||||
3. [Transform the export for Mattermost](#3-transform-the-export-for-mattermost):
|
||||
- Validate the Slack export using `mmetl check slack`.
|
||||
- Use the `mmetl` tool to parse and transform Slack exports.
|
||||
4. [Import into Mattermost](#4-import-data-into-mattermost):
|
||||
- Upload and process transformed archives with `mmctl`.
|
||||
5. Validate and test:
|
||||
- Confirm channel and user data imported correctly.
|
||||
- Run database queries to fix any unread states.
|
||||
6. Go live:
|
||||
- Communicate the cutover plan to users.
|
||||
|
||||
### Migration timeline
|
||||
|
||||
These instructions outline a *best effort* migration path designed to preserve the majority of your messages, files, and workspace structure. Mattermost provides tools and guidance to help streamline the process, but manual adjustments during the data transformation and import steps are often required. Successful migration depends on careful planning and dedicating sufficient time, technical resources, and technical skills to the effort.
|
||||
|
||||
Depending on the size and complexity of your Slack environment, a full migration can take anywhere from several days to multiple weeks of dedicated effort. Larger organizations with multiple workspaces, extensive message history, and many files should expect the process to require significant iteration and testing before completion. It’s important to plan for this timeline in advance by allocating the necessary resources, scheduling time for trial imports in a development environment, and coordinating across teams. Building in extra time for adjustments during the transformation and import steps will help ensure a smoother transition and reduce disruption to your users.
|
||||
|
||||
Scoping the migration appropriately during the preparation step can significantly reduce processing time and allow for faster iteration. Before beginning, carefully consider what data is essential to bring over to Mattermost. Many organizations find that not every channel or file needs to be migrated, and focusing only on what is truly needed can save substantial processing time and manual effort. By setting clear boundaries early, you’ll minimize the amount of data that requires manual intervention and testing, which in turn shortens the migration timeline and helps avoid unnecessary complexity.
|
||||
|
||||
<Note>
|
||||
|
||||
Consider [talking to a Mattermost expert](https://mattermost.com/contact-sales/) if your organization needs support migrating from Slack to Mattermost.
|
||||
|
||||
</Note>
|
||||
|
||||
## Migrations Steps
|
||||
|
||||
### 1. Preparations
|
||||
|
||||
Before beginning the migration, it’s important to properly prepare your environment. Careful preparation helps reduce processing time, allows for faster iteration, and minimizes the chance of running into avoidable issues during the import.
|
||||
|
||||
This document assumes you already have a Mattermost Server deployed that is ready to accept your Slack data. If not, consider the recommendations in this section in conjunction with the appropriate [deployment documentation](/deployment-guide/server/deploy-server#deployment-options) to make informed decisions about your supporting database and file storage infrastructure.
|
||||
|
||||
#### Scope definition
|
||||
|
||||
Start by defining the scope of your migration:
|
||||
|
||||
- **Slack edition**: Migrating from Slack Enterprise Grid involves additional [steps and planning](#faq).
|
||||
- **Data history**: Decide how much history is necessary to import. Importing a smaller time window (e.g., the last six months) can significantly reduce complexity and processing time.
|
||||
- **Export size**: Consider the size of your Slack export file as you progress through this guide. File size directly impacts how long the import will take - for example, files under ~25 GB often complete within a day, while exports over 100 GB can take several days, significantly lengthening the time between iterations and the overall timeline to complete the migration.
|
||||
- **File attachments**: Consider whether you can exclude very large or non-critical attachments (for example, public software download packages, videos, or outdated media assets) to reduce import size and speed up processing.
|
||||
|
||||
#### Infrastructure considerations
|
||||
|
||||
The environment where you run the import can significantly affect performance:
|
||||
|
||||
- **Test environment**: Always run the migration in a development or staging environment first. Most migrations require multiple iterations before a production import is successful.
|
||||
- **Operating system**: The `mmetl` tool is supported on Linux and macOS. Windows is not supported, and we do not recommend using Windows Subsystem for Linux (WSL) since the file system is not performant enough for the heavier processes involved in migration.
|
||||
- **Storage requirements**: Ensure your server can store both the Slack export archive and the fully unpacked data. As a best practice, plan for at least three times the size of your Slack export in available server storage.
|
||||
- **File Storage**: Imports into S3 file storage typically complete faster than imports into local storage or NFS. For large imports, we recommend using AWS S3 or another S3-compatible storage service for best performance.
|
||||
|
||||
#### Mattermost server considerations
|
||||
|
||||
Carefully preparing your environment and making these adjustments up front will help ensure the migration proceeds smoothly and reduces the need for repeated trial-and-error.
|
||||
|
||||
- **Fresh server**: The most reliable imports happen on a fresh Mattermost installation. If importing into an existing server, never import over an existing team.
|
||||
- **Server version**: Make sure you are running the latest supported version of [Mattermost](/product-overview/mattermost-server-releases) to benefit from the most up-to-date functionality and fixes.
|
||||
- **Backups**: When importing into an already existing Mattermost environment, back up both the Mattermost database and the data directory before starting. If an import fails, you’ll need to roll back or reset.
|
||||
- If merging multiple Slack workspaces into a single team is the desired end-result, we recommend completing the import to separate teams, validating the results, then using [mmctl](/administration-guide/manage/mmctl-command-line-tool#mmctl-channel-move) to move channels between teams.
|
||||
- **Configuration settings**: Adjust the following settings before starting the import:
|
||||
- `TeamSettings.MaxChannelsPerTeam`: Set this to a number much higher than the number of channels you are migrating.
|
||||
- `TeamSettings.MaxUsersPerTeam`: Set this to a number much higher than the number of users you are migrating.
|
||||
- **Team Settings \> Allow any user with an account on this server to join this team**: Ensure this is enabled for the team receiving the import.
|
||||
- `EmailSettings.EnableSignUpWithEmail` and `EmailSettings.EnableSignInWithEmail`: Both must be set to `true`
|
||||
- `FileSettings.MaxFileSize`: Set this higher than the largest file in your Slack export.
|
||||
- `ElasticsearchSettings.EnableIndexing`, `ElasticsearchSettings > EnableSearching` and `ElasticsearchSettings.EnableAutocomplete`: All must be set to `false` during the import to prevent performance issues. After the import, you can purge and reindex before enabling Elasticsearch.
|
||||
|
||||
### 2. Export Slack data
|
||||
|
||||
Slack offers two ways to [export your data from their product](https://slack.com/help/articles/201658943-Export-your-workspace-data).
|
||||
|
||||
1. **Public channels export** - Contains only public channel messages and file links. Available on all Slack plans. Generate this from **Slack \> Admin \> Workspace settings \> Security \> Import & export data \> Export**.
|
||||
2. **All channels and conversations export** - Contains all messages including public channels, private channels, DMs, and group messages. Available on Business+ (requires application approval from the workspace primary owner) and Enterprise Grid plans.
|
||||
|
||||
You will receive a zip file containing the following contents:
|
||||
|
||||
- Channels (`channels.json`)
|
||||
- Users (`users.json`)
|
||||
- Direct messages (`dms.json`) (All channels export)
|
||||
- Private channels (`groups.json`) (All channels export)
|
||||
- Group direct messages (`mpims.json`) (All channels export)
|
||||
- App activity logs (`integration_logs.json`)
|
||||
- Folders containing posts for every public channel
|
||||
- Folders containing posts for every private channel (All channels export)
|
||||
|
||||
<Note>
|
||||
|
||||
- Refer to the [Slack help article](https://slack.com/help/articles/220556107-How-to-read-Slack-data-exports) for additional details on zip file contents.
|
||||
- As a proprietary SaaS service, Slack is able to change its export format quickly and without notice.
|
||||
- Workspaces on the Slack Free plan can only export file links from the last 90 days.
|
||||
|
||||
</Note>
|
||||
|
||||
<Important>
|
||||
|
||||
Avoid unzipping and rezipping the Slack export. Doing so can modify the directory structure of the archive which could cause issues with the import process.
|
||||
|
||||
</Important>
|
||||
|
||||
### 3. Transform the export for Mattermost
|
||||
|
||||
Now that you have a Slack export file, let's convert it into Mattermost's bulk import format using the import preparation tool `mmetl`.
|
||||
|
||||
[Download the latest release of mmetl](https://github.com/mattermost/mmetl/releases/) for your OS and architecture. Run `mmetl help` to learn more about using the tool.
|
||||
|
||||
#### Validate the Slack export
|
||||
|
||||
Before transforming, validate the integrity of your Slack export using the `mmetl check` command:
|
||||
|
||||
``` sh
|
||||
./mmetl check slack --file <SLACK EXPORT FILE>
|
||||
```
|
||||
|
||||
This checks for structural issues in the export archive and reports any problems that may cause the transform or import to fail.
|
||||
|
||||
#### Run the transform
|
||||
|
||||
Run the command below to create a Mattermost bulk import file. Replace `<TEAM-NAME>` with the name of your team in Mattermost. Note that the name needs to be one word and lowercase (i.e. if you named your team `My Team`, `<TEAM-NAME>` would be `my-team`).
|
||||
|
||||
<Note>
|
||||
|
||||
The team must already exist on your Mattermost server before importing, and **Allow any user with an account on this server to join this team** must be enabled for that team.
|
||||
|
||||
</Note>
|
||||
|
||||
``` sh
|
||||
./mmetl transform slack --team <TEAM-NAME> --file <SLACK EXPORT FILE> --output mattermost_import.jsonl
|
||||
```
|
||||
|
||||
The tool outputs a [.jsonl](https://jsonlines.org/examples) file containing all of your users, channels, and posts. It also creates a `data` folder that contains all of your attachments. It doesn't matter what you name the `.jsonl` file. You can name it what you want with the `--output` flag as shown above. It just needs to be a `.jsonl` file.
|
||||
|
||||
#### Useful transform flags
|
||||
|
||||
The `mmetl transform slack` command supports several optional flags that can help with common migration scenarios:
|
||||
|
||||
- `--skip-attachments` / `-a`: Skip copying attachments from the import file. Useful for faster iteration when testing the import process before including attachments.
|
||||
- `--allow-download` / `-l`: Allow downloading attachments from URLs.
|
||||
- `--default-email-domain <DOMAIN>`: When a user's email is missing from the export, generate one from their username and the provided domain (e.g., `--default-email-domain example.com`).
|
||||
- `--skip-empty-emails`: Allow users with empty email addresses to be included in the output. Note that this results in invalid import data that will need to be manually corrected before importing.
|
||||
- `--discard-invalid-props` / `-p`: Discard posts with invalid properties. By default, such posts are kept but imported without their properties.
|
||||
|
||||
#### Debug transform
|
||||
|
||||
The `mmetl transform` process produces a `transform-slack.log` file that records INFO level output by default.
|
||||
|
||||
If you run the import commands with the `--debug` flag, the log will include additional `DEBUG` level entries. These entries provide more granular detail on each phase of the process, which can help identify where the transformation may be slowing down or failing.
|
||||
|
||||
#### MMETL parsing phases
|
||||
|
||||
When parsing a Slack export file with the `mmetl` tool, the process runs through four phases. You can track progress by monitoring the log output during each phase. Understanding these phases helps set expectations for how long the parsing step may take.
|
||||
|
||||
**1. Reading the import file**
|
||||
|
||||
In this phase, `mmetl` reads through the Slack export file. Example log line:
|
||||
|
||||
`{"file":"parse.go:359","level":"info","msg":"Processing file 1 of 10335: aluminum-white-lightbulb/","time":"2024-03-11T20:41:09-04:00"}`
|
||||
|
||||
This step usually takes 5–10 minutes depending on the size of the export archive.
|
||||
|
||||
**2. Converting user mentions**
|
||||
|
||||
During this phase, `mmetl` converts Slack user mentions into Mattermost-compatible format. Example log line:
|
||||
|
||||
`{"file":"parse.go:224","level":"debug","msg":"Slack Import: converting user mentions for channel touchscreen-headphones-sleek. 1 of 400","time":"2024-03-11T20:41:10-04:00"}`
|
||||
|
||||
This step can be time-consuming on large imports and may take several hours.
|
||||
|
||||
**3. Converting channel mentions**
|
||||
|
||||
In this phase, channel references are updated. Example log line:
|
||||
|
||||
`{"file":"parse.go:259","level":"debug","msg":"Slack Import: converting channel mentions for channel robust-smart-home-device-matrix. 95 of 400","time":"2024-03-11T20:41:48-04:00"}`
|
||||
|
||||
This step typically completes in about half the time required for user mentions.
|
||||
|
||||
**4. Converting post markup**
|
||||
|
||||
Finally, Slack message formatting is converted into Mattermost-compatible Markdown. Example log line:
|
||||
|
||||
`{"file":"parse.go:330","level":"debug","msg":"Slack Import: converting markdown for channel vertex-robust-vacuum. 120 of 400","time":"2024-03-11T20:41:58-04:00"}`
|
||||
|
||||
This is the fastest step and usually completes quickly.
|
||||
|
||||
### 4. Import data into Mattermost
|
||||
|
||||
You can upload the export through Mattermost's API from the server or from another computer using mmctl commands. The server will save the import in its file store before running the import (e.g. AWS S3), so there will be time spent uploading/downloading the file in this case.
|
||||
|
||||
The migration is idempotent, meaning that you can run multiple imports that contain the same posts, and there won't be duplicated created posts in Mattermost. Each post is imported with the correct user/author and `created_at` value from your Slack instance.
|
||||
|
||||
Ensure you have the Mattermost command line tool `mmctl` installed. This allows you to perform different tasks that communicate to Mattermost's API. You'll also want to [configure authentication](/administration-guide/manage/mmctl-command-line-tool#mmctl-auth) for the tool.
|
||||
|
||||
To prepare our files to be uploaded to the server, we need to put both the `.jsonl` file and `data` folder together into a zip file.
|
||||
|
||||
``` sh
|
||||
zip -r mattermost-bulk-import.zip data mattermost_import.jsonl
|
||||
```
|
||||
|
||||
Validate the import file locally before uploading. This checks the file structure and content without needing to upload it to the server:
|
||||
|
||||
``` sh
|
||||
mmctl import validate ./mattermost-bulk-import.zip
|
||||
```
|
||||
|
||||
Then we can upload the zip file to our Mattermost server. These files can be very large, so getting them onto the server can be challenging. You have two primary options for this step:
|
||||
|
||||
- You can use the `mmctl` tool:
|
||||
|
||||
``` sh
|
||||
mmctl import upload ./mattermost-bulk-import.zip
|
||||
```
|
||||
|
||||
- Alternatively, you can move the file directly to the data directory under `data/import` and give it a unique name.
|
||||
|
||||
Run this command to list the available imports:
|
||||
|
||||
``` sh
|
||||
mmctl import list available
|
||||
```
|
||||
|
||||
Run this command to process the import. Replace `<IMPORT FILE NAME>` with the name you got from the `mmctl import list available` command:
|
||||
|
||||
``` sh
|
||||
mmctl import process <IMPORT FILE NAME>
|
||||
```
|
||||
|
||||
Finally, run this command to view the status of the import process job. If the job status shows as `pending`, then wait before running the command again. The `--json` flag is required to view the possible error message. Replace `<JOB ID>` with the id you got from the `mmctl import job list` command:
|
||||
|
||||
``` sh
|
||||
mmctl import job show <JOB ID> --json
|
||||
```
|
||||
|
||||
#### Debug imports
|
||||
|
||||
You can use the `mmctl import job show` command to view any relevant errors that may have occurred.
|
||||
|
||||
#### Fixing unread channels and threads
|
||||
|
||||
After importing, all messages may appear as unread for users. To resolve this issue, run the following SQL queries directly against the Mattermost database:
|
||||
|
||||
``` sql
|
||||
begin;
|
||||
UPDATE channelmembers
|
||||
SET
|
||||
msgcount = channels.totalmsgcount,
|
||||
lastupdateat = channels.lastpostat,
|
||||
lastviewedat = channels.lastpostat,
|
||||
msgcountroot = channels.totalmsgcountroot
|
||||
FROM channels
|
||||
WHERE channelmembers.channelid = channels.id;
|
||||
|
||||
INSERT INTO preferences (UserId, Category, Name, Value)
|
||||
SELECT
|
||||
cm.userid,
|
||||
'channel_approximate_view_time',
|
||||
cm.channelid,
|
||||
cm.lastupdateat
|
||||
FROM
|
||||
channelmembers cm
|
||||
ON CONFLICT (userid, category, name)
|
||||
DO UPDATE SET
|
||||
Value = EXCLUDED.Value;
|
||||
|
||||
update preferences
|
||||
set value = false
|
||||
where category = 'direct_channel_show';
|
||||
|
||||
update preferences
|
||||
set value = false
|
||||
where category = 'group_channel_show';
|
||||
|
||||
commit;
|
||||
```
|
||||
|
||||
#### Address placeholder emails
|
||||
|
||||
During the import process, the emails and usernames from Slack are used to create new Mattermost accounts. If emails are not present in the Slack export archive, then placeholder values will be generated and the system admin will need to update these manually. We recommend administrators search the final import `jsonl` file for `user` lines with `@example.com` in the email property to address and resolve the missing information prior to import.
|
||||
|
||||
### Email verification behavior
|
||||
|
||||
The email verification process during Slack import depends on who performs the import:
|
||||
|
||||
**System administrator imports:**
|
||||
|
||||
- Email addresses are automatically verified during the import process.
|
||||
- Users can immediately use the **Password Reset** feature to set their password.
|
||||
- No email verification steps are required before password reset.
|
||||
|
||||
**Non-administrator imports:**
|
||||
|
||||
- Email addresses remain unverified after import.
|
||||
- Users must first verify their email addresses before they can reset their password.
|
||||
- Additional email verification steps are required before account access.
|
||||
|
||||
### Account activation
|
||||
|
||||
- Slack users activate their new Mattermost accounts by using Mattermost's **Password Reset** screen with their email addresses from Slack to set new passwords for their Mattermost accounts. See the instructions on how to [migrate user authenticatation to LDAP or SAML](/administration-guide/manage/mmctl-command-line-tool#mmctl-user-migrate-auth).
|
||||
- For imports performed by System Admins: Users can immediately use the **Password Reset** feature (no email verification is required).
|
||||
- For imports performed by non-administrators: Users must first verify their email addresses, then use the **Password Reset** feature.
|
||||
- Once logged in, Mattermost users will have access to previous Slack messages in the public channels imported from Slack.
|
||||
|
||||
## FAQ
|
||||
|
||||
What additional considerations are there for Slack Enterprise Grid? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Slack Enterprise Grid combines multiple workspaces under a single management plane and the associated export reflects that complexity. An Enterprise Grid export is a single archive containing all workspaces and shared channels.
|
||||
|
||||
Mattermost does not support shared channels between teams, so Slack Shared Channels must be mapped to a single team in Mattermost. We can create this mapping by determining the originating teams in Slack and creating a `team.json` mapping file for use with `mmetl`. Because of the manual effort required to identify and map team IDs, Enterprise Grid migrations are typically more time-consuming than single-workspace migrations. Plan additional time and resources to complete this step successfully.
|
||||
|
||||
#### Export structure
|
||||
|
||||
At the root level, you’ll see shared channels that span across Slack workspaces, and under `/teams/` you’ll find per-workspace data such as channels and users files. A typical structure looks like:
|
||||
|
||||
``` text
|
||||
Enterprise Grid Export/
|
||||
├── channel1/
|
||||
│ ├── 2023-01-01.json
|
||||
│ └── 2023-01-02.json
|
||||
├── channel2/
|
||||
│ ├── 2023-05-01.json
|
||||
│ └── 2023-05-02.json
|
||||
├── teams/
|
||||
│ ├── team1/
|
||||
│ │ ├── channel3/
|
||||
│ │ │ ├── 2023-05-01.json
|
||||
│ │ │ └── 2023-05-02.json
|
||||
│ │ ├── channels.json
|
||||
│ │ ├── mpims.json
|
||||
│ │ ├── dms.json
|
||||
│ │ ├── users.json
|
||||
│ │ └── groups.json
|
||||
│ └── team2/
|
||||
│ ├── channel4/
|
||||
│ │ ├── 2023-05-01.json
|
||||
│ │ └── 2023-05-02.json
|
||||
│ ├── channels.json
|
||||
│ ├── mpims.json
|
||||
│ ├── dms.json
|
||||
│ ├── users.json
|
||||
│ └── groups.json
|
||||
├── channels.json
|
||||
├── org_users.json
|
||||
├── mpims.json
|
||||
├── dms.json
|
||||
└── groups.json
|
||||
```
|
||||
|
||||
#### Mapping shared channels to Mattermost teams
|
||||
|
||||
1. Download the full Enterprise Grid export from Slack.
|
||||
2. To determine where each shared channel belongs in Mattermost, look for a `team` attribute on the first post in each shared channel. These `team` values map the channel back to its originating workspace in Slack. This is where each shared channel will live in Mattermost once imported.
|
||||
|
||||
> ``` json
|
||||
> {
|
||||
> "client_msg_id": "",
|
||||
> "type": "",
|
||||
> "text": "",
|
||||
> "user": "U1",
|
||||
> "ts": "1695219722.430309",
|
||||
> "blocks": [ ],
|
||||
> "team": "team1",
|
||||
> "user_team": "team1",
|
||||
> "source_team": "team1",
|
||||
> "user_profile": { }
|
||||
> },
|
||||
> ```
|
||||
|
||||
3. Create a `teams.json` file that maps Slack team IDs to each `team` attribute you found above. For example:
|
||||
|
||||
> ``` json
|
||||
> {
|
||||
> "T0001" : "team1",
|
||||
> "T0002" : "team2"
|
||||
> }
|
||||
> ```
|
||||
|
||||
4. Run the `mmetl grid-transform` command to split the Enterprise Grid export into per-team files:
|
||||
|
||||
> ``` bash
|
||||
> ./mmetl grid-transform -f slackexport.zip -t teams.json
|
||||
> ```
|
||||
|
||||
This process outputs a new archive for each team defined in `teams.json`. Once split, you can continue the standard Mattermost import process on each file.
|
||||
|
||||
### Are there features of Slack that are not supported for migration to Mattermost?
|
||||
|
||||
The Slack import process focuses on preserving core collaboration data such as messages, files, channels, and users. However, certain Slack features are not supported by the Mattermost product and thus will not be migrated using the import tools in this document:
|
||||
|
||||
- **Slack apps and integrations**: Installed apps, bots, slash commands, webhooks, workflow builder and other integrations do not migrate. Most integrations supported by Slack can be recreated using the [integration and automation](/integrations-guide/integrations-guide-index) options in Mattermost.
|
||||
- **Starred conversations**: Starred conversations are not preserved.
|
||||
- **User groups**: User groups from Slack are not preserved, however they can be recreated in Mattermost using the [Custom Groups](/end-user-guide/collaborate/organize-using-custom-user-groups) feature.
|
||||
- **Threaded conversations**: Slack threads are mostly supported, however some threading relationships may not always be preserved given the differences in how Mattermost and Slack threading works.
|
||||
- **Canvases**: Canvases are not supported in Mattermost and will not be migrated.
|
||||
- **User presence and profiles**: User status (online/away), profile pictures, and custom profile fields do not carry over. Users will need to update their profiles in Mattermost.
|
||||
- **Channel memberships for deactivated users**: Deactivated or deleted Slack users are not migrated to Mattermost.
|
||||
|
||||
Because of these limitations, some manual reconfiguration is typically required after the import, especially for workflows and integrations. Support from a [Mattermost expert is available](https://mattermost.com/contact-sales/) for your Slack migration.
|
||||
@@ -0,0 +1,131 @@
|
||||
---
|
||||
title: "Migrate from GitLab Omnibus to standalone Mattermost"
|
||||
---
|
||||
## Overview
|
||||
|
||||
GitLab has announced the [deprecation of Mattermost from the GitLab Omnibus package](https://docs.gitlab.com/update/deprecations/#mattermost-bundled-with-linux-package) with GitLab 19.0. As part of this transition, GitLab will continue to support Mattermost **up to version 10.11 ESR** within the Omnibus installation until the final removal date.
|
||||
|
||||
To ensure continuity and long-term support, organizations using Mattermost within GitLab Omnibus should plan to migrate to a **standalone Mattermost installation**. This approach provides ongoing access to the latest Mattermost releases, security updates, and enterprise capabilities independent of GitLab’s release cycle.
|
||||
|
||||
Migrating to a standalone deployment also enables greater flexibility in managing infrastructure, upgrading PostgreSQL, and scaling Mattermost independently to meet performance and compliance requirements.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
Before you begin:
|
||||
|
||||
- Administrative (root or sudo) access to the GitLab Omnibus server.
|
||||
- A new standalone **PostgreSQL** server prepared and accessible.
|
||||
- Sufficient disk space for the Mattermost database dump.
|
||||
- A planned maintenance window, as Mattermost downtime is required.
|
||||
- A current full backup of your Mattermost instance, including database and file storage.
|
||||
|
||||
## Migration Steps
|
||||
|
||||
Follow the steps below to safely migrate from GitLab Omnibus to a standalone Mattermost installation.
|
||||
|
||||
<Note>
|
||||
|
||||
The following procedure assumes your Mattermost database name is `mattermost_production` and your PostgreSQL user is `mmuser`. Adjust as needed for your environment.
|
||||
|
||||
</Note>
|
||||
|
||||
### Step 1: Create a Database Dump from GitLab Omnibus
|
||||
|
||||
Use the GitLab Omnibus PostgreSQL tools to create a dump of the Mattermost database. Run this command on the GitLab server:
|
||||
|
||||
``` bash
|
||||
sudo gitlab-psql -- /opt/gitlab/embedded/bin/pg_dump -h /var/opt/gitlab/postgresql --no-owner mattermost_production | gzip > mattermost_dbdump_$(date --rfc-3339=date).sql.gz
|
||||
```
|
||||
|
||||
This will create a compressed SQL dump file of your Mattermost database.
|
||||
|
||||
### Step 2: Prepare the New PostgreSQL Server
|
||||
|
||||
Set up your new PostgreSQL server following the official [Mattermost database preparation guidelines](/deployment-guide/server/prepare-database). This includes:
|
||||
|
||||
- Installing the correct PostgreSQL version supported by your Mattermost server.
|
||||
- Creating a new Mattermost database and user with appropriate permissions.
|
||||
|
||||
### Step 3: Transfer and Restore the Database Dump
|
||||
|
||||
Transfer the database dump file to your new PostgreSQL server, then restore it:
|
||||
|
||||
``` bash
|
||||
zcat /tmp/mattermost_dbdump.sql.gz | psql -U mmuser -d mattermost
|
||||
```
|
||||
|
||||
Verify that the database restoration completes successfully without errors.
|
||||
|
||||
### Step 4: Update Mattermost Configuration
|
||||
|
||||
On your standalone Mattermost server, update the `config.json` file to point to the new PostgreSQL server. Locate the `SqlSettings.DataSource` parameter and update it as follows:
|
||||
|
||||
``` json
|
||||
"SqlSettings": {
|
||||
"DriverName": "postgres",
|
||||
"DataSource": "postgres://mmuser:password@new-postgres-server:5432/mattermost?sslmode=disable&connect_timeout=10"
|
||||
}
|
||||
```
|
||||
|
||||
Ensure that credentials, hostnames, and connection settings match your new PostgreSQL configuration.
|
||||
|
||||
### Step 5: Migrate the Mattermost Application and Data
|
||||
|
||||
To move Mattermost application files from the GitLab server to a new standalone server:
|
||||
|
||||
1. **Install the same or newer version** of Mattermost on the new server. See [Deploy the Mattermost server](/deployment-guide/server/deploy-server#deployment-options).
|
||||
|
||||
2. **Copy your existing configuration and data** from the GitLab Omnibus instance:
|
||||
|
||||
``` bash
|
||||
# On the GitLab server
|
||||
sudo cp /var/opt/gitlab/mattermost/config/config.json /tmp/
|
||||
sudo cp -r /var/opt/gitlab/mattermost/data /tmp/mattermost_data
|
||||
|
||||
# Transfer to new Mattermost server
|
||||
scp /tmp/config.json mattermost@new-server:/opt/mattermost/config/
|
||||
scp -r /tmp/mattermost_data mattermost@new-server:/opt/mattermost/data/
|
||||
```
|
||||
|
||||
3. Ensure permissions are correctly set on the new server:
|
||||
|
||||
``` bash
|
||||
sudo chown -R mattermost:mattermost /opt/mattermost
|
||||
```
|
||||
|
||||
### Step 6: Start Mattermost
|
||||
|
||||
Start the Mattermost service on your new standalone installation:
|
||||
|
||||
``` bash
|
||||
sudo systemctl start mattermost
|
||||
```
|
||||
|
||||
Mattermost will now connect to your standalone PostgreSQL database.
|
||||
|
||||
### Step 7: Verify the Migration
|
||||
|
||||
After starting Mattermost, perform the following checks:
|
||||
|
||||
- Confirm that Mattermost starts successfully with no database connection errors.
|
||||
- Review server logs for any startup or connection issues.
|
||||
- Log into Mattermost and verify that all teams, channels, and users are present.
|
||||
- Post test messages and upload files to confirm functionality.
|
||||
- Validate user authentication and permissions.
|
||||
- Confirm that database queries are directed to the new PostgreSQL server.
|
||||
|
||||
## Important Considerations
|
||||
|
||||
- Always maintain a **full backup** of your Mattermost database before migration.
|
||||
- Schedule a **maintenance window** to minimize user disruption.
|
||||
- Validate performance and monitoring configurations post-migration.
|
||||
- Ensure that your new PostgreSQL server follows Mattermost’s security and tuning best practices.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
If you encounter errors during the migration:
|
||||
|
||||
- Review PostgreSQL logs for permission or connection issues.
|
||||
- Verify that the Mattermost PostgreSQL user has full access to the restored database.
|
||||
- Ensure that the `config.json` file contains the correct database connection string.
|
||||
- Restart the Mattermost service and check `mattermost.log` for detailed errors.
|
||||
@@ -0,0 +1,77 @@
|
||||
---
|
||||
title: "Migration guide"
|
||||
---
|
||||
<PlanAvailability slug="all-commercial" />
|
||||
|
||||
Migrations help you move your Mattermost deployment or data from one environment to another with minimal disruption. Whether you’re transitioning your Mattermost server to new infrastructure, restructuring your database, or moving from another collaboration platform like Slack, this guide provides step-by-step instructions for each supported path. Use the sections below to quickly find the scenario that matches your needs and follow the recommended process to ensure a smooth migration.
|
||||
|
||||
To change the database or container images an existing deployment runs on, see [data export and infrastructure migration](/administration-guide/manage/admin/migration) instead.
|
||||
|
||||
[Book a live demo](https://mattermost.com/request-demo/) or [talk to a Mattermost expert](https://mattermost.com/contact-sales/) to explore tailored solutions for your organization's secure collaboration needs. Or try Mattermost yourself with a [1-hour preview](https://mattermost.com/sign-up/) for instant access to a live sandbox environment.
|
||||
|
||||
## Move Mattermost to a new server
|
||||
|
||||
The following instructions migrate Mattermost from one server to another by backing up and restoring the Mattermost database and `config.json` file. For these instructions, `SOURCE` refers to the Mattermost server *from which* your system will be migrated and `DESTINATION` refers to the Mattermost server *to which* your system will be migrated.
|
||||
|
||||
1. Back up your SOURCE Mattermost server. See [Backup and Disaster Recovery documentation](/deployment-guide/backup-disaster-recovery).
|
||||
2. Upgrade your SOURCE Mattermost server to the latest major build version. See [Upgrading Mattermost Server documentation](/administration-guide/upgrade/upgrading-mattermost-server).
|
||||
3. Install the latest major build of Mattermost server as your `DESTINATION`.
|
||||
|
||||
> - Make sure your new instance is properly configured and tested. The database type (MySQL or PostgreSQL) and version of `SOURCE` and `DESTINATION` deployments need to match.
|
||||
> - Stop the `DESTINATION` server using `sudo stop mattermost`, then back up the database and `config.json` file.
|
||||
|
||||
4. Migrate database from `SOURCE` to `DESTINATION`. Backup the database from the `SOURCE` Mattermost server and restore it in place of the database to which the `DESTINATION` server is connected.
|
||||
5. Migrate `config.json` from `SOURCE` to `DESTINATION`. Copy `config.json` file from `SOURCE` deployment to `DESTINATION`.
|
||||
6. If you use local storage (`FileSettings.DriverName` is set to `local`), migrate `./data` from `SOURCE` to `DESTINATION`.
|
||||
|
||||
> - Copy the `./data` directory from `SOURCE` deployment to `DESTINATION`.
|
||||
> - If you use a directory other than `./data`, copy that directory instead.
|
||||
|
||||
7. Start the `DESTINATION` deployment by running `sudo start mattermost`. Then go to the **System Console**, make a minor change, and save it to upgrade your `config.json` schema to the latest version using default values for any new settings added.
|
||||
8. Test that the system is working by going to the URL of an existing team. You may need to refresh your Mattermost browser page in order to get the latest updates from the upgrade.
|
||||
|
||||
Once your migration is complete and verified, you can optionally [upgrade the Team Edition of Mattermost to Enterprise Edition using the upgrade guide](/administration-guide/upgrade/upgrading-mattermost-server#upgrade-team-edition-to-enterprise-edition).
|
||||
|
||||
## Move from Slack
|
||||
|
||||
See the [Migrate from Slack](/administration-guide/onboard/migrate-from-slack) documentation for details on migrating from Slack to Mattermost.
|
||||
|
||||
## Move from Rocket.Chat
|
||||
|
||||
See the [Migrate from Rocket.Chat](/administration-guide/onboard/migrate-from-rocketchat) documentation for details on migrating from Rocket.Chat to Mattermost.
|
||||
|
||||
## Move from Jabber
|
||||
|
||||
BrightScout helped a major U.S. Federal Agency rapidly migrate from Jabber to Mattermost and open sourced their Extract, Transform and Load (ETL) tool at [https://github.com/Brightscout/mattermost-etl](https://github.com/Brightscout/mattermost-etl). Read more about their [case study](https://mattermost.com/blog/u-s-federal-agency-migrates-from-jabber-to-mattermost-the-open-source-way/) online.
|
||||
|
||||
## Move from Pidgin
|
||||
|
||||
In some cases, people are using Pidgin clients with different backends to communicate. To continue using Pidgin with a Mattermost backend, consider using [Mattermost ETL tool](https://github.com/Brightscout/mattermost-etl), created by BrightScout, to migrate data from your existing backend into Mattermost.
|
||||
|
||||
Then use the [Pidgin-Mattermost plugin](https://github.com/EionRobb/purple-mattermost) (complete with an installer for end user machines) to continue to support legacy Pidgin users while offering a whole new Mattermost experience on web, mobile, and PC.
|
||||
|
||||
## Move from Bitnami
|
||||
|
||||
Bitnami uses MySQL, and renames the Mattermost database tables by converting the names to all lower case. For example, in non-Bitnami installations, the Users table is named `Users`, but in Bitnami, the table is `users` (with a lowercase `u`). As a result, when you migrate your data from Bitnami to a non-Bitnami installation, you must modify the MySQL startup script so that it starts MySQL in lowercase table mode.
|
||||
|
||||
You can modify the script by adding the `--lower-case-table-names=1` switch to the MySQL start command. The location of the start-up script generally depends on how you installed MySQL, whether by using the package manager for the operating system, or by manually installing MySQL. You must modify the start-up script before migrating the data.
|
||||
|
||||
For more information about letter case in MySQL table names and the `--lower-case-table-names` switch, see the [Identifier Case Sensitivity](https://dev.mysql.com/doc/refman/5.7/en/identifier-case-sensitivity.html) topic in the MySQL documentation.
|
||||
|
||||
## Move from bespoke messaging solutions
|
||||
|
||||
Mattermost is often selected to replace bespoke solutions by IT and DevOps teams as a stable, enterprise-grade, commercially-supported solution on an open source platform that meets and exceeds the flexibility and innovation of bespoke solutions.
|
||||
|
||||
Migrating from bespoke messengers to Mattermost can be challenging. Because of the difficulty of upgrading and maintaining bespoke solutions, the format for storing data is unpredictable, and the community around any single legacy release is small.
|
||||
|
||||
If your data in the bespoke messenger is vital, consider:
|
||||
|
||||
1. [Mattermost bulk import tool](/administration-guide/onboard/bulk-loading-data): Use the Mattermost bulk import tool to ETL from your bespoke system to Mattermost.
|
||||
2. [Mattermost ETL framework from BrightScout](https://github.com/Brightscout/mattermost-etl): Consider the Mattermost ETL framework from BrightScout to custom-configure an adapter to plug in to the bulk import tool mentioned above.
|
||||
3. **Legacy Slack import:** If you only recently switched from Slack to a bespoke tool, consider going back to import the data and users from the old Slack instance directly into Mattermost, leveraging the extensive support for Slack-import provided.
|
||||
4. **Export to Slack, then import to Mattermost:** [Export Flowdock, Campfire, Chatwork, Hall, or CSV files to Slack](https://slack.com/help/articles/217872578-Import-data-from-one-Slack-workspace-to-another) and then export to a Slack export file and import the file into Mattermost.
|
||||
|
||||
If your data in the bespoke messenger is not vital, consider:
|
||||
|
||||
1. **Parallel systems:** Running Mattermost in parallel with your bespoke system until the majority of workflow and collaboration has moved to Mattermost
|
||||
2. **Hard switch:** Announce a "hard switch" to Mattermost after a period of time of running both systems in parallel. Often this has been done due to security concerns in bespoke products or products nearing end-of-life.
|
||||
@@ -0,0 +1,33 @@
|
||||
---
|
||||
title: "Migration announcement email"
|
||||
---
|
||||
<PlanAvailability slug="all-commercial" />
|
||||
|
||||
To notify your end users of your migration to Mattermost, we created a sample email template that you can use.
|
||||
|
||||
Remember to replace all the items in bold with your information.
|
||||
|
||||
## Email template
|
||||
|
||||
To: End users
|
||||
|
||||
Subject: Moving to Mattermost
|
||||
|
||||
Hi all,
|
||||
|
||||
As some of you already know, we are moving from **\[System\]** to Mattermost as our collaboration platform. We have imported our existing users and data into Mattermost so we can continue to communicate, share files and collaborate.
|
||||
|
||||
To get started:
|
||||
|
||||
1. Open a browser on your computer, go to **\[Mattermost URL\]** and select “I forgot my password” to set your new password for Mattermost using the email address you used on the previous system.
|
||||
2. Once you reset your password, use your email and new password to log in.
|
||||
3. [Download](https://mattermost.com/apps) the Mattermost apps for desktop and mobile. Refer to the [Use Mattermost](/end-user-guide/end-user-guide-index) end user documentation on how to get up and running quickly.
|
||||
4. Remember to bookmark the URL so you can use it to log in next time!
|
||||
|
||||
Questions?
|
||||
|
||||
If you have any questions, feel free to post in the **\[~Mattermost channel\]** or email us at **\[Support email\]**.
|
||||
|
||||
Happy collaborating!
|
||||
|
||||
**\[Sign-off\]**
|
||||
@@ -0,0 +1,44 @@
|
||||
---
|
||||
title: "Multi-factor authentication"
|
||||
---
|
||||
<PlanAvailability slug="all-commercial" />
|
||||
|
||||
Multi-factor authentication (MFA) is a secondary layer of user authentication applied to your Mattermost server that applies to all users on all teams within your Mattermost workspace.
|
||||
|
||||
With MFA enabled, users need to provide a secure one-time code in addition to their username and password in order to log in to Mattermost. MFA is useful in organizations that have specific security and compliance policies. It can also be used in organizations where Mattermost is not behind a firewall and doesn't have access to existing MFA infrastructure.
|
||||
|
||||
Mattermost offers a smartphone-based MFA check in addition to email-password or Active Directory/LDAP authentication to log in to the Mattermost server.
|
||||
|
||||
Supported devices include iOS, Android, or other devices that are able to install a software-based authenticator such as FreeOTP, Google Authenticator, Microsoft Authenticator, 1Password, LastPass, or a similar app. After the app is installed, the device does not require internet access.
|
||||
|
||||
<Note>
|
||||
|
||||
As the MFA implementation relies on Time-based One-time passwords (TOTP) ensure that your server system time is accurate. If there is a discrepancy, users may not be able to log in successfully.
|
||||
|
||||
</Note>
|
||||
|
||||
## Enabling MFA
|
||||
|
||||
System admins can enable this option by going to **System Console \> Authentication \> MFA**, then setting **Enable Multi-factor Authentication** to **true**.
|
||||
|
||||
Once enabled, users can choose to [set up multi-factor authentication](/end-user-guide/preferences/manage-your-security-preferences) on their account by selecting **Profile \> Security \> Multi-factor Authentication** from their profile picture.
|
||||
|
||||
### Disabling MFA
|
||||
|
||||
System admins can disable this option by going to **System Console \> Authentication \> MFA**. When **Enable Multi-factor Authentication** is set to **false**, users can't opt to use or disable multi-factor authentication on their account via **Profile \> Security \> Multi-factor Authentication**.
|
||||
|
||||
MFA can be disabled for user accounts using the API. See the [Mattermost API Reference](https://api.mattermost.com/#tag/users/paths/~1users~1{user_id}~1mfa/put) for details.
|
||||
|
||||
## Enforcing MFA
|
||||
|
||||
Admins can fulfill Multi-Factor Authentication (MFA) compliance requirements by enforcing an MFA requirement for login with email and LDAP accounts. Go to **System Console \> Authentication \> MFA**, then set **Enforce Multi-factor Authentication** to **true**.
|
||||
|
||||
When MFA enforcement is set to **true**, users with email or LDAP authentication who don't have MFA set up will be directed to the MFA setup page when they log in to Mattermost. They will not be able to access the site until MFA setup is complete. Any new users will be required to set up MFA during the sign up process.
|
||||
|
||||
Users will not be able to remove MFA from their account while enforcement is on.
|
||||
|
||||
<Note>
|
||||
|
||||
Turning on MFA enforcement prevents users from accessing the site until set up is complete. We recommended that you turn on enforcement during non-peak hours when people are less likely to be using Mattermost.
|
||||
|
||||
</Note>
|
||||
21
docs/main/administration-guide/onboard/onboard-index.mdx
Normal file
21
docs/main/administration-guide/onboard/onboard-index.mdx
Normal file
@@ -0,0 +1,21 @@
|
||||
---
|
||||
title: "Onboard users"
|
||||
sidebar_label: "Onboard users"
|
||||
---
|
||||
Getting your organization into Mattermost: connect the identity provider your users already have, and get their accounts in.
|
||||
|
||||
Access control for a workspace that's already running, including permissions and roles, is covered in [access control](/administration-guide/manage/admin/user-management).
|
||||
|
||||
## Authentication
|
||||
|
||||
- [Single sign-on](/administration-guide/onboard/corporate-directory-integration) - Connect Mattermost to your identity provider using SAML, OpenID Connect, or OAuth 2.0.
|
||||
- [AD/LDAP](/administration-guide/onboard/ad-ldap) - Synchronize accounts and groups from Active Directory or LDAP.
|
||||
- [Multi-factor authentication](/administration-guide/onboard/multi-factor-authentication) - Require a second factor at sign-in.
|
||||
- [SSL client certificate setup](/administration-guide/onboard/ssl-client-certificate) - Configure mutual TLS authentication for browsers and the desktop apps.
|
||||
|
||||
## Accounts
|
||||
|
||||
- [Provisioning workflows](/administration-guide/onboard/user-provisioning-workflows) - Choose how accounts are created, updated, and deactivated.
|
||||
- [Guest accounts](/administration-guide/onboard/guest-accounts) - Give people outside your organization access to specific channels.
|
||||
|
||||
To pre-provision accounts in bulk, to bring teams, channels, and message history in from another system, or to move an existing deployment onto different infrastructure, see [Migrate](/administration-guide/manage/admin/migration).
|
||||
@@ -0,0 +1,133 @@
|
||||
---
|
||||
title: "SSL client certificate setup"
|
||||
---
|
||||
<PlanAvailability slug="all-commercial" />
|
||||
|
||||
Follow these steps to configure SSL client certificates for your browser and the Mattermost desktop apps on Windows, macOS, and Linux.
|
||||
|
||||
Before you begin, follow the [official guides to install Mattermost](/deployment-guide/deployment-guide-index) on your system, including NGINX configuration as a proxy with SSL and HTTP/2, and a valid SSL certificate such as Let's Encrypt.
|
||||
|
||||
For the purposes of this guide, the Mattermost server domain name is `example.mattermost.com`, and the user account is `mmuser` with email `mmuser@mattermost.com` and password `mmuser-password`.
|
||||
|
||||
<Important>
|
||||
|
||||
\- Generating the client certificates in this section is optional if you have already generated them before. - We strongly recommend configuring an SSL certificate (or a self-signed certificate) for security, privacy, compliance, as well as to avoid browser limitations that can prevent Mattermost product features from working that copy data using the user's local clipboard, including [sharing message links](/end-user-guide/collaborate/share-links#share-message-links) and [inviting people](/end-user-guide/collaborate/invite-people). - SSL client certificates are not yet supported on the Mattermost mobile apps.
|
||||
|
||||
</Important>
|
||||
|
||||
## Set up mutual TLS authentication for the web app
|
||||
|
||||
1. Create a [certificate authority (CA) key](https://en.wikipedia.org/wiki/Certificate_authority) and a certificate for signing the client certificate. When establishing a TLS connection, the NGINX proxy server requests and validates a client certificate provided by the web app.
|
||||
|
||||
``` sh
|
||||
openssl genrsa -des3 -out ca.mattermost.key 4096
|
||||
```
|
||||
|
||||
``` text
|
||||
pass phrase: capassword
|
||||
```
|
||||
|
||||
``` sh
|
||||
openssl req -new -x509 -days 365 -key ca.mattermost.key -out ca.mattermost.crt
|
||||
```
|
||||
|
||||
``` text
|
||||
Country Name: US
|
||||
State: Maryland
|
||||
Locality Name: Meade
|
||||
Organization Name: Mattermost
|
||||
Organization Unit: Smarttotem
|
||||
Common Name: example.mattermost.com
|
||||
Email Address: admin@mattermost.com
|
||||
```
|
||||
|
||||
2. Create the client side key for `mmuser` with a passphrase, and the certificate signing request:
|
||||
|
||||
``` sh
|
||||
openssl genrsa -des3 -out mmuser-mattermost.key 1024
|
||||
```
|
||||
|
||||
``` text
|
||||
passphrase: mmuser-passphrase
|
||||
```
|
||||
|
||||
``` sh
|
||||
openssl req -new -key mmuser-mattermost.key -out mmuser-mattermost.csr
|
||||
```
|
||||
|
||||
``` text
|
||||
Country Name: US
|
||||
State: Maryland
|
||||
Locality Name: Meade
|
||||
Organization Name: Mattermost
|
||||
Organization Unit: Smarttotem
|
||||
Common Name: mmuser
|
||||
Email Address: mmuser@mattermost.com
|
||||
|
||||
Challenge password: mmuser-passphrase
|
||||
```
|
||||
|
||||
3. Sign the user's client certificate with the previously created CA certificate:
|
||||
|
||||
``` sh
|
||||
openssl x509 -req -days 365 -in mmuser-mattermost.csr -CA ca.mattermost.crt -CAkey ca.mattermost.key -set_serial 01 -out mmuser-mattermost.crt
|
||||
```
|
||||
|
||||
4. Check the newly generated client certificate for `mmuser`:
|
||||
|
||||
``` sh
|
||||
openssl x509 -in mmuser-mattermost.crt -text -noout
|
||||
```
|
||||
|
||||
5. Open the file `/etc/nginx/sites-available/mattermost` and modify the following lines, so that the NGINX proxy server requests and verifies the client certificate:
|
||||
|
||||
``` text
|
||||
ssl on;
|
||||
ssl_certificate /etc/letsencrypt/live/example.mattermost.com/fullchain.pem;
|
||||
ssl_certificate_key /etc/letsencrypt/live/example.mattermost.com/privkey.pem;
|
||||
ssl_client_certificate /opt/mattermost/config/ca.mattermost.crt;
|
||||
ssl_verify_client on;
|
||||
|
||||
...
|
||||
|
||||
location ~ /api/v[0-9]+/(users/)?websocket$ {
|
||||
proxy_set_header X-SSL-Client-Cert $ssl_client_cert;
|
||||
proxy_set_header X-SSL-Client-Cert-Subject-DN $ssl_client_s_dn;
|
||||
|
||||
...
|
||||
|
||||
location / {
|
||||
proxy_set_header X-SSL-Client-Cert $ssl_client_cert;
|
||||
proxy_set_header X-SSL-Client-Cert-Subject-DN $ssl_client_s_dn;
|
||||
|
||||
...
|
||||
```
|
||||
|
||||
6. Confirm the CA key for `mmuser` works by the following curl command to the proxy:
|
||||
|
||||
``` sh
|
||||
curl -v -s -k --key mmuser-mattermost.key --cert mmuser-mattermost.crt:mmuser-passphrase https://example.mattermost.com
|
||||
```
|
||||
|
||||
You should see the Mattermost login page. If you see:
|
||||
|
||||
> - `No required SSL certificate was sent`, something went wrong. Review the above steps and try again.
|
||||
> - `Error reading X.509 key or certificate file: Decryption has failed.`, make sure the passphrase is included together with the certificate, because curl doesn't prompt for it separately.
|
||||
|
||||
7. Generate a PKCS12 file from the CA key and certificate, to install the certificate into your client machine for your browser to use:
|
||||
|
||||
``` sh
|
||||
openssl pkcs12 -export -out mmuser-mattermost.p12 -inkey mmuser-mattermost.key -in mmuser-mattermost.crt -certfile ca.mattermost.crt
|
||||
```
|
||||
|
||||
``` text
|
||||
Enter Export Password: mmuser-passphrase
|
||||
```
|
||||
|
||||
8. Repeat steps 2-7 above for other users as needed.
|
||||
9. Import the generated `.p12` file in step 7 into your key chain. In the Chrome browser on macOS:
|
||||
|
||||
> 1. Go to **Settings \> Advanced \> Privacy and security \> Manage certificates**. This opens the Keychain Access app.
|
||||
> 2. Go to **File \> Import Items** and select the `mmuser-mattermost.p12` file.
|
||||
|
||||
10. Go to `https://example.mattermost.com`. You should see a popup for the client certificate request.
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user