Anope Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001598Anope Stable (2.0.x series)[All Projects] Generalpublic2014-05-07 20:232014-11-04 08:38
Reporterelskwi 
Assigned ToAdam 
PrioritylowSeverityfeatureReproducibilityalways
StatusresolvedResolutionfixed 
PlatformALLOSALLOS VersionALL
Summary0001598: Change of behaviour of the defcon
DescriptionThe 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 ReproduceSet 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 InformationThis 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.
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0006672)
Adam (administrator)
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 (developer)
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 (reporter)
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 (developer)
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

- Issue History
Date Modified Username Field Change
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


Copyright © 2000 - 2018 MantisBT Team
Powered by Mantis Bugtracker