Anope Bug Tracker - Anope Stable (2.0.x series)
View Issue Details
0001598Anope Stable (2.0.x series)[All Projects] Generalpublic2014-05-07 20:232014-11-04 08:38
elskwi 
Adam 
lowfeaturealways
resolvedfixed 
ALLALLALL
0001598: Change of behaviour of the defcon
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

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
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.
No tags attached.
Issue History
2014-05-07 20:23elskwiNew Issue
2014-05-07 22:43azanderNote Added: 0006640
2014-05-07 23:15elskwiNote Added: 0006641
2014-05-07 23:38elskwiNote Edited: 0006641bug_revision_view_page.php?bugnote_id=6641#r163
2014-05-07 23:41elskwiNote Edited: 0006641bug_revision_view_page.php?bugnote_id=6641#r164
2014-05-08 00:24YoergerNote Added: 0006642
2014-11-04 08:38AdamNote Added: 0006672
2014-11-04 08:38AdamStatusnew => resolved
2014-11-04 08:38AdamResolutionopen => fixed
2014-11-04 08:38AdamAssigned To => Adam

Notes
(0006672)
Adam   
2014-11-04 08:38   
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.
(0006642)
Yoerger   
2014-05-08 00:24   
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.
(0006641)
elskwi   
2014-05-07 23:15   
(edited on: 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

(0006640)
azander   
2014-05-07 22:43   
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.

--Az