Repository navigation
Tell the inviter when someone accepts their invite - #1090
Conversation
|
Verdict: PASS at a5da416 Ran: TZ=UTC npm run verify exit 0 at a5da416. core 1411 pass, social 457 pass, tree 125 pass, timeline 125 pass, .github/scripts 417 pass, interop 37 pass, live-e2e 16 pass. arch-docs OK. changelog.d valid. Not run:
No actionable findings. Accepting stays one-way: a reply_only remote is not a friend row. The inviter gets one sidebar notice and a toast only for an id that appears after the first status read. People with access keeps that joiner when list_bot_grants is empty or throws, including after reload, and does not double the row when the list already names them. Ask them to share a Bot sends one fixed line and grants nothing. Peer display names go through cleanText before the notice and the access label. The notice is owner UI only. |
Accepting stays one-way, so the joiner's Bot is not a friend row. Keep a sidebar notice and a toast, list that person under People with access when the grant list is empty, and offer one step that asks them to share a Bot back. Fixes #1054 Co-authored-by: Danyang Chen <birfychen@gmail.com>
a5da416 to
d5deea6
Compare
|
Written-by: Dev Self-review note on the rebase. This is not a conclusion; the coordinator will record one for this tip. Tip: d5deea6 Conflict: docs/subsystems/social.md only. Kept both "A remote turn that died (#1068)" and "Inviter sees an accepted invite (#1054)". plugins/social/client.js, src/social.js, and test/social.test.js auto-merged. Compared with origin/main: no function, test name, or issue marker from main is missing; the four #1054 tests are the additions. Diff against main is those three files, the subsystem paragraph, and changelog.d/1054-inviter-accept.fixed.md. Ran: TZ=UTC npm run verify Not run: smoke, Desktop, browser. |
Written-by: Dev
Owner: Dev
Reviewer: Reviewer
Fixes #1054
What changed
Accepting an invite stays one-way: the joiner sees the inviter's Bot, and the inviter does not get a friend row while that Bot is
reply_only. The inviter now sees that the accept happened.send_as_member. Bot Social answersbot_not_shared, stores nothing, and the joiner gets the existing share-request card. A Bot already shared back is not sent that line, and nothing is granted from the notice.list_bot_grantsis empty or throws, including after a reload, and does not list them twice when the grant list already has the same Bot.reply_only: falseremote is a friend row and the notice closes.Rebased onto
mainat3f7e95152c1e73c728f701680db4edfd796b7633. The only conflict wasdocs/subsystems/social.md; both the remote-turn section (#1068) and this accept section are kept. Functions and tests already onmainare still present.Verification at the tip
Tip SHA: d5deea6
Fail-without-change (defect): with
plugins/social/src/social.jsandplugins/social/client.jsat the previous base and only the new tests applied, the accept-notice tests failed (the joiner showed as a friend row;acceptNoticeswas missing;AcceptNoticeswas not a function). The empty-list and throwing-list cases are that defect. The no-duplicate / share-back case is a guardrail. The client test covers the card and that only a notice arriving after the first look toasts.Ran:
TZ=UTC npm run verify(exit 0) atd5deea60aa8aa60609fabbdd1c190bff5289fb80. core 1420 pass, social 471 pass, tree 125 pass, timeline 125 pass, .github/scripts 417 pass, interop 37 pass, live-e2e 16 pass. arch-docs OK.Not run: smoke (no
index.jsorsrc/hostchange). Desktop. Browser (no app server; the sidebar card is covered by the client unit test).Not enqueued. The earlier conclusion named
a5da4166e2d2679e59823e10ded5c5c786df78faand does not apply to this tip.