@claude - Let's update the Mattermost Product Documentation to reflect the End User, System Admin, and Risk Assessor product experience from Mattermost Desktop v6.1.0 onward captured via Engineering PR #3610 (mattermost/desktop#3610).
Create a docs PR on the desktop-v6.1-documentation branch
Scope & Constraints
Version: v6.1.0 (evidence: PR milestone.title)
Non-editable docs (do not modify):
Changelogs (desktop-app-changelog.md, mattermost-desktop-releases.md)
Important upgrade notes
Version archives
Removed/deprecated features
Unsupported legacy releases
In-scope changes:
Document new Sentry error reporting feature
Document privacy settings and user control
Explain what data is collected and sent per persona context
Document default behavior (enabled by default)
Clarify restart requirement
Required Doc Touchpoints
Identify and update the following pages (paths relative to Mattermost docs repository):
Desktop app privacy/data collection page - if exists, or create section
Document error reporting capability
Explain data sent to Sentry
Clarify privacy protections (no PII)
Desktop app settings documentation - likely in desktop configuration/preferences
Add "Send error reports to help improve the app" setting
Document default state (enabled)
Document restart requirement
Desktop app troubleshooting - if exists
Note that error reports help improve app stability
Explain how users can opt out if desired
System admin deployment guide - if exists for desktop
Note default error reporting behavior
Guidance for organizations with strict data policies
Persona-Separated Tasks
End User Tasks
What changed: From Mattermost Desktop v6.1.0, the application includes error reporting to help identify and fix crashes and issues. Error reports are sent automatically to help improve app quality, but users can control this via a Settings option.
Content to add:
Privacy/Data Collection section:
From Mattermost Desktop v6.1.0, error reports and crash information are sent to Sentry (a third-party error tracking service) to help identify and fix issues
This feature is enabled by default (evidence: config.ts line 1137)
What data is sent: Error reports, crash information, app version, platform information (OS, architecture, memory stats) - evidence: sentryHandler.ts addSentryContext method
What is NOT sent: No personally identifiable information (PII) is included (evidence: sendDefaultPii: false in sentryHandler.ts line 1466)
User control: Can be disabled in Settings if preferred
Settings documentation - Add new setting under Advanced category:
Setting name: "Send error reports to help improve the app" Description: If enabled, error reports and crash information will be sent to help identify and fix issues in the application. (evidence: i18n/en.json lines 9-10) Default: Enabled (evidence: config.ts line 1137) Effect: Setting takes effect after restarting the app (evidence: i18n/en.json line 10) Location: Settings Modal > Advanced section (evidence: definition.tsx shows it in SettingsModal; engineering context confirms Advanced section) Steps to disable:
Open Settings (File > Settings or similar)
Navigate to the Advanced section
Locate "Send error reports to help improve the app" checkbox
Uncheck to disable error reporting
Restart the application for changes to take effect
Troubleshooting notes (if applicable):
Error reporting helps the development team identify and fix crashes proactively
If you experience crashes, leaving error reporting enabled helps improve future versions
Error reporting only occurs in production/release builds, not development builds (evidence: sentryHandler.ts line 1525)
System Admin Tasks
What changed: From Mattermost Desktop v6.1.0, desktop clients automatically send error reports to Sentry by default. Admins may need to advise users based on organizational data policies.
Content to add:
Deployment/Configuration guidance:
From Mattermost Desktop v6.1.0, error reporting to Sentry is enabled by default for all users
Error reports help Mattermost identify and fix desktop app issues proactively
Admin awareness: If your organization has policies restricting external telemetry or data transmission, advise users to disable this setting
Privacy policy implications:
Error reports include: crash information, app version, platform details (OS, architecture, memory)
Error reports do NOT include: personally identifiable information (PII is explicitly disabled)
Users can disable error reporting via Settings > Advanced > "Send error reports to help improve the app"
Organizational considerations:
Organizations with strict data handling policies may want to communicate with users about this default-enabled feature
Setting is user-controllable (no admin-level enforcement mechanism evident in PR)
Restart required after changing setting (evidence: i18n description)
Risk Assessor Tasks
What changed: From Mattermost Desktop v6.1.0, desktop clients send error and crash data to Sentry (third-party service) by default, with user opt-out capability.
Content to add:
Data handling disclosure:
External service: Error data sent to Sentry (third-party error tracking platform)
Default behavior: Enabled by default - users must opt out to prevent data transmission
Data collected: Error/crash details, app metadata, platform/system information (OS type, architecture, memory stats) - evidence: sentryHandler.ts addSentryContext
PII protection: sendDefaultPii: false configured in Sentry integration (evidence: sentryHandler.ts line 1466)
Compliance considerations:
Organizations subject to data residency requirements should evaluate Sentry's data handling
[NOT PRESENT IN PR — REQUIRES HUMAN JUDGMENT]: Sentry data center locations, data retention policies, subprocessor information
User consent model: Opt-out (enabled by default) rather than opt-in
Users can disable via Settings > Advanced section, but must take explicit action to opt out
Error reporting requires DSN configuration at build time (via MM_DESKTOP_BUILD_SENTRYDSN environment variable) - evidence: webpack.config.base.js
Audit/verification:
Error reporting only activates in production builds (development/test builds do not send data) - evidence: sentryHandler.ts line 1525 shows NODE_ENV === 'production'
Distinguish between "stable" and "prerelease" builds (evidence: sentryHandler.ts lines 1463-1467 shows environment detection)
[NOT PRESENT IN PR — REQUIRES HUMAN JUDGMENT]: Network traffic verification methods, Sentry endpoint domains for firewall rules
Output Requirements
Please return:
Page list: Specific documentation pages that need updates (with full file paths if known)
Proposed text: Draft content for each persona section following the structure above
Before/after snippets: For any sections being modified (not new content), show current text and proposed changes
Privacy messaging review: Explicit review of privacy-related claims for accuracy and completeness
Compliance checklist: Items requiring SME validation for data handling claims
=== PERSONAS IN SCOPE ===
Operational Champion: No
Economic Buyer: No
System Admin: Yes
Evidence: Admins need to inform users about error reporting capability
Default-enabled setting affects organizational privacy policies
May need to advise users to disable if organizational policy prohibits external telemetry
IT Service Operations: No
Risk Assessor: Yes
Evidence: Privacy/data handling feature - error reports sent to external service
Default-enabled behavior raises privacy considerations
Organizations with strict data handling policies need awareness
Context data includes system information (platform, memory, architecture) per sentryHandler.ts
End User: Yes
Evidence: User-facing setting in Settings Modal with checkbox control
User-facing strings describe feature and privacy implications (i18n/en.json)
Setting affects whether user's error data is sent externally
Restart required for changes to take effect
System Integrator: No
Current evidence shows only user-level control (Settings > Advanced)
Build-time control: Organizations building from source can omit MM_DESKTOP_BUILD_SENTRYDSN to prevent Sentry initialization entirely (evidence: sentryHandler.ts checks for DSN presence)
Context data specifics [PARTIALLY PRESENT]:
What specific error/crash information is sent (stack traces, error messages)?
Are server URLs or team names ever included in error context?
Evidence shows platform/memory info but not full scope of error context
Licensing/legal [NOT PRESENT IN PR]:
Are there license dependencies for Sentry SDK that affect desktop app licensing?
Should license/attribution be updated in desktop app about screen?
@claude - Let's update the Mattermost Product Documentation to reflect the End User, System Admin, and Risk Assessor product experience from Mattermost Desktop v6.1.0 onward captured via Engineering PR #3610 (mattermost/desktop#3610).
Create a docs PR on the desktop-v6.1-documentation branch
Scope & Constraints
Version: v6.1.0 (evidence: PR milestone.title)
Non-editable docs (do not modify):
Changelogs (desktop-app-changelog.md, mattermost-desktop-releases.md)
Important upgrade notes
Version archives
Removed/deprecated features
Unsupported legacy releases
In-scope changes:
Document new Sentry error reporting feature
Document privacy settings and user control
Explain what data is collected and sent per persona context
Document default behavior (enabled by default)
Clarify restart requirement
Required Doc Touchpoints
Identify and update the following pages (paths relative to Mattermost docs repository):
Desktop app privacy/data collection page - if exists, or create section
Document error reporting capability
Explain data sent to Sentry
Clarify privacy protections (no PII)
Desktop app settings documentation - likely in desktop configuration/preferences
Add "Send error reports to help improve the app" setting
Document default state (enabled)
Document restart requirement
Desktop app troubleshooting - if exists
Note that error reports help improve app stability
Explain how users can opt out if desired
System admin deployment guide - if exists for desktop
Note default error reporting behavior
Guidance for organizations with strict data policies
Persona-Separated Tasks
End User Tasks
What changed: From Mattermost Desktop v6.1.0, the application includes error reporting to help identify and fix crashes and issues. Error reports are sent automatically to help improve app quality, but users can control this via a Settings option.
Content to add:
Privacy/Data Collection section:
From Mattermost Desktop v6.1.0, error reports and crash information are sent to Sentry (a third-party error tracking service) to help identify and fix issues
This feature is enabled by default (evidence: config.ts line 1137)
What data is sent: Error reports, crash information, app version, platform information (OS, architecture, memory stats) - evidence: sentryHandler.ts addSentryContext method
What is NOT sent: No personally identifiable information (PII) is included (evidence: sendDefaultPii: false in sentryHandler.ts line 1466)
User control: Can be disabled in Settings if preferred
Settings documentation - Add new setting under Advanced category:
Setting name: "Send error reports to help improve the app" Description: If enabled, error reports and crash information will be sent to help identify and fix issues in the application. (evidence: i18n/en.json lines 9-10) Default: Enabled (evidence: config.ts line 1137) Effect: Setting takes effect after restarting the app (evidence: i18n/en.json line 10) Location: Settings Modal > Advanced section (evidence: definition.tsx shows it in SettingsModal; engineering context confirms Advanced section) Steps to disable:
Open Settings (File > Settings or similar)
Navigate to the Advanced section
Locate "Send error reports to help improve the app" checkbox
Uncheck to disable error reporting
Restart the application for changes to take effect
Troubleshooting notes (if applicable):
Error reporting helps the development team identify and fix crashes proactively
If you experience crashes, leaving error reporting enabled helps improve future versions
Error reporting only occurs in production/release builds, not development builds (evidence: sentryHandler.ts line 1525)
System Admin Tasks
What changed: From Mattermost Desktop v6.1.0, desktop clients automatically send error reports to Sentry by default. Admins may need to advise users based on organizational data policies.
Content to add:
Deployment/Configuration guidance:
From Mattermost Desktop v6.1.0, error reporting to Sentry is enabled by default for all users
Error reports help Mattermost identify and fix desktop app issues proactively
Admin awareness: If your organization has policies restricting external telemetry or data transmission, advise users to disable this setting
Privacy policy implications:
Error reports include: crash information, app version, platform details (OS, architecture, memory)
Error reports do NOT include: personally identifiable information (PII is explicitly disabled)
Users can disable error reporting via Settings > Advanced > "Send error reports to help improve the app"
Organizational considerations:
Organizations with strict data handling policies may want to communicate with users about this default-enabled feature
Setting is user-controllable (no admin-level enforcement mechanism evident in PR)
Restart required after changing setting (evidence: i18n description)
Risk Assessor Tasks
What changed: From Mattermost Desktop v6.1.0, desktop clients send error and crash data to Sentry (third-party service) by default, with user opt-out capability.
Content to add:
Data handling disclosure:
External service: Error data sent to Sentry (third-party error tracking platform)
Default behavior: Enabled by default - users must opt out to prevent data transmission
Data collected: Error/crash details, app metadata, platform/system information (OS type, architecture, memory stats) - evidence: sentryHandler.ts addSentryContext
PII protection: sendDefaultPii: false configured in Sentry integration (evidence: sentryHandler.ts line 1466)
Compliance considerations:
Organizations subject to data residency requirements should evaluate Sentry's data handling
[NOT PRESENT IN PR — REQUIRES HUMAN JUDGMENT]: Sentry data center locations, data retention policies, subprocessor information
User consent model: Opt-out (enabled by default) rather than opt-in
Users can disable via Settings > Advanced section, but must take explicit action to opt out
Error reporting requires DSN configuration at build time (via MM_DESKTOP_BUILD_SENTRYDSN environment variable) - evidence: webpack.config.base.js
Audit/verification:
Error reporting only activates in production builds (development/test builds do not send data) - evidence: sentryHandler.ts line 1525 shows NODE_ENV === 'production'
Distinguish between "stable" and "prerelease" builds (evidence: sentryHandler.ts lines 1463-1467 shows environment detection)
[NOT PRESENT IN PR — REQUIRES HUMAN JUDGMENT]: Network traffic verification methods, Sentry endpoint domains for firewall rules
Output Requirements
Please return:
Page list: Specific documentation pages that need updates (with full file paths if known)
Proposed text: Draft content for each persona section following the structure above
Before/after snippets: For any sections being modified (not new content), show current text and proposed changes
Privacy messaging review: Explicit review of privacy-related claims for accuracy and completeness
Compliance checklist: Items requiring SME validation for data handling claims
=== PERSONAS IN SCOPE ===
Operational Champion: No
Economic Buyer: No
System Admin: Yes
Evidence: Admins need to inform users about error reporting capability
Default-enabled setting affects organizational privacy policies
May need to advise users to disable if organizational policy prohibits external telemetry
IT Service Operations: No
Risk Assessor: Yes
Evidence: Privacy/data handling feature - error reports sent to external service
Default-enabled behavior raises privacy considerations
Organizations with strict data handling policies need awareness
Context data includes system information (platform, memory, architecture) per sentryHandler.ts
End User: Yes
Evidence: User-facing setting in Settings Modal with checkbox control
User-facing strings describe feature and privacy implications (i18n/en.json)
Setting affects whether user's error data is sent externally
Restart required for changes to take effect
System Integrator: No
Current evidence shows only user-level control (Settings > Advanced)
Build-time control: Organizations building from source can omit MM_DESKTOP_BUILD_SENTRYDSN to prevent Sentry initialization entirely (evidence: sentryHandler.ts checks for DSN presence)
Context data specifics [PARTIALLY PRESENT]:
What specific error/crash information is sent (stack traces, error messages)?
Are server URLs or team names ever included in error context?
Evidence shows platform/memory info but not full scope of error context
Licensing/legal [NOT PRESENT IN PR]:
Are there license dependencies for Sentry SDK that affect desktop app licensing?
Should license/attribution be updated in desktop app about screen?