| Commit message (Collapse) | Author | Age | Lines |
| | |
|
| | |
|
| | |
|
| |\
| |
| | |
Blacklist staff_info for duckpond
|
| |/ |
|
| |\
| |
| | |
Allow !poll to leads
|
| | |\
| |/
|/| |
|
| |\ \
| | |
| | | |
Use deleted reason if help channel is closed due to being empty
|
| | |\ \
| |/ /
|/| | |
|
| |\ \ \
| | | |
| | | | |
Update our policy documents
|
| |/ / / |
|
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Co-authored-by: Shivansh-007 <[email protected]>
Co-authored-by: Joe Banks <[email protected]>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
No code changes in this commit.
Co-authored-by: Shivansh-007 <[email protected]>
Co-authored-by: Joe Banks <[email protected]>
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
With the branding-side PR merged, we can now target the production
branch.
|
| | |\ \ \
| |/ / /
|/| | |
| | | | |
Lockfile conflict resolved by re-locking on the merged Pipfile.
|
| | |\ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Conflict in the lockfile resolved by re-locking the merged Pipfile.
Conflict in Branding constants resolved by keeping my local version.
Change in the cog's target branch to 'main' from 'master' is currently
irrelevant as we targets a development branch anyway.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
It would be strange to just send the embed with no explanation of what
it means.
|
| | | | | |
| | | | |
| | | | |
| | | | | |
The fallback event should not produce a notification.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Logs are now proper sentences ended with full stops. Exceptions are
logged with full tracebacks, and log level are revised to be more
sensible and consistent across the extension.
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | | |
No reason for this to be async.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The default KeyError message from dict lookup is just the missing key.
In order to give more context in the log message, we raise our own.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The fetch helpers will now raise when the request fails rather than
logging a warning and returning a fallback value.
This allows better error logging as the caller is able to log the
propagated exception while adding its own context.
Additionally, the caller in some cases no longer needs to check for
the None return and raise its own exception.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Previously, the event description & duration strings were only stored
on event entry. In the case that the description or duration change
for an on-going event, the cached values wouldn't be updated.
After this commit, the cache is refreshed daily by the daemon.
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
After previous changes, the docstring was no longer accurate.
See: 1d5625a2f47a1d4d050f9eb0eb7a18e7d6fe171b
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The daemon will now perform a sync iteration immediately when started,
and then every UTC midnight.
Previously, it would only perform the initial iteration when started
for the first time, which is odd.
It is also believed that splitting the daemon's logic into three
separate functions is beneficial: before, loop, and main.
This commit makes log and doc adjustments where appropriate.
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Fresh stable release, just in time!
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This should never do anything, but it's better to be safe.
Values taken from Discord developer docs.
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Knowing which event failed would probably be quite useful.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The notification is now sent conditionally depending on whether we're
entering a new event. This prevents sending a repeating notification
in the case of a manual resynchronisation.
A practical example of when this may trigger is when a staff member
temporarily applies custom assets & then uses the sync command to
reapply the current event.
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Discord.py doesn't await the return value.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Now that the boolean flags are propagating from 'apply_asset', we can
present them to the user.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The sync command will now be able to use present this information
to the invoking user.
This commit also prevents the cached banner & icon hash from being
overwritten in the case of asset upload failure. As a result, the
daemon will attempt to re-apply the assets the following day.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
It makes more sense for the init and the rotation to be separate
operations.
In a subsequent commit, the separation of responsibility will allow
the `rotate_icons` function to have a meaningful return value.
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This is a prequel to adding a calendar command. To avoid re-querying
the branding repo on command invocation, event information will be
cached whenever we make requests. The command can then simply get an
up-to-date event schedule from the cache, with the option of forcing
an update via the 'populate_cache_events' function.
Since we cannot easily serialize entire 'Event' instances, we simply
store what's needed - the event name, and its duration.
The author has verified that the cache maintains order; in this case
chronological order based on event start date.
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|