| Commit message (Collapse) | Author | Age | Lines |
|---|
| ... | |
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This check was no longer being used anywhere, having been replaced by
in_whitelist_check.
|
| | | | | | | |
|
| | | |_|/ /
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
We're moving the actual predicate into the `utils.checks` folder, just
like we're doing with most of the other decorators. This is to allow us
the flexibility to use it as a pure check, not only as a decorator.
This commit doesn't actually change any functionality, just moves it
around.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Also added a test for this.
This is the DRYest approach I could find. It's a little ugly, but I
think it's probably good enough.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The way we were doing the asyncio.Lock() stuff for increment was
slightly problematic. @aeros has adviced us that it's better to just
initialize the lock as None in __init__, and then initialize it inside
the first coroutine that uses it instead. This ensures that the correct
loop gets attached to the lock, so we don't end up getting errors like
this one:
RuntimeError: got Future <Future pending> attached to a different loop
This happens because the lock and the actual calling coroutines aren't
on the same loop. When creating a new test, test_increment_lock, we
discovered that we needed a small refactor here and also in the test
class to make this new test pass.
So, now we're creating a DummyCog for every test method, and this will
ensure the loop streams never cross. Cause we all know we must never
cross the streams.
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This just tests that the various RuntimeErrors are reachable - that
includes the error about not having a bot instance, the one about not
being a class attribute, and the one about not having instantiated the
class.
This test addresses a concern raised by @MarkKoz in a review.
I've decided not to test that actual contents of these RuntimeErrors,
because I believe that sort of testing is a bit too brittle. It
shouldn't break a test just to change the content of an error string.
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This is a simple validation that only check the type of the collection.
It does not validate the types inside the collection because that has
proven to be quite complex.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Note that `Optional[x]` is just an alias for `Union[None, x]` so this
effectively supports `Optional` too.
This was especially troublesome because the redis password must be
unset/None in order to avoid authentication, but the test would complain
that `None` isn't a `str`. Setting to an empty string would pass the
test but then make redis authenticate and fail.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Changed a RuntimeError to a KeyError (thanks @MarkKoz), and also added
some tests to ensure that the right errors are raised whenever this
method is used incorrectly.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Forgot to update the additional_spec_asyncs when changing the name of
this Bot attribute to be public.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Sometimes, we just want to store a counter in the cache. In this case,
it is convenient to have a single method that will allow us to increment
or decrement this counter.
These methods allow you to decrement or increment floats and integers by
an specified amount. By default, it'll increment or decrement by 1.
Since this involves several API requests, we create an asyncio.Lock so
that we don't end up with race conditions.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
There really was no compelling reason why this method should return an
AsyncIterator or than that `async for items in cache.items()` has nice
readability, but there were a few concerns. One is a concern about race
conditions raised by @SebastiaanZ, and @MarkKoz raised a concern that it
was misleading to have an AsyncIterator that only "pretended" to be
lazy.
To address these concerns, I've refactored it to return a regular
ItemsView instead.
I also improved the docstring, and fixed the relevant tests.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
It's not feasible to mock it because all the commands return futures
rather than being coroutines, so they cannot automatically be turned
into AsyncMocks. Furthermore, no code should ever use the redis session
directly besides RedisCache. Since the tests for RedisCache already use
fakeredis, there's no use in trying to mock redis in MockBot.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Thanks to @kwzrd for this idea, basically we're making a constant with
the typestring prefixes and iterating that in all our converters.
These converter functions will also now raise TypeErrors if we try
to convert something that isn't in this constants list.
I've also added a new test that tests this functionality.
|
| | | | | | |
|
| |\| | | | |
|
| | |\ \ \ \ |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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.
|
| | |/ / / |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
This commit just alters existing code to work with the new interface,
and with async. All tests are passing successfully.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The .set and .get will accept ints, floats, and strings. These will be
converted into "typestrings", which is basically just a simple format
that's been invented for this object.
For example, an int looks like `b"i|2423"`. Note how it is still stored
as a bytestring (like everything in Redis), but because of this prefix
we are able to coerce it into the type we want on the way out of the db.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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`.
|
| | | | | |
|
| |/ / / |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | | | |
|
| |/ /
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |/
|
| |
Replaced `TimeoutError` with `asyncio.TimeoutError`.
|
| |
|
|
|
|
| |
The "unsilence" action of the silence/hush command used `send_messages=True` when unsilencing a hushed channel. This had the side effect of also enabling send messages permissions for those with the Muted rule, as an explicit True permission apparently overwrites an explicit False permission, even if the latter was set for a higher top-role.
The solution is to revert back to the `Inherit` permission by assigning `None`. This is what we normally use when Developers are allowed to send messages to a channel.
|
| |\ |
|
| | | |
|
| | |
| |
| |
| |
| | |
Should return 1st arg (or None) if eval cmd in message, otherwise return
full content.
|
| | | |
|
| | |
| |
| |
| |
| | |
The tasks extensions loop requires an event loop to exist. To work
around this, it's been mocked.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
discord.py yields duplicate Command objects for each alias a command
has, so the duplicates need to be removed on our end.
|
| | |
| |
| |
| |
| | |
* Rename `walk_extensions` to `walk_modules` because some extensions
don't consist of a single module
|
Leon Sandøy
MarkKoz
Leon Sandøy
Dennis Pham
Sebastiaan Zeeff
Numerlor
ks129
Sebastiaan Zeeff
Eivind Teig