Repository navigation
MUL-5792: split mentions out of the comments notification mute group - #6486
Merged
Merged
Conversation
`new_comment` and `mentioned` shared the `comments` preference group, so
muting comment volume also silenced @-mentions — and because a muted item
is never created, those mentions were lost rather than deferred. In
agent-heavy workspaces the only lever that reduces inbox noise also
removed the signal the inbox exists for.
`mentioned` now maps to its own `mentions` group. Preferences are stored
sparse (a missing key means "all"), so existing `{"comments":"muted"}`
rows default the new group to "all" with no migration: muting comments is
a volume decision, not a decision to become unreachable by name.
The split also aligns the global setting with behavior the platform
already had — per-issue unsubscribe keeps delivering direct mentions, and
mention delivery bypasses the subscriber table entirely.
Closes #6468
Co-authored-by: multica-agent <github@multica.ai>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
eric8810
pushed a commit
to eric8810/multica
that referenced
this pull request
Aug 12, 2026
…ultica-ai#6486) `new_comment` and `mentioned` shared the `comments` preference group, so muting comment volume also silenced @-mentions — and because a muted item is never created, those mentions were lost rather than deferred. In agent-heavy workspaces the only lever that reduces inbox noise also removed the signal the inbox exists for. `mentioned` now maps to its own `mentions` group. Preferences are stored sparse (a missing key means "all"), so existing `{"comments":"muted"}` rows default the new group to "all" with no migration: muting comments is a volume decision, not a decision to become unreachable by name. The split also aligns the global setting with behavior the platform already had — per-issue unsubscribe keeps delivering direct mentions, and mention delivery bypasses the subscriber table entirely. Closes multica-ai#6468 Co-authored-by: J <agent@multica.ai> Co-authored-by: multica-agent <github@multica.ai>
14 tasks done
r404r
added a commit
to r404r/multica
that referenced
this pull request
Sep 25, 2026
Brings the branch up to upstream/main e2f4a22. Conflicts resolved: - packages/core/api/schemas.ts: keep email_configured next to upstream's new AppConfig capability fields (vcs_integration_available, feature flags, local_worktree_supported, ...), in both the type and the zod schema. - packages/core/config/index.ts: keep emailConfigured in ConfigState, its default, and the setAuthConfig signature alongside upstream's vcsIntegrationAvailable and other new fields. - packages/core/platform/auth-initializer.tsx: pass emailConfigured and vcsIntegrationAvailable to setAuthConfig. - packages/views/settings/components/notifications-tab.tsx: take upstream's SettingsTab/SettingsSection layout; render EmailNotificationSetting after BrowserNotificationSetting in the delivery section. - server/cmd/server/router.go: keep the email integration import next to upstream's channel/composio/dingtalk imports. - server/internal/handler/config.go: keep EmailConfigured next to upstream's new AppConfig fields. - server/internal/handler/notification_preference_test.go (add/add): take upstream's DB-backed PATCH tests (multica-ai#6486) and keep this branch's validNotifGroups test. - server/internal/service/email.go: take upstream's transport changes (Office 365 LOGIN auth, SMTP_FROM_EMAIL, base64 headers); keep Configured() and SendNotification() on top. - server/internal/service/email_test.go: keep both test sets; the conflict marker split TestSendNotification_RejectsEmptyTo, closed explicitly. Verified: go build ./... and go vet on touched packages; pnpm typecheck core/views/web/desktop. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #6468. MUL-5792.
The problem
new_commentandmentionedshared thecommentspreference group, so muting comment traffic also silenced @-mentions. Because a muted item is never created (notifyMentionedMembersreturns beforeCreateInboxItem), a muted mention was lost, not deferred — it never appears in the inbox, not even later.That makes the only lever for reducing inbox noise also remove the signal the inbox exists for. It bites hardest in agent-heavy workspaces, where a single human approver subscribes to an issue by commenting on it once and then receives every agent reply.
The change
mentionednow maps to its ownmentionsgroup. Settings → Notifications goes from five inbox toggles to six.commentsnew_comment,mentionednew_commentmentionsmentionedNo migration needed. Preferences are stored sparse in JSONB — a missing key means
"all"— so an existing{"comments":"muted"}row lands onmentions: "all"on its own. That is also the behavior we want: muting comments is a volume decision, and it is unlikely anyone chose it intending to stop being reachable by name. Users who did want both silent flip one extra switch. Users who never customized see no change at all.The split also aligns the global setting with behavior the platform already had elsewhere: per-issue unsubscribe already keeps delivering direct mentions, and mention delivery already bypasses the subscriber table. The shared mute group was the one place contradicting that.
@alland@squadexpand intomentioneditems and therefore follow thementionstoggle. This matches current behavior and is called out in the setting's description copy.Files
Five lines of logic; the rest is copy and docs.
server/cmd/server/notification_listeners.go— the group mappingserver/internal/handler/notification_preference.go— API whitelistpackages/core/types/notification-preference.ts,packages/core/notification-preferences/patch.ts— the key (omitting it fromNOTIFICATION_GROUP_KEYSwould make the toggle silently un-sendable)packages/views/settings/components/notifications-tab.tsx+ en / zh-Hans / ja / kosettings.jsonapps/mobile/.../settings/notifications.tsx— hardcoded English, per the mobile parity ruleapps/docs/content/docs/inbox{,.zh,.ja,.ko}.mdxNo DB migration, no new endpoint, no new component.
validNotifGroupsrejects unknown keys, so a client shipped ahead of the server gets400 invalid preference group: mentions. Deploy the backend before web / desktop / mobile.One further compatibility note, not addressed here: the legacy replace-all
PUT /api/notification-preferencesendpoint remains for older installed clients. A client that predates this key would drop it on a full PUT, resettingmentionsto the default. All current clients usePATCH, so this is bounded — but it is one more argument for retiringPUT.Testing
notifTypeToGroup/isNotifMutedhad no test coverage, so this adds it rather than only testing the new key.server/cmd/server/notification_mute_group_test.go(new) — table test pinning the contract in both directions: mutedcommentsstill delivers mentions, mutedmentionsstill delivers comments. Plus a guard on the mapping itself so a future edit can't silently re-couple them.server/internal/handler/notification_preference_test.go— the API acceptsmentions.packages/core/notification-preferences/patch.test.ts— derive/apply carrymentionsindependently.Verified locally:
go test ./cmd/server/ ./internal/handler/— pass (against a freshly migrated DB)pnpm vitest runinpackages/core— 1286 pass;packages/viewslocale parity — 160 pass;packages/viewssettings — 109 passpnpm typecheck(6 packages) andapps/mobiletypecheck — passpnpm lintand mobile lint — 0 errorsapps/mobiletests — 55 passNot run: Playwright e2e.
Conflict note
PR #4105 (email notification channel, open, last updated 2026-06-15) touches
notification_preference.go,notification-preference.ts, andnotifications-tab.tsx. Whichever lands second will need a small rebase.