Skill role refactor - #148
Conversation
|
eccce29 to
1c8e874
Compare
1c8e874 to
ff4c8ca
Compare
Prerequisite for #148 and #179, factored out for easier review: * introduce callbacks for other components to register role checks and be notified of role updates * recast role change detection logic into the language of sets * role update events only fire once new state has been committed, no need for debounce map anymore --------- Co-authored-by: Jeremy Rifkin <51220084+jeremy-rifkin@users.noreply.github.com>
a095f60 to
3b0d2ca
Compare
3b0d2ca to
8c32cdb
Compare
jeremy-rifkin
left a comment
jeremy-rifkin
left a comment
There was a problem hiding this comment.
Thanks for taking the time to do this! Some initial comments:
| options: Discord.GuildMember | Discord.User | Discord.UserResolvable | Discord.FetchMemberOptions, | ||
| ) { | ||
| const member = await this.try_fetch_guild_member(options); | ||
| if (!member || (member.joinedAt && member.joinedAt.getDate() + 28 * DAY <= Date.now())) { |
There was a problem hiding this comment.
If a user leaves and rejoins this will be reset. I think ideally we'd look in the database for some information about how long they've been around.
There was a problem hiding this comment.
Well, the idea was that this would be a default implementation that provides a somewhat reasonable starting point out of the box. I'm not sure requiring a database for it is the way to go here?
There was a problem hiding this comment.
Maybe we can just have the default implementation return false and then have modules overwrite it with something meaningful
| user_id: string; | ||
| roles: string[]; | ||
| last_known_skill_role: string | null; | ||
| }; |
There was a problem hiding this comment.
This is a schema so changing it like this isn't great. I'll give a think about how to do it better.
| options: Discord.GuildMember | Discord.User | Discord.UserResolvable | Discord.FetchMemberOptions, | ||
| ) { | ||
| const member = await this.try_fetch_guild_member(options); | ||
| if (!member || (member.joinedAt && member.joinedAt.getDate() + 28 * DAY <= Date.now())) { |
There was a problem hiding this comment.
Maybe we can just have the default implementation return false and then have modules overwrite it with something meaningful
|
|
||
| type interaction_context = { member: Discord.GuildMember; role?: string; context?: Discord.Message }; | ||
|
|
||
| type skill_level = "beginner" | "intermediate" | "proficient" | "advanced" | "expert"; |
There was a problem hiding this comment.
skill_level now is going to be uppercase versions of these strings, so this is schema breaking
| if (current_skill_level > 0) { | ||
| // don't announce self-assigned roles |
There was a problem hiding this comment.
| if (current_skill_level > 0) { | |
| // don't announce self-assigned roles | |
| if (current_skill_level > SkillLevel.Beginner) { |
…pendent skill role collection, and a couple small cleanups
|
I've pushed some take or leave changes for how I think the above comments should be resolved, please feel free to discard if you'd like to solve them in a different way |
|
|
I will merge and do any further necessary changes |
2 participants
Yet more untethering: make the bot core independent from skill role stuff.
SkillRolescomponent to house skill role logic and trackingWheatley.is_established_member()method to replace skill-role-based checks for screenshots and invite linksTheEstablishmentcomponent that overwritesWheatley.is_established_member()with TCCPP-specific logic.