View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004115 | unreal | ircd | public | 2012-07-06 21:42 | 2015-05-27 21:11 |
| Reporter | katsklaw | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | has patch | Resolution | open | ||
| Product Version | 3.2.9 | ||||
| Summary | 0004115: Add ability to disable chanmodes +qa | ||||
| Description | I've seen this requested before several times and thought I'd make a patch. As the Summary says, this patch allows chanmodes +qa to be disabled. It's done via removing the modes from the channel modes table with a #define settable in config.h When undefined, the ircd returns the typical 472 numeric. The patch also blocks admins from setting chanowner/chanprot as the default level when USE_CHANQA is not defined. Since it's not possible to get chmode +q/a while disabled, this has no effect on PREFIX_QA. Enabled by default for compat. | ||||
| Additional Information | I've tested it and it works for me. Additional testing and checking for completeness would probably be wise ;) Patch created and tested against latest hg checkout. | ||||
| Tags | No tags attached. | ||||
| Attached Files | |||||
| 3rd party modules | |||||
|
|
patch attached. |
|
|
I'm supporting this motion. This should definitely be done. It'll probably break Anope 1.8 assumptions about what UnrealIRCd supports, but I guess that would get sorted out on their end somehow. |
|
|
I can patch 1.8. not sure about 1.9 |
|
|
I doubt there's any need to provide patches for Anope. They'll figure it out soon enough when/if the patch here is accepted. |
|
|
I'm not sure what or if it'll desync if it tries to set a non-existing mode. Perhaps I'll play with that today and see ;) |
|
|
I forgot to mention .. Anope 1.8 assigns ircd features/abilities statically so a patch or a new unreal module that has it disabled is the only complete solution unless Anope can handle 472 err msgs (which I'll test in a few minutes). Not sure about 1.9. |
|
|
1.8 seems to work ok without any patch and new patch also adds a compile flag (Q) so it can be used in deny::version blocks. |
|
|
it should "just work" with Atheme. some flag in PROTOCTL would be nice though so we can disable +q/a flags. |
|
|
I was under the assumption Atheme's +q/a support was completely modular controlled via atheme.conf |
|
|
With this patch if you disable +qa, you can no longer set channel modes u and L? What would be the resolution? Allow all chanops to set +u and +L? I guess so, we have not really a choice... How to do this? Do we make is_chanprot() and is_chanowner() return true for chanops if you disable qa, or do we patch each case individually? If we do the former, does doing so create any new problems? Like would chanops be undeopable because it thinks it's an owner and should be protected? Or is it no problem? etc... Any other things we haven't thought of? (Don't think so?) If you could take a look at this, test things out, and write a new patch, that would be nice :) |
|
|
Also, out of curiousity, why would you want to disable qa in the first place? Personally, +q/+a (among some other channel modes) was my personal reason to choose UnrealIRCd more than 10 years ago. In fact, I was happy that when I introduced the symbols (~ and &) it got even better. I don't mind adding the patch if it's simple & good (see previous comments), but: why would you want to get rid of this? |
|
|
About +u/+L, I can't think of anything requiring +q/+a at the moment, either. It's always bothered me that the modes require +q to set. Seems a bit silly to me. Personally, and this is only my opinion, I think they introduce too much separate rank. It doesn't help that Anope 1.8 forces +q on the founder. I'd say that +q/+a make the channel's staff feel less like a team and more like a company. If you don't trust someone with +o, +h is plenty, especially as restricted as halfops are on UnrealIRCd. Additionally, it feels to me like there have been a lot of efforts to keep UnrealIRCd become more flexible; ~& being hard-coded and required for a couple of channel modes really bother me in that regard. The IRC purists would probably only want to use only +ov anyway, with certain (widespread) services setting +q automatically, that's probably always been work for scripts to automatically unset as well. |
|
|
"Personally, +q/+a (among some other channel modes) was my personal reason to choose UnrealIRCd more than 10 years ago." It's awesome that you added it for your personal reasons. However, not everyone likes +q/a. Not everyone likes what you like. It's all a matter of personal taste, some like it .. some don't. As far as +u/+L goes I didn't take their usage by non-q/a compiles into account because I don't use +u/L either ;P. I suppose an additional check for USE_QA can be added and allow +o to use +u/L if USE_QA is disabled. I agree with CuleX, UnrealIRCd is supposed to be modular yet many things can't be disabled like +q/a/h, encrypted hosts etc. You can't even stop umode +q for netadmins because +N automatically grants unkickability, there is no option. The advantage to modularity is to be able to disable what you don't like. This is the main attraction to ircds like Inspircd. I have a few other things that I'll submit to help make things a bit more flexible and easier to enable/disable. |
|
|
Thanks for explaining CuleX. And actually you are right, halfop was also something I really liked... basically just any additional (chanop-like) access level. katsklaw: Why this tone? "Not everyone likes what you like." ? Well, obviously. You are around for quite some time, so you should know by now, looking at my track record, about the number of features which I pass that I'm not personally in favor of, some I even find plain ugly. I don't mention each time I don't like it myself (why should I?), but I would even go as far as saying that nearly half of the features and behavior changes that get in, I personally am not waiting for. I take the opinion/backing of others very seriously (why else would I ask? see next). It was clear from my post that I would allow this feature in, I was just (as I literally said) curious about the reasons for this request. This has now been answered by CuleX. If you have a problem with having to explain WHY you would want a specific feature or change, then I wonder why you report it in the first place? Normally people who submit a request can explain/argue very well why they want such a change. To everyone: I welcome any patches to make things more modular or at least configurable in areas that you might want to enable/disable. To make all channel modes, user modes, modular is a lot of work. I once modulized about half of the channel modes in the 3.3* branch, so it's possible, but even doing it again (since it's completely outdated) is really a lot of work, personally I don't think I'll ever have time for it again. I'd still like to see it as a long-term objective, but in the meantime being able to configure things through settings will have to suffice. |
|
|
my whole purpose for Icarus was to take unreal and make it more configurable and have done quite a bit to it and can port some of things I did to 3.2.9 and submit them. so I'm very happy you said that ;) I don't have a prob explaining why, it's simple. Not everyone likes +q/a so users should have the ability to disable it. "unkickable" has no place on IRC by some peoples beliefs. |
|
|
If I may add another suggestion, though it may be very overblown... Personally, I've seen these prefix/mode combinations used: (qaohv)~&@%+, (aohv)!@%+, (ohv)@%+, (ov)@+ As you cna see, +a without +q would be prefixed with an exclamation mark instead of an ampersand sign, or at least UltimateIRCd (though discontinued, in use on a large network), ShadowIRCd (though not very common) and euIRCd (though it has +q as well) do it that way, so it might be worth considering disabling only +q OR +a, and if only +q is disabled, change the prefix for +a to !. Just food for thought, it's probably overkill and a gigantic pain, especially if servers on the network, for whatever reason, don't have the same prefix settings. |
|
|
personally I see no need to enable +a without +q since the only difference is +q can +a others. The purpose of this is to prevent chanops from being unkickable and leaving +a will still allow it. However, if more people are in support of separating them I will ;) |
|
|
We currently have set::restrict-usermodes and set::restrict-channelmodes. These settings disable the use of user and channel modes from normal users. Now, it's easy to bypass the channel mode restriction through services MLOCK, for example. Of course if services would implement an option themselves to disable certain channel modes that wouldn't be a problem at all. I've now also learned that some users would like to disable them altogether. For everyone. It seems only logical to create a set::disable-usermodes and set::disable-channelmodes. Perhaps it would be wise to implement this feature request within those settings. To be more precies: if 'a' appears is in set::disable-channelmodes, disable the chanadmin feature and strip it from PREFIXes, and the same for 'q'. I think that would make things more logical, to put it all in one single setting. As for using different prefix symbols, I don't think the symbol for 'a' should change if you disable 'q' or vice versa. And in general, this feature request is not about changing the prefix character. PS: of course in an ideal scenario you wouldn't even load certain channel modes, but that's already discussed in 0004115:0017064, while this is something we can do right now. PPS: it is important that the disabling of channel modes (just like the loading of any additional channel mode module) is the same on all servers on one network. this should be mentioned in the documentation with this feature. for set::restrict-* it would only cause 'odd' situations, while with set::disable-* it will actually cause desynchs and trouble. |
|
|
I skimmed through this a bit, it seems like it would be easier to remove all the IS_CHANOWNER/IS_CHANPROTECT and replace them with whatever the check for +o is. Then worry about removing the modes or making them configurable. |
|
|
This needs to be tabled in light of user/channel modes being modulized in 3.4 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2012-07-06 21:42 | katsklaw | New Issue | |
| 2012-07-06 21:42 | katsklaw | File Added: use_chanqa.patch | |
| 2012-07-06 22:12 | katsklaw | Note Added: 0017031 | |
| 2012-07-06 22:12 | katsklaw | Status | new => has patch |
| 2012-07-10 07:25 | CuleX | Note Added: 0017043 | |
| 2012-07-10 09:19 | katsklaw | Note Added: 0017044 | |
| 2012-07-10 14:33 | CuleX | Note Added: 0017045 | |
| 2012-07-10 16:58 | katsklaw | Note Added: 0017046 | |
| 2012-07-10 21:27 | katsklaw | Note Added: 0017047 | |
| 2012-07-10 23:00 | katsklaw | File Added: use_chanqa-2.patch | |
| 2012-07-10 23:01 | katsklaw | Note Added: 0017048 | |
| 2012-07-23 07:56 |
|
Note Added: 0017052 | |
| 2012-07-25 03:16 | katsklaw | Note Added: 0017055 | |
| 2012-08-11 09:55 | syzop | Note Added: 0017057 | |
| 2012-08-11 09:59 | syzop | Note Added: 0017058 | |
| 2012-08-11 11:24 | CuleX | Note Added: 0017061 | |
| 2012-08-11 22:03 | katsklaw | Note Added: 0017062 | |
| 2012-08-11 22:10 | katsklaw | Note Edited: 0017062 | |
| 2012-08-12 11:17 | syzop | Note Added: 0017064 | |
| 2012-08-14 10:32 | katsklaw | Note Added: 0017067 | |
| 2012-08-18 10:06 | CuleX | Note Added: 0017095 | |
| 2012-08-23 21:26 | katsklaw | Note Added: 0017107 | |
| 2012-08-27 20:39 | syzop | Note Added: 0017108 | |
| 2013-01-09 10:52 | syzop | Relationship added | related to 0003647 |
| 2013-01-30 12:16 | ShawnSmith | Note Added: 0017404 | |
| 2015-05-27 21:11 | katsklaw | Note Added: 0018371 |
