Hello,
I found a bug with the new Quiet List.
When clicking on the "Quiets" button, all of the other buttons (Bans / Excepts etc) become gray and can not click on them.

Thanks for your bug report. When you click any of the list buttons, mIRC disables all of them, sends a requests to the server for the list and waits for a reply. If the buttons are not re-enabled, this means mIRC has not received a reply from the server.

On which IRC network do you see this issue?

If you enable debugging with /debug on (which outputs to a debug.log file), what does it show when you click on the quiet button?

Thank you for your reply. It's strange it speaks to me about the owner list when I click on the button "Quiets"
I'm on the server irc.skyrock.net

-> ircd02.skyrock.net MODE #! +q
<- :ircd02.skyrock.net 386 teo #! KwiZ
<- :ircd02.skyrock.net 386 teo #! Air
<- :ircd02.skyrock.net 387 teo #! :End of Channel Owner List

On Unrealircd +q is owner mode.

Thanks. As Wims pointed out, +q on UnrealIRCd is for owner mode. This conflicts with the use of +q for the quiet list on other networks. As 'q' is listed in CHANMODES for this network, there is no way for mIRC to know in advance if it represents the quiet or owner list. mIRC has to assume it represents the quiet list. I have added a check so that if mIRC sends a MODE +q lookup and it receives numerics 386/387, it will ignore them but re-enable the quiet list button. This will be in the next beta.

This is one of the reasons I held back from adding quiet list support to channel central. mIRC now has to handle six numerics in order to be able to support the quiet list. Two numerics are definitely quiet list numerics, two may or may not be depending on context, and two are not. Let's hope this change now covers all of the numerics.

Update: UnrealIRCd also sends MODE +q owner events, which mIRC uses to fill the quiet list. As there is no way to distinguish between owner/quiet events, the only (bad) solution left is to resort to detecting the server ircd in numeric 004 and disabling quiet list support if it is UnrealIRCd. This will also be in the next beta.

Great
Thanks Khaled ^^

Hello. I hope I don't look dumb, but UnrealIRCD clearly shows "PREFIX=(qaohv)~&@%+" in the connection phase.

Could use that to differentiate between Owner and Quiet modes.

And over on freenode, "MAXLIST=bqeI:100" is in the connection phase, which denotes how large the lists can get.


Both appear to be in numeric 005. Hope this helps!

I'm experiencing the same problem on an InspIRCd server which also uses +q as owner/founder mode. But not on another InspIRCd server. The issue is most likely that this specific InspIRCd server has no prefix symbol configured for the mode on purpose in the 005 message, even though they use this mode. It is done on purpose to still be able to have +q set while not appearing opped to users in the nickname list, as they are also not +o, so to mingle among the plebs if you will. So its still possible to issue ops/owner-only commands (InspIRCd allows for such a configuration, while other IRCds may require both +q and +o to be set on the user).

This server has: PREFIX=(ov)@+ STATUSMSG=@+

However, InspIRCd does have similar functionality for quiet bans, in the form of a module called "muteban", but it does not implement its own mode, but implements an extended ban instead, of which the syntax is:
"m:nick!user@host" e.g.: /MODE #channel +b m:nick!user@host

Of course, due to how this works, mutebans currently show up in the regular ban list among regular bans.

I also realize that due to how this works and due to InspIRCd's flexibility (e.g. the ability to disable the prefix symbol), it may not be possible to solve this issue cleanly, but wanted to report this anyway.

However, InspIRCd does report this by showing the letter m in the 005 message as follows if the module is loaded:
EXTBAN=,CNORSTUmrz

So maybe this information can be used by mIRC after all to look at the combination of it being an InspIRCd server and it also advertising EXTBAN with the letter m in it, and make the Quiets button work as intended (though this would require extra work/code to split all bans starting with "m:" into their own list), or to simply keep the button disabled and preventing this issue (probably the best).

Just thinking out loud here.