View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001598||Anope Stable (2.0.x series)||General||public||2014-05-07 20:23||2014-11-04 08:38|
|Summary||0001598: Change of behaviour of the defcon|
|Description||The defcon changes modes and doesn't keep mode before the defcon :|
#mychan is +i
something not fun appears, admin set defcon : all chanmodes +i
something not fun disappears, admin set defcon 5
#mychan has lost the +i
|Steps To Reproduce||Set a +i mode on a channel|
Change a defcon level with chanmodes +i
Set this defcon level
Set the default defcon level
Channel is now without +i
|Additional Information||This wasn't the default behaviour in Anope 1.8.8|
The defcon restores channel modes in their previous states
The documentation says :
* The channel modes to set on all channels when the DefCon channel mode system is in use.
* Note 1: Choose these modes carefully, because when DefCon switches to a level which does NOT have
* the mode setting selected, Services will set the reverse on all channels, e.g. if this setting
* is +RN when DefCon is used, all channels will be set to +RN, when DefCon is removed, all
* channels will be set to -RN. You don't want to set this to +k for example, because when DefCon
* is removed, all channels are set -k, removing the key from previously keyed channels.
* Note 2: MLOCKed modes will not be lost.
chanmodes = "+m"
I totally understand what the defcon do now !
But, it's not possible to ask every channel owner to put mlock, someone would just want to put a mode for some hours and want to retrieve the channel in its original state even if defcon is used before he come back.
For example, I put a +i mode on a channel for some reasons. I come back and want to have my room with the same state before I left.
Anyway, the mode command for channel modes become useless with the current behaviour.
|Tags||No tags attached.|
||I've checked the old 1.8 behavior and it did not remember modes and then only unset he ones that weren't set before, as the comment says that you pasted (even though you seem to think it says that it did?). Having defcon override mlock when defcon is being turned off is a bug though, so I've fixed that in c4460784c2b3695b9f3a8073fc61712e9f804573.|
||I also disagree about the change, per our discussion in IRC. If users want modes to stay, they would MLOCK them. Also per discussion, DEAFCON should only be used in emergencies and debugging. So the frequency of this occouring should be rare.|
Last edited: 2014-05-07 23:41
On a network, users haven't to register a channel and it is not an obligation.
Someone just want to create a channel without register it and then he lost all settings because of the defcon.
This is an other reason that make me think this is a bad behaviour and this feature doesn't cover all pragmatical use cases.
Something buggin me a lot :
[00:03] <¤ChanServ> COMMAND: elskwi used MODE on #solarproject to lock +nti
[00:08] <¤OperServ> ADMIN: elskwi used DEFCON to change defcon level to 4
[00:08] <¤OperServ> DEFCON: setting +RNnmsTt on all channels
... on channel #solarproject
[00:08] * OperServ sets mode: +smRNT
[00:08] <¤OperServ> ADMIN: elskwi used DEFCON to change defcon level to 5
[00:08] <¤OperServ> DEFCON: setting -RNnmsTt on all channels
... on channel #solarproject
[00:08] * OperServ sets mode: -smntRNT
I have set the mlock
#solarproject t rnt MODE cannot be set due to channel having an active MLOCK restriction policy
result of info command
-ChanServ- Information for channel #solarproject:
Mode lock: +rnti
And the documentation says : Note 2: MLOCKed modes will not be lost
I don't think this behavior should be changed. Channel owners need to take responsibility to managing their channels. This includes using chanserv and mlock.
|2014-05-07 20:23||elskwi||New Issue|
|2014-05-07 22:43||azander||Note Added: 0006640|
|2014-05-07 23:15||elskwi||Note Added: 0006641|
|2014-05-07 23:38||elskwi||Note Edited: 0006641||View Revisions|
|2014-05-07 23:41||elskwi||Note Edited: 0006641||View Revisions|
|2014-05-08 00:24||Yoerger||Note Added: 0006642|
|2014-11-04 08:38||Adam||Note Added: 0006672|
|2014-11-04 08:38||Adam||Status||new => resolved|
|2014-11-04 08:38||Adam||Resolution||open => fixed|
|2014-11-04 08:38||Adam||Assigned To||=> Adam|