View Issue Details

IDProjectCategoryView StatusLast Update
0001503unrealircdpublic2005-02-28 15:17
ReporterfezAssigned Tosyzop 
PrioritynormalSeveritytweakReproducibilityalways
Status resolvedResolutionfixed 
Platformx86OSLinuxOS Version2.4.x
Product Version3.2-RC2 
Target VersionFixed in Version3.2.3 
Summary0001503: let a +a user -a themselves...
Descriptionok, 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
TagsNo tags attached.
3rd party modules

Activities

codemastr

2004-01-18 22:20

reporter   ~0004742

Anyone have any comments on this?

syzop

2004-01-19 01:21

administrator   ~0004745

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 :)

ace

2004-01-19 04:46

reporter   ~0004751

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.

syzop

2004-01-19 14:11

administrator   ~0004752

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.

White_Magic

2004-01-22 01:11

reporter   ~0004763

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?

??????

fez

2004-01-22 01:32

reporter   ~0004764

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.

aquanight

2004-03-12 18:47

reporter   ~0005446

Some services allow you to unset -a if you have access:
* Now talking in #Test...
* ChanServ sets mode: +ao aquanight aquanight
* SuperBot (service@services.myirc.net) has joined #Test.
* SuperBot sets mode: +ao SuperBot SuperBot
<aquanight> !deprotect
* SuperBot sets mode: -a aquanight

White_Magic

2004-03-12 22:54

reporter   ~0005449

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 *

w00t

2004-03-14 17:42

reporter   ~0005491

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.

thunderbirdjl

2004-04-07 09:38

reporter   ~0005759

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.

mitchellj

2004-04-08 10:22

reporter   ~0005788

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 :)

vonitsanet

2004-04-12 07:48

reporter   ~0005831

I think that generally a user with a channel mode (any mode) must have the ability to remove this channel mode himself.

syzop

2004-04-12 12:32

administrator   ~0005833

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).

codemastr

2004-04-12 16:54

reporter   ~0005837

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.

syzop

2004-04-12 19:09

administrator   ~0005847

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.

codemastr

2004-04-13 00:18

reporter   ~0005848

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?)

syzop

2004-04-13 18:34

administrator   ~0005853

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.

MichaelJE2

2004-07-07 14:25

reporter   ~0006921

I found that if you are +qoa you can -ao then -q and it works fine. But only if you have +q

vonitsanet

2004-07-09 14:28

reporter   ~0006954

Any solution for this?

alex323

2004-09-06 20:25

reporter   ~0007566

i think halfops should be able to dehalfop. and admins should be able to deadmin. however, i agree that voices cannot devoice

sin-x

2005-02-23 21:22

reporter   ~0009271

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

JasonTik

2005-02-24 17:49

reporter   ~0009280

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

syzop

2005-02-28 15:17

administrator   ~0009366

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.

Issue History

Date Modified Username Field Change
2004-01-18 10:48 fez New Issue
2004-01-18 22:20 codemastr 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 codemastr Status new => acknowledged
2004-04-07 18:26 codemastr 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 codemastr Note Added: 0005837
2004-04-12 19:09 syzop Note Added: 0005847
2004-04-13 00:18 codemastr 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