Support re-sending user invitations

[david-zacharias]

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.

[rijkvanzanten]

What happens if the request for re-invitation contains a role different than inital invite request?

Great question 🤔 Whenever an invite is created, the user record already exists. Somebody could theoretically open that user and edit the role there too (if permissions allow). Maybe the easiest solution for now is—on reinvite—to disallow updates to the invite, and simply just re-send the email. If the invited user needs to be changed, it can be done by editing the created user record 👍🏻

[david-zacharias]

I am also friend of a solution which keeps things easy for now. I did not think about changes of the user via directus studio or API between invitation (creation) and re-invitation, good point.

One thought: How about raising an error if role of re-invites mismatches the role stored in direcuts? This way, it can be seen as a check to not unintentionally re-invite if one changed the role in the meantime... and the api signature for invite requires a role, so I think it should have some meaning for re-invites as well.

[david-zacharias]

@rijkvanzanten If you find a minute - dispite the important dicussions (#17977) - to give feedback or an aproval to my last thought, I'd be thankful and ready to create a PR.

[rijkvanzanten]

My b! Busy times over here 😅

One thought: How about raising an error if role of re-invites mismatches the role stored in direcuts? This way, it can be seen as a check to not unintentionally re-invite if one changed the role in the meantime... and the api signature for invite requires a role, so I think it should have some meaning for re-invites as well.

Hmm yeah, we'd need to have some sort of check like that, but I'm not sure if blanketly disallowing the re-invite in that case is the correct approach. There's no clear indicator what the current role was supposed to be when you re-invite, so I can imagine it to be very tricky to then "guess" what role might've been used previously 🤔

That being said, I don't really know a better answer though.. Silently ignoring the role for those feels better for emails that already exist, but you end up with a very confusing scenario if you invite multiple new emails, where some of them already exist 🤔

[david-zacharias]

Thanks again, @rijkvanzanten, I know your desk is full.

Maybe one step back: I’d say, the core problem is that on re-invite (if we keep the api as it is) users must hand in a role. So we have the newly handed in role and an existing one.

What do I as user expect? Probably that the role I hand in is the role the user gets assigned. Especially for the case you raised of mixed invites and re-invites, I would expect all users to have the same role. This is also what the Directus Studio UI, implies with the required selection of a role (to assign).

So currently the re-invite fails with an error, if the mail address is already known to the system.

Also an error is thrown if the user has insufficient permissions for inviting (creating) users (needs creation rights on fields status, role, and email).

What if we go for the update way and check if the role changed. If so, we do update the role. This would allow re-invites for everyone with no breaking change (in respect to permissions) if re-invite shares same role as stored user. For cases where roles mismatch permission to edit role is needed to allow re-invites. If this is not granted, the re-invite will fail, but this is similar to current behaviour, yet with another error message (Permission denied instead of duplicate email - maybe we can tweak this in the Studio UI for better UX).

For all users acting as admins this has no effect, since they have needed permissions granted by design, and they can do re-invites.

Puh, sounded like such a simple thing to add to Directus.

[rijkvanzanten]

What if we go for the update way and check if the role changed. If so, we do update the role. This would allow re-invites for everyone with no breaking change (in respect to permissions) if re-invite shares same role as stored user. For cases where roles mismatch permission to edit role is needed to allow re-invites. If this is not granted, the re-invite will fail, but this is similar to current behaviour, yet with another error message (Permission denied instead of duplicate email - maybe we can tweak this in the Studio UI for better UX). For all users acting as admins this has no effect, since they have needed permissions granted by design, and they can do re-invites.

Deal! 🤝 Knowing these edge-cases now, this feels like the most "expected" thing to happen to me 🙂

Puh, sounded like such a simple thing to add to Directus.

Ha! Welcome to Directus! I think you can see why I prefer having these discussions first before we dive into code, much easier to reason through the details like this 🙂 I'll open an Issue to signal this is ready for implementation! 🚀

[rijkvanzanten]

This feature request has been accepted and is queued to be implemented! You can follow along with the progress here: #17994