feat(growth): pull out helper methods for organization_invite_request_details

[scefali]

This PR pulls out some helper methods from OrganizationInviteRequestDetailsEndpoint such that we can leverage common code with an upcoming PR that allows approving member requests with Slack. This is necessary so we can avoid calling the OrganizationInviteRequestDetailsEndpoint endpoint internally from the Slack webhook route while reducing the amount of duplicated code.

I had to factor out an audit log method that does not require a request so that we can call it from a context that doesn't have a request coming from a logged-in user (Slack webhook).

Note I made a utility file called src/sentry/utils/members.py but it might make more sense to move those methods to the OrganizationMember class.

[wedamija]

The refactor looks good, thanks for doing this. All my comments are just nits, lgtm

I agree that we probably need somewhere other than utils for this kind of thing, but we can figure this out later.

Probably the OrganizationMember class is a good idea, like you suggested. Another option might be the manager, since these methods don't operate on a specific instance of an OrganizationMember. A third option is making something like an invitations module/django app and placing all related code there, maybe a bit overkill though.

[wedamija]

Does it make sense at all for organization to be passed as a parameter to get_member_invite_query?

[scefali]

@wedamija I purposely left it out because I have a query where I don't have the organization. See: https://github.com/getsentry/sentry/pull/29708/files#diff-38bebb13f20409b4ea44e977a5c976b696c2e8f3e1ec02855b2581e5d422f4e5R378-R384

The alternative was to add the organization_id to the callback_id but I figured it was better to have a more minimalist approach for what data I need to send.

[wedamija]

Nit: It might be a good idea to add tests for this file, now that this functionality is stand-alone.

[scefali]

@wedamija good call, I can add some basic tests

[wedamija]

Will these functions be used outside of APIs? If that's the case, we might want to raise generic errors here that can be intercepted by the api and other places that are using this function.

Just something simple like:

class CannotInvite(Exception):
    # Probably needs a better name
    pass

that you can throw.

[scefali]

@wedamija are you saying to raise a specific error then have the serializer catch that error and raise a ValidationError? I think that makes sense.

[wedamija]

Yeah exactly, it just makes these functions a little more generic and non-api specific

[scefali]

The refactor looks good, thanks for doing this. All my comments are just nits, lgtm

I agree that we probably need somewhere other than utils for this kind of thing, but we can figure this out later.

Probably the OrganizationMember class is a good idea, like you suggested. Another option might be the manager, since these methods don't operate on a specific instance of an OrganizationMember. A third option is making something like an invitations module/django app and placing all related code there, maybe a bit overkill though.

Well, all those helper methods take an instance of the OrganizationMember as the first argument so we can just do it on that class, i'll make that change