| Commit message (Collapse) | Author | Lines |
|
|
|
Closes #334
|
|
|
|
Co-Authored-By: Sebastiaan Zeeff <[email protected]>
|
|
|
|
* Document support for custom categories.
|
|
|
|
|
|
|
|
|
|
Co-Authored-By: Mark <[email protected]>
|
|
|
|
|
|
It doesn't make sense for these types of infractions to be "active".
Co-Authored-By: Sebastiaan Zeeff <[email protected]>
|
|
|
|
As we have decided that the converter should return naive datetime
objects, we should explicitly test that datetime strings with a
timezone offset are still converted to a naive datetime object. I
have done this by adding a `tzinfo is None` assertion.
|
|
|
|
|
|
|
|
Co-Authored-By: Sebastiaan Zeeff <[email protected]>
|
|
|
|
|
|
Co-Authored-By: scragly <[email protected]>
|
|
Co-Authored-By: scragly <[email protected]>
|
|
Co-Authored-By: scragly <[email protected]>
|
|
The parser we use, `dateutil.parsers.isoparse` returns a timezone-
aware or timezone-unaware `datetime` object depending on whether or
not the datetime string included a timezone offset specification.
Since we can't compare tz-aware objects to tz-unaware objects it's
better to make sure our converter is consistent in the type it will
return.
For now, I've chosen to return tz-unaware datetime objects, since
`discord.py` also returns tz-unaware datetime objects when accessing
datetime-related attributes of objects. Since we're likely to compare
"our" datetime objects to discord.py-provided datetime objects, I
think that's the most parsimonious option for now.
Note: It's probably a good idea to open a larger discussion about
using timezone-aware datetime objects throughout the library to
avoid a UTC-time being interpreted as localtime. This will require
a broader discussion than this commit/PR allows, though.
|
|
This commit removes the angle brackets from the url in the docstring
of `ISODateTime.convert`. The reason: it's ugly.
|
|
Co-Authored-By: Mark <[email protected]>
|
|
https://github.com/python-discord/bot/issues/482
There was small bug in the `cog_unload` method of the WatchChannel
ABC in `bot.cogs.watchchannels.watchchannel`. The problem was that it
tries to check if the Task assigned to `self._consume_task` is done
by accessing its `done` method. However, if a watch channel has not
yet relayed messages after the bot has started, it will not have a
consumption task yet, meaning this `_consume_task` attribute will be
assigned to `None`.
The solution is to change the `if` condition to:
`if self._consume_task and not self._consume_task.done():`
This commit closes #482
|
|
The two cogs will be listed under the same category in the help output.
|
|
* Rename already_has_active_infraction to has_active_infraction
* Fit some lines in utils to 100 columns
|
|
|
|
* Remove redundant discord.Colour() usage
* Fix type annotation of colour parameter for modlog.send_log_message()
* Use a cog check in superstarify to require moderation roles
|
|
|
|
|
|
|
|
* Cancel the task inside deactivate_infraction
|
|
* Shorten the mod log footer for pardons
|
|
|
|
|
|
|
|
* Use dateutil to parse expiration timestamp
|
|
|
|
|
|
* Display error in the confirmation message when the pardon fails
* Only attempt to remove the infraction from Discord once
|
|
* Rename to deactivate_infraction
* Send DM for unmute
* Log errors with logging module and to the mod log embed
* Return a dictionary representation of the mod log text
* Raise a ValueError for unsupported infraction types
|
|
|
|
|
|
The sub-package is now the extension instead of each module being a
separate extension. Thus, the setup methods are now useless.
|
|
|