View Issue Details

IDProjectCategoryView StatusLast Update
0003012unrealircdpublic2013-05-07 07:01
ReporterJase Assigned Tonenolod 
Status resolvedResolutionfixed 
OSFreeBSDOS Version4.6 
Product Version3.2.6 
Target Version3.3-alpha0Fixed in Version3.4-alpha1 
Summary0003012: Ability to sqline channels.
DescriptionI would like to suggest the ability to support sqlining of channels.

Recently I tried on my network running Anope Services, and when I tried to issue the operserv sqline command and apply it to a channel, I was told that applying a sqline to a channel was not supported by Unreal.
TagsNo tags attached.
3rd party modules


has duplicate 0000935 resolvedTrocotronic SQLINE command but for channel banning 



2006-08-02 22:58

reporter   ~0012124

What's the point of this?


2006-08-03 04:24

reporter   ~0012126

So that Service Administrators could close a channel, and stop it from being used all together, without having to go to the Server Administrator and asking for particular 'trouble making' channels to be added to the deny block.

It was just a thought.


2006-08-03 12:04

reporter   ~0012130

I could be wrong but doesn't ChanServ usually have a FORBID command that usually works quite as well? (although sqline the channel would make it easier/better ("Cannot join channel (<forbid reason>)" as opposed to "Cannot join channel (+b)") for services to enforce the forbid rather than have a service bot squat the channel)


2006-08-03 12:58

reporter   ~0012131

I've tried chanserv forbid, but it doesn't seem to have the same effect.
Users can still join the channel, and then they instantly get kicked out, but they don't seem to be banned, so they get kicked, and kicked again, and so on, til they stop trying to join.

In the case where there are lots of drones/bots, it would cause a load on services for each channel that is forbidden.

That is why I thought support for sqlining channels would make things easier in that respect.


2006-08-03 19:40

reporter   ~0012143

True, but that's about as much about anope's bad implementation of the command. What it should do is JOIN ChanServ, BAN *!*@*, KICK, and have ChanServ sit for 60 seconds.
As it is, I'm not sure if it sits or not (been a while since I looked), and I know that it doesn't ban *!*@* but rather just that one host for that user.
And if you set it +s and sit a bot in there, the banlist just gets bigger.


2006-08-03 22:01

reporter   ~0012146

That would also ban opers from the channel (minus a sajoin)
The ability to deny a channel without editing the conf file would be very useful and a good feature


2006-08-03 22:47

reporter   ~0012147

a) why do opers need to step into a forbidden chan. nothing is in there
b) If you have a bot in there, you can have IT invite you
c) If you don't have a bot in there, you can still use any of sajoin, banwalk (OperOverride INVITE, then JOIN), or CS INVITE
d) having the banlist grow to 60+ isn't that good either, esp if the ban list fills and then can't keep growing, so that the ban is no longer effective


2006-08-03 22:48

reporter   ~0012148

Oh yeah. and if this DOES happen, I would hope it would become a new type of *line, not a qline. Talk about breaking existing code...
Why not make a new TKL C or something.


2006-08-04 21:52

reporter   ~0012153

wot happens if, a ircop adds a channel sqline and there are bots inside it?
say theres 1000 bots
thats a nice flood the server has to generate to kick them or so


2006-08-04 22:02

reporter   ~0012154

Point... otoh, an sqline doesn't force the user to change their nick, it just prevents others from changing to it.
You could argue that a channel block would prevent joins.

And tbh, if you do a FORBID or CLOSE or w/e with services, it would cause the same 'flood'.

I'm not necessarily against the idea, but would want it to be done in a proper way that means, to me, NOT a TKL Q or SQLINE. if it must be TKL, make it a new type. alternatively consider a new cmd, like SVSFLINE (in this case, SVSCLINE or something)


2006-08-11 12:36

reporter   ~0012169

(I'll quietly note that if you're worried about this breaking existing code (I presume with your services?) you are making assumptions you shouldn't be. I'm pretty sure bahamut allows for channel-based Q:.)


2006-08-11 12:58

reporter   ~0012170

for SQLINE, sure. for TKL Q... I'll leave that to your imagination.
otoh, I don't have to parse SQLINE as I'll never see it. Only generate it.

meanwhile, if it's gonna become a TKL event, it should be its own. I see it specifically as being different.


2006-08-11 15:38

reporter   ~0012173

BD + Q * #warez w00t 1234 1234 :Fuckers.

Not sure that's fully valid (hey, my UnProtoCol SkiLlZ are rusty), but I fail to see how that's drastically difficult to parse?

You'll never recieve a NICK with a # as the first character, so even if you were doing something bizarre and fucked up with it, nothing would break. So, bahamut-alike behaviour still looks valid


2006-08-13 15:58

reporter   ~0012178

I'm just not wanting more special cases in the code if I can avoid it. Esp if I had to start having my code be aware of what qlines actually do/mean (which, at present, it does not)


2006-08-16 09:03

reporter   ~0012182

i don't see why you would need to put any special cases in the code at all, you
d simply check for a q:line on the nick / channel, there would be no need for checking if # is the first character or anything like that, # is not gonna be the first char in a nick, just like channels will always start with #, so just checking for a q:line would not need anything at all special, because when u check for a channel q:line, it can't match a nick q:line as it won't be prefixed by #; i honestly can't see any reason not to use a q:line for both.


2006-08-16 09:59

reporter   ~0012183

Unless you get wildcards involved. Then you get fun things like *hello* bans both nicks and channels. No it'd probably more like: if the mask starts with a #, it's a channel ban, and if it doesn't, it's not.


2006-08-16 10:13

reporter   ~0012184

yeah, i actually thought about that after i posted, hmmm, there has to be an easy way to do it, while still keeping the same tkl


2006-12-28 12:31

reporter   ~0012947

Fixed in .2320


2013-05-07 07:00

reporter   ~0017522

Issue History

Date Modified Username Field Change
2006-08-01 11:56 Jase New Issue
2006-08-02 22:58 codemastr Note Added: 0012124
2006-08-03 04:24 Jase Note Added: 0012126
2006-08-03 12:04 aquanight Note Added: 0012130
2006-08-03 12:58 Jase Note Added: 0012131
2006-08-03 19:40 tabrisnet Note Added: 0012143
2006-08-03 22:01 djGrrr Note Added: 0012146
2006-08-03 22:47 tabrisnet Note Added: 0012147
2006-08-03 22:48 tabrisnet Note Added: 0012148
2006-08-04 21:52 White_Magic Note Added: 0012153
2006-08-04 22:02 tabrisnet Note Added: 0012154
2006-08-11 12:36 w00t Note Added: 0012169
2006-08-11 12:58 tabrisnet Note Added: 0012170
2006-08-11 15:38 w00t Note Added: 0012173
2006-08-13 15:58 tabrisnet Note Added: 0012178
2006-08-16 09:03 djGrrr Note Added: 0012182
2006-08-16 09:59 aquanight Note Added: 0012183
2006-08-16 10:13 djGrrr Note Added: 0012184
2006-12-01 12:59 syzop Relationship added has duplicate 0000935
2006-12-28 12:31 Trocotronic Status new => resolved
2006-12-28 12:31 Trocotronic Fixed in Version => 3.3-alpha0
2006-12-28 12:31 Trocotronic Resolution open => fixed
2006-12-28 12:31 Trocotronic Assigned To => Trocotronic
2006-12-28 12:31 Trocotronic Note Added: 0012947
2010-07-02 10:22 syzop Relationship added parent of 0003915
2011-07-19 13:58 syzop Assigned To Trocotronic =>
2011-07-19 13:58 syzop Status resolved => needs re porting
2011-07-19 17:11 syzop Target Version => 3.3-alpha0
2012-10-15 21:27 syzop Relationship deleted parent of 0003915
2013-05-07 07:00 nenolod Note Added: 0017522
2013-05-07 07:00 nenolod Status needs re porting => resolved
2013-05-07 07:00 nenolod Fixed in Version 3.3-alpha0 => 3.4-alpha1
2013-05-07 07:00 nenolod Assigned To => nenolod