Pablo Vélez
1dacc2d514
* MM-69828 - Fix ABAC team Access-tab stuck-public cards, parent-policy mode-flip count * Add fallback handling for parent-policy fetch failure in AccessTab component * MM-69829 - Show Attribute Based indicator for policy-governed teams in admin Teams list * MM-69829 - Clear stale navigation-block flag when opening a membership policy in the editor * MM-69829 - Save cleanly when removing a team membership policy instead of prompting to re-apply * MM-69829 - Count qualifying team members correctly in the apply-policy confirmation modal * fix failing test * do not show apply policy confirmation modal on policy unlink * Refactor TableEditor state management and integrate deleteAccessControlPolicy action * fix ci linter for playwright test * adjust e2e to the new flow - no policy/rule , no blocking, clean state abac off * MM-69830 - Return an OK body when deleting an access policy so rule removal saves cleanly * MM-69830 - Soften the self-exclusion message on public teams to reflect advisory enforcement * MM-69830 - Soften membership-policy notices to advisory copy on public teams * MM-69830 - Uncheck auto-add when the last team membership rule is removed * MM-69830 - Warn that removing all rules drops attribute enforcement instead of showing the save-count modal * MM-69830 - Dispatch the deleted policy id so removing team rules doesn't crash the reducer * MM-69830 - Skip the self-exclusion block on public teams instead of rewording it * MM-69830 - Use advisory wording in the save-rules confirmation on public teams * MM-69830 - Use advisory auto-add descriptions on public teams * MM-69830 - Block switching a team to private when the admin would be self-excluded by the rules * fix prettier issues and adjust comments * MM-69830 - Assert advisory confirmation copy for team admins on public teams * MM-69830 - Show a saving state on the membership save panel while a confirmed save runs * MM-69830 - Save immediately when confirming the switch-to-private mode flip * MM-69829 - Surface delete failures and page through all members in the ABAC team save flow * MM-69830 - Align the remove-all-rules confirmation with performSave's parent-import check * MM-69830 - Drop an unnecessary cast on the team policy result and memoize the self-exclusion modal handler
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.