modulatingforce/forcebot_rs
1
0
Fork 0
Code Issues 33 Pull requests 11 Projects 2 Activity

ModulesManager #37

Merged
modulatingforce merged 22 commits from modulesmanager into main 2024-03-22 21:34:08 -04:00
Conversation 7 Commits 22 Files changed 4 +2005 -96
modulatingforce commented 2024-03-20 21:07:14 -04:00
Owner
Copy link

Addressing #26

Plan of Action :

  • Review current BotModules code . In particular, where we can set the statusdb in
pub struct ModulesManager {
    statusdb: Arc<RwLock<HashMap<ModType, Vec<ModStatusType>>>>,
    pub botactions: Arc<RwLock<HashMap<ModType, Vec<BotAction>>>>,
}
  • Create ModulesManager Methods to work with StatusTypes
  • Bot should NOT allow BotAction to run (e.g., Listener or BotCommand)
    • FUTURE For Routines, when a module is set to Disabled, it should also Abort all running routines for the Module >> At least ensure this requirement is in the Routines issue > That will be addressed here #5 (comment)
  • Unit tests
  • BotCommands to Enable & Disable Modules
  • Runtime / live tests
  • Comments cleanup
Addressing https://git.flake.sh/modulatingforce/forcebot_rs/issues/26 **Plan of Action :** - [x] Review current `BotModules` code . In particular, where we can set the `statusdb` in ```rust pub struct ModulesManager { statusdb: Arc<RwLock<HashMap<ModType, Vec<ModStatusType>>>>, pub botactions: Arc<RwLock<HashMap<ModType, Vec<BotAction>>>>, } ``` - [x] Create ModulesManager Methods to work with StatusTypes - [x] Bot should NOT allow `BotAction` to run (e.g., `Listener` or `BotCommand`) - [x] **FUTURE** For `Routines`, when a module is set to Disabled, it should also Abort all running routines for the Module >> At least ensure this requirement is in the Routines issue > That will be addressed here https://git.flake.sh/modulatingforce/forcebot_rs/issues/5#issuecomment-608 - [x] Unit tests - [x] BotCommands to Enable & Disable Modules - [x] Runtime / live tests - [x] Comments cleanup
modulatingforce self-assigned this 2024-03-20 21:07:46 -04:00
modulatingforce added this to the Rust Learning project 2024-03-20 21:07:50 -04:00
modulatingforce added this to the Prototype 1.0 milestone 2024-03-20 21:07:52 -04:00
modulatingforce added the
Kind/Feature
Priority
High
 labels 2024-03-20 21:08:05 -04:00
modulatingforce added a new dependency 2024-03-20 21:09:56 -04:00
#26 [CORE] ModulesManager
modulatingforce started working 2024-03-20 22:29:52 -04:00
modulatingforce commented 2024-03-20 22:31:30 -04:00
Author
Owner
Copy link

At the moment, during ModulesManager.add_botaction() , the BotModule is ensured existing in statusdb , and is Enabled(Instance)

Lines 302 to 305 in b5873a6
let mut dbt = self.statusdb.write().await;
let statusvector = dbt.entry(in_module.clone()).or_insert(Vec::new());
statusvector.push(ModStatusType::Enabled(StatusLvl::Instance)); // Pushes the Module as Enabled at Instance Level

We should be handling the above elsewhere, Disabled By Default at Instance level (except for certain Core modules) , unless Explicitly Coded to be Enabled

  • By Keeping Default Disabled, but being able to Enable at Channel level gives some control
At the moment, during `ModulesManager.add_botaction()` , the `BotModule` is ensured existing in `statusdb` , and is `Enabled(Instance)` https://git.flake.sh/modulatingforce/forcebot_rs/src/commit/b5873a6ac179371861298f2cbbd67b99d9c190ff/src/core/botmodules.rs#L302-L305 --- We should be handling the above elsewhere, Disabled By Default at Instance level (except for certain `Core` modules) , unless Explicitly Coded to be Enabled - By Keeping Default Disabled, but being able to Enable at Channel level gives some control
modulatingforce stopped working 2024-03-21 09:39:02 -04:00
11 hours 9 minutes
modulatingforce commented 2024-03-21 09:39:37 -04:00
Author
Owner
Copy link

LULE I did not work on this for 11 hours - but testing this timer functionality - though I did a bit

LULE I did not work on this for 11 hours - but testing this timer functionality - though I did a bit
modulatingforce added 8 commits 2024-03-21 09:40:54 -04:00
smol
All checks were successful
ci/woodpecker/pr/cargo-checks Pipeline was successful
Details
23f12b3956
modulatingforce commented 2024-03-21 10:15:15 -04:00
Author
Owner
Copy link

Business Rules

  • #todo may need to add this business logic in a wiki or the issue

Drafted this last night that I'm gearing my current commits on related to ModGroup

ModGroup Core & Custom

Core BotModules should :

  • Critical Modules
  • Always Be Enabled, and Enabled at an Instance Level
  • They are never enabled / disabled at Channel Levels
  • There should be no way to Disable these BotModules

Custom BotModules should :

  • Optional Modules
  • be toggleable between Enabled/Disabled at Channel or Instance Level
  • When added, they are Disabled at an Instance Level
    • Moderators can Enable/Disable the BotModule at Channel Level > In this case, Enabled(Channel) / Disabled(Channel) will be returned
  • A custom modules developer can call ModulesManager to Enable the Module at Instance Level , after they've added BotActions
  • A BotAdmin can Enable at Instance Level
  • Enabled At Instance Level means :
    • If the Channel does not Define a Status Level OR that Channel is Defined as Enabled > Enabled(Instance) or Enabled(Channel) will be returned
      • This allows Modules to be Enabled by Default to Introduce the functionality . The custom modules developer or admin should understand this before Enabling at Instance Level
    • If the Channel is Defined a Disabled > Disabled(Channel) will be returned
  • Force Disable fn to Disable a Module by Setting Disabled(Instance) and removing all Enabled(Channel) (doing nothing to Disabled(Channel) that exists)
    • This should require elevated access
# Business Rules - [ ] _#todo_ may need to add this business logic in a wiki or the issue Drafted this last night that I'm gearing my current commits on related to `ModGroup` ## `ModGroup` Core & Custom `Core` BotModules should : - Critical Modules - Always Be Enabled, and Enabled at an Instance Level - They are never enabled / disabled at Channel Levels - There should be no way to Disable these BotModules `Custom` BotModules should : - Optional Modules - be toggleable between Enabled/Disabled at Channel or Instance Level - When added, they are Disabled at an Instance Level - Moderators can Enable/Disable the BotModule at Channel Level > In this case, Enabled(Channel) / Disabled(Channel) will be returned - A custom modules developer can call ModulesManager to Enable the Module at Instance Level , after they've added BotActions - A BotAdmin can Enable at Instance Level - Enabled At Instance Level means : - If the Channel does not Define a Status Level OR that Channel is Defined as Enabled > Enabled(Instance) or Enabled(Channel) will be returned - This allows Modules to be Enabled by Default to Introduce the functionality . The custom modules developer or admin should understand this before Enabling at Instance Level - If the Channel is Defined a Disabled > Disabled(Channel) will be returned - Force Disable fn to Disable a Module by Setting Disabled(Instance) and removing all Enabled(Channel) (doing nothing to Disabled(Channel) that exists) - This should require elevated access
modulatingforce commented 2024-03-21 12:24:30 -04:00
Author
Owner
Copy link
  • Unit Tests should be based on the following ModulesManager methods
pub async fn modstatus(&self, in_module: ModType, in_chnl: ChType) -> StatusType

pub async fn set_instance_disabled(&self, in_module: ModType) -> (StatusType,ChangeResult)

pub async fn force_disable(&self, in_module: ModType) -> (StatusType,ChangeResult)

pub async fn set_instance_enabled(&self, in_module: ModType) -> (StatusType,ChangeResult)

pub async fn set_ch_disabled(&self, in_module: ModType , in_chnl: ChType) -> (StatusType,ChangeResult)

pub async fn set_ch_enabled(&self, in_module: ModType , in_chnl: ChType) -> (StatusType,ChangeResult)

pub async fn affirm_in_statusdb(&self,in_module:ModType,in_modgroup: ModGroup)
- [x] Unit Tests should be based on the following `ModulesManager` methods ```rust pub async fn modstatus(&self, in_module: ModType, in_chnl: ChType) -> StatusType pub async fn set_instance_disabled(&self, in_module: ModType) -> (StatusType,ChangeResult) pub async fn force_disable(&self, in_module: ModType) -> (StatusType,ChangeResult) pub async fn set_instance_enabled(&self, in_module: ModType) -> (StatusType,ChangeResult) pub async fn set_ch_disabled(&self, in_module: ModType , in_chnl: ChType) -> (StatusType,ChangeResult) pub async fn set_ch_enabled(&self, in_module: ModType , in_chnl: ChType) -> (StatusType,ChangeResult) pub async fn affirm_in_statusdb(&self,in_module:ModType,in_modgroup: ModGroup) ```
modulatingforce added 2 commits 2024-03-21 14:02:11 -04:00
unit tests
All checks were successful
ci/woodpecker/pr/cargo-checks Pipeline was successful
Details
68f9be4968
modulatingforce deleted spent time 2024-03-21 21:21:30 -04:00
- 11 hours 9 minutes
modulatingforce added 9 commits 2024-03-22 19:08:30 -04:00
rsp only to elevated users
Some checks failed
ci/woodpecker/pr/cargo-checks Pipeline failed
Details
2c298663b1
modulatingforce added 1 commit 2024-03-22 19:51:28 -04:00
listener modules validated
Some checks failed
ci/woodpecker/pr/cargo-checks Pipeline failed
Details
4b0d51a674
modulatingforce added 1 commit 2024-03-22 20:18:08 -04:00
clippy adj
All checks were successful
ci/woodpecker/pr/cargo-checks Pipeline was successful
Details
06e182df55
modulatingforce commented 2024-03-22 20:20:09 -04:00
Author
Owner
Copy link

Beautiful looking good.

Going to monitor for a few days in case there's any additional changes I can tack on that might be related to modules

Also need to do a comments cleanup

Beautiful looking good. Going to monitor for a few days in case there's any additional changes I can tack on that might be related to modules Also need to do a comments cleanup
modulatingforce added the
Status
Need More Info
 label 2024-03-22 20:20:20 -04:00
modulatingforce added 1 commit 2024-03-22 21:06:22 -04:00
comments cleanup
All checks were successful
ci/woodpecker/pr/cargo-checks Pipeline was successful
Details
72ebd5193c
modulatingforce commented 2024-03-22 21:32:28 -04:00
Author
Owner
Copy link

Really want this merge ASAP before working on other functionality .

Going to Approve the Merge but keep the Branch for any potential Code Improvements while Issue #26 is still open

Ideally should delete out the Branch after the Issue is closed out

Really want this merge ASAP before working on other functionality . Going to Approve the Merge but keep the Branch for any potential Code Improvements while Issue https://git.flake.sh/modulatingforce/forcebot_rs/issues/26 is still open Ideally should delete out the Branch after the Issue is closed out
modulatingforce removed the
Status
Need More Info
 label 2024-03-22 21:33:12 -04:00
modulatingforce changed title from WIP: ModulesManager to ModulesManager 2024-03-22 21:33:28 -04:00
modulatingforce merged commit 45e3f02297 into main 2024-03-22 21:34:08 -04:00
modulatingforce commented 2024-04-03 00:07:39 -04:00
Author
Owner
Copy link

No need to keep the branch if there are no changes to add soon. Deleting the branch for now ; the issue can remain open and we can create a new PR if there are code changes that are required or need to be explored

No need to keep the branch if there are no changes to add soon. Deleting the branch for now ; the issue can remain open and we can create a new PR if there are code changes that are required or need to be explored
modulatingforce deleted branch modulesmanager 2024-04-03 00:07:53 -04:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
Automated
  
Backlog
Post_Prototype_1.0

  
Bot_Code
Core

  
Bot_Code
Custom

  
CI/CD
  
Complexity
Advanced

  
Complexity
Basic

  
Complexity
Expert

  
Complexity
Intermediate

  
Kind/Breaking

Breaking change that won't be backward compatible

  
Kind/Bug

Something is not working

  
Kind/Bug Fix

Branches intended to address an existing Bug

  
Kind/Documentation

Documentation changes

  
Kind/Enhancement

Improve existing functionality

  
Kind/Feature

New functionality

  
Kind/Security

This is security issue

  
Kind/Testing

Issue or pull request related to testing

  
Nix
  
Ownership
Collab

  
Ownership
Collab with Leads
Collab with one or more Leads

  
Ownership
Individual Lead

  
Ownership
In-Review
Ownership may be in a review or disputed status

  
Ownership
Needs Owner > May Delegate
Tasks that may need reassignment

  
Ownership
Workshop with Leads
Workshop Tasks

  
Phase 1.0
Requirements > Drafting

  
Phase 1.0
Requirements > Researching

  
Phase 1.0
Requirements > Review & Planning

  
Phase 2.0
Design > Research & Analysis

  
Phase 3.0
Coding > Implementation

  
Phase 4.0
QA > Unit Testing & Design

  
Phase 5.0
Resolution > Completed

  
Phase 5.0
Resolution > Review for Completion

  
Priority
Critical
The priority is critical

  
Priority
High
The priority is high

  
Priority
Low
The priority is low

  
Priority
Medium
The priority is medium

  
Reviewed
Confirmed
Issue has been confirmed

  
Reviewed
Duplicate
This issue or pull request already exists

  
Reviewed
Invalid
Invalid issue

  
Reviewed
Won't Fix
This issue won't be fixed

  
Status
Abandoned
Somebody has started to work on this but abandoned work

  
Status
Blocked
Something is blocking this issue or pull request

  
Status
Need More Info
Feedback is required to reproduce issue or to continue work

No labels
Automated
Backlog
Post_Prototype_1.0
Bot_Code
Core
Bot_Code
Custom
CI/CD
Complexity
Advanced
Complexity
Basic
Complexity
Expert
Complexity
Intermediate
Kind/Breaking
Kind/Bug
Kind/Bug Fix
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Security
Kind/Testing
Nix
Ownership
Collab
Ownership
Collab with Leads
Ownership
Individual Lead
Ownership
In-Review
Ownership
Needs Owner > May Delegate
Ownership
Workshop with Leads
Phase 1.0
Requirements > Drafting
Phase 1.0
Requirements > Researching
Phase 1.0
Requirements > Review & Planning
Phase 2.0
Design > Research & Analysis
Phase 3.0
Coding > Implementation
Phase 4.0
QA > Unit Testing & Design
Phase 5.0
Resolution > Completed
Phase 5.0
Resolution > Review for Completion
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
Milestone
Clear milestone
No items
No milestone
Prototype 1.0
Projects
Clear projects
No items
No project
Rust Learning
Assignees
Clear assignees
No assignees
modulatingforce
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Blocks
#26 [CORE] ModulesManager}
modulatingforce/forcebot_rs
Reference: modulatingforce/forcebot_rs#37
No description provided.
Delete branch "modulesmanager"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?