Support re-sending user invitations

[rijkvanzanten]

Discussed in #17856

^{Originally posted by david-zacharias March 20, 2023}

Summary

It should be possible to re-send an invitation mail to users already invited to directus (as long as user.status is invited)

Basic Example

No changes to the API signature

Motivation

If users miss to receive an invitation mail (mail got bounced, user delete invitation by accident, or invite token ttl ended), the user must be deleted from directus users table to allow sending a new invite. This is extra steps which hopefully can be avoided.

Detailed Design

inviteUser checks if a user (identified by email) is already invited to directus (status: invited).

If the user does not exist, current behavior of creation and sending takes place.

If the user exists a new token is created and invitation mail is sent to the user.

If a user is re-invited, the API will simply recreate the invite token and send the new email. If the user changed the Role in the invite, the API will try to update the user using the permissions of the user creating/updating the invite

Requirements List

Must Have:

• Resending invite emails
• Allowing the role to be changed in the updated invite
• Must rely on the permissions of the inviter for create/update

Should Have:

—

Could Have:

• A way to "cancel" invites that isn't deleting the user

Won't Have:

—

Drawbacks

There's possible confusion in the requirement of create vs update permissions when changing the role of an invite.

Alternatives

Instead of changing the behavior of inviteUser a new API endpoint for explicitly resending invites could be added. Since a users is known to the system after first invite it could be a sub-route of a user like POST /users/:id/invite, however this extends development complexity.

Adoption Strategy

Simple enhancement on top of an existing endpoint. The signatures and current behavior remain the same, so this is not a breaking change.