Files
mattermost/webapp
85e95437ab [MM-70822] Explain the blocked section switch while editing a channel permission rule (#38751)
* [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>
2026-10-02 19:03:29 -04:00
..
…
…
…
…

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.

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.