A conversation cannot be shared with anybody past the first page of members.
ShareDialog's MemberPicker is the only way to share a conversation since
#931 removed the email field (released 0.0.335) — and it offers exactly what
useMembers returns. That hook calls /orgs/{id}/members with no pagination
parameters, and list_members defaults to limit=50
(backend/app/api/routes/v1/members.py). So in an organization with more than 50
members, members 51 onwards are not in the list, are not searchable in the
popover, and there is no longer a field to type an address into.
Before #931 the address field was the escape hatch. Removing it was right — it
made sharing outside the organization impossible by construction, which is #930's
client half — but it also made the picker's completeness load-bearing, and it is
not complete.
The sequence
- an organization with 60 members;
- open a conversation, Share;
- the popover lists 50 of them; the other 10 cannot be found by typing either,
because the filter runs over what was fetched.
How you would know it was fixed
An integration test with a members fixture longer than one page: the picker
offers a member from the second page, and the share carries their id. Whichever
shape is chosen — fetch every page, or a server-backed search parameter on
/orgs/{id}/members — the test is the same.
Found reviewing #1291 (Codex, P1); the picker is the surface #931 built and #930
tightened, so it belongs to that cluster.
A conversation cannot be shared with anybody past the first page of members.
ShareDialog'sMemberPickeris the only way to share a conversation since#931 removed the email field (released 0.0.335) — and it offers exactly what
useMembersreturns. That hook calls/orgs/{id}/memberswith no paginationparameters, and
list_membersdefaults tolimit=50(
backend/app/api/routes/v1/members.py). So in an organization with more than 50members, members 51 onwards are not in the list, are not searchable in the
popover, and there is no longer a field to type an address into.
Before #931 the address field was the escape hatch. Removing it was right — it
made sharing outside the organization impossible by construction, which is #930's
client half — but it also made the picker's completeness load-bearing, and it is
not complete.
The sequence
because the filter runs over what was fetched.
How you would know it was fixed
An integration test with a members fixture longer than one page: the picker
offers a member from the second page, and the share carries their id. Whichever
shape is chosen — fetch every page, or a server-backed search parameter on
/orgs/{id}/members— the test is the same.Found reviewing #1291 (Codex, P1); the picker is the surface #931 built and #930
tightened, so it belongs to that cluster.