Skip to content

fix(desktop): collapse consecutive member removals into one system row - #5006

Open
tadeo-ctrl wants to merge 1 commit into
block:mainfrom
tadeo-ctrl:feat/group-consecutive-member-removals
Open

fix(desktop): collapse consecutive member removals into one system row#5006
tadeo-ctrl wants to merge 1 commit into
block:mainfrom
tadeo-ctrl:feat/group-consecutive-member-removals

Conversation

@tadeo-ctrl

Copy link
Copy Markdown

Problem

Desktop already collapses a run of contiguous member_joined events into one summary row — buildMembershipGroups in timelineItems.ts plus the members_added / members_joined branches in SystemMessageRow.tsx. The matching member_removed case was never wired up, so each removal takes its own timeline row.

That reads fine for the one-off removal the copy was written for. It reads badly for the bulk case, which is ordinary — offboarding a team, or clearing the placeholder identities left behind by a workspace import. Removing eleven members leaves eleven near-identical rows pinned to the bottom of the channel.

There is also no way to clean them up after the fact: deleting a system row publishes a message_deleted system row in its place, so the row count never drops.

Change

Group contiguous member_removed events performed by the same administrator, reusing the machinery that already backs members_added — the same one-hour adjacency window, the same day/unread barriers, the same avatar stack and "and N others" tooltip.

  • timelineItems.tsparseMembershipChangePayload recognises member_removed as a new removal mode; membershipChangesCanGroup joins removals only to removals by the same actor.
  • SystemMessageRow.tsxbuildGroupedRemovalPayload emits a members_removed payload, with a describeSystemEvent branch rendering it through the existing MemberNamesInlineList.

Removals do not group with additions, and two different moderators still render separately, so no existing sequence changes shape.

Tests

  • timelineItems.test.mjs — three cases: contiguous removals by one actor group; removals by different actors do not; removals do not group with additions.
  • mentions.spec.tsgroups contiguous removal activity with hidden names in the standard tooltip, mirroring the existing arrival-grouping spec, covering the collapsed copy, the avatar stack and the overflow tooltip.

Gates run locally: pnpm test (4390 passing), pnpm typecheck, pnpm check, and the full smoke run of mentions.spec.ts (59 passing).

Screenshots in a comment below.

Desktop already collapses a run of contiguous `member_joined` events into a
single summary row ("… added by Alice, along with Bob and 3 others"), but the
matching `member_removed` case was never wired up. Every removal therefore
takes its own timeline row.

That is fine for the one-off case the copy was written for and poor for the
bulk case, which is ordinary: offboarding a team, or cleaning up the placeholder
identities left behind by a workspace import. Removing eleven members leaves
eleven near-identical rows pinned to the bottom of the channel, and there is no
way to clear them — deleting a system row publishes a `message_deleted` system
row in its place.

Group contiguous removals performed by the same administrator, reusing the
grouping window, barrier and avatar-stack machinery that already backs
`members_added`:

    Alice Chen removed Erica Chapman, Peter Griffin, Marcia Thomas,
    and 3 others from the channel

Removals only group with removals by the same actor, so an add/remove sequence
or two different moderators still render as separate rows.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Fizz <tadeo@villanuevak.com>
@tadeo-ctrl
tadeo-ctrl requested a review from a team as a code owner August 6, 2026 04:05
@tadeo-ctrl

Copy link
Copy Markdown
Author

Before — six removals by one admin, six rows

before

After — one row

after

Captured from the mentions.spec.ts removal-grouping spec added in this PR, run against main (before) and this branch (after).

Note: scripts/post-screenshots.sh pushes to origin, which an outside fork contributor cannot write to, so these blobs live on the same immutable commit-SHA scheme on the fork instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants