View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003505 | unreal | ircd | public | 2007-08-06 23:13 | 2010-08-14 20:49 |
| Reporter | Shining Phoenix | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Platform | i386 | OS | Linux | OS Version | 2.6.10-1.771_FC2 |
| Product Version | 3.2.6 | ||||
| Summary | 0003505: Seven possible new ban functions and corresponding extbans | ||||
| Description | First, I need to introduce a couple terms I'm going to use: Event extban - These specify what the banned user can't do, e.g. ~n, ~q, ~j Matching extban - These specify how to match banned users, e.g. ~c, ~r Normal ban - nick!user@host Normal ban. I suggest that anyone matching a normal ban cannot do the following events targeting the channel unless they have halfop: 1. /topic 2. /invite 3. /notice 4. CTCP 5. ACTION I suggest that anyone matching a normal ban cannot do the following events targeting the channel unless they have voice: 6. /part Well, a person not in the channel doesn't have voice: 7. /knock New event extbans. [suggested letters] I suggest that anyone matching the following extban(s) cannot do the respective event(s) targeting the channel unless they have voice: 8. /topic [t] 9. /invite [i] 10. /notice [T] 11. CTCP [C] 12. ACTION [m] 13. /part [p] Well, a person not in the channel doesn't have voice: 14. /knock [k] Putting it all together. 15. When one of these event extbans is chained with a matching extban, instead the banned user needs halfop to do the restricted events. This way, events 1 through to 5 can be controlled the same way as /nick. You may not have used bans enough to notice this pattern: i) +N - halfops and lower cannot /nick ii) +bb ~q: ~c:+#channel - voices and lower cannot /nick iii) +b ~c:+#channel - voices cannot /nick iv) +b ~q: - people without status cannot /nick This more detailed level of control can be done for other events if 1-5, 8-12 and 15 are done. 16. +b ~q would include the effects of 8-13, but +e ~q would not. | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
nice, I like this idea |
|
|
Note: Where I say /part above, I mean "block part message", not "disallow /part". Note 2: Change the ~q's above to ~n's |
|
|
Firstly, note it's pretty much impossible to have the "exempt status level" be one thing for one kind of ban, and something else for another. Or at the least, there's very little reason to do this. [quote]1. /topic[/quote] Already checked, as equivalent to privmsg/notice. Also appears to already require (half)op if banned (but voice is enough in +m). Sensible I think. As an extban, just use ~q. [quote]2. /invite[/quote] The general rule to deal with invite abuse is just set +i (note that you can +I *!*@* to turn off the "can't join" part of +i, keeping the "only chanops can invite"). Note, of course, that invites are silent (except by chanop/overriding ircop), so only user/ircop complaint would ever clue you that such a measure is necessary ;) . [quote]3. /notice[/quote] Equivalent to privmsg. And IMHO, it's really equivalent in every sense of the word. There's little reason to be more strict about notice than privmsg. If it's that much of a problem, just use +f noticeflood or have +T permanently. As an extban, just use ~q. [quote]4. CTCP[/quote] Equivalent, no, in fact, *IS* a privmsg. Not reason to be more strict really. Use +f ctcpflood or +C if it's a problem. Also textban can handle the problem (but can't be chained, currently). [quote]5. ACTION[/quote] This is just a fancy CTCP. See above. [quote]6. /part[/quote] Already reported. 0003354 - As an extban, can't see use for one as per the original report. Probably ~j (or ~q) if anything. [quote]7. /knock[/quote] Already checked for. Try it some time ;) . It also uses extban ~j. [quote]New event extbans. [suggested letters][/quote] I've put my extban responses above, but I'll mention this here: some can say we already have too many extbans, so we don't really need more in core. However, if you really felt you needed an extra extban, many (if not all) of these can be done via module. [quote]15. When one of these event extbans is chained with a matching extban, instead the banned user needs halfop to do the restricted events. This way, events 1 through to 5 can be controlled the same way as /nick. You may not have used bans enough to notice this pattern:[/quote] See above: it's not really a good idea to have differing "exempt status level" as it can only just create more confusion (both in users and in code!). [quote]16. +b ~q would include the effects of 8-13, but +e ~q would not.[/quote] Extbans generally should be the same whether +b or +e. Making them different just confuses things. |
|
|
Aquanight: "Firstly, note it's pretty much impossible to have the "exempt status level" be one thing for one kind of ban, and something else for another." Me: "You may not have used bans enough to notice this pattern: i) +N - halfops and lower cannot /nick ii) +bb ~n: ~c:+#channel - voices and lower cannot /nick iii) +b ~c:+#channel - voices cannot /nick iv) +b ~n: - people without status cannot /nick" ~n and normal/~c/~r have different exempt status levels for /nick - voice and halfop respectively. Aquanight: "Or at the least, there's very little reason to do this." Me: See how /nick has several grades of restriction? Enabling several grades of restriction for other events is the reason for this. Aquanight: "Note, of course, that invites are silent (except by chanop/overriding ircop), so only user/ircop complaint would ever clue you that such a measure is necessary ;) ." Me: This silent thing was implemented after 3.2.6? Me: "16. +b ~q would include the effects of 8-13, but +e ~q would not." Aquanight: "Extbans generally should be the same whether +b or +e. Making them different just confuses things." Me: This isn't confusing. It changes "~q blocks PRIVMSGs" to "~q blocks messages". Stopping someone from speaking but letting them action/ctcp/notice/knock seems stupid to me. |
|
|
> i) +N - halfops and lower cannot /nick > ii) +bb ~q: ~c:+#channel - voices and lower cannot /nick > iii) +b ~c:+#channel - voices cannot /nick > iv) +b ~q: - people without status cannot /nick" This isn't quite the same as what you're suggesting (not to mention you probably meant ~n instead of ~q): +N isn't a ban, so it can make its own rules. Though having looked at it, I do see that a +b n!u@h would block voices from nick-changing. Interesting, dunno why syzop told me (at least I could have sworn he did) some time back that voiced users where pretty much exempt from all ban checking. [quote]Me: This silent thing was implemented after 3.2.6?[/quote] Use of invite, as far as I know, has never produced any kind of notice unless it was used by a chanop or an ircop using it to override-join. This has been the case for at least as long as I can remember ;) . [quote]This isn't confusing. It changes "~q blocks PRIVMSGs" to "~q blocks messages". Stopping someone from speaking but letting them action/ctcp/notice/knock seems stupid to me.[/quote] ~q has always been "blocks messages". Note that action/ctcp are just PRIVMSGs, and notice goes through the same m_message stuff as PRIVMSG. Knock is based on joining, so if you want someone to quit knocking, set a ~j. (Of course, knock only works if the channel is +i (and not +K or +V) anyway, and there's always +f knockflood.) |
|
|
>> i) +N - halfops and lower cannot /nick >> ii) +bb ~n: ~c:+#channel - voices and lower cannot /nick >> iii) +b ~c:+#channel - voices cannot /nick >> iv) +b ~n: - people without status cannot /nick" > >This isn't quite the same as what you're suggesting: +N isn't a ban, so it can make its own rules. Ok, ignore +N. That still leaves the ability to use extbans to restrict some event to voices and higher OR halfops and higher. >Use of invite, as far as I know, has never produced any kind of notice unless it was used by a chanop or an ircop using it to override-join. /me tests...you're right :p |
|
|
Looked at it, and I agree with aquanight, most of this has been handled now, and for the suggested new extbans I see very little use, and I don't like the suggestion to make them suddenly behave different if chained either ;P. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2007-08-06 23:13 | Shining Phoenix | New Issue | |
| 2007-08-07 00:30 | Stealth | Note Added: 0014691 | |
| 2007-08-07 04:22 | Shining Phoenix | Note Added: 0014694 | |
| 2007-08-07 22:35 | aquanight | Note Added: 0014697 | |
| 2007-08-08 00:34 | Shining Phoenix | Note Added: 0014698 | |
| 2007-08-08 05:53 | aquanight | Note Added: 0014699 | |
| 2007-08-08 05:57 | aquanight | Note Edited: 0014699 | |
| 2007-08-08 21:11 | Shining Phoenix | Note Edited: 0014694 | |
| 2007-08-08 21:11 | Shining Phoenix | Note Edited: 0014698 | |
| 2007-08-08 21:21 | Shining Phoenix | Note Added: 0014703 | |
| 2007-08-08 21:21 | Shining Phoenix | Note Edited: 0014703 | |
| 2007-08-08 21:22 | Shining Phoenix | Note Edited: 0014703 | |
| 2007-08-08 21:22 | Shining Phoenix | Note Edited: 0014703 | |
| 2007-08-08 21:23 | Shining Phoenix | Note Edited: 0014703 | |
| 2007-08-10 03:21 | Shining Phoenix | Note Edited: 0014703 | |
| 2007-08-10 03:21 | Shining Phoenix | Note Edited: 0014703 | |
| 2010-07-14 21:18 | syzop | Relationship added | duplicate of 0003928 |
| 2010-08-14 20:49 | syzop | QA | => Not touched yet by developer |
| 2010-08-14 20:49 | syzop | U4: Need for upstream patch | => No need for upstream InspIRCd patch |
| 2010-08-14 20:49 | syzop | Note Added: 0016272 | |
| 2010-08-14 20:49 | syzop | Status | new => closed |
| 2010-08-14 20:49 | syzop | Resolution | open => no change required |
