View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003495 | unreal | ircd | public | 2007-08-01 15:45 | 2007-09-17 18:35 |
| Reporter | SNU | Assigned To | |||
| Priority | normal | Severity | tweak | Reproducibility | N/A |
| Status | closed | Resolution | wont fix | ||
| Product Version | 4.0-devel | ||||
| Summary | 0003495: [req] "own" Usermode by default ( /mode +-xyz) | ||||
| Description | As you provided /mode #chan +L #whereelse without +l 1 I thought you also could make that "/mode +-xyz" is the same as "/mode <ownnick> +-xyz" So if no nick or Channel is provided the own nick alsways will be used. I think that will be no real problem and makes live easier on irc :D The real idea came whan I installed "deny private messages" introducing mode D Now Im used to do /mode SNU +-D maybe it might be more comfortable only to do /mode +-D | ||||
| 3rd party modules | |||||
|
|
... but that's not how the protocol works. Simple solution: alias "umode" { format "^$" { type real; command "mode"; parameters "%n"; }; format "^.+$" { type real; command "mode"; parameters "%n %1-"; }; type command; }; |
|
|
Its not really a sane idea. As Bugz pointed out thats the good solution. Or even make an IRCd alias (instead of client) or w/e...anyway..i'll set to feedback to see what others thing |
|
|
+ and - never prefix a nickname/channel when changing its modes, so adding this feature shouldn't break anything. OR, we could make umode2 a supported(i.e. in documentation) command, and tweak it so you can use it to change server notice masks too. |
|
|
Not really a point in tweaking umode2, as there is not an alias option for umode. As I already mentioned, the protocol specifically defines the MODE command to require at least 1 parameter, which is the channel or nick. The seconds parameter is the modes requested. |
|
|
"Not really a point in tweaking umode2, as there is not an alias option for umode." - I don't get the connection between alias and umode in that sentence, please explain :) Protocol says what we can send and expect to work. It doesn't stop the receiver from being able to understand some non-protocol stuff as well. |
|
|
not for unreal3 at least, I'm not in favor of it. no need, and can confuse things if typed in like.. a channel window. unless u4 takes this, this can be closed. EDIT: version field updated to u4, i don't want to see this issue on my screen anymore... |
|
|
So lets look at an extreme example: MODE +x Believe it or not, this on other ircds is a request for the mode of channel +x. So your statement that +/- don't prefix nick/channel is partially false. But the result will always be empty (assuming the IRCd doesn't just tell you off) because +chan are modeless channels per RFC281X (which only IRCnet follows 100%, but it's probably not the only ircd with +modeless channels). Also, as far as optional parameters go in protocol, the only parameters in IRC that appear as optional are ones that are at the end. For example: QUIT, PART, KICK - These use some default value if the optional reason parameter (which is at the end, and a longparam at that). MODE, TOPIC - Leaving out the modestring or newtopic parameters gives you the current values. Note in this case modestring can be optional because mode parameter required-ness is conditional on what modes are being changed. Also note in all those cases, only the final parameter is actually optional. There's little precedent for more than 1 optional parameter. Some exceptions are the *line commands, which allow you to leave out reason and expire-time. The extreme case of /*line and /spamfilter allowing the use of *no* parameters to get a list isn't an example of everything being optional. It's closer to C++'s function overloading, concept-wise. Finally, there is certainly no precedent for "skipping" a parameter without some placeholder. Take gline for example: both expire and reason fields are optional. But if you want to give a reason, you must also give an expire, else it'll eat the first word of your reason for it. Not even IRCu's "backwards read" method can deal with this, because "/gline a@b go away lamer" becomes "/gline", "a@b", "go", "away lamer", due to gline's MAXPARA being 3. Unless the client puts a : in front of the reason field (which most won't by default as they don't handle /gline since it's a non-RFC command), unreal can't know that the 2nd parameter was supposed to be a number until it's too late and the parameter list has already been split. This same thing is why spamfilter makes you use "-" as a placeholder for parameters that aren't applicable (tkltime for non-tkl actions, or tkltime and reason for removing spamfilters) - it can't know where the spamfilter should start until the parameter list has already been split. But wait: it gets better. Now most people probably don't use this particular feature, but in processing the mode string, there is assumed a leading + (and an explicit one just confirms that assumption). Eg: MODE #chan +l 3 and MODE #chan l 3 will do exactly the same (it'll set the limit to 3). So now while a leading + or - will make it obvious (exception: + and modeless chans clash, see above), if the implicit + method is used, MODE will have no way to tell that you didn't really mean to try to get the usermode of someone with the nick "iwxsqetc", even though that operation might fail because that nick doesn't exist or isn't you. Bugz gave the perfect example of how to deal with the apparent redundancy in MODE (make an alias). That alias works for unreal3. Unreal4 uses a slightly different approach: alias { text "UMODE"; replace "MODE $nick $2-" }; (or insp-style: <alias text="UMODE" replace="MODE $nick $2-">) In summary: this would complicate the code immensely, for something a simple addition (indeed, a copy-paste job - we just gave you the answers!) to the config file would solve. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2007-08-01 15:45 | SNU | New Issue | |
| 2007-08-01 17:25 | Stealth | Note Added: 0014653 | |
| 2007-08-01 21:34 | Bricker | Note Added: 0014654 | |
| 2007-08-01 21:34 | Bricker | Status | new => feedback |
| 2007-08-02 02:02 | Shining Phoenix | Note Added: 0014655 | |
| 2007-08-02 10:15 | Stealth | Note Added: 0014656 | |
| 2007-08-03 01:48 | Shining Phoenix | Note Added: 0014658 | |
| 2007-09-06 12:42 | syzop | Note Added: 0014759 | |
| 2007-09-13 05:13 | syzop | QA | => Not touched yet by developer |
| 2007-09-13 05:13 | syzop | U4: Need for upstream patch | => No need for upstream InspIRCd patch |
| 2007-09-13 05:13 | syzop | U4: Upstream notification of bug | => Not decided |
| 2007-09-13 05:13 | syzop | U4: Contributor working on this | => None |
| 2007-09-13 05:13 | syzop | Product Version | 3.2.8 => 4.0-devel |
| 2007-09-13 05:13 | syzop | Note Edited: 0014759 | |
| 2007-09-17 18:35 | aquanight | Note Added: 0014781 | |
| 2007-09-17 18:35 | aquanight | Status | feedback => closed |
| 2007-09-17 18:35 | aquanight | Resolution | open => wont fix |
