| Commit message (Collapse) | Author | Age | Lines |
| |
|
|
|
|
| |
The Limit values are mostly assumptions, as this feature is very
difficult to test at scale. Please see docstring amendmends for
further information.
|
| | |
|
| |
|
|
|
| |
Generic request dispatch method to avoid code duplication with error
handling & bad status logging.
|
| |
|
|
|
|
|
|
|
|
| |
Suppress errors coming from Discord when changing the confirmation
message in case it gets deleted, or something else goes wrong.
This commit also adds either the ok hand or the warning emoji to
the edited message content, as with the guild syncer confirmation.
Co-authored-by: MarkKoz <[email protected]>
|
| |
|
|
| |
Co-authored-by: MarkKoz <[email protected]>
|
| |
|
|
| |
Co-authored-by: MarkKoz <[email protected]>
|
| |
|
|
| |
Co-authored-by: MarkKoz <[email protected]>
|
| |
|
|
|
|
| |
This just reads better.
Co-authored-by: MarkKoz <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
| |
In an edge case, the `_kick_members` and `_give_role` could act on
a member who has verified *after* being marked by `_check_members`
as unverified.
To address this, we perform one additional check just before sending
the request. Testing seems to indicate that the `discord.Member`
instance get updates as appropriate, so this should at least reduce
the chances of such a race happening to very close to nil.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
If tasks are stopped manually, they will not automatically restart
on cog reload or bot restart.
Using `maybe_start_tasks` is necessary because we cannot interface
with Redis from a sync context.
We're using 1 and 0 because RedisCache does not currently permit
bool values due to a typestring conversion bug.
|
| |
|
|
|
|
|
|
|
|
| |
Allow checking whether tasks are running, starting them, and stopping
them.
Currently, the tasks cannot be started or stopped separately. It is not
believed that we would need such a level of granularity.
Calling `cancel` on a task that isn't running is a no-op.
|
| |\ |
|
| | |\
| | |
| | | |
Deps: update discord.py to 1.4.0
|
| | |/
| |
| |
| | |
It was released on PyPI. No longer need to clone via git.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
It now explains that new users can only see a limited amount of public
channels, and that there will be more once they verify.
Co-authored-by: Sebastiaan Zeeff <[email protected]>
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
We will begin pinging users in the verification channel, prompting
them to join. This can cause a surge of activity that may trigger
the filter.
A better solution would involve allowing per-filter channel config,
but after internal discussion this is seen as unnecessary for now.
|
| | | |
|
| |\|
| |
| |
| |
| | |
This adds the RedisCache #1090 fix, allowing us to use the cache
to hold the ping task on start-up.
|
| | | |
|
| | |\
| | |
| | |
| | |
| | | |
python-discord/bug/backend/1080/cog-reload-cancel-scheduler
Cancel scheduled tasks when cogs unload
|
| | | |\
| | |/
| |/| |
|
| | |\ \
| | | |
| | | | |
RedisCache: remove erroneous `_redis` alias
|
| | | |\ \
| | |/ /
| |/| | |
|
| | |\ \ \
| | | | |
| | | | | |
Source: raise BadArgument for dynamically-created objects
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The code is identical to the else block and there's no reason for
help commands to have an explicit check.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Commands, cogs, etc. created via internal eval won't have a source file
associated with them, making source retrieval impossible.
Fixes #1083
Fixes BOT-7K
|
| | | | | |
| | | | |
| | | | |
| | | | | |
This reverts commit 59c62162
|
| | |\ \ \ \
| | |/ / /
| |/| | | |
HelpChannels: use more reliable check for claimed channel
|
| | |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Using the channel's category isn't reliable since it may take Discord a
while to actually move the channel once it's received a request from the
bot. I suppose using redis technically has the same problem, but it
should be much faster and less susceptible to lag than Discord.
Fixes #1074
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
If a RedisCache instance was being accessed before bot has created
the `redis_cache` instance, the `_redis` alias was being set to
None, causing AttributeErrors in lookups.
See: #1090
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| | |
When cogs reload, they used new Scheduler instances, which aren't aware
of previously scheduled tasks. This led to duplicate scheduled tasks
when cogs re-scheduled tasks upon initialisation.
Fixes #1080
Fixes BOT-7H
|
| | |
| |
| |
| | |
This reverts commit be14db91b1c70993773e67cfa663fef0cfa85666.
|
| | |\
| | |
| | | |
Add support for plural FilterList types.
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| | |
This will allow mods to use '!whitelist get guild_invites'
in addition to '!whitelist get guild_invite'
This is just a naive implementation which works if the plural
form is a simple s at the end of the word. It's implemented
into the converter.
|
| | |
| |
| |
| |
| |
| |
| | |
Previously, this would not provide any feedback at all, which is really
terrible UX. Sorry about that.
This also adds error handling in case the API call fails.
|
| | | |
|
| | |\
| | |
| | | |
FilterLists: Manage whitelisting and blacklisting via the bot
|
| | | |\
| | |/
| |/| |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
Thanks @Den4200!
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
For deleting and listing data, we now get some more feedback when things
fail.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We want the !help invocations to give you all the information you need
in order to use the command. That also means we need to provide the
valid filterlist types, which are subject to change.
So, we fetch the valid ones from the API and then dynamically insert
them into the docstrings.
|
| | | | |
|