| Commit message (Collapse) | Author | Age | Lines |
| ... | |
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
This will help catch anything that tries to get/set an attribute/method
which doesn't exist. It'll also catch missing/too many parameters being
passed to methods.
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
Because some of the redis pool/connection methods return futures rather
than being coroutines, the redis pool had to be mocked using the
CustomMockMixin so it could take advantage of `additional_spec_asyncs`
to use AsyncMocks for these future-returning methods.
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
The fix is to mock the loop and pass it to the Bot. It will then set
it as `self.loop` rather than trying to get an event loop from asyncio.
The `create_task` patch has been moved to this loop mock rather than
being done in MockBot to ensure that it applies to anything calling it
when instantiating the Bot.
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
I'm not sure how it even managed to work before. It was calling the
`post` coroutine (without specifying a URL) and then changing
`__aenter__`. Now, a separate mock is created for the context manager
and the `post` simply returns that mocked context manager.
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
The assertion wasn't using the assertion method. Furthermore, it was
testing a non-existent function `create_loop` rather than `create_task`.
|
| | | | | | | | | | | | |
|
| | | | | | |_|/ / / /
| | | | |/| | | | | |
|
| | | | | | | | | | | |
|
| | | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
for embed descriptions
|
| | | | | | | | | | | |
|
| | | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
test_get_disallowed_extensions
|
| | | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
extensions and added a test for it.
|
| | | | | | | | | | | |
|
| | | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
Co-authored-by: Mark <[email protected]>
|
| | | | | | | | | | | |
|
| | | | | | | | | | | |
|
| | | | | | | | | | | |
|
| | | | | | | | | | | |
|
| | | | | | | | | | | |
|
| | | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
meantime.
|
| | | | | | | | | | | |
|
| | | | | | | | | | | |
|
| | | | | | | | | | | |
|
| | | | |/ / / / / / |
|
| | | | | | | | | | |
|
| | | | | | | | | | |
|
| | | | | | | | | | |
|
| | | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
Replace `{"foo": "bar"}` with `{"id": 1}`
|
| | | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
To allow `.get`, I had to replace `str` return value with `dict`
|
| | | | | | | | | | |
|
| | | | | | | | | | |
|
| | | |\ \ \ \ \ \ \
| | | | |/ / / / /
| | | |/| | | | | |
|
| | | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
- Remove unnecessary space from placeholder
- Rename `has_active_infraction` to `get_active_infraction`
|
| | | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
Co-authored-by: Leon Sandøy <[email protected]>
|
| | | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
removed unnecessary type hint and added comment to kick truncation test about awaiting `kick`.
|
| | | | | | | | | | |
|
| | | | | | | | | | |
|
| | | | |_|_|/ / /
| | |/| | | | | |
|
| | | |/ / / / /
| |/| | | | | |
|
| | |\ \ \ \ \ \
| | | |_|_|/ /
| | |/| | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
As @mathsman5133 pointed out, it's better to use the `Command`-instance
we typically already have in the current context than to rely on parsing
the qualified name again.
The invocation is now done as: `await ctx.send_help(ctx.command)`
|
| | | | |/ / /
| | |/| | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
After the refactoring of the help command, we need to use the built-in
method of calling the help command: `Context.send_help`. As an argument,
the qualified name (a string containing the full command path, including
parents) of the command can be passed.
Examples:
- await ctx.send_help("reminders edit")
This would send a help embed with information on `!reminders edit` to
the Context.
- await ctx.send_help(ctx.command.qualified_name)
This would extract the qualified name of the command, which is the full
command path, and send a help embed to Context.
- await ctx.send_help()
This will send the main "root" help embed to the Context.
|
| | |/ / / / |
|
| |/ / / / |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| | | | |
| | | |
| | | |
| | | | |
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.
|