Repository navigation
People with access merges every Bot of a friend into one row, so one Revoke takes them all #995
Description
What happens
Friend's home runs two Bots; my Bot was shared with both, so "Share with a friend" shows two rows (correct since #973/#983).
"People with access" shows one row for that person:
SelfTest B2 (@selftestb2.home)
In use in 8 rooms: Face-to-face …, Face-to-face …, Face-to-face … +5 more
Auto-send Revoke
No Bot is named, and the single Revoke removes every Bot-level grant to that person. Measured: 2 person grants before the click, 0 after.
Expected
Now that sharing is per Bot, revoking should be able to target one Bot too — either one row per Bot (same label shape as the share list), or the person row says which Bots it covers ("Chief, Writer") and offers revoke per Bot. Today a person with two Bots cannot take one back without also cutting the other.
Why
accessRows (plugins/social/src/social.js:2505-2538) keys rows by the person's home and merges the grants into grantIds; social/revoke-grant then deletes them one after another (:2553-2560), which is the design from #383/#387. Multi-Bot friends only became visible with #973, so the merged row now hides a distinction the share list shows.
Keep the existing rule that a talk-through grant on an already-shared Bot stays on its own row (#387).
Scope
Shape of the access list and of revoke (plugins/social, access UI). Grants already store Bot-level ids, so the data is there.
Evidence
main 0553ba1e, real browser UI on isolated homes.- A's Chief held person grants to B's Chief and B's Writer (plus a stale one for a Bot B had removed). "People with access" printed the single row above with one Revoke button; after clicking it,
list_bot_grantshad 0 person grants. - Related: One-click Share names the friend but grants to one of their Bots: the panel and the success line never say which Bot #973, Ask the share list per Bot, not per person #983, People with access lists each person once; a talk-through grant on an already-shared Bot is not a share #387, People with access lists the same friend twice when my already-shared Bot joins that friend's invite (talk-through grant shown as a share) #383.
Activity
Birfy commentedon Oct 24, 2026
Owner: Dev3 (Triage; Chief assigned this and #994 across the two free hands; you just did the two-slot note in the same panel's sibling file).
Reviewer: Reviewer
Triage check at main
da17eb5f:accessRowsisplugins/social/src/social.js:2505-2538::2521pushes every grant of the same person into one row'sgrantIds,:2527starts a new row.social/revoke-grant(:2553-2560) deletes the batch in one click (fencedRevoke), which is People with access lists the same friend twice when my already-shared Bot joins that friend's invite (talk-through grant shown as a share) #383/People with access lists each person once; a talk-through grant on an already-shared Bot is not a share #387's design and was right when a person could hold only one Bot-level grant.Decision, so the shape is not yours to invent: one row per Bot, labelled the way the share list already labels it (
<Bot> (<Owner>), #973/#991's shape), and Revoke takes exactly the rows shown. Keep #387's rule that a talk-through grant on an already-shared Bot keeps its own row. The room-usage line can stay per row; if that turns out to display something wrong once rows split, report it here instead of inventing a third shape.Acceptance: a friend with two Bots, both granted → two rows named per Bot; revoking one leaves the other's grant in place (
list_bot_grantsshows it);#387's talk-through row is unchanged; a single-Bot friend still shows one row and one Revoke.Birfy commentedon Oct 24, 2026
Owner: Dev3 — claimed, branch
dev3/fix/995-access-per-botfromda17eb5f.Plan (shape is Triage's, not mine): one row per Bot in People with access, labelled like the share list (
Bot (Owner), #973), each row's Revoke takes exactly its own grant; #387's talk-through row keeps its own row; a single-Bot friend still shows one row and one Revoke. Red first: two Bot-level grants to one friend → today one row / one Revoke.Where the Bot name comes from: core
grants.setkeeps onlyid/grantee/name/relationshipId/roomId(reach.js:355-370), so the per-Bot display name cannot ride on the grant record. I will keep a plugin-local handle→{bot, owner} map filled from the rawlist_bot_grantsthe sync already fetches, and fall back to today's person label when the server sends no Bot name.Split People with access into one row per Bot (ThinkFlowLab#1009)
Restore both directions when a re-invite is accepted (ThinkFlowLab#1000…
Name the link that keeps a removed friend's row (ThinkFlowLab#1001) (T…