um_callerid, um_regonlymsg: various cleanups #364
Conversation
This should eliminate some unnecessary /accept list entries because reverse messages would have been allowed anyway. Also fixes opers not getting added to source's /accept list with the new mode to bypass callerid.
aaronmdjones
force-pushed
the
dwfreed/callerid-cleanup
branch
from
717c0e8
to
d27fba3
Compare
| IsSetAnyCallerID(source_p) && | ||
| !accept_message(target_p, source_p) && | ||
| !IsOperGeneral(target_p)) | ||
| !allow_message(target_p, source_p)) |
There was a problem hiding this comment.
I don't think this is the right test for here - if you message someone who's currently +M then an auto-accept wouldn't be added, and once +M times out they won't be able to reply. The version of this part from #383 takes account of that.
There was a problem hiding this comment.
I think that if you have +M set, you should be around (and not just letting it time out while AFK), and equally if it gets dropped (because you're busy), you can always reset it. I also imagine the typical use of +M is such that it is set for a split second so a global/server notice can be pushed out and then cleared again. (Eg, I have an alias for OFTC's "god" mode that sets it, does the thing I want to do, and then clears it right after). I really don't think this is going to be much of an issue in practice.
There was a problem hiding this comment.
the typical usecase is any time staff are attempting to message a user for network-related things and they're +g, in which case the only thing that needs force is your initial messages. if they choose to respond, auto-accept makes sense for a back-and-forth of unpredictable duration
There was a problem hiding this comment.
Sure, so you set +M for your initial message, and then clear it right after, and when the user responds, auto-accept still kicks in with this change, because you are no longer +M
There was a problem hiding this comment.
why clear it when it'll time out all on its own
There was a problem hiding this comment.
Because you don't need it anymore and you should be carrying excess privilege for as short a duration as necessary? A simple client alias can handle the whole process for you, eg /alias overridemsg umode +M; msg $0 $1-; umode -M
There was a problem hiding this comment.
this feels like seeking a problem to justify a solution. i dont think holding on to +M for a few minutes more than you need it is particularly a problem, same with override. real world usage would agree with me
There was a problem hiding this comment.
(especially because you can't foresee how long you'll need the powers)
There was a problem hiding this comment.
Clogging up (and potentially completely filling) a user's /accept list with auto-accepts that they often don't even know exist isn't a problem? Especially with relaxed caller-id, every person you message, even if they are capable of messaging you because of relaxed caller-id, will earn you an auto-accept that isn't even necessary.
There was a problem hiding this comment.
no, i don't think that's a problem, or at least don't think +M is anything to do with making that not a problem
Uses
allow_messageinstead ofaccept_messageso that reverse auto-/acceptentries are only added if reverse messages would not otherwise be allowed. This change also fixes messages to opers not triggering reverse auto-/accept, which is needed with the switch to a usermode (and privilege) to bypass callerid.Also has
um_regonlymsgcheck whether the source is identified before scanning the target's/acceptlist, which saves an unnecessary scan for identified sources.