-
Notifications
You must be signed in to change notification settings - Fork 55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
send pseudo MODE for chm_hidden modes on oper_up #98
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is a good change. I've got some nitpicks (and one important thing) in the review comments. I also wonder if it's worth sending RPL_CHANNELMODEIS rather than MODE if it'll do the same job of keeping clients in sync?
@@ -1469,6 +1474,29 @@ oper_up(struct Client *source_p, struct oper_conf *oper_p) | |||
send_umode_out(source_p, source_p, old); | |||
sendto_one_numeric(source_p, RPL_SNOMASK, form_str(RPL_SNOMASK), | |||
construct_snobuf(source_p->snomask)); | |||
|
|||
if (HasPrivilege(source_p, "auspex:cmodes")) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You don't oper_up
when your privset changes, so I think this is the wrong place to do anything that checks privs. Currently the best place is probably user_mode
, hacky though it is, since we arrange to call it every time privs change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
doesn't it also get called for other stuff? how are we meant to know when /mode mynick
isn't supposed to send out these MODE
s?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we can :(
Maybe it's time to bite the bullet and add a standard mechanism for all privilege changes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what does this involve
c4e305b
to
4230b78
Compare
4230b78
to
0907d3c
Compare
do we also want to send the removal of these modes if someone either deopers are drops to a privset without |
I think that'd be ideal, yeah. |
then when we add a "standard mechanism" for priv changes, we'd want to make sure it's also called for changing to no privs |
depends on #112 |
placement of this code might be wrong. it's quadratic which I think is probably fine unless we have loads of
chm_hidden
modes or so. usual caveat that I'm not great at Ccloses #97