Ok, here some (first) thoughts:

1) Perhaps we should keep 4 handler, but in a slightly different way: tells, pgmsg, gc and global (any one of the 3). This would allow differentiation where it's wanted, and centralization where it's mode senseful. And add a global send() function, that takes the target channel as parameter.

2) Personally I like that I can change the rights during runtime. But yes, the queries done are a waste. It would make more sense to cache the current rights once queried, and only update the table and cache if some changes occur. Default rights should definitly be added, best over some $this -> bot -> rights -> define_rights() function.

3) The is_member function needs a serious overhaul as you stated. It needs more differentiation, and I think it should be moved out of the Bot class into a core module. This would allow easier custumization for bot owners without changing any of the real core functionality.

What i have in mind right now (thanks a lot for ideas Vhab) is a single command list for plugins to register with.
This would in turn call say handler() in the plugin with

• Name/Source
• Type (Tell, Pgroup, GC)
• Command
• Command args

I see two ways of doing it, both with advantages and disadvantages:

• one halder() for all commands of a module
• single handler for a single command only, like if $commands["whois"] = &$whois is the define, the function $whois -> whois() is called

Both would get the same parameters, $name of caller, full command, and channel of origin. Single handler would make for cleaner structured code, global handler could save some overhead of similar commands.

Runtime updates can still occur, you just have to update the entry in the in memory permissions list in addition to the database
Default user levels can be set in the actual hooking so that when the module registers a handler it would do something like:
$commands["whois"]["guests"] = &$roster;

Considering the possible problems with function calls in the init phase of the modules I guess a defined array that get's parsed after startup is the best choice. The parsing should just take existing access rights in the database over predefined in the array, people may not like the predefines.

Im looking at moving more stuff into core modules right now. And i would also like to separate actual user availible command handlers into their own modules instead of having them reside in the core modules, thus keeping the core modules an extention of Bot.php containing only functions to be called.

So basically all under core/ only offers functions, and all that reacts directly to commands is under module?
Would be a nice clean split tbh, hadn't thought that far.

Are you thinking of changing how commands are registered? At times it's nice to write something that is tell, org chat, or private group only.

It may or may not happen. Although i am currently leaning slighty in favour of doing it, combining everything into a single command handler in the bot core, and then giving the module the opportunity to select what channels to act upon the command in.

The only real drawback to this aside from that every module will need slight modification, is that you can no longer set access per command per channel.
We would still be able to say that members have access to any commands in gc, pgroup and tells, but guests only in tells. And from there it would be up to the rightsmanagement to determine if the user should be allowed to access it or not (And of course you would have a default setting either in the actual hook or as a separate function)

Again something I've done by passing a vairable to the extra function. It works well most of the time. This method would also work well with a global output handler.

This is also what i did in my example in the first post, and regardless of what i end up with, any channel will be calling a single function in the module probably named handler() which also includes a $type variable that tells the module what channel the request came from.

I don't use it because since it's not distributed with the current stable bot. I write modules so they can be dropped into any series 0.2.X BeBot and work. I'll take advantage of anything that makes it into the core of the bot. IMHO, users should not have to modify the bot core to use a module.

I should probably have made this clear from the getgo, but this change would only happen in the 0.3 branch.
Having worked with software development projects for some time i am strongly opposed to changing the API in minor patch releases, it simply should not be done because it confuses the users and frustrates developers even more.
This is also the reason i am taking my time with 0.3 before it becomes the new stable release as 0.4 (or 1.0) because i want to get these major changes out of the way.

This is my security band-aid that I've used in a few of my modules. I like it for being simple. Send it the username and the security group, and get back a true if they pass the security check (they are in that group or a higher group) or false if not.

Code: [Select]

    /*
        Check Security
            Returns TRUE if $name is in $level or above.
            Otherwise Returns False.
    */
    function check_security($name, $level)
    {
        $name = ucfirst(strtolower($name));
        $level = strtoupper($level);

        switch ($level)
        {
            case "GUEST":
                if ( ($this -> bot -> is_member($name) == 2)
                      || ($this -> bot -> admin -> is_member($name) == 1) )
                    return TRUE;
                    break;
            case "MEMBER":
                if ($this -> bot -> is_member($name) == 1)
                // is_member($name) : returns if person is a member of the bot (true = member, 2 = guest, false = unknown)
                    return TRUE;
                 else
                    return FALSE;
                break;
            case "RAIDLEADER":
                if ($this -> bot -> admin -> in_group($name, "raidleader")
                    || $this -> bot -> admin -> in_group($name, "admin")
                    || $this -> bot -> admin -> in_group($name, "superadmin"))
                    return TRUE;
                else
                    return FALSE;
                break;
            case "ADMIN":
                if ($this -> bot -> admin -> in_group($name, "admin")
                    || $this -> bot -> admin -> in_group($name, "superadmin"))
                    return TRUE;
                else
                    return FALSE;
                break;
            case "SUPERADMIN":
                if ($this -> bot -> admin -> in_group($name, "superadmin"))
                    return TRUE;
                else
                    return FALSE;
                break;
            default:
                return FALSE;
                break;
        }
    }


I was actually planning something similiar, although i am hoping to more or less eliminate the need to do access control inside a module almost entirely.
This will most likely mean that in addition to registering a default access level, it should also be possible to make sure a command cannot be allowed below a certain level. For example shutdown and restart commands should always be limited to at least higher than member (to allow for custom admin groups control)