View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001503 | unreal | ircd | public | 2004-01-18 10:48 | 2005-02-28 15:17 |
| Reporter | fez | Assigned To | syzop | ||
| Priority | normal | Severity | tweak | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | x86 | OS | Linux | OS Version | 2.4.x |
| Product Version | 3.2-RC2 | ||||
| Fixed in Version | 3.2.3 | ||||
| Summary | 0001503: let a +a user -a themselves... | ||||
| Description | ok, this doesn't really make sense to me.... a +v user cannot -v themself a +h user cannot -h themself a +o user can -o themself a +a user cannot -a themself a +q user can -q themself I think that a +a user should be allowed to set -a themself on a channel. What do you think? -- fez | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
Anyone have any comments on this? |
|
|
Strange someone can -q themselves but not -a ;). If neither was allowed that would help against the "-q but still having +o"-desynch ;). [I know we can't/shouldn't change that and it's not a valid reason.. just pointing out it now makes no sense _at all_ ;p]. Before you consider this, doublechec that it would not cause server desynchs with beta19<->nextrelease :) |
|
|
Well, is there an actual reason as to why someone can't, for example, -h themselves but can -o themselves? Doesn't make sense to me. |
|
|
from a coding point of view it's simple to explain why it's like this: -h/+h'ing is simply denied for halfops, +a/-a'ing is simply denied for +a'd people, etc.. so you have to code an exception in. not to mention, such a thing is not often used. |
|
|
my views is, in the end, Unless ur an oper, you never give urself this modes, services give u the modes, why would services give you a mode you wanna get rid of? kinda pointless no?.. also, if your assigned a mode ie +o its coz either you want it or you was given it, if you dont want it then simply tell the owner of the room?? Modes +q and +a are for protection, yet again, if you dont want the modes then dont bother to get them, why would you want +a or +q if ur gonna get rid of it, waste of time n space having them in that case. One last point i think sholud be said, if u get auto +v +h +o +a +q whichever, u`ll find that if its thru services u can remove that mode using services (unless the channel founder adjusts the LEVELS). if u get a temporary +v +h thru /mode command, why not /hop? ?????? |
|
|
white_magic: well, this might not make sense to you, but sometimes people who have services access to a channel do not necessarily always want to have the +a or +o status showing to everyone else. I don't see why it should be that one can be force-fed a high status that they can't get rid of, if only just temporarily. |
|
|
Some services allow you to unset -a if you have access: * Now talking in #Test... * ChanServ sets mode: +ao aquanight aquanight * SuperBot ([email protected]) has joined #Test. * SuperBot sets mode: +ao SuperBot SuperBot <aquanight> !deprotect * SuperBot sets mode: -a aquanight |
|
|
aquanight: thats using services, i think fez is referring to this " without " services as in using " /mode " or " /msg IRC MODE " and as i said already..... " One last point i think sholud be said, if u get auto +v +h +o +a +q whichever, u`ll find that if its thru services u can remove that mode using services (unless the channel founder adjusts the LEVELS). " If allowing urself to remove +a is made same as +q, i really see it as defeating the purpose of having the +a or +q modes, coz the present " +q " system is you *CAN* Take away Someone elses +q which shouldnt really be allowed... Should only be one +q in the channel, the name of the founder thru services... maybe the coders of unreal have a reason for removing +q and +o, but to me, +q or +a should be non removable by users unless thru services (only ON the user who requests it, not someone else with +q) .. or thru an oper. If it was made so you can ONLY -a or -q yourself then i find that as ok, for the reason is, it supports this bug report.. and it makes sense, you should only have the right to remove your own modes.. ( unless channel founder ) *waits to get shouted @ by Syzop & codemastr now * |
|
|
My two cents... Yeah, I agree. I dont like being opped all the time. Sometimes we like to go off duty, ya know? So why then can't you remove any mode that gets set on you?! If you have it, why can't you unset it? I mean, its like with IRCOps being able to -o but not +o. So I don't know. Only services can create the first op perhaps? Then each other op\whatever gets set by the channel owner OR services. |
|
|
My input: Halfops +h should be able to dehalfop -h themselves and Protected +a should be able to deprotect -a themselves. Voiced users should _not_ be able to devoice themselves because they are not in a position of power at all. |
|
|
Hmm, a +v user cannot -v themself --- Quite rightly so a +h user cannot -h themself -- I believe this is a good idea as well as some different networks use them for alternative reasons, not just hops :) And if its given for a reason it should stay there, although i know this isn't the documented use of it. a +o user can -o themself --- well Duh ! :p a +a user cannot -a themself --- This one doesn't really seem sensible, i think users who want to hide their power, as some people prefer to leave channel management to their Ops don't want to be seen to be the all seeing eye ;) a +q user can -q themself --- Think its good keeping this as is :) |
|
|
I think that generally a user with a channel mode (any mode) must have the ability to remove this channel mode himself. |
|
|
Well, this entry has been 'acknowledged'... So the -a thingy will be done, but.. after 3.2. Things that are more interresting to debate are -h and -v... *grin* (and possible side-effects). |
|
|
The -v is a very bad idea. One side-effect comes to mind right away. Eggdrop "desynch detection" MODE #test -v codemastr Eggdrop tests is "codemastr" +hoaq? If not, Eggdrop sends MODE #test +v codemastr It would (if designed correctly) detect a +v user setting -v as being desynch because as far as it know,s +v users can not change modes. Furthermore I see it causing general problems. For example, our own channel, #unreal-support. <Nick> I accidentily set -v on myself, can you +v me again so I can talk? +v was designed for "can speak" not "is helper" or anything else that people use it for. So the way I see it is, if you are +v, and you don't want to talk, then don't type anything. There is no reason to force yourself not to be able to talk. |
|
|
I agree on voice.. it has no status except that you can speak trough +m/+b/.., the halfops story is however much more fun :P. |
|
|
Indeed. I would say _if_ it were implemented, definately you should only be able to -h yourself, not others. I see the point of adding it, the "off duty" idea. +h does have real power, and it seems like a good idea to easily remove +h when you go away or something so users know not to bother trying to get help from you. On the other hand, Unreal is designed to be used with services. Services usually have a command to do this. But back to the first hand, that same argument could be made for +oaq. Services usually have a way to remove them too. As for compatibility... Well, what does Hybrid do? Do they let users -h themselves? If so, I'd say we don't have too much to worry about with compatibility. If not, we'll have to do some research. Assuming no compatibility problems exist, I guess, if people want it, why not add it. Just make sure it doesn't screw up MODE synching in Unreal (I don't think we check remote permissions anymore, do we?) |
|
|
Just fixed a thing that checked for halfop access for remote clients too (so yeah it did check :/)... so in the future we could consider doing this for real. |
|
|
I found that if you are +qoa you can -ao then -q and it works fine. But only if you have +q |
|
|
Any solution for this? |
|
|
i think halfops should be able to dehalfop. and admins should be able to deadmin. however, i agree that voices cannot devoice |
|
|
Well, I think that all should be able to remove the mode on themselves, but if that rank doesnt cover the changing of it on others, then ofcourse not on them. like +v can remove v off themselves only, +h can -h themselves, but not other h's |
|
|
Anyone but +v should be able to remove their own access. The no -a is irritating, I occasionally find myself with this typo situation /mode #Here -qao Jason Dangit! /mode #Here -ao Jason Jason FAIL |
|
|
Fixed in CVS [.307]: - Made it so halfops can -h themselves, and chanadmins can -a themselves, reported by fez (0001503). (This introduces no desynch issues btw) voice will be kept as-is. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-01-18 10:48 | fez | New Issue | |
| 2004-01-18 22:20 |
|
Note Added: 0004742 | |
| 2004-01-19 01:21 | syzop | Note Added: 0004745 | |
| 2004-01-19 04:46 | ace | Note Added: 0004751 | |
| 2004-01-19 14:11 | syzop | Note Added: 0004752 | |
| 2004-01-22 01:11 | White_Magic | Note Added: 0004763 | |
| 2004-01-22 01:32 | fez | Note Added: 0004764 | |
| 2004-03-12 18:47 | aquanight | Note Added: 0005446 | |
| 2004-03-12 22:54 | White_Magic | Note Added: 0005449 | |
| 2004-03-14 17:42 | w00t | Note Added: 0005491 | |
| 2004-04-07 09:38 | thunderbirdjl | Note Added: 0005759 | |
| 2004-04-07 18:26 |
|
Status | new => acknowledged |
| 2004-04-07 18:26 |
|
ETA | none => < 1 month |
| 2004-04-08 10:22 | mitchellj | Note Added: 0005788 | |
| 2004-04-12 07:48 | vonitsanet | Note Added: 0005831 | |
| 2004-04-12 12:32 | syzop | Note Added: 0005833 | |
| 2004-04-12 12:32 | syzop | Product Version | 3.2-beta19 => 3.2-RC2 |
| 2004-04-12 16:54 |
|
Note Added: 0005837 | |
| 2004-04-12 19:09 | syzop | Note Added: 0005847 | |
| 2004-04-13 00:18 |
|
Note Added: 0005848 | |
| 2004-04-13 18:34 | syzop | Note Added: 0005853 | |
| 2004-07-07 14:25 | MichaelJE2 | Note Added: 0006921 | |
| 2004-07-09 14:28 | vonitsanet | Note Added: 0006954 | |
| 2004-09-06 20:25 | alex323 | Note Added: 0007566 | |
| 2005-02-23 21:22 | sin-x | Note Added: 0009271 | |
| 2005-02-24 17:49 | JasonTik | Note Added: 0009280 | |
| 2005-02-28 15:09 | syzop | Status | acknowledged => assigned |
| 2005-02-28 15:09 | syzop | Assigned To | => syzop |
| 2005-02-28 15:17 | syzop | Status | assigned => resolved |
| 2005-02-28 15:17 | syzop | Fixed in Version | => 3.2.3 |
| 2005-02-28 15:17 | syzop | Resolution | open => fixed |
| 2005-02-28 15:17 | syzop | Note Added: 0009366 |
