Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Charles Kingsley]

Viper raised bug #1084:

chan_set_correct_modes() does not currently remove voices that are not "legally
acquired" (not on access list when secureops is on)..
Main issue is whether secureops should apply to voices too.. it s a simple
on/off and currently affects qaoh, but not v..

I ran into the issue because one of my modules uses this function to
synchronize  users' status with the access list and voices never were removed..
Whether it s something that needs to be changed, is up for discussion..

It has been decided to leave it as is on the stable branch but to open the idea of SECUREDACCESS which does include voice's for 1.9.x.

Thoughts?

[MeiR]

hm.. I belive that SecureOPS refers to.. well, ops.
but still, why not making it a conf directive? "SecureOpsIncVoice" or something..
in order to leave the decision for every spceific channel owner?

and how "chan_set_correct_modes()" will act after implementing SECUREDACCESS? by checking whether it's on or off and update voices accordingly?

[Darth Panda]

Since +v has no privileges other than the ability to talk in +m channels, I fail to see how devoicing a user would be considered "more secure" in any scenario.

I agree it should remain as is too.

[MeiR]

we discussed it a bit on the IRC channel
mooncup suggested "/cs set #chan secure 0/1/2"
but since:

«20:22:26» (%Namegduf) Ew.
«20:22:31» (mooncup)
«20:22:42» (mooncup) numberphobic? D:

I think "/cs set #chan secure ops|all|off" will be good

[Taylor]

I like your way  /cs set $chan secure ops|all|off
i sometimes like to remove even voice cause we use it as a VIP status
so yea