144037 - /mode and /oper should be recognized by Chatzilla

Status: VERIFIED FIXED

(Other Applications Graveyard :: ChatZilla, defect)

Description

[Garth Wallace]

Currently, Chatzilla responds to /mode and /oper commands with "Unknown command
''mode'', just guessing" and "Unknown command ''oper'', just guessing",
respectively. Since both MODE and OPER are implemented on most (all?) IRC
servers, this oversight seems particularly odd and looks sloppy. MODE is used
for almost all basic channel operation, and OPER is used by IRCops to identify
themselves.

Neither command requires any special processing beyond suppressing the error
message.

Comment 1

[Samuel Sieb]

*** Bug 152954 has been marked as a duplicate of this bug. ***

Comment 2

[Tague Griffith]

Attachment: fix for bug #152954 - implments chanmode command to change channel modes

Implements a chanmode command to change the togglable channel modes

Comment 3

[Garth Wallace]

Just wondering, why "chanmode"? Why not just fix "mode"?

Besides, the MODE command is used to change user modes as well as channel modes,
so "chanmode" is a bit of a misnomer as well as being longer than it should be.

Comment 4

[Tague Griffith]

i used /chanmode instead of /mode since it doesn't implement the ircii /mode
command and could be confusing to irc users.  i implemented functionality which
is missing for my day to day work, feel free to run with the code and implement
the full /mode command.

Comment 5

[Samuel Sieb]

*** Bug 180575 has been marked as a duplicate of this bug. ***

Comment 6

[:Gijs (he/him)]

Attachment: implements /mode using raw MODE, no syntax check whatsoever

In the current version of CZ, using /raw MODE or /MODE doesn't give any errors.
As some people in #chatzilla figured it'd be useful to have it use the current
channel, nick or user (in a query view) if the user failed to mention any, I
wrote this little thing. It'll implement /mode, but it does no syntax checking
whatsoever, so anyone using it should know how to use mode themselves. The pro
is that this doesn't 'block' any commands that specific server systems might
support, while other servers might not.

It's a plugin because I'm too much of a newbie too create a patch. I'll try my
hand at it when I have more time.

Comment 7

[James Ross]

*** Bug 271251 has been marked as a duplicate of this bug. ***

Comment 8

[:Gijs (he/him)]

Marking this to block the tracker bug :-).

I would try my hand at this, but I really think bug 282680 needs a fix first.
I'm not sure if everyone agrees though, so I'd like some opinions before marking
this dependant on that bug.

Comment 9

[:Gijs (he/him)]

Attachment: Patch for /oper

Patch to implement /oper. Allows you not to specify the password and enter it in a cen*****sored dialog box instead, for security reasons and whatnot. Patch for /mode coming up as soon as I have more time available, so taking this bug :-).

Comment 10

[:Gijs (he/him)]

Attachment: Same idea, better patch.

Missed a use of the renamed locale strings. Fixed a fromUnicode nit (thanks James!).

Comment 11

[Samuel Sieb]

Comment on attachment 202160 [details] [diff] [review]
Same idea, better patch.

If the password dialog is cancelled, then just abort the command, you don't need to give an error message.  Also the help message needs some work.  What's a "safe alert"?  Yes, *I* know from your description, but what about a user?

Comment 12

[:Gijs (he/him)]

Attachment: [checked in] Patch with a better help text and without thrown error messages

Comment 13

[:Gijs (he/him)]

Attachment: Patch for /mode

Patch for /mode. Syntax-checks the mode string, but doesn't really care about anything else you throw at it. It copes with being used from a channel view without adding the channel name.

Comment 14

[:Gijs (he/him)]

Attachment: [checked in] Patch with a better name for what we're setting a mode on

<tH>	Hannibal: i just remembered, /mode can also be used with user modes, so it'd probably be best to call the parameter <target>

Done.

Comment 15

[:Gijs (he/him)]

Argh. Obviously the one but last hunk should have contained:

+cmd.mode.help   = Changes the channel or user mode of <target> using <modestr> and any subsequent <param> if added. When used from a channel view, <target> may be omitted. For a list of modes you may use, see http://irchelp.org.

instead of an accidental reuse of <channelname>

Comment 16

[Samuel Sieb]

Comment on attachment 202655 [details] [diff] [review]
[checked in] Patch with a better name for what we're setting a mode on

a reminder to whoever checks it in to make that help text change

Comment 17

[James Ross]

Comment on attachment 202260 [details] [diff] [review]
[checked in] Patch with a better help text and without thrown error messages

Do we want to do any more things for /find, or fix the wrap option on toolkit?

Comment 18

[James Ross]

Argh, Bugzilla you suck. That was the OTHER attachment.

Comment 19

[James Ross]

Comment on attachment 202260 [details] [diff] [review]
[checked in] Patch with a better help text and without thrown error messages

This has actually been checked in now.

Comment 20

[James Ross]

Comment on attachment 202655 [details] [diff] [review]
[checked in] Patch with a better name for what we're setting a mode on

Is that it for this bug?

Comment 21

[:Gijs (he/him)]

(In reply to comment #20)
> (From update of attachment 202655 [details] [diff] [review] [edit])
> Is that it for this bug?
> 

I think so, resolving :-).

I would check whether the checkin coped with the better help text, but seeing as LXR is down at the moment, I'll just trust Silver :-).

Oh, fwiw, the dependency on 282680 was somewhat bogus. I thought I'd need the patches there, it turned out I didn't. Sorry!