* MM-63588: Add e2e tests for System Console Custom Profile Attributes Add Playwright e2e tests for the System Console User Attributes page, covering CRUD operations for custom profile attribute field definitions. Tests cover: - Page navigation and empty state display - Creating text, select, and multiselect attributes with options - Editing attribute names - Deleting attributes (saved and unsaved) - Duplicating attributes - Changing attribute types (Text to Phone) - Configuring visibility (Always show/Hide when empty/Always hide) - Toggling "Editable by users" setting - Batch creation (multiple attributes at once) - Persistence verification after page reload - Validation warnings (empty name, duplicate names) Follows the same patterns established in MM-62558 / PR #30722 for Profile Popup CPA tests, reusing shared helpers for field setup/cleanup. * Fix 6 failing e2e tests for System Console User Attributes - Remove .clear() before .fill() to prevent value-based locators from going stale (edit name, persist after reload tests) - Hover on visibility submenu instead of click, use force:true to handle DOM detach during menu animation (visibility test) - Press Escape to close dot menu before clicking Save, since the "Editable by users" toggle keeps the menu open (editable test) - Fix expected validation text: use "Attribute names must be unique." instead of "Attribute name already taken." (duplicate names test) - Increase timeout for Save button disabled assertion after deleting unsaved attribute (delete unsaved test) * Fix stale locators, flaky save check, and document dirty-state bug - Use data-testid locators instead of value-based selectors for inputs that get mutated by fill() (edit name + persist reload tests) - Wait for Save button to return to disabled after save before API check to avoid flaky field-not-found failures - Add test.fail() for Save-stays-enabled bug after deleting an unsaved row so CI passes today and alerts when the app bug is fixed - Add LOCATOR NOTE to file header explaining the lazy locator pitfall * Address CodeRabbit review: save helper, locator fix, test rename - Add saveAndWaitForSettled() helper and apply to all 11 save paths for consistent post-save stabilization before API verification - Fix deptInput locator: use input[value] instead of broken filter({hasText}) which doesn't match input element children - Rename "different types" test to "multiple text attributes" to match actual coverage * MM-63588: add SystemProperties page object and refactor spec to POM Extract all UI selectors from user_attributes.spec.ts into a SystemProperties page object class, eliminating inline selectors from the test file. Replace coarse networkidle with waitForResponse on the actual save API endpoint. * fix playwright e2e test failures - selectType was failing as 'select' caught both 'select' and 'multi-select' - Prior behavior where Save button wasn't returning to disabled appears to be working now, removing test.fail() --------- 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.