mirror of
https://github.com/mattermost/mattermost.git
synced 2026-08-30 17:06:34 +08:00
cursor[bot]
44c0490c7c
* Prevent system-owned bots from being disabled System-owned bots (system-bot, content-review) could be disabled either directly via the API or via the owner-deactivation path when DisableBotsWhenOwnerIsDeactivated=true. Once disabled, they never self-healed, silently breaking post reminders, reports, and channel notifications. - Add model.ProtectedBotUsernames and remove the dead BotWarnMetricBotUsername constant. - Guard UpdateBotActive so protected bots cannot be disabled (403), covering both the API and disableUserBots paths. - Auto-heal the system bot in GetOrCreateSystemOwnedBot by fetching including deleted and re-enabling if disabled. - Hide the Edit and Disable controls for protected bots in the System Console bot list. Co-authored-by: mattermost-code <matty-code@mattermost.com> * Strengthen tests for protected system bots - Parameterize the app-layer guard test over both protected usernames (system-bot and content-review). - Assert the underlying user is also reactivated by the auto-heal path. - Drive the owner-deactivation test through the real UpdateActive path and add a non-protected bot to prove the batch keeps disabling other bots. - Add an API-layer test asserting a 403 when disabling the system bot. - Make the webapp recovery test click Enable and assert the action fires. Co-authored-by: mattermost-code <matty-code@mattermost.com> * Address CodeRabbit feedback on protected bot reactivation - Add reactivateProtectedBot to bypass active-user limit checks when auto-healing or re-enabling disabled system-owned bots - Fail closed on bot store lookup errors in UpdateBotActive before mutating user state Co-authored-by: mattermost-code <matty-code@mattermost.com> * Fix govet shadow lint in reactivateProtectedBot Co-authored-by: mattermost-code <matty-code@mattermost.com> * Update unknown bot test for bot-first lookup in UpdateBotActive Co-authored-by: mattermost-code <matty-code@mattermost.com> * Address PR feedback: DRY protected bot reactivation, range over ProtectedBotUsernames, label system bots as Managed by Mattermost * Refactor UpdateActive to share inner updateActive with protected bot reactivation * Address PR feedback: remove user-limit bypass for bot activation Bot accounts are excluded from the active-user/license counts (User().Count defaults to IncludeBotAccounts=false), so the dedicated bypass path was guarding a case that cannot occur. Revert the UpdateActive/updateActive split and the protected-bot branch in UpdateBotActive; bot (re)activation goes through the normal UpdateActive path again. * Replace hardcoded webapp protected-bot list with server-driven system_owned field Addresses marianunez's review comment: the webapp kept its own copy of the protected bot usernames (system-bot, content-review), duplicating model.ProtectedBotUsernames and risking silent drift if a new system-owned bot is added server-side without updating the client list. model.Bot now computes IsSystemOwned() from ProtectedBotUsernames and serializes it as system_owned via a custom MarshalJSON, so the webapp reads it directly off the bot instead of matching usernames itself. --------- Co-authored-by: Cursor Agent <cursoragent@cursor.com> Co-authored-by: mattermost-code <matty-code@mattermost.com> Co-authored-by: Ben Schumacher <ben.schumacher@mattermost.com>
Mattermost Web App
This folder contains the client code for the Mattermost web app. It's broken up into multiple packages each of which either contains an area of the app (such as playbooks) or shared logic used across other packages (such as the packages located in the platform directory). For anyone who's used to working in the mattermost/mattermost-webapp repo, most of that is now located in channels.
npm Workspaces
To interact with a workspace using npm, such as to add a dependency or run a script, use the --workspace (or --workspaces) flag. This can be done when using built-in npm commands such as npm add or when running scripts. Those commands should be run from this directory.
# Add a dependency to a single package
npm add react --workspace=playbooks
# Build multiple packages
npm run build --workspace=platform/client --workspace=platform/components
# Test all workspaces
npm test --workspaces
# Clean all workspaces that have a clean script defined
npm run clean --workspaces --if-present
To install dependencies for a workspace, simply run npm install from this folder as you would do normally. Most packages' dependencies will be included in the root node_modules, and all packages' dependencies will appear in the package-lock.json. A node_modules will only be created inside a package if one of its dependencies conflicts with that of another package.
Useful Links
- Developer setup, now included with the Mattermost server developer setup
- Web app developer documentation
Dependency Changes
Any PR that modifies package.json or package-lock.json needs extra scrutiny:
- No duplicate libraries. Before adding a new dependency, check whether an existing one already covers the same use case. Multiple libraries for the same purpose (e.g., two different date pickers, or Bootstrap 3 and Bootstrap 4 simultaneously) create long-term upgrade pain.
- License check. New dependencies must not use GPL or similarly restrictive licenses. Dependencies with no license at all should also be flagged.
- Justify the addition. A new dependency should solve a real problem that existing code or dependencies don't already address. Push back on adding packages for trivial functionality.
- Version conflicts. Check whether the new dependency introduces conflicting peer dependency versions. Cascading version conflicts are expensive to untangle later and have historically blocked upgrades for months.