mirror of
https://github.com/hanzoai/team.git
synced 2026-09-30 01:57:35 +00:00
b5f007d35e
* docs: resolve cross-file anchor mismatches from RST-to-MDX migration
The Sphinx-to-Docusaurus migration converted `:ref:`/`{ref}` links using
naive text-slugification, so anchors that pointed to headings in a
different file (e.g. release-summary tables linking into their
respective changelog pages) were emitted as same-page fragments and
silently resolved to nothing.
Built a label registry from the original Sphinx `.. _label:` / `(label)=`
targets to recover the true source file for each cross-reference, then
rewrote the affected links to point at the correct file + heading
anchor. Fixes 282 broken cross-file anchors, primarily in the mobile/
desktop/server release-summary pages, plus assorted same-page anchor
mismatches caught by re-auditing after the prior admonition/anchor fix.
* docs: manually resolve remaining anchor mismatches after cross-file audit
Hand-verified fixes for anchors that fuzzy-matching alone couldn't
safely resolve (confirmed against actual heading text/context, and in a
few cases against the original RST source, before applying):
- Typos and dropped words carried over from the original Sphinx docs
(e.g. "bot-acocunts", "auto-follow-all-new-channel-threads" ->
"follow-all-new-channel-threads").
- Sphinx auto-generated duplicate-heading IDs (#id1/#id3/#id4) resolved
to their real target headings.
- Numbered-step TOC links in enterprise-roll-out-checklist.mdx that
dropped the leading "N. " used in the actual heading slugs.
- Push-notification docs pointing at the wrong file entirely
(environment-configuration-settings instead of
push-notification-server-configuration-settings).
- SAML "saml-enterprise" label resolved to its true cross-file target
(authentication-configuration-settings#saml-2-0), recovered from the
original RST label definition that the automated registry missed
because it sat after an RST transition marker.
- sso-saml-technical references converted from broken same-page/
malformed-path anchors to correct page links.
* docs: fix SAML 2.0 anchor slug (saml-2-0 -> saml-20)
github-slugger strips periods rather than hyphenating them, so "SAML
2.0" slugifies to saml-20, not saml-2-0 as previously fixed.
* docs: fix broken path links found during docs/main migration cleanup
* docs: convert div.tab blocks to Docusaurus Tabs/TabItem components
* docs: restore missing Kubernetes deployment architecture diagrams
The RST-to-MDX migration never copied over the AWS/Azure/Oracle
architecture diagrams referenced by the deployment-architecture-at-scale
page, leaving broken images in each Tabs/TabItem.
* docs: fix 7 anchor mismatches from the fragment/heading audit
Covers three root causes from the anchor mismatch breakdown:
- Fragment repeated the target page's own title instead of a real
heading, so the link is simplified to point at the bare page.
- Heading exists verbatim but lives on a sibling settings page
(experimental-configuration-settings, push-notification-server-
configuration-settings) rather than environment-configuration-settings.
- A page path was mistakenly pasted into a same-page #fragment instead
of being used as a real cross-page link.
* docs: fix 8 anchor slugs that were close but didn't match the real heading
Repoints links whose fragment was a plausible guess (typo, reworded
heading, or wrong section) at the actual auto-generated slug of the
target heading, confirmed by inspecting each target page directly.
* docs: merge split Tabs blocks so tabs render horizontally
The div.tab conversion script split some sibling tab groups into
separate single-item Tabs blocks whenever a stray blockquote marker
sat between them, causing them to render stacked instead of as one
horizontal tab bar. Merges the MySQL/PostgreSQL and Team/Enterprise
Edition tab groups back into single Tabs blocks.
* docs: remove Azure tab and restore Kubernetes deploy content
The Mattermost Operator, Azure, and Oracle platform tabs on the
Kubernetes deployment guide were split across two separate Tabs
blocks (rendering stacked instead of as one tab bar) and all three
tab bodies were empty because the migration never flattened the
original RST include directives. Removes the unsupported Azure tab
and restores the Mattermost Operator and Oracle content from the
pre-migration RST sources as a single merged Tabs block.
* addresscoderabbitreview
* docs: unify Linux/Kubernetes/Containers deploy pages and fix FIPS/STIG placement
Kubernetes and Containers duplicated full install content across a top-level
page (Tabs) and orphaned sidebar subpages that nothing linked to. Reworked
both to follow the Linux page's pattern: shared content on the landing page,
platform-specific instructions live once in their own subpage.
Also removed configure-fips-at-install-time.mdx, which claimed FIPS is
available for native Linux installs — FIPS/STIG in Mattermost is a container
image property (Chainguard-based build), not available outside Docker/
Kubernetes. Consolidated all FIPS/STIG references onto
containers/fips-stig.mdx and pointed the Mattermost Operator subpage (not
Oracle OKE, which doesn't expose image selection) at it.
* docs: fix review findings — image alt text, Important callout markup, typo
- Replace generic alt="image" on scaling diagrams with descriptive text
identifying cloud provider and user scale.
- Convert raw div.important markup in deploy-containers.mdx to the
repo's <Important> component, matching usage elsewhere in the file.
- Fix "Matermost" typo in manage-your-display-options.mdx.
---------
Co-authored-by: Hanzo Dev <[email protected]>
125 lines
11 KiB
Plaintext
125 lines
11 KiB
Plaintext
---
|
||
title: "Enable push notifications"
|
||
---
|
||
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 physical location of the Mattermost Hosted Push Notification Service (HPNS) server.</p>
|
||
<p>Select from <strong>US</strong> <strong>(Default)</strong> or <strong>Germany</strong> to automatically populate the <strong>Push Notification Server</strong> field server URL.</p></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>
|
||
|
||
# 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>
|