DEV: deprecate `invite.via_email` in favor of `invite.emailed_status`
This commit adds a new column `emailed_status` in `invites` table for
tracking email sending status.
0 - not required
1 - pending
2 - bulk pending
3 - sending
4 - sent
For normal email invites, invite record is created with emailed_status
set to 'pending'.
When bulk invites are sent invite record is created with emailed_status
set to 'bulk pending'.
For invites that generates link, invite record is created with
emailed_status set to 'not required'.
When invite email is in queue emailed_status is updated to 'sending'
Once the email is sent via `InviteEmail` job the invite emailed_status
is updated to 'sent'.
There was a race condition when 2 invites existed for 1 user where in some
cases data from both invites would be used for the redeem. Depending on DB
ordering.
Fix is to delete duplicate invites earlier in the process prior to
`redeem_from_email` being called.
This reduces chances of errors where consumers of strings mutate inputs
and reduces memory usage of the app.
Test suite passes now, but there may be some stuff left, so we will run
a few sites on a branch prior to merging
Includes support for flags, reviewable users and queued posts, with REST API
backwards compatibility.
Co-Authored-By: romanrizzi <romanalejandro@gmail.com>
Co-Authored-By: jjaffeux <j.jaffeux@gmail.com>
Do not send an activation email to users invited via email. They
already confirmed their email address by clicking the invite link.
Users invited via link will need to confirm their email address before
they can login.
https://meta.discourse.org/t/bulk-invites-and-trust-level/73535
If the user enters password when accepting invite they were not granted
trust level based on their group privileges. It was because `password_required` was set to true when creating user record and when the user was updated again when granting trust level the password validation was raising error saying that the password is empty. This commit fetches fresh user record after the user is created so that the user record can be updated successfully.
This commit fixes the case where invited users who typed in a password
would not be approved by default. Because we moved the user create logic
for an invited user there was a clash with the `save` in the user model
and the `save` in the invite_redeemer class.
- added approve logic into invite_redeemer class.
- added tests to verify that the user is approved
- added a check to see if must_approve_users is on
- added a check to see if the inviter is staff
- go ahead and approve the user if must_approve_users is off
- keep existing User.approve workflow if user exists
- improve if/else logic to remove duplicate code
- use `Time.zone.now`
