シンプル - Discord Bot with role selection, moderation, karma ranking, a starboard, code execution, raid alerting, backups, a web interface, twitch notifications and more!
Sticky roles help with several things.
The two I come across the most are people who want to evade punishments like mutes, and people wo leave the guild every 2 weeks just to come back several days later.
Data structure
If you are using Postgres, it could make sense to use the integrated array data structure on the guild member table as an additional roles column containing the role IDs.
If you are however deleting rows from this table in any way, I would suggest using a new table for these mappings.
Depending on how you want to implement this feature, it could also make sense for this mapping table to contain a single row for every role mapping rather than arrays as they are more easy to deal with and perform better in many use cases.
Building mappings
To build these mappings I would suggest implementing a command and a corresponding button in the web interface which says Sync role mappings which would iterate through all current members with roles and build the database. This makes sense if you want to make existing roles sticky or if the bot went down (I'll come to that later).
Additional to that I think it is obvious to use the role assignment events to maintain the mappings.
If the bot went down I'd think about re-syncing the mappings for every guild with the module enabled in the background automatically as not every guild owner would notice the bot going down, possibly corrupting the role mapping state.
Cleanup system
I see the technical difficulty of cluttering the database with user-role-mappings, so I will go into detail on how I would counter this problem by proposing several cleanup systems.
Role deletion events
The most obvious one would be listening to role deletion events and removing every row mapping to that role (one row per mapping rather than arrays would make sense for that I think).
Cleanup task
A task iterating through the mappings and checking whether that role exists.
This is optional and I don't think it would make much sense when you have a solid system that is able to re-sync the state after a restart pretty reliable, as it would be impossible to reach a state where this task finds a non-existing role in the database in this case.
Mapping lifetime
Additionally, a maximum lifetime for role mappings after the corresponding member left the guild could make sense, but this is very depending on the amount of people using the bot and your will to keep these entries forever but eventually having to upgrade storage when the bot reaches more popularity.
Thank you for reading and I'd love to participate in technical discussions about this feature.
Type
A new feature
Description
Introduction
Sticky roles help with several things. The two I come across the most are people who want to evade punishments like mutes, and people wo leave the guild every 2 weeks just to come back several days later.
Data structure
If you are using Postgres, it could make sense to use the integrated array data structure on the guild member table as an additional
rolescolumn containing the role IDs. If you are however deleting rows from this table in any way, I would suggest using a new table for these mappings.Depending on how you want to implement this feature, it could also make sense for this mapping table to contain a single row for every role mapping rather than arrays as they are more easy to deal with and perform better in many use cases.
Building mappings
To build these mappings I would suggest implementing a command and a corresponding button in the web interface which says
Sync role mappingswhich would iterate through all current members with roles and build the database. This makes sense if you want to make existing roles sticky or if the bot went down (I'll come to that later).Additional to that I think it is obvious to use the role assignment events to maintain the mappings.
If the bot went down I'd think about re-syncing the mappings for every guild with the module enabled in the background automatically as not every guild owner would notice the bot going down, possibly corrupting the role mapping state.
Cleanup system
I see the technical difficulty of cluttering the database with user-role-mappings, so I will go into detail on how I would counter this problem by proposing several cleanup systems.
Role deletion events
The most obvious one would be listening to role deletion events and removing every row mapping to that role (one row per mapping rather than arrays would make sense for that I think).
Cleanup task
A task iterating through the mappings and checking whether that role exists. This is optional and I don't think it would make much sense when you have a solid system that is able to re-sync the state after a restart pretty reliable, as it would be impossible to reach a state where this task finds a non-existing role in the database in this case.
Mapping lifetime
Additionally, a maximum lifetime for role mappings after the corresponding member left the guild could make sense, but this is very depending on the amount of people using the bot and your will to keep these entries forever but eventually having to upgrade storage when the bot reaches more popularity.
Thank you for reading and I'd love to participate in technical discussions about this feature.
Cheers
Attachments
No response