aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeLines
...
| * | | | | Branding: check for empty icon cacheGravatar kwzrd2021-03-14-0/+4
| | | | | |
| * | | | | Branding: add embed length cut-offs for safetyGravatar kwzrd2021-03-14-7/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This should never do anything, but it's better to be safe. Values taken from Discord developer docs.
| * | | | | Branding: provide class documentationGravatar kwzrd2021-03-14-2/+43
| | | | | |
| * | | | | Branding: log correct amount of cached eventsGravatar kwzrd2021-03-14-1/+3
| | | | | |
| * | | | | Branding: log event path alongside errorGravatar kwzrd2021-03-14-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Knowing which event failed would probably be quite useful.
| * | | | | Branding: avoid sending #changelog notification on resyncGravatar kwzrd2021-03-14-7/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | | | | Branding: make 'cog_unload' synchronousGravatar kwzrd2021-03-14-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Discord.py doesn't await the return value.
| * | | | | Branding: show success information in 'sync' responseGravatar kwzrd2021-03-14-6/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that the boolean flags are propagating from 'apply_asset', we can present them to the user.
| * | | | | Branding: propagate success-indicating boolean from 'apply_asset'Gravatar kwzrd2021-03-14-19/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | | | | Branding: do not call 'rotate_icons' from rotation initGravatar kwzrd2021-03-14-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | | | | Branding: replace ugly lambda with 'attrgetter'Gravatar kwzrd2021-03-13-1/+2
| | | | | |
| * | | | | Branding: add calendar command groupGravatar kwzrd2021-03-13-0/+63
| | | | | |
| * | | | | Branding: cache all available eventsGravatar kwzrd2021-03-13-11/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | | | | Branding: extract duration string in helper functionGravatar kwzrd2021-03-13-9/+17
| | | | | |
| * | | | | Branding: add missing early exitGravatar kwzrd2021-03-13-0/+1
| | | | | |
| * | | | | Branding: lock commands to mods+ where necessaryGravatar kwzrd2021-03-13-1/+3
| | | | | |
| * | | | | Branding: implement command interfaceGravatar kwzrd2021-03-13-1/+85
| | | | | |
| * | | | | Branding: gate sync via helper functionGravatar kwzrd2021-03-13-8/+19
| | | | | | | | | | | | | | | | | | | | | | | | Sync make also be invoked with a command; avoid logic duplication.
| * | | | | Branding: implement daemonGravatar kwzrd2021-03-13-3/+109
| | | | | |
| * | | | | Branding: implement internal utilityGravatar kwzrd2021-03-13-2/+174
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | | | | Branding: expose SHA on remote objectsGravatar kwzrd2021-03-13-0/+1
| | | | | |
| * | | | | Branding: implement asset application logicGravatar kwzrd2021-03-13-0/+51
| | | | | |
| * | | | | Branding: do not require 'RemoteObject' instance to fetch fileGravatar kwzrd2021-03-13-5/+5
| | | | | |
| * | | | | Branding: correctly annotate optional attributeGravatar kwzrd2021-03-13-1/+1
| | | | | |
| * | | | | Branding: make event instances aware of their locationGravatar kwzrd2021-03-13-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | This allows us to add a neat string representation.
| * | | | | Branding: add event gettersGravatar kwzrd2021-03-13-0/+51
| | | | | | | | | | | | | | | | | | | | | | | | These methods form the API to the repository abstraction.
| * | | | | Branding: define event construction methodologyGravatar kwzrd2021-03-13-0/+90
| | | | | |
| * | | | | Branding: add HTTP fetch helper methodsGravatar kwzrd2021-03-13-0/+54
| | | | | |
| * | | | | Branding: migrate constantsGravatar kwzrd2021-03-13-11/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Constants will only be used in one place and there's not enough of them to warrant a separate module.
| * | | | | Branding: initiate repository abstractionGravatar kwzrd2021-03-13-0/+15
| | | | | |
| * | | | | Branding: remove current implementationGravatar kwzrd2021-03-13-812/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since we're planning substantial changes, it will be easier to build from scratch.
| * | | | | Pipenv: add 'python-frontmatter' & re-lockGravatar kwzrd2021-03-07-48/+59
| | | | | |
| | | * | | Use deleted reason if help channel is closed due to being emptyGravatar Chris2021-03-30-1/+2
| |_|/ / / |/| | | |
* | | | | Merge pull request #1491 from python-discord/fix/dmrelayGravatar Joe Banks2021-03-30-13/+9
|\ \ \ \ \
| * \ \ \ \ Merge branch 'main' into fix/dmrelayGravatar Xithrius2021-03-30-345/+490
| |\ \ \ \ \ | |/ / / / / |/| | | | |
* | | | | | Merge pull request #1470 from python-discord/help-channel-closing-delay-changesGravatar Joe Banks2021-03-30-345/+490
|\ \ \ \ \ \ | | | | | | | | | | | | | | Extend close time logic to differentiate between the claimant and other users
| * | | | | | Fix copy & paste error in closing reason enumGravatar Chris2021-03-30-1/+1
| | | | | | |
| * | | | | | Change to an Enum for possible closing reasonsGravatar Chris2021-03-30-20/+32
| | | | | | |
| * | | | | | Enumerate all possible values for closed_on in docstringGravatar Chris2021-03-30-1/+4
| | | | | | |
| * | | | | | HelpChannels: refactor get_closing_timeGravatar MarkKoz2021-03-30-43/+43
| | | | | | |
| * | | | | | HelpChannels: use aware datetimes everywhereGravatar MarkKoz2021-03-30-27/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix issues converting timestamps to datetimes and vice-versa. The main culprit id `datetime.timestamp()`, which always assumes naïve objects are in local time. That behaviour conflicts with discord.py, which returns naïve objects in UTC rather than local time. Switching from `utcfromtimestamp` to `fromtimestamp` was incorrect since the latter also assumes the timestamp is in local time.
| * | | | | | Update arrow to 1.0.3Gravatar MarkKoz2021-03-30-267/+336
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It has some API changes, so it's best to update now before the project starts using the library more.
| * | | | | | Switch to datetime.fromtimestamp() to avoid over-compensationGravatar Chris2021-03-26-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously we were using `utcfromtimestamp()` which would compensate the timestamp when converting to UTC even though the timestamp itself was in UTC: >>> datetime.utcnow() datetime.datetime(2021, 3, 26, 22, 8, 47, 441603) >>> a = datetime.utcnow().timestamp() 1616821624.207364 >>> a = datetime.utcfromtimestamp(a) datetime.datetime(2021, 3, 27, 5, 7, 4, 207364) By switching to `fromtimestamp()` this avoids that behaviour.
| * | | | | | Use correct constant for each type of help session userGravatar Chris2021-03-26-5/+5
| | | | | | |
| * | | | | | Add 1 second due to POSIX timestamps being lower resolution than datetime ↵Gravatar Chris2021-03-26-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | objects.
| * | | | | | Fix error when converting non claimant messageGravatar Chris2021-03-26-7/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | datetime.min cannot be converted to a timestamp as it's pre-epoch. Instead wait until we actuall need it and then create the correct datetime object depending on teh cache contents.
| * | | | | | Convert to timestamp before posting to redisGravatar Chris2021-03-25-2/+2
| | | | | | |
| * | | | | | Reset a channel's non-claimant cache on claim, to indicate that the session ↵Gravatar Chris2021-03-25-7/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | has yet to be answered.
| * | | | | | Refactor if block within help channel system to be more readableGravatar Chris2021-03-25-6/+7
| | | | | | |
| * | | | | | Refactor help channel update message cache function for clearer flowGravatar Chris2021-03-25-9/+8
| | | | | | |