diff options
| author | Christophe Besson <cbesson@gmail.com> | 2026-08-15 00:49:54 +0200 |
|---|---|---|
| committer | Christophe Besson <cbesson@gmail.com> | 2026-08-15 00:49:54 +0200 |
| commit | 76724252d08162d4df39090af19796054bf4add8 (patch) | |
| tree | 2ed96118f3a0ee7139281b308f2489d7a176ea35 /packages/meshbay-node/src/meshbay_node | |
| parent | 4156b5b8c3986278a887d1dce4db265746e9155f (diff) | |
| download | meshbay-76724252d08162d4df39090af19796054bf4add8.tar.gz | |
fix(members): restore the member list and invite form, and retire the pairing form
Moving the invite form above the member list cut both out of MembersPanel and
pasted them into AdminPage, where `doInvite`, `members`, `adminId` and
`inviteCode` do not exist. A standard member saw an empty Members tab, the
group owner saw only a pairing form, and the hub's own Users tab referenced
four undefined names.
The pairing form outstaying its welcome is a second bug and an older one.
`is_node_admin` compares the connecting account with the account that owns the
node — it says nothing about whether *this browser's key* was ever paired, which
is the thing pairing changes and the thing that lets you sign an invite. So the
form showed for an operator who paired months ago, accepted a fresh code,
reported success, and stayed exactly where it was. The node already reports the
roster role in `join_result`; the transport keeps it, and the form appears only
when this identity is not an operator key yet.
Also dropped a clause from the pairing hint: the code never passing through the
hub is worth saying, the theory behind it is not.
test_spa_ordering.py gets three checks for this class of bug — a cut-and-paste
between components is invisible to every other test we have.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Diffstat (limited to 'packages/meshbay-node/src/meshbay_node')
0 files changed, 0 insertions, 0 deletions