Mark a role as invite-grantable, and bind one to an invite (GRYT-893) - #371
Merged
Conversation
The client half of the invite role binding. server#129 has the rules and the storage; without this nothing can set the flag or bind a role, so the feature ships inert. Two pieces. The role editor gets a tick: "Can be given out by an invite", off for every role until somebody turns it on, and disabled for built-in roles. The copy under it says the two things somebody needs before ticking it — that the role is then only as private as the link, and that admin, owner and anything able to hand out permissions can never be given this way whatever the tick says. The invite form gets a role picker, and it only appears when at least one role has been marked. An empty picker on a server where nobody has ticked anything would read as the feature being broken; no picker reads as nothing to pick. The list is whatever the server sent back already filtered, rather than a judgement made here — the server refuses roles at or above the creator's own rank too, and duplicating that rule in the client is how the two drift apart. `yarn lint` clean, which is `tsc -b` and eslint at zero warnings. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The client half of the invite role binding. Gryt-chat/server#129 has the rules and the storage; without this nothing can set the flag or bind a role, so that PR ships inert.
Merge the server one first — this talks to
grantableByInviteonserver:roles:definitionsand sendsgrantsRoleonserver:invites:create, neither of which exists until it lands. Against an older server the tick saves nothing and the picker never appears, which is ugly but not broken.Two pieces
The role editor gets a tick, "Can be given out by an invite", off for every role until somebody turns it on and disabled for built-in roles. The copy under it says the two things somebody needs before ticking: the role is then only as private as the link, and admin, owner and anything able to hand out permissions can never be given this way whatever the tick says.
The invite form gets a role picker, which only appears once at least one role has been marked. An empty picker on a server where nobody has ticked anything reads as the feature being broken; no picker reads as nothing to pick.
What to look at
The picker lists what the server sent back, already filtered, rather than filtering here. The server also refuses any role sitting at or above your own in the list, and duplicating that rule in the client is how the two drift apart — but it does mean the list can contain a role the server will then refuse, and the refusal arrives as a
server:errortoast rather than the option being absent. I think that is the right trade; say if you would rather it were filtered both ends.Verification
yarn lintclean —tsc -bplus eslint at zero warnings. Not exercised against a running server, because the server half is not merged yet, so the wire format is checked by reading rather than by joining.Caught one of my own errors on the way: two edits both added
grantableByInviteto the same object literal, whichtscrefused. Worth mentioning only because it is the kind of thing that survives a read-through.🤖 Generated with Claude Code