View Issue Details

IDProjectCategoryView StatusLast Update
0003308unrealircdpublic2008-02-12 06:07
ReporterShining PhoenixAssigned Tonate 
PrioritynormalSeverityfeatureReproducibilityalways
Status resolvedResolutionfixed 
Platformi386OSLinuxOS Version2.6.10-1.771_FC2
Product Version3.2.6 
Target VersionFixed in Version3.3-alpha0 
Summary0003308: When someone creates a channel, +q them as well
Descriptioni.e.
* Now talking in #blah
* server.network.tld sets mode +q Phoenix
#blah ~@Phoenix
#blah End of /NAMES list.

Why do this? So channel creaters can have a little more control/features without registering the channel :)
TagsNo tags attached.
3rd party modules

Activities

syzop

2007-04-30 05:01

administrator   ~0013942

We could make it a feature to configure which access rights channel creators get.
That'd also take care of people wanting chancreators to have no rights whatsoever.

WolfSage

2007-04-30 09:47

reporter   ~0013946

set::modes-on-chancreate with a default of "o". Sound good?

syzop

2007-04-30 10:04

administrator   ~0013948

one could misinterpret that as which modes the channel gets.
but yeah, something like that :)
perhaps something with 'level' in it, or.. well, be creative ;p

WolfSage

2007-04-30 10:28

reporter   ~0013951

Ahh, good point. Which makes me wonder. We could put the both together, and limit which modes they're allowed to set on create (no modes requiring an argument), and any modes which would apply to a user's access level (ohv) would automatically apply to them, so:

set::modes-on-chancreate "ovnt";

Would set the chan +nt, and them +ov.

And

set::modes-on-chancreate "nt";

Would set the chan +nt, and no access (for those strange networks that want that)

syzop

2007-04-30 11:02

administrator   ~0013952

[quote]limit which modes they're allowed to set on create (no modes requiring an argument)[/quote]
nah, we should still provide the ability to set like +j X:Y and +f xxx by default. it's used by various networks to provide a safe flood default setting.

but @ combining them, I understand your logic, but... hmmm :)
I'd say... make it a separate setting.

set::level-on-join ? nicely combines with modes-on-join, but it does not have something with create in it, slightly confusing. then again, so is modes-on-join.
set::level-on-channel-create ? tad long

set::level-on-chancreate ? bleh
set::level-on-firstjoin? hmz
set::level-on-first-join? argh

perhaps set::level-on-join is the way to go.

Shining Phoenix

2007-04-30 22:24

reporter   ~0013959

Last edited: 2007-05-01 06:45

set::status-on-create

\o/

aquanight

2007-05-02 18:29

reporter   ~0013981

I should point out, we wouldn't have to do the servermode thing. NAMES does that anyway. We don't do server.mode MODE +o blah, why do it for anything else?

Granted it gets fun with a pre-NAMESX client. But they already have to put up with +ov etc anyway.

Stealth

2007-05-02 20:43

reporter   ~0013982

The server mode is sent to other servers, even on the first join (I don't know why)

Also, we should also support having no level, for people who don't want users opped when they create a channel. Something like set::level-on-join ""; or set::level-on-join 0;

Shining Phoenix

2007-05-02 21:19

reporter   ~0013985

Or set::status-on-create +;

...since + and - are the two characters that can't ever be channel modes themselves. A channel mode 0 might happen someday :o

aquanight

2007-05-02 22:13

reporter   ~0013986

[quote]The server mode is sent to other servers, even on the first join (I don't know why)[/quote]

That's how it is between servers, but the client doesn't see that (just the NAMES shows his @). And technically it's an SJOIN anyway.

[quote]Also, we should also support having no level, for people who don't want users opped when they create a channel. Something like set::level-on-join ""; or set::level-on-join 0;[/quote]

Syzop did suggest (in the first bugnote) making that possible already :) . I'd imagine "" (or "+" - we should allow optional leading + (but not - since that won't make any sense anyway)) would be reasonable (with default == "o" if not given).

[quote]...since + and - are the two characters that can't ever be channel modes themselves. A channel mode 0 might happen someday :o[/quote]

The first part might be true (although - really shouldn't ever be in here, since this is stuff to add, they have nothing to start with to be removed). But I hope I never see a channel mode 0 for unreal (if I have to hardcode unreal myself to reject nonletters, I will! :P ). Reeks too much of that ircd (dancer wasn't it?) that had so damn many modes they needed digits *and symbols (*, _, etc)* for them. ARGH.

tabrisnet

2007-06-10 11:29

reporter   ~0014305

a) not having any channel mode set on the user would seem to preclude registration (most services require the user be opped before registering). So that's certainly interesting.
b) I fail to see why +q is needed when joining, short of networks w/o services.

Stealth

2007-06-10 16:25

reporter   ~0014313

> a) not having any channel mode set on the user would seem to preclude registration (most services require the user be opped before registering). So that's certainly interesting.

I've found the joindeop module is quite popular... Some may download it to just have it, but if a good number of people downloading it are actually using it, this would be a rather popular feature... Also, there could be the people downloading the module to modify it to +a or +q users on join.

> b) I fail to see why +q is needed when joining, short of networks w/o services.

When this feature is implemented, I'll probably have it set to +q people. If the channel isn't registered, it makes perfect sense the first person in would be the founder.

Trocotronic

2007-07-20 14:58

reporter   ~0014540

Done. Directive level-on-join <levels> to set default levels. You can also leave it empty to give no level. It's doc'd.

I also fixed some bugs. I also doc'd nick-length directive.

2007-07-20 14:58

 

levelonjoin.patch (12,105 bytes)

nate

2008-02-12 06:06

reporter   ~0015119

Implemented in 3.3 dev codebase (.262)

Issue History

Date Modified Username Field Change
2007-04-30 04:41 Shining Phoenix New Issue
2007-04-30 05:01 syzop Note Added: 0013942
2007-04-30 05:01 syzop Status new => acknowledged
2007-04-30 09:47 WolfSage Note Added: 0013946
2007-04-30 10:04 syzop Note Added: 0013948
2007-04-30 10:28 WolfSage Note Added: 0013951
2007-04-30 11:02 syzop Note Added: 0013952
2007-04-30 22:24 Shining Phoenix Note Added: 0013959
2007-05-01 06:45 Shining Phoenix Note Edited: 0013959
2007-05-02 18:29 aquanight Note Added: 0013981
2007-05-02 20:43 Stealth Note Added: 0013982
2007-05-02 21:19 Shining Phoenix Note Added: 0013985
2007-05-02 22:13 aquanight Note Added: 0013986
2007-06-10 11:29 tabrisnet Note Added: 0014305
2007-06-10 16:25 Stealth Note Added: 0014313
2007-07-20 14:58 Trocotronic Note Added: 0014540
2007-07-20 14:58 Trocotronic File Added: levelonjoin.patch
2008-02-12 06:06 nate Note Added: 0015119
2008-02-12 06:07 nate Status acknowledged => assigned
2008-02-12 06:07 nate Assigned To => nate
2008-02-12 06:07 nate QA => No need for QA
2008-02-12 06:07 nate U4: Need for upstream patch => No need for upstream InspIRCd patch
2008-02-12 06:07 nate Status assigned => resolved
2008-02-12 06:07 nate Fixed in Version => 3.3-alpha0
2008-02-12 06:07 nate Resolution open => fixed