| Commit message (Collapse) | Author | Age | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
Simplification comes from being able to access permissions as attributes
on the overwrite object. This removes the need to iterate all
permissions.
Efficiency comes from checking all roles within a single iteration of
all channels. This also removes the need to flatten and filter the
channels afterwards, which required additional iterations.
|
| |\ |
|
| | |\
| | |
| | | |
Specify encoding when reading tag files
|
| | |/
| |
| |
| |
| |
| |
| |
| | |
Not all operating systems use UTF-8 as the default encoding. For systems
that don't, reading tag files with Unicode would cause an unhandled
exception.
(cherry picked from commit adc75ff9bbcf8b905bd78c78f253522ae5e42fc3)
|
| | |
| |
| |
| |
| |
| |
| | |
We're using the set comprehension to prevent duplicates anyway, so
flipping these back makes more sense.
Also added a missing ctx and tested ok.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- We're using a set comprehension and flipping the order for counting
the number of channels that are both staff allow and @everyone deny.
- We're breaking the staff channel count stuff into a separate helper
function so it doesn't crowd the server_info() scope.
These fixes are both to address the code review from @MarkKoz, thanks
Mark.
|
| | |
| |
| |
| | |
I wish this test didn't exist.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We now check:
- Does the @everyone role have explicit read deny permissions?
- Do staff roles have explicit read allow permissions?
If the answer to both of these are yes, it's a staff channel.
By 'staff roles', I mean Helpers, Moderators or Admins.
|
| |\| |
|
| | |\
| | |
| | | |
Ignore response when posting python news
|
| | | |\
| | |/
| |/| |
|
| | | |
| | |
| | | |
Sometimes a mailing list user doesn't press respond correctly to the email, and so a response is sent as a separate thread. To keep only new threads in the channel, we need to ignore those.
|
| | | | |
|
| |/ /
| |
| |
| |
| |
| | |
Cleaning up a particularly dirty line by turning it into like 10 lines,
and also adding the number of channels that are hidden to the
`@everyone` role - which we're classifying as "Staff channels".
|
| |\ \
| |/
|/| |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Discord has introduced a new, strict rate limit for individual channel
edits that reduces the number of allow channel name/channel topic
changes to 2 per 10 minutes per channel.
Unfortunately, our help channel system frequently goes over that rate
limit as it edits the name and topic of a channel on all three "move"
actions we have: to available, to occupied, and to dormant. In addition,
our "unanswered" feature adds another channel name change on top of
the move-related edits.
That's why I've removed the topic/emoji changing features from the help
channel system. This means we now have a generic topic that fits all
three categories and no status emojis in the channel names.
|
| |/
|
|
|
|
|
|
|
|
| |
The `check_for_answer` method of the HelpChannels cog relies on the
channel->claimant cache being available. However, as this cache is
(currently) lost during bot restarts, this method may fail with a
KeyError exception.
I've used `dict.get` with an `if not claimant: return` to circumvent
this issue.
|
| |\
| |
| | |
RedisCache - Data Persistence
|
| | | |
|
| | |
| |
| |
| | |
This addresses a review comment by @aeros.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The bot can get into trouble in three distinct ways:
- It has no Bot instance
- It has no namespace
- It has no parent instance.
These happen only if you're using it wrong. To make the test more
precise, and to add a little bit more readability (RuntimeError could be
anything!), we'll introduce some custom exceptions for these three
states.
This addresses a review comment by @aeros.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
- Refactor error messages in _to_typestring and _from_typestring to just
print the prefix tuples instead of that custom error string.
- Create a RedisKeyOrValue type to simplify some annotations.
- Simplify partialmethod calls.
- Make the signatures for _to_typestring and _from_typestring one-liners
- Fix a typo in the errors.
|
| | |\
| |/
|/| |
|
| |\ \
| | |
| | |
| | |
| | | |
python-discord/moderation_commands_in_modmail_category
Permit moderation commands in ModMail category
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
This check was no longer being used anywhere, having been replaced by
in_whitelist_check.
|
| | |\ \
| |/ /
|/| | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
For example, we don't want the mod commands to produce any kind of error
message when run by ordinary users in regular channels - these should
have the perception of being invisible and unavailable.
|
| | | | |
|
| | | | |
|
| | | | |
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| | |
We're moving the actual predicate into the `utils.checks` folder, just
like we're doing with most of the other decorators. This is to allow us
the flexibility to use it as a pure check, not only as a decorator.
This commit doesn't actually change any functionality, just moves it
around.
|
| | |
| |
| |
| | |
I should be shot.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
We're using functools.partialmethod to make the code a little cleaner
and more readable here.
Read more about them here:
https://docs.python.org/3/library/functools.html#functools.partial
https://docs.python.org/3/library/functools.html#functools.partialmethod
|
| | |
| |
| |
| |
| |
| |
| | |
Also added a test for this.
This is the DRYest approach I could find. It's a little ugly, but I
think it's probably good enough.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The way we were doing the asyncio.Lock() stuff for increment was
slightly problematic. @aeros has adviced us that it's better to just
initialize the lock as None in __init__, and then initialize it inside
the first coroutine that uses it instead. This ensures that the correct
loop gets attached to the lock, so we don't end up getting errors like
this one:
RuntimeError: got Future <Future pending> attached to a different loop
This happens because the lock and the actual calling coroutines aren't
on the same loop. When creating a new test, test_increment_lock, we
discovered that we needed a small refactor here and also in the test
class to make this new test pass.
So, now we're creating a DummyCog for every test method, and this will
ensure the loop streams never cross. Cause we all know we must never
cross the streams.
|
| | | |
|
| | |\
| |/
|/| |
|
| |\ \
| | |
| | | |
feature to restrict tags to specific role(s)
|
| | |\ \
| |/ /
|/| | |
|
| | | | |
|
| |\ \ \
| | | |
| | | | |
Filtering: don't attempt to send additional embeds for invalid invites
|
| | |\ \ \
| |/ / /
|/| | | |
|
| | | | | |
|
| |\ \ \ \
| | | | |
| | | | | |
Help System: Move dormant faster if help channel is empty
|
| | |\ \ \ \
| |/ / / /
|/| | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
At this point, it's just a thin wrapper to call another function. It's
redundant.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
It was being done repeatedly outside the function so let's move it in
to reduce redundancy.
|
MarkKoz
Leon Sandøy
Leon Sandøy
Dennis Pham
Matteo Bertucci
Joseph Banks
Sebastiaan Zeeff
Sebastiaan Zeeff
Shirayuki Nekomata
kwzrd