← Back to PRs

#13695: feat(slack): support email glob patterns in allowFrom

by brin-tapcart open 2026-02-10 21:59 View on GitHub →
channel: slack stale
## Summary Adds support for email glob patterns (e.g. `*@example.com`, `*@tapcart.com`) in the Slack `allowFrom` configuration. Currently, `allowFrom` accepts literal emails which are resolved to user IDs at startup. This PR extends that to support glob patterns, expanding them against all workspace users at startup time. ## Motivation Teams using OpenClaw often want to allow all users from their domain without listing every email individually. For example: ```yaml slack: allowFrom: - "*@mycompany.com" ``` This is especially useful for larger orgs where maintaining individual email entries is tedious and error-prone as employees join/leave. ## Changes **`src/slack/resolve-users.ts`** — the only file changed: - **`isEmailPattern(email)`** — detects if an email entry contains glob chars (`*` or `?`) - **`emailMatchesPattern(email, pattern)`** — converts glob pattern to regex and tests against a literal email (case-insensitive, anchored) - **Modified `resolveSlackUserAllowlist`** — when an email entry is a pattern, filters all workspace users whose email matches the pattern and adds each as a resolved entry. Non-pattern emails continue exact matching as before. ## How It Works Pattern expansion happens at **startup** during the existing `users.list` resolution pass. No runtime API calls are added. The flow: ``` config: "*@example.com" startup: users.list → filter by pattern → [U123, U456, U789] runtime: pure ID matching (unchanged) ``` **Tradeoff**: Users who join mid-runtime won't be picked up until next gateway restart. This is already true for literal email entries. ## Pattern Support | Pattern | Matches | |---------|---------| | `*@example.com` | All users with @example.com emails | | `dev-*@example.com` | Users like dev-team@example.com | | `?@example.com` | Single-char local part | ## Testing Helpers are pure functions, easily unit-testable. The resolution path is exercised by existing `resolveSlackUserAllowlist` tests — pattern entries just add a new branch. <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> Adds glob pattern support (`*@example.com`) to Slack's `allowFrom` configuration, enabling domain-wide allowlisting without maintaining individual email entries. Patterns are expanded at startup against the workspace user list via pure regex matching - no new runtime API calls. The implementation is clean and follows the existing resolution flow: pattern entries filter the user list and push multiple resolved entries (one per matched user), while non-pattern emails continue exact matching as before. The regex escaping is correct, edge cases are handled (zero matches, null emails), and the approach is consistent with the existing code style. <h3>Confidence Score: 5/5</h3> - This PR is safe to merge with minimal risk - The changes are minimal (3 new pure functions, one branch in existing logic), well-isolated to a single file, and follow existing patterns. The regex implementation correctly escapes special characters, handles edge cases (zero matches, missing emails), and poses no ReDoS risk due to anchoring. Pattern expansion reuses the existing user list fetch, adding no new API calls or performance concerns. The logic integrates cleanly with the existing resolution flow and maintains backward compatibility for literal email entries. - No files require special attention <!-- greptile_other_comments_section --> <sub>(2/5) Greptile learns from your feedback when you react with thumbs up/down!</sub> <!-- /greptile_comment -->

Most Similar PRs