| Commit message (Collapse) | Author | Age | Lines |
| ... | |
| | |\ \ \ \ \ \ \ \ \ \
| |/ / / / / / / / / /
|/| | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
Add upstream changes & resolve config conflicts introduced by #1041.
In the conflicting parts of the diff, this commit also re-sorts
constants which were added upstream to lexicographical order.
This does **not** re-sort all constants added upstream.
|
| |\ \ \ \ \ \ \ \ \ \ \
| |_|_|/ / / / / / / /
|/| | | | | | | | | | |
Update or-gotcha.md
|
| | |\ \ \ \ \ \ \ \ \ \
| |/ / / / / / / / / /
|/| | | | | | | | | | |
|
| |\ \ \ \ \ \ \ \ \ \ \
| |_|_|/ / / / / / / /
|/| | | | | | | | | | |
Invoke fuzzywuzzy's processor before matching
|
| | |\ \ \ \ \ \ \ \ \ \
| |/ / / / / / / / / /
|/| | | | | | | | | | |
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
Fixes a regression where the string to be matched was not processed
beforehand.
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
Trying to match a string with only non-alphanumeric characters
results in a warning by fuzzywuzzy.
Processing the string before matching lets us avoid the warning, which
which uses the root logger and thus isn't supressible.
|
| | | |\ \ \ \ \ \ \ \ \
| |_|/ / / / / / / / /
|/| | | | | | | | | | |
|
| |\ \ \ \ \ \ \ \ \ \ \
| | | | | | | | | | | |
| | | | | | | | | | | | |
DM relay - minor fixes
|
| | |\ \ \ \ \ \ \ \ \ \ \
| |/ / / / / / / / / / /
|/| | | | | | | | | | | |
|
| | | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
https://github.com/python-discord/bot/issues/1041
|
| | | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
Weird.
https://github.com/python-discord/bot/issues/1041
|
| | | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
When we're using the !reply command, using a regular UserConverter is
somewhat problematic. For example, if I wanted to send the message
"lemon loves you", then I'd try to write `!reply lemon loves you` -
however, the optional User converter would then try to convert `lemon`
into a User, which it would successfully do since there's like 60 lemons
on our server.
As a result, the message "loves you" would be sent to a user called
lemon.. god knows which one.
To solve this bit of ambiguity, I introduce a new converter which only
converts user mentions or user IDs into User, not strings that may be
intended as part of the message you are sending.
https://github.com/python-discord/bot/issues/1041
|
| | | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
Co-authored-by: Sebastiaan Zeeff <[email protected]>
|
| | | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
https://github.com/python-discord/bot/issues/1041
|
| | | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
Without this, it is difficult to know precisely who the user that is
DMing us is, which might be useful to us.
https://github.com/python-discord/bot/issues/1041
|
| | | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
This reverts commit 042f472a
|
| | | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
Co-authored-by: Sebastiaan Zeeff <[email protected]>
|
| | | | | | | | | | | | | |
|
| | | | | | | | | | | | | |
|
| | | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
Adjust description and include link to docs
|
| | | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
Co-authored-by: MarkKoz <[email protected]>
|
| | | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
Suggested by Mark during review. If the download fails, we fallback
on showing an informative message, which will link the attachment
cdn link.
The attachment-handling logic was moved from the `archive` coroutine
into `make_embed`, which now also returns the file, if available.
In the end, this appears to be the smoothest approach.
Co-authored-by: MarkKoz <[email protected]>
|
| | | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
Co-authored-by: MarkKoz <[email protected]>
|
| | | | | |\ \ \ \ \ \ \ \ |
|
| | | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | | |
Co-authored-by: MarkKoz <[email protected]>
|
| | | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | | |
Co-authored-by: MarkKoz <[email protected]>
|
| | | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | | |
Better than building the set manually. Tested against regression by
comparing the two sets for equality.
Suggested by vivax.
Co-authored-by: vivax3794 <[email protected]>
|
| | | | | |\ \ \ \ \ \ \ \ \ |
|
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
There is no handling of file types as explained in the `archive`
docstring. Testing indicates that relaying incidents with e.g. a text
file attachment is simply a noop in the Discord GUI.
If there is at least one attachment, we always only relay the one
at index 0, as it is believed the user-sent messages can only contain
one attachment at maximum.
This also adds an extra test asserting the behaviour when an incident
with an attachment is archived. The existing test for `archive` is
adjusted to assume no attachments.
Joe helped me conceive & test this.
Co-authored-by: Joseph Banks <[email protected]>
|
| | | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
This applies the previously defined `make_embed` function.
As the `archive` function is now simpler, I decided to reduce the
amount of whitespace ~ it's a lot more compact now.
Tests are adjusted as appropriate.
|
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
See `make_embed` docstring for further information.
The tests are fairly loose and should be easily adjustable in
the future should changes be made.
|
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
This is an important piece of information that shall be relayed.
|
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
Decision was made to use embeds to archive incidents instead of
webhooking the raw message. As such, we're reverting the branch
to a state from which the adjustments will be easier to make.
Reverted commits:
* a8d179d9b04f54b20c5e870bcfa85c78c42c8dca
* 6fa8caed037b247a7c194f58a4635de7dae21fd2
|
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
Incident author and the moderator who actioned report are now passed
through `make_username` to create the webhook username.
Tests adjusted as appropriate.
|
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
The justification is to incorporate the `actioned_by` name into the
username in some way, and so the logical thing to do is to abstract
this process into a helper so that it can easily be adjusted in the
future. For now, I've chosen to separate the names by a pipe.
Discord webhook username cannot exceed 80 characters in length, and
so we cap it at this length by default. This is seen as more of an
edge-case, but it should be accounted for, as we're not joining two
names. The `max_length` param is configurable primarily for testing
purposes, it probably should never be passed explicitly.
This commit also provides two tests for the function.
|
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
See: a8b4e394d9da57287cd9497cd9bb0a97fa467e84
|
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
With PR #1009 merged, we now apply the same fix to our relay function.
This prevents the "clyde" word from sneaking into the webhook username,
which is forbidden and will return a 400.
|
| | | | | |\ \ \ \ \ \ \ \ \ \
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
Adds the `sub_clyde` function, which we'll apply to our webhook.
|
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
This is already being patched at class-level.
|
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
Suggested by Mark during review. This follows the "ask for forgiveness
rather than permission" paradigm, ends up being less code to read, and
may be seen as more logical / safer.
The `ALLOWED_EMOJI` set was renamed to `ALL_SIGNALS` as this now better
communicates the set's purpose.
Tests adjusted as appropriate.
Co-authored-by: MarkKoz <[email protected]>
|
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
Using `issubset` is a much simpler & more readable way of expressing
the relationship between the two sets.
Suggested by Mark during review.
Co-authored-by: MarkKoz <[email protected]>
|
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
Requested during review.
Co-authored-by: ks129 <[email protected]>
Co-authored-by: Joseph Banks <[email protected]>
|
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
Suggested by Mark during review.
Co-authored-by: MarkKoz <[email protected]>
|
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
Pointed out by Mark during review that this is unnecessary, as logging
using `exception` automatically appends the `exc_info` of the handled
exception when done in an except block.
Co-authored-by: MarkKoz <[email protected]>
|
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
This is way too spacious for how little is happening here.
Suggested by ks129.
Co-authored-by: ks129 <[email protected]>
|
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
Caught during review by ks129.
Co-authored-by: ks129 <[email protected]>
|
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
This was originally in place to silence a PyCharm warning regarding
accessing the private attributes.
However, since there is no corresponding error code to specify,
the noqa will silence any linter warning, which is potentially
dangerous, and seems to be bad practice.
|
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
Logs useful when observing the internals but too verbose for DEBUG are
reduced to TRACE.
|