| Commit message (Collapse) | Author | Lines |
|---|
|
|
|
* Show the user in the post_infraction error log message
|
|
There's now a check to see if the `user` argument (possibly a
`discord.Object`) needs to be made a `User`, instead of doing so
directly, to avoid unnecessary requests to the Discord API. Besides
that, a possible HTTPException is catched if it the fetch fails,
cancelling the message to be send to the user (which would make the
following calls fail later on for not being of the proper type.)
|
|
This changes also removes the original `proxy_user` used by
`watchchannels` the attributes in its `discord.Object` object to the one
returned by FetchedUser.
|
|
|
|
It turns out how it was originally was the best idea. Now the
`infractions` module imports `FetchedUser` and makes a `typing.Union`
between it and `utils.UserTypes`. The usage of `FetchedUser` isn't
needed in `utils` at all, and it shouldn't be used for/as type hinting there.
|
|
|
|
|
|
Co-Authored-By: Mark <[email protected]>
|
|
|
|
|
|
The `proxy_user` function now belongs to the `Converters` module,
since its use is directly related to it. `FetchedUser` uses this
function if there's an error trying to fetch and it doesn't indicate
a non existing user.
Technically finished and working.
|
|
|
|
The FetchedUser Converter now counts with a `proxy_user` helper function (which
SHOULD NOT be there) to return a user as a last resource, in case
there was an issue fetching from the Discord API, as long as the error
isn't that there's no user with the given ID.
|
|
Now `post_user(...)` expects either a `discord.User` or a
`discord.Object` object as `user`. Either way, it will try to take the relevant
attributes from `user` to fill the DB columns. If it can't be done,
`.avatar_hash`, `.discriminator`, and `name` will take default values.
|
|
|
|
It's important to us that we keep the information we have about users
in the database in sync with the actual user information the bot can
observe in our guild. To do this, we relied on the `on_member_update`
event listener to synchronize a user's information when an update of
the information was detected. However, unfortunately, this does not
work for user account information (i.e., the username, avatar, and
discriminator of the user).
The solution is to use the `on_user_update` event listener to watch
for updates in the user settings and to use the `on_member_update`
event listener to watch for updates in guild-related information for
that user. (We currently only sync the roles the user has.)
See:
- https://discordpy.readthedocs.io/en/stable/api.html#discord.on_member_update
- https://discordpy.readthedocs.io/en/stable/api.html#discord.on_user_update
Note:
The docs for `discord.py` make it *seem* like the `on_member_update`
event does not fire for updates of theusername, discriminator, and
avatar attributes. However, experimentation shows that this event
*does* fire; it's just that the member objects provided as `before`
and `after` to the listener will already have been updated in cache
by the `on_user_update` event that fires *before* it.
This means that if the only changes made were to the username,
avatar, and discriminator, the `on_member_update` event does fire,
but with two *equal* Member objects. This makes it appear as if you
may be able to use `on_member_update`, since it fires, but it does
not actually contain anything useful.
|
|
Try twice to apply the infraction. If the user is not in the database,
try to add it, then try to apply the infraction again.
This allows any moderation function that uses `FetchedUser` as a
converter to apply the infraction even when the user is absent in the
local database.
|
|
As it is now, this function is planned to be used a big-helper in
`post_infraction`. Its interface is partially similar: it will return
a "JSON" dictionary if everything went well, or `None` if it
failed. If it fails, it will send a message to the channel and
register the issue in the `log`.
|
|
|
|
This `discord.ext.commands.Converter` fetches a user from the Discord
API and returns a `discord.User` object. This should replace the
`proxy_user` function from the moderation `utils`.
|
|
|
|
|
|
Similar to `format_infraction_with_duration` ( if not outright copying it ), added 3 tests for `until_expiration`:
- None `expiry`.
- Custom `max_units`.
- Normal use cases.
|
|
`format_infraction_with_duration`
- `until_expiration` was being a pain to unittests without a `now` ( default to `datetime.utcnow()` ). Adding an optional argument for this will not only make writing tests easier, but also allow more control over the helper function should we need to calculate the remaining time between two dates in the past.
- Changed typehint for `date_from` in `format_infraction_with_duration` to `Optional[datetime.datetime]` to better reflect what it is.
|
|
|
|
|
|
|
|
This make the channel specifiable without the amount.
Co-Authored-By: scragly <[email protected]>
|
|
|
|
|
|
|
|
|
|
It will attempt to find the most recent infraction authored by the
invoker of the edit command.
|
|
|
|
Messages are deleted after a delay of 10 seconds. This helps keep the
channel clean. The periodic ping is an exception; it will remain.
|
|
|
|
|
|
|
|
Raising an exception allows the error handler to display a message to
the user if the failure happened from a command invocation.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The object is basically just a namedtuple so there's no need to
re-create it every time a token is obtained.
* Remove log message which shows credentials.
* Initialise headers attribute to None in __init__.
|
|
This removes the duplicate code for renewing the token. Since
fetch_posts is the only place where the token gets used, it can just be
refreshed there directly.
|
|
|
|
|
MarkKoz
Manuel Ignacio Pérez Alcolea
Sebastiaan Zeeff
Shirayuki Nekomata
Joseph