| Commit message (Collapse) | Author | Age | Lines |
|---|
| ... | |
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
Sync make also be invoked with a command; avoid logic duplication.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This adds the core logic of branding management. In comparison with the
previous version, we now maintain all state in Redis, which allows the
bot to seamlessly restart without losing any information.
The 'send_info_embed' function is intentionally implemented with the
consideration of allowing users to invoke it on-demand. It always
reads information from the cache, even if the caller could pass
a 'MetaFile' instance. So while this may look needlessly indirect
right now, it should begin to make sense once the command API
is implemented.
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
This allows us to add a neat string representation.
|
| | | | |
| | | |
| | | |
| | | | |
These methods form the API to the repository abstraction.
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Constants will only be used in one place and there's not enough of them
to warrant a separate module.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Since we're planning substantial changes, it will be easier to build
from scratch.
|
| |/ / / |
|
| | | | |
|
| | | |
| | |
| | | |
Bug caused by an outdated function signature in a previous commit in the #1402 PR
|
| |\ \ \
| | | |
| | | | |
Implement showing filterlist entry comment in alerts
|
| | |\ \ \
| |/ / /
|/| | | |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
ChrisLovering/Don't-suggest-when-a-tag-is-on-cooldown
Don't fuzzy search for tags when tag is on cooldown
|
| | |\ \ \ \
| |/ / / /
|/| | | | |
|
| |\ \ \ \ \ |
|
| | | | | | | |
|
| | | | | | | |
|
| |/ / / / / |
|
kwzrd
Boris Muratov
Xithrius
Joe Banks