* [MM-70822] Explain the blocked section switch while editing a channel permission rule The Channel Settings modal refuses to switch sections while a tab reports unsaved changes, and the Permissions Policy tab reports unsaved changes for as long as its rule editor is open. The SaveChangesPanel that explains the refusal only renders in that tab's list view, so clicking Info, Membership Policy or Configuration while editing a rule did nothing at all: no section change, no message, even though the items still looked clickable. Route the modal's existing showTabSwitchError signal into the rule editor's error slot so the refusal is explained where the user is looking, and mark that slot role='alert' so it is announced rather than only seen. Co-authored-by: mattermost-code <matty-code@mattermost.com> * [MM-70822] Scroll the blocked section-switch warning into view When the rule editor is taller than the modal, the alert that explains a refused section switch sat below the fold. Scroll it into view when the error appears so the message is actually visible. Co-authored-by: mattermost-code <matty-code@mattermost.com> * Align max-login-attempts Playwright locators with current login copy The full Playwright suite failed on max_login_attempts.spec.ts: exact matches for the old invalid-credentials banner and lockout sentence no longer hold. Use the shared invalidCredentialsError locator and the stable lock-message prefix. Co-authored-by: mattermost-code <matty-code@mattermost.com> * Pick future dates in the demo plugin date dialog e2e spec Days 20 and 22 of the current month are in the past after mid-month, and the plugin rejects those submissions. Advance to next month in that case. Co-authored-by: mattermost-code <matty-code@mattermost.com> * Retrigger CI for Enterprise docker image and E2E Co-authored-by: mattermost-code <matty-code@mattermost.com> * [MM-70822] Report the blocked section switch through the modal's floating footer Per review, the rule editor now raises the same SaveChangesPanel the rest of the Channel Settings modal uses, in its built-in error state, instead of a bespoke inline message — matching the Team Settings membership policy editor. The footer is position: fixed at the bottom of the modal, so it is visible whatever the editor is scrolled to; the scroll-into-view workaround the inline message needed goes away with it. Saving from the footer stays disabled (the rule is committed from the editor's own button) and its Cancel leaves the editor, so the two ways out of the block are the ones the message names. Co-authored-by: mattermost-code <matty-code@mattermost.com> * [MM-70822] Cover the blocked-switch footer's way out in the E2E spec The footer's Cancel is now the exit the message points at, so assert it drops the draft and returns to the rules list. Co-authored-by: mattermost-code <matty-code@mattermost.com> * Revert unrelated e2e test fixes Restore demo_dialog_date.spec.ts and max_login_attempts.spec.ts to their upstream state. These e2e changes are unrelated to the MM-70822 channel permission-rule fix and were flagged for removal in review. Address PR feedback: 0 answered, 1 resolved, 0 declined * Retrigger CI after an unrelated Playwright flake on HEAD Co-authored-by: mattermost-code <matty-code@mattermost.com> --------- Co-authored-by: Cursor Agent <cursoragent@cursor.com> Co-authored-by: mattermost-code <matty-code@mattermost.com> Co-authored-by: Mattermost Build <build@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.