Role Based Access System Discussion

Table of Contents Some Recipes for Access Levels Default (base `config.json`) Default with Flexible Tagging Default with Conservative Tagging Very Permissive with Flexible Tagging Very Permissive with Conservative Tagging Whitelist with Conservative Tagging Very Restrictive with Conservative Tagging Old Documentation HOWTO: Custom Access Control Documented Behaviours Default Behaviour "Whitelist" Mode Role-based Access (WIP)

Some Recipes for Access Levels

Some of these may be out-of-date, feel free to modify this page based on your experiences and observations with the tags-based access control mechanism.

Note: Admins can always run all commands

Default (base `config.json`)

• Basically, the starting configuration for new bots
• Users can run any plugin-determined user command
• No tagging - tagged users will have same access as untagged users

Default with Flexible Tagging

"commands_tagged": [ ... ]

• Users can execute any plugin-determined user command
• Admins can only block users from executing tagged commands

Default with Conservative Tagging

"commands.tags.escalate": true,
"commands_tagged": [ ... ]

• Users can execute any plugin-determined user command, except if also listed in `commands_tagged`
• Tagged users can execute matching commands from `commands_tagged`
• Admins must explicitly assign tags to users to execute commands in `commands_tagged`

Very Permissive with Flexible Tagging

"commands_user": true,
"commands_tagged": [ ... ]

• Users can run ALL commands
• Admins can only block users from executing tagged commands

Very Permissive with Conservative Tagging

"commands_user": true,
"commands.tags.escalate": true,
"commands_tagged": [ ... ]

• Users can run ALL commands, except those listed in `commands_tagged`
• Tagged users can execute matching commands from `commands_tagged`
• Admins must explicitly assign tags to users to execute commands in `commands_tagged`

Whitelist with Conservative Tagging

"commands_user": [ ... ],
"commands.tags.escalate": true,
"commands_tagged": [ ... ]

• Users can execute any command from `commands_user` list, except if also listed in `commands_tagged`
• Tagged users can execute matching commands from `commands_tagged`
• Admins must explicitly assign tags to users to execute commands in `commands_tagged`

Very Restrictive with Conservative Tagging

"commands_admin": true,
"commands.tags.escalate": true, # or not set
"commands_tagged": [ ... ]

• Users cannot execute any command
• Tagged users can execute matching commands from `commands_tagged`
• Note: Setting "commands.tags.escalate" won't matter, as all commands are already admin-only

Old Documentation

Following section is older documentation, and is preserved for reference purposes - most likely out of date

HOWTO: Custom Access Control

[Moved](https://github.com/hangoutsbot/hangoutsbot/wiki/Customising-Access-Control#rolling-your-own-access-control)

Documented Behaviours

Default Behaviour

• Plugins register commands as either admin-level or user-level commands
• User-level commands can be elevated to admin-level via:

  * `config.commands_admin`
  * `config.conv.convid.commands_admin` (highest priority)

"Whitelist" Mode

• Can be triggered on a per-conversation or global level
• Any command can be downgraded to user-level via:

  * `config.commands_user` - globally overrides Default Behaviour
  * `config.conv.convid.commands_user` (highest priority)
    * any other conversation still runs with Default Behaviour

Role-based Access (WIP)

Note: This is a work-in-progress - this section contains speculation, hearsay, arguments

  and current developments and is subject to change ;P

Related Issue: https://github.com/hangoutsbot/hangoutsbot/issues/121

Expected behaviours

• Overrides all other behaviours
  • Would be too confusing otherwise to dev and use properly
• Makes use of per-user memory.json to store individual roles
  • Requires modification of some plugins to standardise this behaviour
  • Structure may lead to inefficiencies when searching for matching roles in a userlist, may require dual usage of original structure and the per-user memory entry
• Default roles for all users set in config.json

In current dev branch:

• For users, roles can be defined via

  1. global
     * `"roles" : { "role1": [user_id], " role2": [user_id]}`

• For commands, roles can be assigned via:

  1. global
     * `"command_role1": [cmd1, cmd2]`
  2. per-conversation
     * `"command_role1": [cmd1, cmd2]`