View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003575 | unreal | ircd | public | 2008-01-08 22:18 | 2011-12-29 20:53 |
| Reporter | Celelibi | Assigned To | syzop | ||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | fixed | ||
| Product Version | 3.2.7 | ||||
| Summary | 0003575: List ops with /mode #chan +o | ||||
| Description | Hi, It's possible to get list of owners/protect in the chan with /mode #chan +q or +a. But it don't work with +o, +h or +v. | ||||
| Additional Information | After reading of the source code of unrealircd 3.2.7, this just seems to be not implemented. | ||||
| Attached Files | ohv_mode.patch (4,410 bytes) vho_mode_list-3_2.patch (3,458 bytes) unreal-3575.diff (4,596 bytes) unreal-3575-2.diff (4,596 bytes) | ||||
| 3rd party modules | |||||
|
|
Simple rip from the way the /mode $chan [+q|+a] works, tested and functional. |
|
|
Implemented in 3.3 dev codebase (.249) |
|
|
I would say, who cares, but.. since there's already a patch.. why not re-port it? |
|
|
new patch, based on latest 3.2 in Hg |
|
|
vho_mode_list-3_2.patch: Bad patch, it uses is_chanprot for all 3 modes instead of is_chan_op, is_halfop, has_voice. I don't have 3.2.9RC2 installed or I'd repatch, sorry. |
|
|
Was looking into this and.. hmm.. I'm not too happy with the numerics that are being used. First, it seems there's not really an existing numeric, as "no" other ircd implements it. Googling on the the numeric name/id found only some java ircd. Second, the numeric is in the 5xx range, while 4xx and 5xx are meant for errors (ok, at the end of 5xx I added three RPL_'s). This gives me second-thoughts, is this really worth introducing 4 new numerics? Will anyone actually use this feature? Given that all the info is already available through NAMES(X). IIRC the original reason to implement the q/a list was because we had not implemented prefixes yet, so there was no way to see who was +q/+a unless you happened to see the MODE +a/+q when they received it. Nowadays all this info can normally be seen, unless you compile without prefixes. Anyway, for +v/+h/+o I don't really see a use? Comments are welcome. |
|
|
I can see this used by CLI clients that don't use/have a nick list and perhaps on large channels to list ops only and the like. NAMES orders nicks by join time, not status or alphabetical so listing all the chanops in a 100+ channel with NAMES could be challenging. I could re-do the patch to use better numerics and fix the issue I stated then resubmit but it'll be later this weekend. |
|
|
unreal-3575.diff: Used 653-658 for RPL_* 200-399 is rather full and couldn't find 6 numerics in a row empty. Fixed checks from vho_mode_list-3_2.patch. compiled and tested without issues on latest hg |
|
|
unreal-3575-2.diff: Fixed issue with src/s_err.c displaying wrong numeric. |
|
|
Trying to come up with new numerics and implementing this when there is no precedent for it in other IRCds doesn't seem to nice for me. Not sure if this idea makes any sense, but maybe /who could be expanded to support this. It already has its own numeric and each response line and conveys the same information similar to how NAMES conveys that information, and UnrealIRCd's WHO has the special parameters like +c which could be expanded. Maybe something like: WHO +C @#unreal-support to list all ops on #unreal-support, and WHO +C ~#unreal-support for +q people and WHO +C ~&@%+#unreal-support for everybody except for the undecorated. |
|
|
I like that idea better as well. With regards to that: we can also use the existing +c instead of a new +C, as I don't see the new functionality causing any conflict. |
|
|
I guess uniformity isn't even a factor then? modes +b,q,a and perhaps E already follow an established pattern that's been in place for years. I'm all for reserving numerics since there are a limited number of them, but I'd rather see this feature not included than for users to have to remember something as complicated as half the modes can be checked one way and the other half a completely different way. Having half in /mode and the other half in /who seems sloppy and just hacked together without careful thought. In my humble opinion, all mode lists should be done via the /mode command as its been done with +b for nearly 2 decades. Lets keep things simple and uniform by keeping all mode lists in /mode where it belongs. |
|
|
I still don't see a good reason as to why to implement this. The way I see it, it seems that it went like 'oh, it seems I can list X, but not Y, so let's implement that cause it seems they forgot', I'm not saying that's an illogical conclusion, but the question still remains.. is there any need? I've already explained (note 0003575:0016825) why it was added for q/a (though it's no longer the case), the principle is: for these modes you need(ed) to be in the channel in order to see on who they got set. The same is true for b/e/I, otherwise you can't know on who/what they were set. It's not true for v/h/o (and a/q nowadays), as you see those in NAMES(X). The only comment as to 'why' it could be useful was: [quote]I can see this used by CLI clients that don't use/have a nick list and perhaps on large channels to list ops only and the like.[/quote] Clients should maintain their own nick list, like pretty much all clients do: use the NAMES reply for initial status, and then add users on join and delete them on kick/quit/part. IMHO we should not encourage client developers to 1) not maintain such a list, and 2) instead increase server load for all kinds of operations because they are lazy. What ohnobinki suggested was using a different way, but sorry for being blunt, but it almost sounds like you're not interested in that? Which makes me wonder, is this really about the functionality, or is this about making something 'complete', which as I already pointed out - see first part of my comment - is not 'incomplete', as v/h/o have no need to be listed like this as you already get them by NAMES(X). I know you worked on the patch, but in the end it's all about whether a feature enhancement is needed (ok, and the quality of the patch). I'm sorry for starting the confusion in comment 0003575:0016718, I was scanning over 100 bugids and didn't really read all the details on this one. |
|
|
Not all client display a nicklist to users. Ircii, one of if not the oldest among them. Such clientsa will print a nicklist into the screen buffer that soon vanishes. For GUI clients this isn't a problem at all. NAMES is just simply horrid on large channels. I don't think binki's idea is bad. Its quite good to be honest if such a list didn't exist before now. However, this isn't a new feature, it's extending an existing one and having qa in mode and ohv in who will cause confusion and so will moving qa to who. Personally, I'm not worried if this gets implemented or not because I've already patched it in Icarus. I just think that a solution other than names should exist and since +qa already exists in /mode, ohv should too. If you still don't see the need, then close the bug and move on. It's not going to affect me one way or another because I don't use stock Unreal, I use my own fork. :) |
|
|
Personally I use irssi. When you do /names it shows the current nicklist (it doesn't actually send NAMES to the server). It also has /names -ops, /names -halfops, and so on. Just to mention a text mode client that implements this. IMO it's logical to do such (basic selective listing) on the client-side. Ok, understood. Now I'm not sure if we should do the WHO flag or not. We can either close the bug, or rename it and see if anyone finds it useful and provides a patch for the WHO +c functionality. I'm fine with either one. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2008-01-08 22:18 | Celelibi | New Issue | |
| 2008-01-24 05:01 | nate | File Added: ohv_mode.patch | |
| 2008-01-24 05:02 | nate | Note Added: 0014981 | |
| 2008-02-08 20:50 | nate | Status | new => assigned |
| 2008-02-08 20:50 | nate | Assigned To | => nate |
| 2008-02-08 20:51 | nate | QA | => No need for QA |
| 2008-02-08 20:51 | nate | U4: Need for upstream patch | => No need for upstream InspIRCd patch |
| 2008-02-08 20:51 | nate | Status | assigned => resolved |
| 2008-02-08 20:51 | nate | Fixed in Version | => 3.3-alpha0 |
| 2008-02-08 20:51 | nate | Resolution | open => fixed |
| 2008-02-08 20:51 | nate | Note Added: 0015053 | |
| 2011-07-19 18:09 | syzop | Note Added: 0016718 | |
| 2011-07-19 18:09 | syzop | Assigned To | nate => |
| 2011-07-19 18:09 | syzop | Status | resolved => needs re porting |
| 2011-07-20 15:20 | nate | File Added: vho_mode_list-3_2.patch | |
| 2011-07-20 15:22 | nate | Note Added: 0016725 | |
| 2011-07-20 15:22 | nate | Status | needs re porting => has patch |
| 2011-08-04 06:40 | katsklaw | Note Added: 0016736 | |
| 2011-12-25 13:12 | syzop | Note Added: 0016825 | |
| 2011-12-25 13:12 | syzop | Status | has patch => feedback |
| 2011-12-25 20:17 | katsklaw | Note Added: 0016836 | |
| 2011-12-27 17:38 | katsklaw | File Added: unreal-3575.diff | |
| 2011-12-27 17:42 | katsklaw | Note Added: 0016839 | |
| 2011-12-28 00:32 | katsklaw | File Added: unreal-3575-2.diff | |
| 2011-12-28 00:33 | katsklaw | Note Added: 0016840 | |
| 2011-12-29 00:01 | ohnobinki | Note Added: 0016842 | |
| 2011-12-29 13:52 | syzop | Note Added: 0016843 | |
| 2011-12-29 14:07 | katsklaw | Note Added: 0016844 | |
| 2011-12-29 19:25 | syzop | Note Added: 0016845 | |
| 2011-12-29 20:28 | katsklaw | Note Added: 0016846 | |
| 2011-12-29 20:50 | syzop | Note Added: 0016847 | |
| 2011-12-29 20:53 | syzop | Status | feedback => closed |
| 2011-12-29 20:53 | syzop | Assigned To | => syzop |
| 2011-12-29 20:53 | syzop | Fixed in Version | 3.3-alpha0 => |
