add Member#isPending

[sebm253]

Pull Request Etiquette

• I have checked the PRs for upcoming features/bug fixes.
• I have read the contributing guidelines.

Changes

• Internal code
• Library interface (affecting end-user code)
• Documentation
• Other: _____

Closes Issue: NaN

Description

this PR adds Member#isPending and GuildMemberUpdatePendingEvent. i'm not really sure about the event name as it's a pretty much one-way event but.. yeah

[kantenkugel]

Does the Discord API also allow for checking if a Guild has rule screening enabled and for fetching/updating said rules?
Cuz that would fit into this PR as well

[RedDaedalus]

Yes, it's a guild feature: MEMBER_VERIFICATION_GATE_ENABLED

[duncte123]

My main concern is that it is not documented if there's an event when this gets changed

[RedDaedalus]

My main concern is that it is not documented if there's an event when this gets changed

There's a pull request to document this, but Discord doesn't make breaking changes regardless of documentation status.

[duncte123]

My main concern is that it is not documented if there's an event when this gets changed

There's a pull request to document this, but Discord doesn't make breaking changes regardless of documentation status.

I see discord/discord-api-docs#2396 (comment)

[duncte123]

LGTM

[sebm253]

Does the Discord API also allow for checking if a Guild has rule screening enabled and for fetching/updating said rules?
Cuz that would fit into this PR as well

@kantenkugel i thought about adding membership screening details too, but as those are unfinished, and more types are going to be added in the future, i think it will be better to wait until it's completely finished

[kantenkugel]

Regarding latest commit: is PUBLIC gone now?

[sebm253]

Regarding latest commit: is PUBLIC gone now?

yes, it's gone at least from the official docs

[kantenkugel]

Regarding latest commit: is PUBLIC gone now?

yes, at least it's gone from the official docs

And is there a replacement? cuz public basically meant discoverable/community

[sebm253]

Regarding latest commit: is PUBLIC gone now?

yes, at least it's gone from the official docs

And is there a replacement? cuz public basically meant discoverable/community

yep, that's literally DISCOVERABLE feature. btw the PUBLIC feature has been directly replaced by COMMUNITY

[kantenkugel]

Looking through the diffs of doc state of this branch and the discord docs, there are a few differences tho:
JDA docs are missing:

• COMMUNITY
• FEATURABLE

JDA Docs have extra (apart from the 2 new ones):

• MORE_EMOJI

I wouldn't touch the MORE_EMOJI tho, since i am not sure about whether it is still used for some special servers (and iirc it was always kinda hidden).

The other 2 might be wise to add here, as this MR already touches that part of the docs anyways

[sebm253]

Looking through the diffs of doc state of this branch and the discord docs, there are a few differences tho:
JDA docs are missing:

* COMMUNITY

* FEATURABLE

JDA Docs have extra (apart from the 2 new ones):

* MORE_EMOJI

I wouldn't touch the MORE_EMOJI tho, since i am not sure about whether it is still used for some special servers (and iirc it was always kinda hidden).

The other 2 might be wise to add here, as this MR already touches that part of the docs anyways

i've added community and featurable features in my community updates/rules channel pr. more_emoji is more about your decision as i don't see any issue with removing it

[kantenkugel]

Ah ok, sorry about that then

[duncte123]

I searched about 4k guilds and did not find the MORE_EMOJI feature https://canary.discord.com/channels/125227483518861312/169484473333710848/790942477443923968

I suggest that if it was to be removed it should be its own PR

[Andre601]

Something I noticed, but why isn't there a on method for the event?
Does Discord simply not send one when this happens or what is the main reason behind this not being present? How are bots supposed to listen for this even if there isn't a on for the ListenerAdabter?

[sebm253]

Something I noticed, but why isn't there a on method for the event?
Does Discord simply not send one when this happens or what is the main reason behind this not being present? How are bots supposed to listen for this even if there isn't a on for the ListenerAdabter?

i just forgot to add it actually no, all methods have been replaced by ClassWalker

[Andre601]

Something I noticed, but why isn't there a on method for the event?
Does Discord simply not send one when this happens or what is the main reason behind this not being present? How are bots supposed to listen for this even if there isn't a on for the ListenerAdabter?

i just forgot to add it actually no, all methods have been replaced by ClassWalker

Still needs a on method to my knowledge... Not sure tho.

[kantenkugel]

Something I noticed, but why isn't there a on method for the event?
Does Discord simply not send one when this happens or what is the main reason behind this not being present? How are bots supposed to listen for this even if there isn't a on for the ListenerAdabter?

i just forgot to add it actually no, all methods have been replaced by ClassWalker

Still needs a on method to my knowledge... Not sure tho.

Yes it does. the classwalker still needs reference methods to call. if the method is not defined, it won't be called
The only thing in the ListenerAdapter class itself that changes is that there is no longer a need for that long and ugly instanceof cascade

[Andre601]

I tried out the event and it's kinda odd.
The bot I tried it on does have access to all required intents and the GUILD_MEMBER event is selected and enabled, but the below code doesn't seem to get executed properly because even with the member passing the screening do they not gain the role in question.

The role does exist and the ID used matches it, since I use it in other places too, where I need the role.

Anyone else having an idea?

Code snippet used:

@Override
public void onGuildMemberUpdatePending(@Nonnull GuildMemberUpdatePendingEvent event){
    if(!event.getGuild().getId().equals(IDs.GUILD)){ // Check against a specific Guild ID.
        return;
    }

    Guild guild = event.getGuild();
    if(!event.getNewPending()){ // Check if Member still isn't confirmed
        return;
    }

    Role member = guild.getRoleById(IDs.MEMBER); // Get the member role
    guild.modifyMemberRoles(event.getMember(), Collections.singletonList(member), null)
        .reason("Member " + event.getMember().getEffectiveName() + " passed Member screening")
        .queue();
}

[MinnDevelopment]

Member update events only work when the member is cached.

[Andre601]

Member update events only work when the member is cached.

That's the odd thing here. Since I only use the bot on one Guild do I have the Member caching set to all.

        jda = JDABuilder.createDefault(fileManager.getString("config", "bot-token"))
                  .enableIntents(
                          GatewayIntent.GUILD_MEMBERS,
                          GatewayIntent.GUILD_PRESENCES
                  )
                  .setMemberCachePolicy(MemberCachePolicy.ALL)
                  .setChunkingFilter(ChunkingFilter.ALL)
                  .addEventListeners(
                          new CommandListener(this, commandHandler),
                          new ReadyListener(this),
                          new MemberListener(this), // Event is used here
                          new ReactionListener(this),
                          new RoleListener(),
                          new MessageListener(this)
                  )
                  .build();

[GoldRenard]

@MinnDevelopment

Member update events only work when the member is cached.

Why? It's not like GuildMemberRoleRemoveEvent/GuildMemberRoleAddEvent update events where we HAVE to know member's previous data.

In case of pending it doesn't make any sense, it's very important thing that we need the fact that member accepted community rules (current new value) even if it doesn't cached and we can't get the previous value (which will be false most likely).

It must be always fired to get the current value IMO. The old pending value could be just nullable in case it isn't available in cache.

[sebm253]

@MinnDevelopment

Member update events only work when the member is cached.

Why? It's not like GuildMemberRoleRemoveEvent/GuildMemberRoleAddEvent update events where we HAVE to know member's previous data.

In case of pending it doesn't make any sense, it's very important thing that we need the fact that member accepted community rules (current new value) even if it doesn't cached and we can't get the previous value (which will be false most likely).

It must be always fired to get the current value IMO. The old pending value could be just nullable in case it isn't available in cache.

it's not like the "pending event" is an event by itself. it's a guild member update event and in order to fire the pending event, jda has to compare the previous pending boolean against the "new" pending boolean. if the previous state "isn't cached", jda cannot assume it's the pending flag being updated

[MinnDevelopment]

@GoldRenard https://ci.dv8tion.net/job/JDA/javadoc/net/dv8tion/jda/api/events/guild/member/GuildMemberUpdateEvent.html

Discord only sends an update with the new data, regardless of what changes. The library cannot figure out what changed without a cache of the previous state. See also discord/discord-api-docs#2137

[GoldRenard]

it's not like the "pending event" is an event by itself. it's a guild member update event and in order to fire the pending event, jda has to compare the previous pending boolean against the "new" pending boolean. if the previous state "isn't cached", jda cannot assume it's the pending flag being updated

Yeah I figured it out by myself after reading discord docs just before your comment. Huff...

Wanted to edit my first comment but you was faster.

[Andre601]

Something I'm curious to know about is, what exact settings, such as Cache Flags, Chunking filter, etc, are needed for this to work.
As I mentioned before does my bot use the ALL MemberCachePolicy and the ChunkingFilter is also set to ALL, yet the event won't get fired here at all.

I currently think that this could perhaps require the CLIENT_STATUS flag, which is disabled in createDefault, to work? I really see no other reason as to why the even either doesn't get fired or doesn't give back updated values like the new boolean.

[MinnDevelopment]

Maybe it makes sense to add a MemberCachePolicy.PENDING to make handling of pending members easier?

Example:

static MemberCachePolicy PENDING = Member::isPending;

In theory, this should allow bots to handle pending without caching all members.

[Andre601]

I think I found my issue.

I used the getNewPending wrong. I actually thought true means the member is passing the screen, while it actually is false... Didn't test it yet, but I'm sure that's the problem I had.

EDIT: Yes. The system works now when I inverted the boolean.

[MinnDevelopment]

Since it seems like discord is still trying to figure this out we might just want to mark all these things as @Incubating so we can put this temporary API design into 4.2.1.