[ENH] Silence Mode #6

New issue

Open

opened 2023-12-23 10:49:17 -05:00 by modulatingforce · 3 comments

modulatingforce commented

2023-12-23 10:49:17 -05:00

Owner

Design a working enhanced Silence Mode that Channel Moderators can toggle so that the bot doesn't respond in Chat

The solution should involve the following :

A flag or field or module that is accessible from bot instance that represents its state per channel . There can be optionally an Instance level Silence mode if a Bot Admin wants to quiet the bot as a whole
For any given Channel where Silence Mode is Enabled , any bot attempt to respond in Chat should by default not be sent if the Channel is in Silence Mode , regardless of BotAction
There should be a coded option to force respond or say something in chat ; for example for some administrative command that would only run in an admin or bot channel (validated before calling the BotAction), we may want to force bot to say something despite enabled Silence Mode
- This should be rarely used, but should be allowed in the Solution
Allow BotAction to continue running regardless of Silence Mode :
- Listener s and Routine s would still continue to run ; but would not respond in silence mode
- BotCommand should continue to run . This is because Module Developers may want to control normal bot messages, but still guarantee that required chat messages will still be sent

Design a working enhanced Silence Mode that Channel Moderators can toggle so that the bot doesn't respond in Chat The solution should involve the following : - A flag or field or module that is accessible from bot instance that represents its state per channel . There can be optionally an Instance level Silence mode if a Bot Admin wants to quiet the bot as a whole - For any given Channel where Silence Mode is Enabled , any bot attempt to respond in Chat should *by default* not be sent if the Channel is in Silence Mode , regardless of `BotAction` - There should be a coded option to force respond or say something in chat ; for example for some administrative command that would only run in an admin or bot channel (validated before calling the `BotAction`), we may want to force bot to say something despite enabled Silence Mode - This should be rarely used, but should be allowed in the Solution - Allow `BotAction` to continue running regardless of Silence Mode : - `Listener` s and `Routine` s would still continue to run ; but would not respond in silence mode - `BotCommand` should continue to run . This is because Module Developers may want to control normal bot messages, but still guarantee that required chat messages will still be sent

modulatingforce added this to the Prototype 1.0 milestone 2023-12-23 10:49:22 -05:00

modulatingforce added this to the Rust Learning project 2023-12-23 10:49:25 -05:00

modulatingforce added the

Kind/Enhancement

Priority

Low

labels 2023-12-23 10:50:14 -05:00

modulatingforce commented

2023-12-23 10:55:27 -05:00

Author

Owner

Pretty easy to design and roll out - but there are other priorities at the moment, so started this to flesh out the idea and backlog into the current sprint

With the most current bot code on local, a Module Developer is recommended to call the Bot's version of chat related commands, as these have internal controls driving whether the chat message is sent and how the chat message is formatted

Pretty easy to design and roll out - but there are other priorities at the moment, so started this to flesh out the idea and backlog into the current sprint With the most current bot code on local, a Module Developer is recommended to call the Bot's version of chat related commands, as these have internal controls driving whether the chat message is sent and how the chat message is formatted

modulatingforce commented

2024-01-30 10:28:57 -05:00

Author

Owner

I think it might be better to have some Channel Modes and Channel Modes Manager that :

Takes any Mode (e.g., Silence Mode)
Allows Privileged UserRoles to run Channel Mode Commands to define the state of that mode
The modes can be based on existing enums from botmodules

#[derive(Debug, PartialEq, Eq, Hash, Clone)]
pub enum ChType {
    Channel(String),
}


#[derive(Debug)]
enum StatusLvl {
    Instance,
    Ch(ChType),
}

#[derive(Debug)]
pub enum ModStatusType {
    Enabled(StatusLvl),
    Disabled(StatusLvl),
}

Like maybe ModeStatusType ?

pub enum ModeStatusType {
    Enabled(StatusLvl),
    Disabled(StatusLvl),
}

Then I can have some Hashmap like the following

enum ChMode {
    Silence,
}

#[derive(Clone)]
pub struct ModeManager {
    modesStatus: HashMap<ChMode,Vec<ModeStatusType>>, 
}

I think it might be better to have some Channel Modes and Channel Modes Manager that : - Takes any Mode (e.g., Silence Mode) - Allows Privileged UserRoles to run Channel Mode Commands to define the state of that mode - The modes can be based on existing enums from `botmodules` ```rust #[derive(Debug, PartialEq, Eq, Hash, Clone)] pub enum ChType { Channel(String), } #[derive(Debug)] enum StatusLvl { Instance, Ch(ChType), } #[derive(Debug)] pub enum ModStatusType { Enabled(StatusLvl), Disabled(StatusLvl), } ``` Like maybe `ModeStatusType` ? ```rust pub enum ModeStatusType { Enabled(StatusLvl), Disabled(StatusLvl), } ``` Then I can have some Hashmap like the following ```rust enum ChMode { Silence, } #[derive(Clone)] pub struct ModeManager { modesStatus: HashMap<ChMode,Vec<ModeStatusType>>, } ```

modulatingforce self-assigned this 2024-01-30 10:29:39 -05:00

modulatingforce commented

2024-01-30 11:01:56 -05:00

Author

Owner

ModeManager should have similar status related functions that ModulesManager uses

Below is from ModulesManager at the moment that's related

    pub fn modstatus(&self, _:ModType, _:ChType) -> ModStatusType {
        // Example usage : botmanager.modstatus(
        //     BotModule("GambaCore"),
        //     Channel("modulatingforce")
        // ) 
        // - The ModStatusType checks in the context of the given channel , 
        //  but also validates based on wheher the module is disabled at a bot instance
        //  level as well
        ModStatusType::Enabled(StatusLvl::Instance)
    }


    pub fn togglestatus(&self, _:ModType, _:ChType) -> ModStatusType {
        // enables or disables based on current status
        ModStatusType::Enabled(StatusLvl::Instance)
    }


    pub fn setstatus(&self, _:ModType, _:ModStatusType) -> Result<&str,Box<dyn Error>> {
        // sets the status based given ModSatusType
        // e.g., b.setstatus(BodModule("GambaCore"), Enabled(Channel("modulatingforce"))).expect("ERROR")
        Ok("")
    }

    fn statuscleanup(&self,_:Option<ChType>) -> () {
        // internal cleans up statusdb . For example : 
        // - remove redudancies . If we see several Enabled("m"), only keep 1x
        // - Clarify Conflict. If we see Enabled("m") and Disabled("m") , we remove Enabled("m") and keep Disabled("m")
        // the IDEAL is that this is ran before every read/update operation to ensure quality
        // Option<ChType> can pass Some(Channel("m")) (as an example) so statuscleanup only works on the given channel
        // Passing None to chnl may be a heavy operation, as this will review and look at the whole table
        ()
    }

`ModeManager` should have similar status related functions that `ModulesManager` uses Below is from `ModulesManager` at the moment that's related ```rust pub fn modstatus(&self, _:ModType, _:ChType) -> ModStatusType { // Example usage : botmanager.modstatus( // BotModule("GambaCore"), // Channel("modulatingforce") // ) // - The ModStatusType checks in the context of the given channel , // but also validates based on wheher the module is disabled at a bot instance // level as well ModStatusType::Enabled(StatusLvl::Instance) } pub fn togglestatus(&self, _:ModType, _:ChType) -> ModStatusType { // enables or disables based on current status ModStatusType::Enabled(StatusLvl::Instance) } pub fn setstatus(&self, _:ModType, _:ModStatusType) -> Result<&str,Box<dyn Error>> { // sets the status based given ModSatusType // e.g., b.setstatus(BodModule("GambaCore"), Enabled(Channel("modulatingforce"))).expect("ERROR") Ok("") } fn statuscleanup(&self,_:Option<ChType>) -> () { // internal cleans up statusdb . For example : // - remove redudancies . If we see several Enabled("m"), only keep 1x // - Clarify Conflict. If we see Enabled("m") and Disabled("m") , we remove Enabled("m") and keep Disabled("m") // the IDEAL is that this is ran before every read/update operation to ensure quality // Option<ChType> can pass Some(Channel("m")) (as an example) so statuscleanup only works on the given channel // Passing None to chnl may be a heavy operation, as this will review and look at the whole table () } ```

modulatingforce added the

labels 2024-03-27 18:42:32 -04:00

modulatingforce modified the project from Rust Learning to Forcebot Prototype 1.0 Push

2024-03-27 18:46:42 -04:00