Author Topic: Strict division between core and modules? (Read 2671 times)

Alreadythere · « **on:** March 10, 2007, 05:58:53 pm »

I think we should try to enforce a stricter division between core modules and normal modules. Mostly we are doing that already, I'm just trying to write it down.

Core modules should offer interfaces to other modules that are potentially used by more then just one module, or offer functions that are needed to run the bot at all (like user management, queue) because the Bot class is using them. So if a function of the module is directly called out of the bot class it should end in core. In my opinion they shouldn't offer any direct user interfaces at all (meaning they shouldn't contain any chat commands). They can create output though as reaction to some function call.

Everything offering an user interface in any way should be a normal module. If it needs some core functionality it can call the offered functions from the core modules. Everything else that doesn't fall under core should be considered a normal module too.

Khalem · « **Reply #1 on:** March 11, 2007, 02:00:00 am »

I second.

I already started doing this for the new user/roster management.

Blueeagle · « **Reply #2 on:** March 27, 2007, 02:06:31 pm »

In that respect I've split out the command handling from core/Security.php into modules/Security.php.

I'm not sure if any of the functions left in the core module can/should be moved over. The splitted files are attached to this post.

Please help me test this as I am not very comfortable with this module at all. The only testing I've done as of now is that I checked that the bot started

Cheers.

Alreadythere · « **Reply #3 on:** March 28, 2007, 02:52:32 am »

Didn't dare to touch those modules

I'll try to test them out soon.

Blueeagle · « **Reply #4 on:** March 28, 2007, 03:01:51 am »

Quote from: Alreadythere on March 28, 2007, 02:52:32 am

Didn't dare to touch those modules

I talked to Glara and he said that he had put the command handling into the security module because he intended to keep the cache private.

I am not sure that I share his view on this tho.

...but then again I don't get the point with having both security groups and access levels as they both do the same thing. I am assuming this is a feature useful with raid bots.

Glarawyn · « **Reply #5 on:** March 28, 2007, 06:39:34 pm »

One of the issues in BeBot 0.2 was that if someone created a custom security group, every module had to be edited to use that custom security group. To remove the need to recode every security check in the bot, I created the 8 Access Levels.

Access Levels are defined by the Bot itself. Every BeBot will have the same 8 Access Levels. The only thing a coder needs to do is check access levels.

Security groups are intended to keep the customizable security groups that BeBot 0.2 provided. The Security module creates superadmin, admin, and leader groups automatically, but these groups are not the same as the SUPERADMIN, ADMIN, AND LEADER Access Levels. The security module does treate the superadmin, admin, and leader groups as special groups because you can't delete them and you cannot change their access level, and you cannot rename them. Other than that, they are normal security groups.

When you create a new security group, it's access level defaults to ANONYMOUS. Users can then raise the Access Level of the security group to whatever level between ANONYMOUS and SUPERADMIN that they want. If the user wants to change the access for that group, they can at any time. As only the access level changes, deleting, recreating, and repopulating the group and it's members is not needed to change the access for that group.

Bottom line: Access Levels exist to provide simplicity and consistency for coders, custom groups exist to provide customizably for end users without breaking security or requiring module modifications to use custom groups.

I hope that helps, I don't know if I can explain it any better...

Blueeagle · « **Reply #6 on:** March 28, 2007, 07:25:34 pm »

If security groups had been tied into spesific parts of the bot and not just the security level asociated with the group I would have seen the point. What it does now is simply control the minimum access level of all members of a group for all commands and bot features. However if there was a way to tie modules/commands to spesific security groups (ie. a collection of trusted guests of a bot would have access to a command that not even all members have while denying those guests access to some of the commands that members have got acces to)

Right now you might just as well promote those members/guests of such a group to the required access level for the spesific group because they are, as far as I can tell, able to access any command associated with the access level of the security group.

Edit: Typos :/

Alreadythere · « **Reply #7 on:** March 28, 2007, 07:45:26 pm »

Actually I see the security module as a framework that defines who has which basic rights (access levels) and who is in which group.

The new access control management I wrote is just using the first information to limit access to commands. Structural there is nothing prohibiting an access control management based on a mix of access levels and security groups, or just security groups like the old rights management.

The access levels help quite a bit to hold the amount of work required to hardcode some access in modules (in the rare cases where it's needed there instead of using the access control, like with subcommands) down for us coders. We only got to worry about a limited amount of choices, and those can be put quite nicely into the settings tables.

Blueeagle · « **Reply #8 on:** April 07, 2007, 01:38:12 pm »

core/Alts.php has been split into core/Alts.php and modules/Alts.php. The changes have been tested and committed to CVS.

Documentation for the module has been put in the wiki

I have not attempted to write a help file for this module.