[Frontend] Let players set their own character name #383
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Impact: MEDIUM
Found in the August 2026 session lifecycle review (#319).
What the user experiences
A new player who joins a campaign has no way to set their own character name. The "Edit character" button only renders once a character name already exists — so the first name must be set by the GM, for every player, and nothing in the product says so.
Evidence
webapp/frontend/src/pages/CampaignDetail.jsx:1581-1590— the button is wrapped inm.character_name && (…), so it renders only when a name already exists.webapp/frontend/src/pages/CampaignDetail.jsx:1598— for the GM's view of other members, the button already correctly reads{m.character_name ? "Edit character" : "Set character"}; the fix is to apply the same conditional to the player's own row.Why it matters for a hosted product
An onboarding step the product could trivially self-serve (a player naming their own character) instead silently requires the GM to do it for every player, with no indication anywhere that this is expected.
Proposed fix
Drop the
m.character_name &&guard on the player's own row so the button reads "Set character" when empty, matching the pattern the GM's view of other members already uses at:1598. This is the audit's P14.Acceptance criteria
Picking this up as part of v4.3.0 phase 1 (#514), shipping early as v4.2.3. Same conditional the GM's view already uses, applied to the player's own row, with a test for both states.
Closed by PR #515 (merged), shipping in v4.2.3, with a finding: this no longer reproduced on main. PR #330's multi-character refactor replaced the
m.character_name && (…)guard the audit saw withcanManageCharacters = isGm || m.user_id === user?.id, and a player's own row renders "+ Add character" through that check whether or not a character exists, plus "Edit character" when one does. So the fix landed as a side effect of #330, before this issue was filed against the older code.What #515 adds is the coverage that was missing: two tests in
CampaignDetail.test.jsxpin the exact scenario named here (a non-GM player, their own row, zero characters, sees an actionable button; with a character, sees Edit), so the guard cannot quietly come back. No production change.