In this PR, I've added a "Report an issue" button and a few more
button-related changes:
- Add "Report an issue" button
- Add icon for "Octobot's source code"
- Rename `AboutTitleRepository` to `ButtonOpenRepository`
- Rename `OpenEventInfoButton` to `ButtonOpenEventInfo` to be consistent
with other language string names
- Rename `ColorsList.cs` to `Miscellaneous.cs`
- Add public const strings in `Octobot.cs` to get repository & issues links
---------
Signed-off-by: mctaylors <cantsendmails@mctaylors.ru>
This PR adds an extension method to make it easier to pass Result<Embed> to CreateMessageAsync
---------
Co-authored-by: Octol1ttle <l1ttleofficial@outlook.com>
This PR fixes an issue that is currently causing CI to fail in all pull
requests:
`Notice: "[CA1854] Prefer a 'TryGetValue' call over a Dictionary indexer
access guarded by a 'ContainsKey' check to avoid double lookup" on
/home/runner/work/Octobot/Octobot/src/Services/Update/ScheduledEventUpdateService.cs(107,4168)`
The issue is resolved by following the advice mentioned in the notice.
This PR fixes an issue that prevented scheduled event status updates
from running again if they failed. This happened because, before each
update, the events would be synchronized. The `ScheduleOnStatusUpdated`
field would be set even if it's already `true`, which will cause it to
be set to `false` for unsuccessful updates. The issue is fixed by
surrounding the field set call with a condition that will prevent
setting the field from `true` to `false`
Closes #163
Discord's API sucks a lot. You ask it for a member, but it won't give
you a member. This is why this PR updates the
`GetEventNotificationMentions` method used to determine what roles and
users should get pinged for a scheduled event. Previously, the bot asked
Discord to provide the member for each subscriber to determine whether
or not they have the event notification role (to avoid pinging people
personally when the role would already ping them). With this pull
request, the bot uses MemberData, it's own member storage, for that
purpose (if you're wondering why, refer to the first two sentences)
This PR splits the extension methods contained in `Extensions.cs` into
separate classes in the `Octobot.Extensions` namespace. This was done
for multiple reasons:
1) The `Extensions.cs` violates SRP (Single Responsibility Principle) -
it takes upon itself every extension method for many types
2) Having a separate class for each extended type is a standard practice
- take a look at
[Remora.Discord](https://github.com/Remora/Remora.Discord/tree/main/Backend/Remora.Discord.Rest/Extensions)
or [osu!](https://github.com/ppy/osu/tree/master/osu.Game/Extensions)
3) Having all extension methods in one file makes it hard to find the
method you want
In this PR, I added `Markdown.Sanitize` for every `scheduledEvent.Name`
and `eventData.Name`. That means, every title in scheduled event embeds
will be sanitized.
I did that because in scheduled event list event title displays only as
sanitized string.
Signed-off-by: Macintosh II <mctaylxrs@outlook.com>
This PR moves all code related to synchronization of scheduled events to
ScheduledEventUpdateService. Just like #130, this reduces possible
points of failures, maintenance burden and reliance on gateway events
Because the Discord API sucks at providing data when needed, this PR
makes it so that events are synchronized every tick instead of on
gateway events. This fixes an issue where the bot won't know about a
scheduled event if it was created before the bot was started
We're moving!
---------
Signed-off-by: Macintosh II <mctaylxrs@outlook.com>
Signed-off-by: Macintosh II <95250141+mctaylors@users.noreply.github.com>
Co-authored-by: Octol1ttle <l1ttleofficial@outlook.com>
This PR closes #85.
This PR fixes many issues related to scheduled events. Most importantly,
scheduled events that are no longer present in the guild, but still have
data related to them, won't be left rotting.
This requires deletion of `ScheduledEvents.json` files in all guilds.
Maybe I'll start writing datafixers one day...
Signed-off-by: Octol1ttle <l1ttleofficial@outlook.com>
This PR fixes EventEarlyNotification timestamp not displaying correctly
and also has some other changes:
- Add xmldocs for `/settingslist`'s `page` option in
SettingsCommandGroup.cs
- Add option description for `index` for `/delreminder`
- Some corrections of grammatical errors in Messages.tt-ru.resx
- Fix `ArgumentOutOfRangeException` in `/settingslist` that appears if
the user uses a negative integer in `page`
---------
Signed-off-by: Macintosh II <95250141+mctaylors@users.noreply.github.com>
Co-authored-by: Octol1ttle <l1ttleofficial@outlook.com>
This PR fixes a fatal crash that occurs when the bot tries to send an
early notification for a scheduled event. An exception is thrown by
`string#Format` when the argument list provided doesn't match the
argument list in the template. This is fixed by correcting the template
and the argument list
Signed-off-by: Octol1ttle <l1ttleofficial@outlook.com>
This PR fixes the following bugs in ScheduledEventUpdateService:
- When a scheduled event is first added into ScheduledEventData, its
status update code will be skipped. This results in some messages not
being sent to the EventNotificationChannel
- When the status update code returns an unsuccessful Result, the status
in ScheduledEventData will still be updated, meaning that the code will
not retry.
---------
Signed-off-by: Octol1ttle <l1ttleofficial@outlook.com>
GuildUpdateService is a service that contains way too many
responsibilities with everything strictly coupled to each other. The
code is buggy, hard to refactor and swallows errors. This prompted me to
make this PR, which splits it into three independant services:
- SongUpdateService (responsible for changing songs presence);
- MemberUpdateService (responsible for updating member datas: unbanning
users, adding the default role, sending reminders, filtering nicknames);
- ScheduledEventUpdateService (responsible for updating scheduled
events: sending notifications, automatically starting events).
All of these services and their methods use Results to push errors all
the way up in the stack, making sure no error is missed. To make logging
and debugging easier, an extension method for `ILogger` was created -
`LogResult`. The method checks if the result was successful or if its
failure was caused by a user or environment error before logging
anything - providing cleaner code and logs. `ExceptionError`s will also
have their exception stacktrace and type logged (except in Remora code).
This PR also fixes an issue that prevented banned users from being
unbanned when their punishment was over.
---------
Signed-off-by: Octol1ttle <l1ttleofficial@outlook.com>
