| Commit message (Collapse) | Author | Age | Lines |
| ... | |
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
Also updates the tests for this cog.
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
Instead of fetching the guild invite IDs from config-default.yml, we
will now be using the AllowDenyList cache to check these.
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
This includes commands to add, remove and show the items in the
whitelists and blacklists for the different list types.
Commands are limited to Moderators+.
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
Instead of just dumping the JSON response from the site, we'll build a
data structure that it will be convenient to access from our new cog,
and from the Filtering cog.
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
Currently, some types of errors are returning plain strings that repeat
the input (which can be exploited to deliver stuff like mentions), and
others are returning generic messages that don't give any exception
information.
This commit unifies our approach around putting as much information as
we can (including the exception message), but always putting it inside
an embed, so that stuff like pings will not fire.
This, combined with the 1.4.0a `allowed_mentions` functionality, seems
like a reasonable compromise between security and usability.
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
We'll use this to ensure the input is valid when people try to whitelist
or blacklist stuff. It will fetch its data from an Enum maintained on
the site, so that the types of lists we support will only need to be
maintained in a single place, instead of duplicating that data in the
bot and the site.
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
We shouldn't be making an API call for every single message posted, so
what we're gonna do is cache the data in the Bot, and then update the
cache whenever we make changes to it via our new AllowDenyList cog.
Since this cog will be the only way to make changes to this, this level
of lazy caching should be enough to always keep the cache up to date.
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
`LockGuard` was lonely and the decorators were cluttering up
decorators.py.
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
A mutex is the same thing as a lock. The former is a relatively esoteric
contraction, so the latter is preferred.
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
It was not being used anywhere.
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
Concerns were raised over possible race conditions due `asyncio.Lock`
internally awaiting coroutines. Does a mere `await` suspend the current
coroutine, or does it have to actually await something asynchronous,
like a future?
Avoid answering that question by doing away with the awaits, which
aren't necessary but are there as a consequence of using `asyncio.Lock`.
Instead, add a custom `LockGuard` object to replace the previous locks.
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
Clarify the significance of the argument being passed.
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
The annotation was previously changed on the basis of an incorrect
return annotation PyCharm inferred for `check()`.
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
The exception it raises reads better if the singular form of the word
is used.
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
Silent failure is confusing to users. Showing an error message clears up
why nothing happened with their command.
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
The exception will facilitate user feedback for commands which use the
decorator.
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
Instead of taking a callable, this wrapper just takes a name or position
to get the resource ID.
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
Explicit is better than implicit, and this default value wasn't much of
a convenience.
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
Replace the `_get_arg_value` call with `function.get_arg_value` cause
the latter makes use of bound arguments, which are more accurate.
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
This fixes race conditions between editing, deleting, and sending a
reminder. If one operation is already happening, the others will be
aborted.
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
This is a more advanced version meant to eventually replace the
`_get_arg_values` in decorators.py.
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
Bound arguments are more convenient to work with than the raw args
and kwargs.
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
Supporting ID retrieval by arg name or position made for a confusing
interface. I also doubt it would have been used much. A callable can
achieve the same thing, albeit with a little more code.
Now the decorator instead supports passing an ID directly or a callable.
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
This will be used to prevent race conditions on a resource by stopping
all other access to the resource once its been acquired.
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
It's fine to accept an int since it'll get converted to a string anyway.
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
Only one call was benefiting from that function also cancelling the
task. Therefore, the function was redundant and has been replaced with
a direct request to delete.
This change has the consequence of also fixing reminder tasks cancelling
themselves. That issue was potentially suppressing errors (such as the
duplicate DELETE request which was fixed earlier). Under normal
circumstances, the scheduler will automatically removed finished tasks
so tasks won't need to cancel/remove themselves.
|
| | |_|_|_|_|_|_|_|_|/
|/| | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
`send_reminder` already deletes the reminder so it's redundant to
delete it in the scheduled task too.
|
| | | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
This adds a little bit of logic to the Help Channel `init_available`
coroutine, which runs when the cog loads. This ensures that if there are
more help channels in available than there should be, we remove the
superfluos ones.
Previously, if the bot started with too many channels, it would maintain
and defend that excessive amount. This is because we never actually
count the number of channels before adding in new available channels
whenever one disappears.
If we ever get too many available channels in the future, this can be
solved by simply reloading this cog.
|
| |\ \ \ \ \ \ \ \ \ \
| | | | | | | | | | |
| | | | | | | | | | | |
Change regex so it catches new discord URL
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
requested by lemon
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | | |
|