Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Review who can change module's per-channel settings #17

Open
dgw opened this issue Feb 21, 2016 · 0 comments
Open

Review who can change module's per-channel settings #17

dgw opened this issue Feb 21, 2016 · 0 comments

Comments

@dgw
Copy link
Owner

dgw commented Feb 21, 2016

At least one channel owner requested that chanops be allowed to enable/disable bomb kicks (see dgw/sopel-BombBot#20), and a similar situation will eventually apply to this module when #4 is implemented. Some thought is required before making this change, so initially it will have the same restrictions as .duelself and .duelcw.

Admin access (+a) was chosen as a minimum because a lot of the channels my own bot instance runs in give op (+o) status to anyone who's part of the group that runs the channel (rather than only granting op to a select few "moderators"). Allowing any additional access levels to change any or all of the settings is worth careful consideration due to the sheer number of users that would suddenly be allowed to change things.

An alternative is to allow bot admins to change some or all of the settings, but that comes with its own risks. Ultimately the top channel leaders (+q and, to a lesser extent, +a) should have the absolute final say in what's enabled, and allowing bot admins to override their preferences feels almost as bad as letting bot admins use the bot's powers to kick people even if they themselves have no access on the channel in question (which Sopel's core adminchannel module explicitly disallows).

One solution is to allow chanops and/or bot admins to change the setting unless it was last modified by a channel admin+… but that gets complicated fast, and requires storing even more cruft in bot.db.

So yes: Definitely needs careful consideration. But this will definitely block on #6, because right now that needs to get done first. It might as well also block on #16 because who can change settings is tied up in how privileges are handled.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant