| Commit message (Collapse) | Author | Age | Lines |
| ... | |
| |\ \ \ \ \
| | | | | |
| | | | | | |
Allowing `!eval` in help channels
|
| | |\ \ \ \ \
| |/ / / / /
|/| | | | | |
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | | |
Use a role overwrite to keep track of help channel cooldowns
|
| | |\ \ \ \ \ \
| |/ / / / / /
|/| | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
People are more familiar with the "close" alias than its actual name,
"dormant". "close" also feels more natural.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
A NotFound error can be misleading since it may apply to the member or
the role. The log message was not simply updated because each of the
scenarios need to have different log levels: missing members is a normal
thing but an invalid role is not.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
This will allow `_change_cooldown_role` to handle the role argument
rather than putting that burden on the callers.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
* Remove obsolete log message
* Shorten a log message which was the only line in the entire module
over 100 characters
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
A user may leave the guild before their role can be changed. Sometimes,
there could also be role hierarchy issues or other network issues. It's
not productive to halt everything and just dump these as exceptions to
the loggers. The error handler provides a more graceful approach to
these exceptions.
* Add a wrapper function around `add_roles` & `remove_roles` which
catches exceptions
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Resetting permissions relied on getting the member from the cache, but
the member was already removed from the cache prior to resetting the
role. Now the member is passed directly rather than relying on the
cache.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Users should know they can close their own channels.
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Overwrites had issues syncing with channels in the category.
* Remove update_category_permissions; obsolete
* Add constant for the cooldown role wrapped in a discord.Object
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Claimants will have a special role that needs to be removed rather than
using member overwrites for the category.
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
The `in_whitelist` decorator should not fail when a decorated command was called in a DMChannel; it should simply conclude that the user is not allowed to use the command. I've added a test case that uses a DMChannel context with User, not Member, objects.
In addition, I've opted to display a test case description in the `subTest`: Simply printing the actual arguments and context is messy and does not actually show you the information you'd like. This description is enough to figure out which test is failing and what the gist of the test is.
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
The API of the `in_whitelisted_context` decorator was a bit clunky:
- The long parameter names frequently required multiline decorators
- Despite `#bot-commands` being the defacto default, it needed to be passed
- The name of the function, `in_whitelisted_context` is fairly long in itself
To shorten the call length of the decorator, the parameter names were shortened by dropping the `whitelisted_` prefix. This means that the parameter names are now just `channels`, `categories`, and `roles`. This already means that all current usages of the decorator are reduced to one line.
In addition, `#bot-commands` has now been made the default redirect channel for the decorator. This means that if no `redirect` was passed, users will be redirected to `bot-commands` to use the command. If needed, `None` (or any falsey value) can be passed to disable redirection. Passing another channel id will trigger that channel to be used as the redirection target instead of bot-commands.
Finally, the name of the decorator was shortened to `in_whitelist`, which already communicates what it is supposed to do.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
As help conversations now take place in their own, dedicated channels, there's no longer a pressing need to restrict the `!eval` command in help channels for regular members. As the command can be a valuable tool in explaining and teaching Python, we've therefore chosen to allow it in channels in `Help: Available` and `Help: Occupied` catagories.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
I have added tests for the new `in_whitelisted_context` decorator. They work by calling the decorator with different kwargs to generate a specific predicate callable. That callable is then called to assess if it comes to the right conclusion.
|
| | | | | | | | |
|
| | |/ / / / /
|/| | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The `in_channel` decorator that served as a factory for `in_channel` checks was replaced by the broaded `in_whitelisted_context` decorator. This means that we can now whitelist commands using channel IDs, category IDs, and/or role IDs. The whitelists will be applied in an "OR" fashion, meaning that as soon as some part of the context happens to be whitelisted, the `predicate` check the decorator produces will return `True`.
To reflect that this is now a broader decorator that checks for a whitelisted *context* (as opposed to just whitelisted channels), the exception the predicate raises has been changed to `InWhitelistedContextCheckFailure` to reflect the broader scope of the decorator.
I've updated all the commands that used the previous version, `in_channel`, to use the replacement.
|
| |\ \ \ \ \ \
| |_|/ / / /
|/| | | | | |
Free tag
|
| | |\ \ \ \ \
| |/ / / / /
|/| | | | | |
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | | |
Fix category cache issue
|
| |/ / / / / / |
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | | |
Answered help session statistics
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| |/ / / / / /
| | | | | |
| | | | | |
| | | | | | |
anyone but the claimant
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | | |
Co-Authored-By: Shirayuki Nekomata <[email protected]>
|
| | | | | | |
| | | | | |
| | | | | | |
Co-Authored-By: Shirayuki Nekomata <[email protected]>
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | | |
Co-authored-by: Joseph Banks <[email protected]>
|
| | | | |\ \ \ |
|
| | | | | | | |
| | | | | | |
| | | | | | | |
Co-authored-by: Sebastiaan Zeeff <[email protected]>
|
| | | | | | | |
| | | | | | |
| | | | | | | |
Co-authored-by: Joseph Banks <[email protected]>
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
In `News` cog PEP news posting, define `utf-8` as encoding on response parsing to avoid the error.
Co-authored-by: Joseph Banks <[email protected]>
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | |/ / /
| | | | | |
| | | | | |
| | | | | | |
confusion
|
| | | | | | | |
|
| | | | | | | |
|