|  | Commit message (Collapse) | Author | Age | Lines | 
|---|
| ... |  | 
| | | | | | |  | 
| |\ \ \ \ \  
| | | | | | 
| | | | | | | 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. | 
| | | | | | | 
| | | | | | 
| | | | | | | Co-Authored-By: Mark <[email protected]> | 
| | | | | | | 
| | | | | | 
| | | | | | 
| | | | | | | Log message still used the first regex result (re.search) rather than the expanded approach (re.findall) recently added. | 
| | | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | | Partial hits may cause issues when packages get removed. The cache will
get bloated with packages which are no longer needed. They will keep
accumulating as more packages get removed unless the cache is unused for
7 days and gets automatically deleted by Azure Pipelines. Lingering
packages are also a potential cause for conflicts (e.g. unused package x
depends on package y==4.0 and useful package z depends on y==5.0).
Removing support for partial hits means all dependencies will be
installed whenever a single dependency changes. | 
| | | | | | | 
| | | | | | 
| | | | | | 
| | | | | | | "python" is a shorter and clearer name. | 
| | | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | | Prevents the following error:
Can not perform a '--user' install. User site-packages are not visible
in this virtualenv. | 
| | | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | | Some of pipenv's dependencies overlap with dependencies in the Pipfile.
When installing from the Pipfile, any dependencies already present in
the global site will not be installed again to the user site, and thus
will not be cached. Therefore, pipenv is installed to the user site to
ensure all dependencies get cached.
* Move PATH prepend step before pipenv invocation | 
| | | | | | | |  | 
| | | | | | | |  | 
| | | | | | | |  | 
| | | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | | Reduces frequency of using pipenv to install dependencies in CI. Works
by caching the entire Python directory. Only a full cache hit will
skip the pipenv steps; a partial cache hit will still be followed by
using pipenv to install from the pipfiles.
* Disable pip cache | 
| | | | | | | 
| | | | | | 
| | | | | | 
| | | | | | | Makes the script for the coverage step cleaner. | 
| | | | | | | |  | 
| | | | | | | |  | 
| | | | | | | |  | 
| | | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | | The edit causes two channel update events to dispatch simultaneously:
one for the channel topic changing and one for the category changing.
The ModLog cog currently doesn't support ignoring multiple events of
the same type for the same channel. Therefore, the ignore was hard coded
rather than using the typical ignore mechanism.
This is intended to be a temporary solution; it should be removed once
the ModLog is changed to support this situation. | 
| | | | | | | |  | 
| | | | | | | 
| | | | | | 
| | | | | | | Co-Authored-By: Leon Sandøy <[email protected]> | 
| | | | | | | |  | 
| | | | | | | |  | 
| | | | | | | 
| | | | | | 
| | | | | | 
| | | | | | | There is no longer a reliance on static alphabetical position numbers. | 
| | | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | | When a channel is moved, all channels below have their positions
incremented by 1. This threw off the previous implementation which
relied on position numbers being static.
Co-authored-by: Sebastiaan Zeeff <[email protected]> | 
| | | | | | | |  | 
| | | | | | | |  | 
| | | | | | | |  | 
| | | | | | | |  | 
| | | | | | | |  | 
| | | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | | Resetting a specific permission still keeps the overwrite for the member
around despite having default values. These will accumulate over time so
they should be completely removed once the permission needs to be reset. | 
| | | | | | | |  | 
| | | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | | This was happening when attempting to schedule a task twice for a user.
Because the scheduler refuses to schedule a duplicate, the coroutine
is deallocated right away without being awaited (or closed explicitly
by `scheduled_task`).
To fix, any existing task is cancelled before scheduling. This also
means if somehow a user bypasses the lack of permissions, their
cooldown will be updated. However, it probably doesn't make a difference
as if they can bypass once, they likely can bypass again. | 
| | | | | | | 
| | | | | | 
| | | | | | 
| | | | | | | Explicitly close the callback if it's a coroutine. | 
| | | | | | | 
| | | | | | 
| | | | | | 
| | | | | | | Can rely on `__str__` already being a channel's name. | 
| | | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | | Replace retrieval of all channels of a category with a direct comparison
of the categories themselves. In the case of the `on_message` listener,
the change enables the check to be done before the lock acquisition.
This is because it doesn't rely on the channels in the category to be up
to date. In fact, it doesn't even need the category object so it can
exit early without needing to wait for the cog to be ready. | 
| | | | | | | |  | 
| | | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | | This ensures everyone has a clean slate when the bot restarts or the
cog reloads since the tasks to reinstate permissions would have been
cancelled in those cases. | 
| | | | | | | |  | 
| | | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | | To support scheduling different coroutines, `_scheduled_task` now
accepts an awaitable in the data arg. The data arg is actually a
named tuple of the wait time and the awaitable. | 
| | | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | | They must be greater than 0 because the cog obviously couldn't do
anything without any channels to work with. It must be greater than
max_available because it'd otherwise be impossible to maintain that many
channels in the Available category.
* Create a new function to validate the value
* Move validation against MAX_CHANNELS_PER_CATEGORY into the function
  rather than just logging a warning | 
| | | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | | This will ensure the maximum amount of dormant channels possible before
attempting to move any to the available category. It also allows the
dormant command to already be enabled in case there are still no
dormant channels when trying to init available channels. | 
| | | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | | The ready event wasn't used because channels could change categories
between the time the command is invoked and the cog is ready (e.g. if
move_idle_channel wasn't called yet). his may confused users. So would
potentially long delays for the cog to become ready. | 
| | | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | | * Make a copy of the dict
* Add a `ignore_missing` param to `cancel_task` to suppress the warning
  for a task not being found | 
| | | | | | | |  | 
| | | | | | | |  | 
| | | | | | | |  | 
| | | | | | | |  | 
| | | | | | | |  | 
| | | | | | | |  |