Skill role refactor #148
Skill role refactor #148
Conversation
|
michael-kenzel
force-pushed
the
skill-role-refactor
branch
from
eccce29 to
1c8e874
Compare
michael-kenzel
force-pushed
the
skill-role-refactor
branch
from
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 <[email protected]>
michael-kenzel
force-pushed
the
skill-role-refactor
branch
3 times, most recently
from
a095f60 to
3b0d2ca
Compare
michael-kenzel
force-pushed
the
skill-role-refactor
branch
from
3b0d2ca to
8c32cdb
Compare
| 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?
| override async setup(commands: CommandSetBuilder) { | ||
| // const role_manager = unwrap(this.wheatley.components.get("RoleManager")) as RoleManager; | ||
| // role_manager.register_role_check(this.check_established.bind(this)); | ||
| this.wheatley.is_established_member = this.is_established_member.bind(this); |
There was a problem hiding this comment.
This sort of thing makes me pretty uneasy. If the check isn't suitable to just be implemented in wheatley, I think it'd be better for other components to just get handles to this component and use its logic.
There was a problem hiding this comment.
Well, the issue with that is that we have some components like anti-invite-links or anti-screenshots that I think we would like to just work out-of-the-box, independent of guild-specific components. Otherwise, we would probably have to move these into the TCCPP components?
|
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.