Include additional logging of guild events
Currently, in our server, we use DynoBot to log member joins, leaves, voice channel joins/leaves, nickname changes, and (rather redundantly) message deletions. We should introduce logging for some of these events in the same vein as message logging, and eventually, we should remove Dyno from the server altogether. I will investigate an implementation.
Click below for examples from dynobot:

I'm willing to start helping out with Modix, I could help if needed.
Sure! This feature will probably look very similar to MessageLogBehavior - create a class that extends from BehaviorBase and implement the events you need. You'll then want to log those events in the same way MessageLogBehavior does - call IDesignatedChannelService#SendToDesignatedChannelsAsync with the message/embed and the appropriate DesignatedChannelType.
Here are my recommendations for new designations, one for each log type:
- MemberJoinLog (joins and leaves from the server)
- MemberVoiceLog (joins and leaves from voice channels)
- MemberModificationLog (nickname changes)
Not too attached to any of the names specifically, though.
Alright, thanks for the tips! I might name MemberModificationLog something like MemberUpdateLog, but I'll check out MessageLogBehavior.
Been a while since I commented here, but I forked and I'll start work on this.
Edit 10/03/2019 Almost a month later, finally have the time to add stuff to the fork.
Actions that Dyno is able to log and whether MODiX is also able to log that action:
- [ ] Member Joined
- [ ] Member Left
- [x] Member Banned
- [x] Member Unbanned
- [x] Message Edited
- [x] Message Deleted
- [x] Bulk Message Deletion
- [ ] Channel Created
- [ ] Channel Deleted
- [ ] Role Created
- [ ] Role Deleted
- [ ] Role Updated
- [ ] Role Given
- [ ] Role Removed
- [ ] Nickname Changed
- [ ] Member Joined Voice Channel
- [ ] Member Left Voice Channel
- [ ] Member Moved to Voice Channel
Thoughts:
- It's probably not necessary to be able to log all of the above. We may want to determine a subset that make sense for our use case.
- It would be nice to have the option to toggle each of these individually in case we decide we want more or less logging. Toggle-ability may not be necessary for the initial implementation.
- It's probably fine just to have a single channel for non-message logging or maybe a few like jmaz mentions above and one for message logging like we do currently.
Out of those, the ones we probably care about are:
- Member Joined
- Member Left
- Role Given
- Role Removed
- Nickname Changed
Another question: how much of that could be retrieved from the audit logs?
The list of audit log events is here:
https://discordapp.com/developers/docs/resources/audit-log#audit-log-entry-object-audit-log-events
The only ones from that list it can provide context for are Role Given / Role Removed, in the form of MEMBER_ROLE_UPDATE, and Nickname Changed as MEMBER_UPDATE.
So, in the interest of having Discord be the source of truth, I think we need to pull info from there, primarily. We can dupe/denormalize it locally for the sake of performance, if need be.
My guess is that d.NET already pulls that information from there into these events it provides.
No, Discord.NET events all come through the socket/gateway connection. I don't think they have anything that supplements from the audit logs, especially considering they were only recently added.
So, in the interest of having Discord be the source of truth,
No, Discord.NET events all come through the socket/gateway connection
Wouldn't that make those events good enough?
Wouldn't that make those events good enough?
The gateway events don't contain information like who changed the nickname or who modified the roles, just that it happened.
The gateway events don't contain information like who changed the nickname or who modified the roles, just that it happened.
Ooh, I didn't know that that type of information was even a thing. I rest my case.
As part of a new effort to refocus on priorities, I will close this. If you feel this is imperative to the bot, a new issue can be opened to supersede this.