Repository navigation
Define paused-member behavior for card assignments and historical content #575
Description
✨ Feature Request
Is your feature request related to a problem? Please describe.
Paused workspace members currently appear alongside active members in card
assignment controls without any status indication. They can be selected when
creating or editing a card, and they also appear in mention suggestions.
At the same time, hiding them everywhere would make existing assignments and
historical content hard to understand. A card may still be assigned to someone
who was paused later, and their comments, activity and time entries should
remain attributable.
The paused member status was introduced in #184 after card assignees were
already implemented, and its behavior across these surfaces does not appear to
have been defined yet.
Describe the solution you'd like
- Active members remain available for new assignments and mentions.
- Paused members cannot receive new card assignments or be newly mentioned.
- Pausing someone does not automatically remove their existing card
assignments or historical content. - A paused member who is already assigned remains visible on the card, with a
clearPausedindicator, and can still be unassigned. - Once unassigned, that paused member is no longer offered for selection until
they are reactivated. - Board member filters may still include paused members who have cards assigned,
because finding work that needs reassignment is useful. - Comments and other historical records remain readable and attributable. A
small current-status label beside the author is preferable to dimming the
whole record. - Reactivating a member restores normal presentation and selection without
rewriting history.
invited should remain a separate state rather than automatically inheriting
the paused-member rules. It would be useful to confirm the intended behavior
for pending invitees as part of this discussion.
This is also consistent with the model we are migrating from: deactivation
preserves existing card assignments so teams can find and reassign outstanding
work, while preventing the deactivated member from accessing the workspace.
Describe alternatives you've considered
- Automatically unassigning paused members loses useful ownership and
provenance. - Hiding paused members completely makes outstanding work difficult to find.
- Leaving them selectable without a status marker makes an unavailable person
look like a valid assignee.
Additional context
The affected surfaces include the existing-card member selector, card context
menu, new-card form, assigned avatars on board cards, board member filters,
mention autocomplete and comment authors.
The separate cross-workspace validation bug in card member assignment is
already tracked by #416 and should remain a focused backend fix rather than be
mixed into this UX proposal.
We are happy to share screenshots of the current behavior and a proposed
light/dark treatment before implementation.
Implementation ideas (optional)
The card and board payloads already expose workspace member status in some
places. Existing selected paused assignees can be derived from the assignment
relationship, while new choices can be restricted to eligible members. The API
should enforce the same policy so it cannot be bypassed by non-UI clients.
Status should be resolved once per card/board response rather than with a query
per comment or avatar.
Would you like to work on this feature?
- Yes, I'd like to help implement this feature
- No, I'm just suggesting the feature
Activity
bionicman commentedon Sep 4, 2026
@hjball We have now implemented the proposed behavior in our fork and tested it
against a production-sized migrated workspace. Before opening the feature PR,
we would appreciate a quick confirmation that this policy fits the project.
The implementation keeps the boundary fairly small:
existing paused assignee to be removed;
Pausedlabel;board, with current members first and paused members at the bottom;
invitedretains its current behavior;per-comment requests.
The board-filter membership query is independent of the currently applied card
filters, so a filtered result does not accidentally shrink its own choices. On
our migrated data it took about 4.9 ms for a board with 1,203 cards and 6.8 ms
for a board with 1,890 cards; the existing indexes were sufficient.
The screenshots use a synthetic handover: Boromir remains as the paused
historical assignee, while Faramir takes over the current task.
Card selector and attribution: light · dark
Board filter: light · dark
The code is ready in the fork, and we can adjust the policy or split before
opening the PR if you would prefer a different shape.
hjball commentedon Sep 4, 2026
This is something I've been meaning to clean up for a while. Policy sounds sensible to me @bionicman