Document Membership Screening

[advaith1]

👋

• MEMBER_VERIFICATION_GATE_ENABLED and PREVIEW_ENABLED guild features
• Membership Screening object
• GET and PATCH routes

[SinisterRectus]

Some sort of narrative documentation about screening should be added. Something that explains how it works in the context of the API. How GUILD_MEMBER_ADD is emitted on the initial join and GUILD_MEMBER_UPDATE is emitted for the screening completion (if I have that right).

[advaith1]

added an explanation of screening

---

in 2fe4e62's desc I saw

true -> member is pending
false -> member becomes no longer pending (i.e., becomes a regular member)
not serialized -> member is not pending

which seems to indicate that pending should only be false in guild member update at the time the user accepts the rules, and it shouldn't be present anytime after; however, I see pending: false on a normal nickname change? can we have some clarification on this or is it a bug? it would be useful to many bots to know if this is the event caused by the user accepting the rules (so if there is some behavior with it not included, it should be documented)

[ckohen]

Couple of typos here.

[advaith1]

pending was previously added to the Guild Member object but looks like Guild Member Update Fields is a different object (might just be due to the legacy of presence data there?) so I added it to that too

[HuyaneMatsu]

When editing form_fields I always get 500 Internal server error, so I asume Discord wont merge it for a while (if they even will).

[advaith1]

@HuyaneMatsu you're probably sending an array instead of a string (#2394), you need to serialize the array to a string as this PR documents

[HuyaneMatsu]

@advaith1 Didn't see that issue :KoishiDerp:. The issue tracker is spammed with slash commands.

[msciotti]

Looks good to us once the merge conflict is fixed. Thanks @Kamilla-K for the review!

[advaith1]

could someone from Discord answer #2396 (comment)? i could mention it in the docs if its clarified

[Kamilla-K]

added an explanation of screening

in 2fe4e62's desc I saw

true -> member is pending
false -> member becomes no longer pending (i.e., becomes a regular member)
not serialized -> member is not pending

which seems to indicate that pending should only be false in guild member update at the time the user accepts the rules, and it shouldn't be present anytime after; however, I see pending: false on a normal nickname change? can we have some clarification on this or is it a bug? it would be useful to many bots to know if this is the event caused by the user accepting the rules (so if there is some behavior with it not included, it should be documented)
@advaith1

sorry for the confusion- did some digging and found out what's happening:

for our GUILD_ events that contain member (like GUILD_CREATE, GUILD_MEMBER_UPDATE, etc), we will always serialize pending and it will either be true or false.

the only times pending is not serialized, is for non GUILD_ events that contain member (for example, VOICE_STATE_UPDATE). for these events, pending members can't trigger them anyway, so the member returned with that event will never be serialized.

hope that makes sense!

[advaith1]

ah, I see; that makes sense although it's unfortunate that bots can't tell if the member update event is being triggered by the member passing screening.

I've added a bit about when pending is included to the pr, I think it's done now.

[ckohen]

Maybe also add to the member structure (after the similar note about user):

The field pending won't be included in the member object attached to events that do not begin with GUILD_

[advaith1]

hm, maybe just completely move it there?

[ckohen]

yeah, that could work too

[Kamilla-K]

thanks for documenting this!

[rickling]

thx @advaith1