Bug: Invites are not being accepted

Summary

It appears as though invites are not being accepted.

Steps to reproduce

• Create/find a group/project you have permissions to invite (ex. pcordero+testtrialprod04242024@gitlab.com)
• Invite a non-existent user to GitLab (ex. pcordero+1TestInvitedUserPROD@gitlab.com and pcordero+2TestInvitedUserPROD@gitlab.com)
• Receive the invitation email in your email inbox
• Go through invite_registration
• Confirm on step 1 that the email invited matches

Example Project

https://gitlab.com/821931/first

What is the current bug behavior?

• Invite does not appear to be accepted as on /welcome a user sees
• User is then not dropped into the group/project they were invited to
• When logging back into the account that invited pcordero+testtrialprod04242024@gitlab.com
  • the member is not added
  • the invite is still pending

What is the expected correct behavior?

• On /welcome a user should see
• They should then be dropped into the group/project they were invited to.

Relevant logs and/or screenshots

Output of checks

Results of GitLab environment info

Expand for output related to GitLab environment info

(For installations with omnibus-gitlab package run and paste the output of:
`sudo gitlab-rake gitlab:env:info`)

(For installations from source run and paste the output of:
`sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)

Results of GitLab application Check

Expand for output related to the GitLab application check

(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true)
(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true)
(we will only investigate if the tests are passing)

Possible fixes

see #457938 (comment 1879484286)

• Fix the query to be case downcase in the search of invite_email.
  • always pick latest updated_at somehow as the winner of the invite to accept maybe
    • incomplete thought: Member.where('LOWER(invite_email)=LOWER(?)', verified_emails).order(updated_at: :desc).distinct(:invite_email) but somehow distinct by lower has to happen too.
  • existing records we won't be able to solve in the members table, but the above will allow us to consider user behavior and possible other member record differences if more than one insensitive match exists for an email.
• Create follow-up to set new invite by email members to be downcase on insertion to database.
  • 2 diff approaches !151792 (closed) or !151796 (merged)
  • invite modal will need error case consideration in matching token color and error message with email casing considerations - see below:
  • note: this part could be a follow-up issue as it is not needed to resolve the acceptance bug that this issue centers on. - Set new invite by email members to be downcase ... (#460708 - closed)