Commands

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.