aboutsummaryrefslogtreecommitdiffstats
path: root/tests/helpers.py (unfollow)
Commit message (Collapse)AuthorLines
2019-10-02Make ISODateTime return tz-unaware datetimeGravatar Sebastiaan Zeeff-1/+33
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.
2019-10-02Remove angle brackets from ISODateTime docstringGravatar Sebastiaan Zeeff-1/+1
This commit removes the angle brackets from the url in the docstring of `ISODateTime.convert`. The reason: it's ugly.
2019-10-02Apply docstring review suggestionGravatar Sebastiaan Zeeff-1/+1
Co-Authored-By: Mark <[email protected]>
2019-10-01Remove surplus quotation mark in class docstringGravatar Sebastiaan Zeeff-1/+1
Co-Authored-By: S. Co1 <[email protected]>
2019-10-01Add converter for ISO-formatted datetime stringsGravatar Sebastiaan Zeeff-0/+88
Related to https://github.com/python-discord/bot/issues/458 This commit adds a converter that automatically parses ISO-formatted datetime strings and returns a `datetime.datetime` object. It uses `dateutil.parser.isoparse` to do the heavy lifting, so it supports the same formats as this method. In addition, I have added tests that ensure that it accepts certain formats and added a description of these 'guaranteed' formats to the `ISODate.convert` docstring. This commit should make it easy to implement #485
2019-09-30Remove temp instructions, add link to contrib guide on website.Gravatar scragly-27/+1
2019-09-30Make `bot` wait for `web`, use `latest` web image.Gravatar scragly-2/+3
2019-09-29Do up some basic setup instructions for new setup.Gravatar scragly-0/+28
2019-09-28Update site to use new manage.py, add bot dev compose.Gravatar scragly-7/+20
2019-09-28Use pathlib, avoid inner `bot` directory for logs.Gravatar scragly-7/+6
2019-09-27Apply suggestions from code reviewGravatar S. Co1-2/+2
Co-Authored-By: Mark <[email protected]>
2019-09-28Lovely lemon let loose and forgot linting.Gravatar scragly-1/+1
2019-09-27Allow Rockstars and Partners to use !eval.Gravatar Leon Sandøy-7/+10
Anyone who is not a Rockstar, a Partner, or a member of staff will still be redirected to #bot-commands.
2019-09-27Ensure docker containers are published only for master branch builds.Gravatar scragly-1/+1
2019-09-26Remove invalid colorama markersGravatar S. Co1-2/+0
2019-09-26Update flake8-annotations & fix missing lintsGravatar S. Co1-10/+47
2019-09-26Use Command.cog_name attr instead of missing instance attrGravatar S. Co1-2/+2
2019-09-26Fix incorrect kwargs in watchchannel modlog sendGravatar S. Co1-2/+2
2019-09-26Parse timestamps with dateutil for watch channelsGravatar MarkKoz-5/+2
2019-09-26Use format_infaction datetime util in talentpoolGravatar Sebastiaan Zeeff-11/+5
The watchchannel ABC defined its own private utility function to format ISO datetime strings to something more human-readable. I have removed this private utility function and replaced the calls to it with calls to the new `format_infraction` utility function defined in bot.utils.time. In addition, I've changed the utility function to use `dateutil` to parse the datetime string, since `dateutil.parser.isoparse` supports the strings our API generates out of the box. With the built-in `datetime.datetime.fromisoformat`, we needed to prepare the string by slicing of the `Z` timezone indicator.
2019-09-26Add utility function to consistently format infraction timestampsGravatar MarkKoz-33/+18
The format used is %Y-%m-%d %H:%M.
2019-09-26Show when field is unchanged in infraction edit confirmation messageGravatar MarkKoz-0/+4
2019-09-25Display "Permanent" in mod log for edited infractionsGravatar MarkKoz-2/+2
2019-09-25Merge infraction edit commandsGravatar MarkKoz-108/+62
Both the duration and the reason can be edited with the new command. * Remove try-except; the default error handler is already adequate * Remove the new reason from the confirmation message * Simplify humanisation of the timestamp in the confirmation message * Add a converter to support permanent durations
2019-09-25Fix AttributeError with cog special methodsGravatar MarkKoz-4/+4
Discord.py's internals use the __func__ attribute of special methods (cog_command_error, cog_check, cog_before_invoke, cog_after_invoke). Therefore the methods must be bound methods rather than static so that the attribute exists.
2019-09-25Swapped Lambda for itemgetterGravatar Daniel Brown-1/+2
- For the sake of code style and consistency, the lambda has been swapped with operator.itemgetter Signed-off-by: Daniel Brown <[email protected]>
2019-09-25Free Command FixGravatar Daniel Brown-2/+2
- Moved the sorted function to its own line and instead passed the generated list for code clarity. Signed-off-by: Daniel Brown <[email protected]>
2019-09-25Free Command FixGravatar Daniel Brown-4/+4
- Fixed bug where if two channels had the same last message timestamp the command would error out. Signed-off-by: Daniel Brown <[email protected]>
2019-09-25Remove infraction reason from infraction confirmationGravatar S. Co1-53/+10
Closes #325
2019-09-25Unhide the tags commandGravatar S. Co1-1/+1
KAIZEN! Closes #385
2019-09-25Decouple warnings and notesGravatar S. Co1-1/+1
Closes #453
2019-09-25Remove permanent mutesGravatar S. Co1-89/+2
Add previous permanent mute invocations as aliases of their respective mute commands. Closes #318
2019-09-24Note Type CorrectionGravatar Daniel Brown-1/+1
- In the database, notes were being listed as "warnings" despite having a type specifically for them. Changed it so that notes are now listed as the proper type. Signed-off-by: Daniel Brown <[email protected]>
2019-09-25Add all the shieldsGravatar scragly-3/+7
2019-09-24Remove repeat logic for off-topic-name api callGravatar Sebastiaan Zeeff-6/+1
After a short discussion in the core-dev team, we decided to not use retry logic for a failed API call for new off-topic-names. We may introduce something similar in the future, but we're not sure on the direction we want to take yet.
2019-09-25Remove unnecessary sudo for pipenv install.Gravatar scragly-1/+1
2019-09-24Fix reminders filter queryGravatar S. Co1-2/+2
Closes #445
2019-09-25Remove regex wheel as dateparser is no longer used.Gravatar scragly-0/+0
2019-09-24Put import in alphabetical orderGravatar Matteo Bertucci-1/+1
2019-09-24Override waiting time to half an hour Gravatar Matteo Bertucci-1/+6
If an exception occurred
2019-09-24Fix importing errorGravatar Matteo Bertucci-1/+2
`bot.api.ResponseCodeError` is now imported
2019-09-24Prevent false-positives of the rich embed filterGravatar Sebastiaan Zeeff-15/+33
https://github.com/python-discord/bot/issues/293 The rich embed filter is plagued by false positives now Discord has added more custom preview embeds for various websites. Since these embeds have the `rich` type instead of the `link` type, these embeds triggered the filter we had in place. This commit remedies that by using the existing URL regex pattern to list all the URLs contained in the message content and then checking if the embed url is a member of that list. If so, it's very likely that the embed was auto-generated from that URL, so we should ignore it. This approach deviates slightly from that outlined in #293. This does increase the probability of a false-negative, as a "true" user-generated rich embed could also have a url that's contained in the message body. However, I've checked most of the triggers we have had in the past and none of the legitimate triggers would have been a false-negative under the new rules. Therefore, I think it's very reasonable to adopt this strategy. In addition to the change in behavior of the rich embed filter, I have also kaizened the existing regex patterns by compiling them at load time. Since we check a lot of regex patterns for every message received by the bot, this should be beneficial for performance.
2019-09-24Add `continue` in the except blockGravatar Matteo Bertucci-0/+1
2019-09-24Create default django admin user.Gravatar scragly-1/+3
2019-09-24Fix random text mistake in Dockerfile.Gravatar scragly-1/+1
2019-09-24Add docker build condition for CI.Gravatar scragly-0/+1
2019-09-24Remove unneeded Pipfile scripts and azure stages/vars.Gravatar scragly-51/+14