AO3-6712 Allow invites to be resent and index invitee_email

[weeklies]

Issue

https://otwarchive.atlassian.net/browse/AO3-6712

Purpose

• Revert AO3-6666 Revert AO3-6609 invitation resending (#4689) (#4685) (#4648) #4710 with a new index
• Allow the "Look me up" button to have a hover style effect
• Additional i18n

Testing Instructions

See Jira issue.

[Bilka2]

The rails code that produces the slow query in AO3-6666 is Invitation.unredeemed.from_queue.find_by(invitee_email: params[:email]) in invite_requests#show and invite_requests#resend.

Before, first iteration of this feature:

MariaDB [otwarchive_development]> EXPLAIN SELECT `invitations`.* FROM `invitations` WHERE (invitee_email IS NOT NULL and redeemed_at IS NULL) AND `invitations`.`external_author_id` IS NULL AND (`invitations`.`creator_type` = 'Admin' OR `invitations`.`creator_type` IS NULL) AND `invitations`.`invitee_email` = '3@example.com' LIMIT 1;
+------+-------------+-------------+------+-----------------------------------------+-----------------------------------------+---------+-------+------+------------------------------------+
| id   | select_type | table       | type | possible_keys                           | key                                     | key_len | ref   | rows | Extra                              |
+------+-------------+-------------+------+-----------------------------------------+-----------------------------------------+---------+-------+------+------------------------------------+
|    1 | SIMPLE      | invitations | ref  | index_invitations_on_external_author_id | index_invitations_on_external_author_id | 5       | const | 10   | Using index condition; Using where |
+------+-------------+-------------+------+-----------------------------------------+-----------------------------------------+---------+-------+------+------------------------------------+
1 row in set (0.001 sec)

After, with the index added in this PR :

MariaDB [otwarchive_development]> EXPLAIN SELECT `invitations`.* FROM `invitations` WHERE (invitee_email IS NOT NULL and redeemed_at IS NULL) AND `invitations`.`external_author_id` IS NULL AND (`invitations`.`creator_type` = 'Admin' OR `invitations`.`creator_type` IS NULL) AND `invitations`.`invitee_email` = '3@example.com' LIMIT 1;
+------+-------------+-------------+------+----------------------------------------------------------------------------+------------------------------------+---------+-------+------+------------------------------------+
| id   | select_type | table       | type | possible_keys                                                              | key                                | key_len | ref   | rows | Extra                              |
+------+-------------+-------------+------+----------------------------------------------------------------------------+------------------------------------+---------+-------+------+------------------------------------+
|    1 | SIMPLE      | invitations | ref  | index_invitations_on_external_author_id,index_invitations_on_invitee_email | index_invitations_on_invitee_email | 1023    | const | 1    | Using index condition; Using where |
+------+-------------+-------------+------+----------------------------------------------------------------------------+------------------------------------+---------+-------+------+------------------------------------+
1 row in set (0.001 sec)

"Using index condition" sounds pretty good combined with the fact that it's using the invitee_email as the index now:

if parts of the WHERE condition can be evaluated by using only columns from the index, the MySQL server pushes this part of the WHERE condition down to the storage engine. The storage engine then evaluates the pushed index condition by using the index entry and only if this is satisfied is the row read from the table.

So in most cases only one row should be getting read from the table. (Invitee email seems to be intended to be unique, but this is not getting validated so it may be more than one row. But it should be pretty rare.) That sounds like near the best case we could have, so I would say just this index on invitee_email should be enough to get good performance. 👍

It looks like previously it was doing this strategy with the external_author_id index, with external_author_id = NULL. Invitations created via the "request an invite" page do not have an external author set, meaning most invitations have external_author_id = NULL. So it was reading a whole lot of rows -> performance problem.

If there are still performance problems after this PR, we could try to validate invitee_email with uniqueness: true, allow_nil: true on the model and convert to an unique index in the DB. However, adding this uniqueness validation may be a behaviour change so I think it's fine to hold off for now.

[Bilka2]

Looks good, thank you!

Note: I only reviewed the new changes, not the code that was reverted in AO3-6666, because that already went through review and QA on staging.

[Bilka2]

Completely optional, nitpick: It would be nice if this also used count as the interpolation variable and had the one/other distinction in the locale.