organization: member-added webhook should include invite id

[andrewaustin]

Select Topic Area

Bug

Body

The Problem

I want to invite and remove organization members programmatically by email. Inviting is easy using the organization "create invitation" REST endpoint.( documented here: https://docs.github.com/en/rest/orgs/members?apiVersion=2022-11-28#create-an-organization-invitation ). However, once the user has accepted the invite, one cannot map their username to the invite since it was via email and not via github username. This means one cannot revoke a user's access to an organization because one does not know an invited user's username (only their email).

This seems like a major gap in the REST API.

Bug Fix

The organization: member-added webhook ( documented here: https://docs.github.com/developers/webhooks-and-events/webhooks/webhook-events-and-payloads?actionType=member_added#organization ) should include the invite id that has been accepted so that callers of the invite API can tie an invite sent with the accepted member. This would allow developers to revoke organization membership programmatically that was invited via email.

Other Thoughts

Since invites via email can be accepted by a github account with a different email address, removing a user from an organization by email is not sufficient to solve this issue.

[m-barthelemy]

We're having the same issue here when it comes to automating users provisioning/revocation.

As a bad workaround, we're currently asking new employees to send us their github username, this way we can invite them and we can map employee <==> github user.
However it could happen that a new employee gives us a wrong Github username, containing a typo but which is an existing account for someone else - and in that case that would be a security issue.

[andrewaustin]

@Iron-Ham @jmeridth Is there a formal way to have this bug tracked instead of just having it lost in the ether? I have another detailed writeup of the issue here: https://github.com/orgs/community/discussions/45673

[ettaboyle]

@andrewaustin Hi there,

Please note, contacting any member of GitHub Staff via unsolicited mentions or pings is strongly discouraged and may be considered a violation of our prohibition against harassment. Please review our Code of Conduct for more information.

Let's work together to keep GitHub Community a place where people feel safe to participate by being respectful of them and their time.

Any repeat and future violations may result in a temporary or indefinite block from the Community. Thanks for understanding.

[andrewaustin]

Hi @ettaboyle

Thanks for the feedback. I fail to see how a single ping on a year old issue could be considered harassment, but I will avoid mentioning Github employees in the future.

The Code of Conduct suggests opening a support ticket, which I did a year ago and they directed me here. Is this still the appropriate location to file bugs, or is there a better place?

Thanks,
Andrew

[ettaboyle]

I fail to see how a single ping on a year old issue could be considered harassment, but I will avoid mentioning Github employees in the future.

Thanks for your understanding @andrewaustin. We have to be consistent in how we respond to all posts that tag staff members and other users.

Is this still the appropriate location to file bugs, or is there a better place?

Yes, great question! The Community Discussions are still an appropriate place to file bugs. We have assigned community managers for each category who track trending posts from users to inform conversations with members of our product and engineering teams.

This community is managed by GitHub employees, but there is no SLA or guarantee each post will get a response from a community manager or product leader.

For your post here and any in the future related to product feedback (including bugs) or a feature request we encourage you to review the "Making Suggestions" guidelines in the repo readme including: "Once you kick off a discussion, the GitHub product team will evaluate the feedback but will not be able to respond to every submission."

Thank you for contributing and continuing to support other users in the GitHub Community Discussions.

[Omar-Gebal]

@andrewaustin I had the same issue and did an interesting workaround that kinda works well enough (I mark users with unlinked emails as suspicious in case the webhook fails).

[Omar-Gebal]

also keep in mind that this drawing may not be 100% accurate since I made it when thinking of a solution months ago, but it shows the general idea