This affects both ChatZilla and Konversation. It happens "almost every time, with unpredictable exceptions" (considering the ~ vs. & vs. @ behaviour described below as "good" and always-@ as "bad"). In ChatZilla, channel owners are sometimes shown in the sidebar with a tilde, or maybe a swung dash (which IIUC means "channel owner") but usually with an @ (meaning "channel op"). Channel admins are in the same circumstances shown (rarely) with & ("channel admin"), (usually) with @ In Konversation, chanops have a green "O" icon in the sidebar, but a yellow one if they are known to be admins or owners. AFAICT, this yellow icon appears (a) when ChatZilla is displaying "~" or "&" rather than "@"; (b) when the concerned nick joined the channel "not earlier than we did". Also in Konversation, when an owner joins, the message is usually: --> somenick has joined this channel (somenick@EA6494FA.34B248F4.A9371869.IP). *** ChanServ sets a quiet on somenick *** ChanServ gives channel operator privileges to somenick but rarely --> somenick has joined this channel (somenick@EA6494FA.34B248F4.A9371869.IP). *** ChanServ gives channel owner privileges to somenick *** ChanServ gives channel operator privileges to somenick (notice the difference in the middle line). ChatZilla does not translate the mode message, giving (also for an owner) -->| somenick(somenick@EA6494FA.34B248F4.A9371869.IP) has joined #somechannel =-= Mode #somechannel +qo somenick somenick by ChanServ in all cases, but, as said above, the icon in the sidebar is not always identical. I don't know what makes a difference; maybe the particular server to which I am connected, but since it has happened to me to get sand.m.o (the farthest possible server, in California) when trying to connect to gravel.m.o (in Amsterdam, a few hundred kilometers from my hometown of Brussels) I don't know how to test this hypothesis: AFAIK which one of the five servers I get (gravel, concrete, sand, concrete2 or dust) is random, unrelated to the particular *.mozilla.org IRC URL I'm trying to connect to. Random but not equally distributed, BTW: I usually get concrete or sand; less often gravel or dust; I'm not sure I ever got concrete2 (evidence from the MOTD and from netsplit messages is not 100% in agreement).
digi, did the prefixwhatever option get incorrectly set on certain servers?
P.S. Comment #0 assumes "ChatZilla → Preferences → Appearance → User list → Show user mode symbols" in ChatZilla and "Settings → Configure Konversation → Interface → Nicklist Themes → Big Bullets ("Big Bullets" by Dario Abiatianni)" in Konversation
Assignee: server-ops → infra
Component: Server Operations → Infrastructure: Other
Product: mozilla.org → Infrastructure & Operations
QA Contact: shyam → jdow
Unsure if there's any action from us here.
:reed We rolled all irc related changes back, so we're still running the same code base that we were prior to the irc maintenance. Unless the original requestor can demonstrate that this is a server side issue I think this is a bug in ChatZilla. I have used irssi and weechat on irc.m.o and I have not observed any inconsistency with channel mode reporting. :tonymec If you can provide additional information demonstrating that our ircd is sending inconsistent messages to your client (such as in a packet capture) we can move forward with this bug report.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → INCOMPLETE
In reply to comment #4: My notion that the bug was on the server comes from circumstantial evidence, viz., that both ChatZilla and Konversation react the same way, only rarely displaying statuses higher than "operator" in the sidebar. In fact I've seen them only a few times shortly before reporting this bug, then (still before reporting this bug) it went back to "never": I would expect channel admins and channel owners to have a different icons than @ (operator) but they don't. Nowadays Konversation is broken on this system so I can't compare them anymore. If you thought this was a bug in ChatZilla you should have moved to the appropriate Product/Component for ChatZilla rather than closing the bug. And no, nowadays the display is consistently bad, and I don't know how to do packet capture.
Assignee: infra → rginda
Status: RESOLVED → REOPENED
Component: Infrastructure: Other → ChatZilla
Product: Infrastructure & Operations → Other Applications
QA Contact: jdow
Resolution: INCOMPLETE → ---
Version: other → Trunk
(In reply to Tony Mechelynck [:tonymec] from comment #5) > If you thought this was a bug in ChatZilla you should have moved to the > appropriate Product/Component for ChatZilla rather than closing the bug. And > no, nowadays the display is consistently bad, and I don't know how to do > packet capture. I apologize for not triaging this more appropriately when I saw the RESO INCO earlier - I've only been working here for three years and didn't realize that ChatZilla was a product that we are responsible for! Thank you for correcting our misunderstanding on that point. (In reply to Tony Mechelynck [:tonymec] from comment #0) > In ChatZilla, channel owners are sometimes shown in the sidebar with a > tilde, or maybe a swung dash (which IIUC means "channel owner") but usually > with an @ (meaning "channel op"). Channel admins are in the same > circumstances shown (rarely) with & ("channel admin"), (usually) with @ If you try joining a channel that you're owner on and repeatedly flipping the +o/-o and +q/-q bits in various combinations on yourself, does Chatzilla correctly reflect the status at every step? Does it ever desynchronize and fail to reflect ownership in the manner described here? I'm not familiar with the admin status, but a similar test involving op, owner, and/or admin would be useful data to collect regarding this issue. > Also in Konversation, when an owner joins, the message is usually: > > --> somenick has joined this channel > (somenick@EA6494FA.34B248F4.A9371869.IP). > *** ChanServ sets a quiet on somenick > *** ChanServ gives channel operator privileges to somenick > > but rarely > > --> somenick has joined this channel > (somenick@EA6494FA.34B248F4.A9371869.IP). > *** ChanServ gives channel owner privileges to somenick > *** ChanServ gives channel operator privileges to somenick Which version of Konversation were you using when these results occurred? It has encountered a bug in the past specifically related to +q handling, where at one point they were mistakenly reporting "+q Type A" modes as "owner" rather than "quiet", and have since corrected that handling to report +q as quiet more often - which is entirely correct on Charybdis IRCd but entirely incorrect on Unreal IRCd. The Konversation docs do not indicate any ability to differentiate between the use of +q modes to mean different things , however their bug tracker does indicate that they continue to have open outstanding issues, as of their latest release, with +q mode handling ; however, they do not have any open bugs related to our IRC network, so I presume they would be interested in both in your report that Konversation is somehow failing with our system, and that you continue to experience inconsistent handling of +q on our network .  http://docs.kde.org/development/en/extragear-network/konversation/serverlist.html  https://bugs.kde.org/show_bug.cgi?id=139591 I will keep an eye out personally to see if irssi ever has issues reporting owner status accurately - it's been working well for me for the past couple years, and none of my channels use admins, but we do have a few owners now and then.
So, ChatZilla has some hard-wired knowledge of +v (voice), +h (halfop), +o (op), +a (admin) and +q (founder). If you use those modes with those meanings, you'll get the best experience (i.e. correct colour blobs or symbols in the userlist). However, ChatZilla supports any combination of letters/symbols for the user modes and will always sort the userlist correctly based on those available and used by a network, as long as the network is not misconfigured. The usual misconfiguration that would cause admin and founder to not be reported is having the 005 message (RPL_ISUPPORT) sent to the client with PREFIX=(ohv)@%+ which declares that only voice/halfop/op is used. The current PREFIX on sand and concrete (I can't connect to concrete2) is (ovh)@%+ so the whole Mozilla network is currently declaring that it does not support or use admin and founder statuses. You will therefore not get any behaviour in the userlist if you set +a or +q on them (no special sorting nor symbols/icons). There was a period, in June 2013, when this was not so consistent. I had a conversation in #chatzilla with Gijs, who'd noticed on the 19th June 2013 that he was seeing admin and founder statuses in the userlist, but I was not. We checked all the servers at the time and found: concrete PREFIX=(ohv)@%+ concrete2 PREFIX=(qaohv)~&@%+ gravel PREFIX=(qaohv)~&@%+ sand PREFIX=(qaohv)~&@%+ This was only a brief misconfiguration I believe, since I have no further records of the admin/founder-enabled version after 21st June 2013. But during that period, admin (+a) and founder (+q) modes would have been enabled in ChatZilla on 3 of 4 Mozilla servers.
(In reply to James Ross from comment #7) > The usual misconfiguration that would cause admin and founder to not be > reported is having the 005 message (RPL_ISUPPORT) sent to the client with > PREFIX=(ohv)@%+ which declares that only voice/halfop/op is used. > > The current PREFIX on sand and concrete (I can't connect to concrete2) is > (ovh)@%+ so the whole Mozilla network is currently declaring that it does > not support or use admin and founder statuses. You will therefore not get > any behaviour in the userlist if you set +a or +q on them (no special > sorting nor symbols/icons). Confirmed. It turns out that enabled PREFIX_AQ requires recompiling the IRC daemon, which is not a simple (or, so far, successful) task. > There was a period, in June 2013, when this was not so consistent. I had a > conversation in #chatzilla with Gijs, who'd noticed on the 19th June 2013 > that he was seeing admin and founder statuses in the userlist, but I was > not. We checked all the servers at the time and found: > concrete PREFIX=(ohv)@%+ > concrete2 PREFIX=(qaohv)~&@%+ > gravel PREFIX=(qaohv)~&@%+ > sand PREFIX=(qaohv)~&@%+ It turns out that, for some unexpected reason, our IRC admins decided years ago to say "no" to PREFIX_AQ support, and when we attempted to upgrade the IRC network to newer versions earlier this year, we accepted the default of "yes", causing inconsistent handling of the PREFIX values. > This was only a brief misconfiguration I believe, since I have no further > records of the admin/founder-enabled version after 21st June 2013. But > during that period, admin (+a) and founder (+q) modes would have been > enabled in ChatZilla on 3 of 4 Mozilla servers. Unfortunately, we were unable to stabilize the IRC network with a mix of old and new servers, and so all changes were reverted back to the current PREFIX=(ohv) support. Thank you for helping us identify the root cause of this issue. I'm going to take this back to our queue, since it was our misconfiguration of the IRC servers, and mark the bug as RESOLVED INCOMPLETE; we're no longer reporting the (qaohv) statuses, but we are also not currently working on upgrading the IRC servers. In our particular queue, 'INCOMPLETE' indicates that we would like to complete this, but cannot yet - that is the case here as well, since it would be ideal to have PREFIX_AQ enabled. It is possible that Chatzilla or other clients may still choose to report users as having +q/+a statuses when the modes are set while you are joined to a channel - however, we have no control over that client behavior, If this issue reoccurs in the future, please collect the following information before reopening the bug so that we are able to help you further -- and verify that PREFIX=(qaohv), rather than PREFIX=(ohv), is reported by at least one of the servers. 1. Run /LINKS to collect a list of active servers on the network. 2. Run /VERSION <servername> for each server listed to collect a list of their advertised 005 configurations. If all servers report PREFIX=(ohv), please do not reopen this bug; we are aware of the desire to support +q/+a, and it is certain that someday we will (as a side effect of upgrading our IRC network) reenable +q/+a support in a more consistent fashion. James, Tony, thanks for your help and patience as we worked through these IRC issues. It provides valuable insight into undocumented decisions made years ago that are not immediately apparent to our team as we maintain it.
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago → 5 years ago
Resolution: --- → INCOMPLETE
Assignee: rginda → infra
Component: ChatZilla → Infrastructure: Other
Product: Other Applications → Infrastructure & Operations
QA Contact: jdow
Version: Trunk → other
In reply to comment #6: The current (and nonfunctional) version of konversation on this openSUSE system seems to be some patchlevel of 1.4; rpm and YaST apparently disagree about which exact SuSE patchlevel it is. In any case the version with which I fleetingly saw owner/admin statuses in the sidebar was no later than this.
In reply to comment #7: Yes, "at some time in the 2nd half of June 2013, but not on all servers" jibes with me seeing it "sporadically at some point before 1st July 2013" according to the date of comment #0, and then no more.
You need to log in before you can comment on or make changes to this bug.