Changes to Membership Screening API

[rickling]

Hey everyone, a couple of weeks ago we released Membership Screening, a feature that allows servers to require members to agree to rules before they can talk. As part of this, we also introduced new API support & docs (thx @advaith1 ).

This is an announcement that we intend to make significant changes to the API specifically related to getting and editing Membership Screening and the Membership Screening object. Long story short, the current API design isn't great and can be improved. As such, we're undocumenting the current documentation until we finalize the new API and roll it out.

We ARE NOT making changes to pending members and how that ties into GuildMemberAdd and GuildMemberUpdated. You can continue to use pending=false to add roles or w/e after someone passes the screening.

Hopefully, this doesn't impact too many of you. Thanks for building cool stuff.

Edit cuz as correctly pointed out it should be pending=false.

[advaith1]

should probably remove the routes at the bottom of the file too

also looks like your table formatting setting is different from Mason's (has spaces around the pipes in the divider line, which was the old formatting)

[rickling]

should probably remove the routes at the bottom of the file too

also looks like your table formatting setting is different from Mason's (has spaces around the pipes in the divider line, which was the old formatting)

woops good catch, I'll fix those.

[A5rocks]

I assume #2530 will be fixed in the next iteration of the API design?

[Skillz4Killz]

We ARE NOT making changes to pending members and how that ties into GuildMemberAdd and GuildMemberUpdated. You can continue to use pending=true to add roles or w/e after someone passes the screening.

I'd like to request that changes SHOULD be made to this as well. pending is one of if not the most confusing things to use in the entire discord API right now. The current implementation is also hard on devs as it essentially requires us to cache every single member just to know when a member has passed the screening.

This is the second time a Discord staffer(not blaming, just as evidence to how confusing this is) has made an inaccurate statement about how pending works. pending=true would not be used add roles that would mean the user is still pending.

Let's make this simpler please 🙏 Thank You!

[A5rocks]

Hey I was wondering if u can add like an anti alt feature or something so we can easily prevent alts and ban evasion

I believe the scope was specified at the top. This is not in said scope...

Idk how but like ik people use vpn to bypass the ipban but if u can make an alt detector which scans every members ip every 5hours or some

They can stay on their VPN

if 2 people in a server has a same ip they get auto banned but it ignores admins and owners.

So I should get banned for visiting the same residential area as someone else that's in the server (NATs are a thing)? No thanks.

(Just writing this so that you know why you're being downvoted...)

PS https://support.discord.com/hc/en-us/community/topics

[MinnDevelopment]

So, from what I understand the problem of join roles persists. You still need to cache the members with pending=true until either a member remove or member update happens because you otherwise have no way to tell that they pass screening? This is very unfortunate.

Edit: This is not only a problem for adding roles on joins, this is generally the problem of losing a way to tell that a member joined for any use-case unless caching the state of pending members. There are a multitude of possible ways to use join events for other purposes, such as welcome DMs, captcha bots, and other similar features.

[advaith1]

I don't see why you'd need to cache for join roles (in most cases), just check if (!member.pending && !member.roles.includes('roleid')

[rickling]

We ARE NOT making changes to pending members and how that ties into GuildMemberAdd and GuildMemberUpdated. You can continue to use pending=true to add roles or w/e after someone passes the screening.

I'd like to request that changes SHOULD be made to this as well. pending is one of if not the most confusing things to use in the entire discord API right now. The current implementation is also hard on devs as it essentially requires us to cache every single member just to know when a member has passed the screening.

This is the second time a Discord staffer(not blaming, just as evidence to how confusing this is) has made an inaccurate statement about how pending works. pending=true would not be used add roles that would mean the user is still pending.

Let's make this simpler please 🙏 Thank You!

Discussing... stay tuned.

[GolfingSuccess]

I don't see why you'd need to cache for join roles (in most cases), just check if (!member.pending && !member.roles.includes('roleid')

Because what if I want to unverify a member for whatever reason?

[FasterSpeeding]

was removing the optional marker from premium_since intentional here?

[advaith1]

364e7fb

[FasterSpeeding]

Doesn't take too long to get guild member update events without premiums_since though 😕

[erkinalp]

A better design could use an event such as SCREENING_PASSED to prevent the pending member caching requirement on the bot side.

[SamTheone1]

removed comment