Skip the invitation process entirely (automatically accept invitation)

This fit our use case as well. I'm a little behind on updates but this applied to 2.0.1 just fine and works as advertised.
The user created the account with the invite link and their invite was automatically applied.

I can potentially see a need to not have this apply but if it was a ginvite setting that might be good enough to allow administrators to toggle it on if needed.

It saved a ton of confusion for new users/invitees.

After updating to 2.1.0 the patch in 3 no longer applied. I attempted to re-roll it here.
It seems to work fine in the latest 2.x of ginvite.

Oops. I'm still getting used to this process when composer is involved. The patch in 5 is busted.

I'm not sure what is different between 2.0.1 and 2.1.0 exactly that would cause this but when calling

$group_membership->save();

I get a problem where php exits with a connection reset by peer error.

The patch in 6 is not working for me anymore. Still investigating.

I ended up leveraging the event that is dispatched at the end of the ginvite user_insert hook.

In a custom module EventSubscriber I used the same basic idea, code snips here:

Necessary use statements:

use Drupal\ginvite\Event\UserRegisteredFromInvitationEvent;
use Drupal\group\Entity\GroupContent;
use Drupal\ginvite\Plugin\GroupContentEnabler\GroupInvitation;

Event Callback

  /**
   * Auto Accept Group Invitations from the ginvite module
   *
   * @param \Drupal\ginvite\Event\UserRegisteredFromInvitationEvent $event
   *   The UserRegisteredFromInvitationEvent to process.
   */
  public function autoAcceptGroupInvitation(UserRegisteredFromInvitationEvent $event) {
    $invitation = $event->getGroupInvitation();
    $group_content = $invitation->getGroupContent();
    $group = $group_content->getGroup();

    $contentTypeConfigId = $group_content->getGroup()
      ->getGroupType()
      ->getContentPlugin('group_membership')
      ->getContentTypeConfigId();

    // Pre-populate a group membership with the current user.
    $group_membership = GroupContent::create([
      'type' => $contentTypeConfigId,
      'entity_id' => $group_content->get('entity_id')->getString(),
      'content_plugin' => 'group_membership',
      'gid' => $group->id(),
      'uid' => $group_content->getOwnerId(),
      'group_roles' => $group_content->get('group_roles')->getValue(),
    ]);

    $group_membership->save();

    // set the status of the invitation to accepted and save it
    $group_content->set('invitation_status', GroupInvitation::INVITATION_ACCEPTED);
    $group_content->save();
  }

Subscribed Event:

  /**
   * {@inheritdoc}
   */
  public static function getSubscribedEvents() {
    // ginvite event to auto accept invitation
    $events['user_registered_from_invitation'][] = ['autoAcceptGroupInvitation'];
    return $events;
  }

This seems to work without causing memory issues like I was experiencing with the patch.

The method in #8 works for me. Thanks!

I need your opinion:
1) How useful it would be to have such settings per plugin. So, we can enable / disable it per group type ?
2) Or it is better keep it per invitations. For example on the form, we can have a checkbox "Accept invitation automatically" ?

Would it be possible to provide it as an option per group instance?

I can see a need for one group of the same type to use autoaccept while another wants to provide the second step after invite.

If a per instance group setting would be too difficult, I would vote for option 1 (autoaccept toggle per group type). I think autoaccept is the best experience for most invitees to a group.

1) I've added a new settings on the plugin. So, we can control it per group type and change it at any moment
2) Also, I've added a new event, when user login with invitations. In this case I check current invitations and accept them too. Also, this event could be useful for some other cases
3) I refactored a bit code

I will now continue to work on version for Group 2 and Group 3 based on #12