commands

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
commands [2007/12/04 17:27]
Alreadythere Added section for subcommand handling, modified GUI entry to include subcommand information
commands [2020/09/12 01:30] (current)
Line 1: Line 1:
 +====== Access Control ======
 +BeBot offers an access control management for all chat commands. This access control allows it to set minimal access levels to use a command. This means that the bot only reacts to a command if it is given by a user of the minimal access level or a higher one.
  
 +===== Access Levels =====
 +The access control management is using the same access levels as the [[Security]] module. In addition to those real access levels it is using another pseudo access level to disable commands completly. If the minimal access level of a command is set to DISABLED nobody at all can use this commands, it's the same as if it doesn't exist for uses of the bot. You can re-enable it by setting it to a real access level though during runtime.
 +
 +===== Access Control GUI =====
 +To reach the access control GUI call ///tell <botname> !commands (gc|pgmsg|tell|all) full//. This lists all commands with their current access level restriction for the selected channel. The pseudo-channel //all// lists all commands in gc, pgmsg and tell with their current access levels, and allows to set all 3 of those levels to the same value. If a command has existing subcommand entries a line to call the subcommands GUI is added.
 +
 +
 +===== Special Handling of !commands =====
 +The GUI doesn't allow it to disable the //!commands// command at all. This way the owner of a bot cannot lock himself out from the bot completly. The GUI checks on each startup the same, if the //!commands// command is disabled or no rights for it exist it will be set to OWNER again.
 +
 +
 +
 +===== Setting Default Rights =====
 +If you want to add predefined default rights for a new module you can use the function **//$this -> bot -> accesscontrol -> create(channel, command, default_level)//**. This adds a default access level for command in channel if no access level is yet set for that combination.
 +
 +In addition to this there is a setting AccessControl -> DefaultLevel used by a cronjob in the access control module to set default rights for commands without any rights yet.
 +
 +
 +===== Support for subcommands =====
 +The newest development version of bebot supports access control for the first level of subcommands. This is implemented as a straight extension of the existing access control system, with most of the interface fully downwards-compatible. The only function calls that have to be changed are calls to //accesscontrol -> check_rights()//.
 +
 +==== Subcommand field in table ====
 +Any information about access levels for subcommands are saved in the //subcommand// field of the access control table. This field contains either the full string of the subcommand or one of the two special chars $ and *.
 +
 +==== * special subcommand sign ====
 +* is a general placeholder for subcommands. It fits any subcommand, including empty subcommands. This is used to set a default access level for the command, and is the internal fallback for all subcommands that don't have their own subcommand entry. Any command must have this entry. It is created by the //accesscontrol -> create()// call.
 +
 +==== $ special subcommand sign ====
 +$ is used as a sign for empty subcommands, this means pure command calls without any parameter. Entries with $ as subcommand are optional, though if they exist they overwrite the * entry.
 +
 +==== Other subcommand strings ====
 +Every other subcommand string besides * and $ is used for exact string matches, though the there isn't made any difference between upper-case or lower-case subcommand entries and calls. In addition the subcommand string cannot contain any spaces, as those are used to catch the command, subcommand and any further parameter.
 +
 +==== Creating subcommand access restrictions ====
 +The default way to create access levels for subcommands is using the //accesscontrol -> create_subcommand($channel, $command, $sub, $defaultlevel)// function. This creates an entry for //$command// with subcommand //$sub// in channel //$channel// and default access level //$defaultlevel//.
 +
 +Another way to create access control entries for subcommands is using the the access control chat command //commands//. A call of ///tell <botname> !commands add channel command subcommand level// creates an entry for //command subcommand// in //channel// with default access level of //level//.
 +
 +==== Access level DELETED ====
 +The access level DELETED is used internally to specify that a subcommand entry is no longer valid. This means that any calls to the subcommand use the fallback to * now. You can set a new access level restriction with the chat command //commands add//. Calls to //accesscontrol -> create_subcommand()// don't overwrite this setting though.