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 #20

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

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

dgw opened this issue Feb 20, 2016 · 0 comments

Comments

@dgw
Copy link
Owner

dgw commented Feb 20, 2016

At least one channel owner requested that chanops be allowed to enable/disable bomb kicks. Some thought is required before making this change.

Admin+ was chosen as a minimum for .bombkickon/.bombkickoff to be consistent with who can enable/disable bombs in general via .bombson/.bombsoff. It's worth carefully considering the effects of changes to the minimum access level required to modify these settings, since 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").

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.

Not sure if this should happen before, after, or as part of #14, but for now it's a separate issue because it was specifically requested.

Should probably block on #8 and #19.

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