| Commit message (Collapse) | Author | Age | Lines |
|---|
| |\ |
|
| | |\
| | |
| | |
| | |
| | | |
python-discord/bug/backend/911/log-listener-exceptions
Log unhandled errors from event listeners
|
| | | |\
| | |/
| |/| |
|
| | |\ \
| | | |
| | | | |
Update to Antimalware Filter (.txt uploads)
|
| | | |\ \
| | |/ /
| |/| | |
|
| | |\ \ \
| | | | |
| | | | | |
Display animated avatars in the user info command
|
| | | | | | |
|
| | |/ / /
| | | |
| | | |
| | | | |
Fixes #914
|
| | | | |
| | | |
| | | |
| | | | |
than 2000 chars
|
| | | | |
| | | |
| | | |
| | | | |
longer than 2000 characters
|
| | |/ /
| | |
| | |
| | | |
longer than 2000 characters
|
| | | |
| | |
| | |
| | | |
help channel
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
By default, discord.py prints them to stderr. To better help detect such
errors in production, they should instead be logged with an appropriate
log level. Some sentry metadata has also been included.
`on_error` doesn't work as a listener in a cog so it's been put in the
Bot subclass.
Fixes #911
|
| | |\
| | |
| | | |
Sort help channels and add support for `how-to-get-help` channel
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
As we want to add an "informational" channel to the `Python Help: Available` category, we need to make sure that the Help Channel System ignores that channel.
To do that, I've added an `is_excluded_channel` staticmethod that returns `True` if a channel is not a TextChannel or if it's in a special EXCLUDED_CHANNELS constant. This method is then used in the method that yields help channels from a category and in the `on_message` event listener that determines if a channel should be moved from `Available` to `Occupied`.
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This commit reintroduces bottom sorting for help channels during a category move, but in a more reliable way that also causes far fewer "channel list glitches". This is accomplished by using the "bulk channels update" endpoint of the Discord API.
-----------
The Problem
-----------
Discord's positioning system is not that easy to work with for developers: Instead of having separate pools of position integers for each category, all text channels are considered to be part of the same "position pool" (or "bucket" in discord.py terms). This also means that changing the position integer of one channel may cause the position integer of another to change, regardless of if the channels share a category or even of if they are close to each other in the guild. As clients receive the position update for each channel as separate CHANNEL UPDATE events, this means that moving one channel may cause other channels to (temporarily) jump around as the client receives the EVENTS from the API. As some position changes affect all the channels in the guild, this will also trigger a nice "channel wave" rolling down the channel list from time to time.
For our use case, this was exacerbated by the way `discord.py` handles position changes: It will enumerate the entire, sorted channel list whenever a position change occurs and send a "bulk request" with updated position integers for the entire guild to Discord. This was the reason that all of the sorting methods we've tried resulted in a lot of those "wave" glitches as clients would get a lot of CHANNEL UPDATE events. In addition, the way `discord.py` inserted channels into the payload also meant that our "high integer" methods did not work reliably.
------------
The Solution
------------
Fortunately, there is a solution that will work well most of the time: Making a `bulk channels update` request with only channels of the category we're currently interested in. By providing the current position of the channels that are already in the category, combined with the correct position of the channel moving into the category, we effectively "lock in" the existing channels at the location they already have. The new channel is simply moved into the right position in relation to the existing channels.
This means that effectively, we only communicate one channel position change to Discord, making sure that as few channels as possible actually change their formal "position int".
From there on, there are two options:
1. Keep the existing channels in place, add the new channel at the bottom (new highest int)
2. Keep the existing channels in place, add the new channel at the top (new lowest int)
Both methods work, but option two has a flaw: The position int will get smaller and smaller, until it reaches `0`. Since negative position integers are not allowed, the entire category now has to be shifted upwards to make room for new top channels. This comes at the cost of a "wave" glitch within the category. My initial instinct was to solve this by giving the channels in the category a "really high" straight of position ints, but as Discord recalculates the ints from time to time anyway, this does not work.
That's why I opted for the `bottom sort` option, which does not suffer from that issue. I've also asked the question of `top` vs `bottom` in #admins, without the context above, and the preferred method seemed to be `bottom` in any case.
-----------
Limitations
-----------
While Discord doesn't care that much about duplicates or neatly ascending integers, some channel move actions will inevitably result in a recalculation of the positions ints. This means that "wave" glitches may still happen from time to time, but they should be infrequent. (They also happen if you drag channels in your client; it seems to be a fundamental part of how positioning works.) I think this is something we'll have to live with.
Another thing that I suspect may happen is that during times of API lag in the middle of help channel rush hour, some CHANNEL UPDATE events belonging to previous channel moves will not be received/processed yet by the time we make the next move. As we rely on cached position integers, this could mean that from time to time a channel is inserted near the bottom but not at the bottom. As Discord sends these CHANNEL UPDATE replies as individual events in an asynchronous manner instead of as a single response to our `bulk channels update` request, there's nothing much we can do about this. However, I have yet to observe this, so maybe it will never happen.
|
| | |\
| | |
| | | |
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
|
| | | |\ \
| | |/ /
| |/| | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | | |
Co-Authored-By: Shirayuki Nekomata <[email protected]>
|
| | | | |
| | | |
| | | | |
Co-Authored-By: Shirayuki Nekomata <[email protected]>
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
`BaseTransport.close()` is not a coroutine and therefore should not
be awaited.
|
Daniel Brown
Sebastiaan Zeeff
kwzrd
MarkKoz
Savant-Dev
Joseph Banks
Shirayuki Nekomata
Matteo Bertucci