| Commit message (Collapse) | Author | Age | Lines |
| ... | |
| | | | | |
|
| | |/ / |
|
| | |\ \
| | | |
| | | | |
Improve LinePaginator to support long lines
|
| | | | |
| | | |
| | | | |
Co-authored-by: Mark <[email protected]>
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
* Since LinePaginator now supports long lines, there's no need to
shorten the nomination reason to 200 characters.
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | | |
Co-authored-by: Leon Sandøy <[email protected]>
|
| | | | |
| | | |
| | | | |
Co-authored-by: Leon Sandøy <[email protected]>
|
| | | |\ \
| | |/ /
| |/| | |
|
| | |\ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
python-discord/bug/backend/bot-50/sync-ignore-guilds
Sync: ignore events from other guilds
|
| | | |\ \ \
| | |/ / /
| |/| | | |
|
| | |\ \ \ \
| | | | | |
| | | | | | |
Created tests for startup logging
|
| | | |\ \ \ \
| | |/ / / /
| |/| | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
- Remove embed attributes checks
- Replace `self.dev_log.assert_awaited_once_with` with `self.dev_log.assert_awaited_once`.
|
| | | |\ \ \ \ |
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Need to compare the IDs against each other rather than the Guild object
against the ID.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
404s probably mean the user is from another guild.
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | |\ \ |
|
| | | | | | | | | |
|
| | | | | | | | | |
|
| | | | | | | | | |
|
| | | | | | | | |
| | | | | | | |
| | | | | | | | |
Co-authored-by: Kieran Siek <[email protected]>
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
* Exclude all sequences/mapping types rather than excluding by name
* Replace MEMBER_CHANGES_SUPPRESSED with excludes as DeepDiff args
* Don't keep track of "done" attributes - there shouldn't be dupes
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
This was preventing diffs for added nicknames from showing, among
other things.
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
The correct event for user changes is on_user_update, so this code
does nothing in the on_member_update event.
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
`iterable_item_removed` and `iterable_item_added` lack `new_value` and
`old_value`. Instead, they just contain the actual value added or
removed. The code was incorrectly trying to access old and new values
for the iterable changes.
The iterable changes are only useful for the role diff, but they aren't
even needed for that. The role diff calculation has been refactored to
always get the diff rather than doing it only if it sees there has
been a change to the `_roles` attribute.
To be clear, `_roles` only has IDs, which is why its diff isn't that
useful anyway. To use it, the code would have to get the Role objects,
which is basically what the `roles` property already does. `_cs_roles`
seems to be some Role object cache, but its reliability is unclear.
|
| | | | | | | | | |
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
It'd fail to schedule the coroutine otherwise anyway. There is also the
potential to close the coroutine, which may be unexpected to see for a
coroutine that was already running (despite being documented).
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Showing the task ID in the logs makes them distinguishable from logs for
other tasks.
The coroutine state is logged because it may come in handy while
debugging; the coroutine inspection check hasn't been proven yet in
production.
|
| | | | | | | | | |
|
| | | | | | | | | |
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
The coroutine may cancel the scheduled task, which would also trigger
the finally block. The coroutine isn't necessarily finished when it
cancels the task, so it shouldn't be closed in this case.
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
The task is already popped from the dict, so there is no need to delete
it afterwards.
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
This prevents unawaited coroutine warnings.
|
| | | | | | | | | |
|
| | | | | | | | | |
|