| Commit message (Collapse) | Author | Age | Lines |
|---|
| | |
|
| |
|
|
|
|
| |
With the new addition of non latin-11 chars in channel names - which get logged,
the logging to files fails on those entries on OSs where the default
encoding is not utf8 or an other encoding capable of handling them.
|
| |
|
|
|
|
| |
Deleting the channel from the claimant cache on
invokation of the dormant command prevents users running
the command multiple times before the bot moves it.
|
| |
|
|
|
|
| |
Reversing the order ensures the task is not cancelled
when moving to dormant fails which gives a fallback to move it
after the initial period of time.
|
| |
|
|
|
|
| |
In a testing environment, the bot may try to edit the message of a
different bot. Therefore, the author of the message should be checked
to ensure the current bot sent it.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Co-authored-by: MarkKoz <[email protected]>
|
| |
|
|
| |
Co-authored-by: MarkKoz <[email protected]>
|
| | |
|
| | |
|
| |
|
|
|
| |
Only resetting the permission caused the overwrites for the users
to remain on the category, potentially piling up and causing further issues.
|
| |
|
|
|
|
|
|
|
| |
Pairing users to channels was a design flaw,
because the keys didn't get overwritten.
This allowed multiple users to access the dormant command
for the running session of the bot.
Replacing this with a reversed paring fixes both issues
because the cache is overwritten on channel activation.
|
| |
|
|
|
|
|
| |
After the dormant command is used and the permissions
are restored for the user that started the session,
the task for restoring them after the claim time
has passed is no longer necessary.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Removing the `with_role` check from the command and
replcaing it with a new `dormant_check` that's used in the body,
which also checks against a cache of users that started the sessions,
allows them to close their own channels along with the role check.
|
| | |
|
| |\
| |
| |
| |
| | |
python-discord/mitigate-permission-unsynchronization-available-help-channels
Mitigate available help channels failing to synchronize their permissions
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The help channels in the `Help: Available` category should automatically synchronize their permissions with the category permissions to ensure that the overwrites we use to prevent people from claiming multiple help channels are properly enforced. Unfortunately, for unknown reasons, they sometimes get in an "out of sync" state that requires intervention to get them back in sync.
This PR mitigates that issue by checking the available channel for their synchronisation status during certain critical times in our help channel system:
1. Whenever the overwrites for the category change
2. Whenever a channel is moved into the new category
3. After the categories have been reset during the initialization process
The check is straightforward: The `ensure_permissions_synchronization` method iterates over all the channels in the category and checks if the channels are currently synchronizing their permissions. If not, we remedy that by making a channel edit request to the Discord API. If all channels were already "in sync", no API calls are made. The latter should make this an inexpensive mitigation procedure: As we typically have very few channels in the available category and channels mostly stay in sync, we typically do very little.
To make this process a bit easier, I've factored out `set_permissions` calls to a helper function that also calls the `ensure_permissions_synchronization` method. The only exception is during the reset process: As we may edit multiple permissions in this loop, it's better to only ensure the synchronization after we're done with all permission changes.
|
| |/
|
|
| |
The embed displayed in available help channels still used the term "in use" instead of "occupied". I've updated the embed to reflect the new name of the "occupied" category.
|
| |\
| |
| |
| |
| | |
python-discord/help-channel-system-minor-improvements
Add status emojis to help channels and improve bottom sorting
|
| | |
| |
| |
| |
| |
| | |
As Discord is having a rather persistent issue with one of the channels in the current `Help: In Use` category, we're going to start using a new category that excludes the old channel.
The old channel, help-argon, appears to be completely broken on Discord's end, resulting in "Not found" errors for any kind of interaction, including channel move and/or channel delete admin actions. As it's still visible, it's currently triggering a lot questions from our members. We hope that using a new category will fix that.
|
| | |
| |
| |
| | |
The set that keeps track of the used channel names should discard emojis. To do that, I'm cleaning the names before they're added to the set of channel names.
|
| | |
| |
| |
| | |
The help channel prefix is configurable as a constant, but I accidentally used a static prefix in the utility function that cleaned the channel names. This commit makes sure the utility method uses the prefix defined in the constants.
|
| | |
| |
| |
| |
| |
| | |
The current approach of trying to find the maximum channel position, adding one, and using that as the position integer for channels does not seem to work reliably. An approach that seems to work in the testing environment is using a very large integer for the position attribute of the channel: It wil be sorted at the bottom and Discord will automatically scale the integer down to `max + 1`.
This also means the `get_position` utility function is no longer needed; it has been removed.
|
| |/
|
|
|
|
| |
I've added channel status emojis as a prefix to our help channels to make it more obvious to the end user what the current status of a channel is. All channels in the Available category will be marked with a green checkmark emoji, while all channels in the In Use category will be marked with an hourglass. Channels in the Dormant category stay unadorned.
Channels will be stripped of their previous prefix when moved to another category. This relies on the `help-` naming convention, as that is the most reliable way to do it that does not break if we ever opt for another emoji.
|
| |
|
|
| |
The current sorting algorithm we used created unpredictable channel order (for our human end-users) and induced a flickering channel light-show in Discord clients. To combat these undesirable side-effects, I've changed the ordering to always order channels at the bottom of a category. This also means that channels looking for answers the longest will naturally float up.
|
| |\
| |
| | |
Implement a new help channel system
|
| | |\
| |/
|/| |
|
| |\ \
| | |
| | | |
Cache all Python dependencies in CI
|
| | |\ \
| |/ /
|/| | |
|
| | | | |
|
| |\ \ \
| | | |
| | | | |
Update token filter logging to match expanded detection
|
| | |\ \ \
| |/ / /
|/| | | |
|
| | | | |
| | | |
| | | |
| | | | |
The Coding Den is a language agnostic community that's been around for years with over 12000 members.
I think we can allow that invite in our community.
|
| |\ \ \ \
| | | | |
| | | | | |
Don't let change expiration time when infraction already expired.
|
| | |\ \ \ \
| |/ / / /
|/| | | | |
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
Tags response + command message deletion with trashcan reaction
|
| | |\ \ \ \ \
| |/ / / / /
|/| | | | | |
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | | |
Filtering: merge the word and token watch filters
|
| | |\ \ \ \ \ \
| |/ / / / / /
|/| | | | | | |
|
| |\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
Fixed !zen command exact word matching.
|
| | |\ \ \ \ \ \ \
| |/ / / / / / /
|/| | | | | | | |
|
| |\ \ \ \ \ \ \ \
| | | | | | | | |
| | | | | | | | | |
Logging Level Adjustments
|
| | |\ \ \ \ \ \ \ \
| |/ / / / / / / /
|/| | | | | | | | |
|
| | | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
The "unsilence" action of the silence/hush command used `send_messages=True` when unsilencing a hushed channel. This had the side effect of also enabling send messages permissions for those with the Muted rule, as an explicit True permission apparently overwrites an explicit False permission, even if the latter was set for a higher top-role.
The solution is to revert back to the `Inherit` permission by assigning `None`. This is what we normally use when Developers are allowed to send messages to a channel.
|
| |\ \ \ \ \ \ \ \ \
| | | | | | | | | |
| | | | | | | | | | |
Implement silencer (hush) cog.
|
Numerlor
MarkKoz
Sebastiaan Zeeff
Joseph
S. Co1
Shirayuki Nekomata
Leon Sandøy
S. Co1
Karlis S
Eivind Teig