Flipping `>` to `<=` changed null handling semantics within the
operator, causing the unban/unmute code to always run
Signed-off-by: Octol1ttle <l1ttleofficial@outlook.com>
If a user was muted using the `MuteRole` method and then banned, the
UnknownMember warning will flood your logs when `DateTimeOffset.UtcNow >
data.MutedUntil` becomes true, because there is no user in the server to
unmute.
---------
Signed-off-by: Macintosh II <95250141+mctaylors@users.noreply.github.com>
- Added support for `MuteRole`, now if you add any role to this setting,
then try to mute a member, all his roles will be removed except for the
one you set in this setting.
- Fixed `/unmute`, that tried to set target's display name to unmute
reason.
---------
Signed-off-by: Macintosh II <mctaylxrs@outlook.com>
This PR closes #105
This PR fixes exceptions caused by changing a collection's contents
while it is being enumerated. This can often happen with Guild- and
MemberDatas. By using `ToArray()` on these global collections and using
it in the `foreach` loop, we create a new copy of the collection,
preventing any modification to it.
While this does introduce a lot of memory allocations, there is no
fixing that. Usually, the fix to these exceptions would be to convert
the `foreach` to a reverse-`for`. However, because indices cannot be
used on these collections, that is not possible.
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>
