feature: members invitations

[lucasmenendez]

New endpoint to invite new organization members:

• The endpoint must include the required user information and the role of that user in the organization.
• The organization must exists before invite new members.
• Only admins can invite new members.
• If the new member user already exists, the endpoint just requires the email address of the user.
• If the new member does not exists yet, the endpoint requires also the first name, the last name and the phone of the new user. The new account will be created with a random password and a code to reset it will be sent to the user (via email or sms).

[selankon]

If I understand, when you are inviting somebody and the account doesn't exist, you have to provide the specific information to create this account.

Imo I think this is not how it should work, actually the ui looks like:

So simplifying:

• If you want to invite somebody you need only the email.
• Then on the received email it should have an invite code that brings you to the app and if you have an account add the new signer organization to your organizations list, and if not you go to the create account form adding the organization as your default org.

I am correct with this description @jpaulet ??

[lucasmenendez]

Right now the backend needs some information about new users to create them in the database. It is needed because of the validations we implement in the database, such as uniqueness and non-empty first and last name, or phone number.

If we want to support invitations for non-users without this information, we need to implement an intermediate status for these users, to give them the possibility to fill this information before receiving the invitation code.

The current behavior has been defined to use the current "reset password" flow for simplicity.

[selankon]

Right now the backend needs some information about new users to create them in the database. It is needed because of the validations we implement in the database, such as uniqueness and non-empty first and last name, or phone number.

If we want to support invitations for non-users without this information, we need to implement an intermediate status for these users, to give them the possibility to fill this information before receiving the invitation code.

The current behavior has been defined to use the current "reset password" flow for simplicity.

Imho we cannot create a user on the database only inviting it from the admin control panel.

In addition, an admin could not know the phone number or the last name. After talk with @jpaulet we talk that the only thing needed to invite someone is to use the email.

If when accessing to the invite link the user is not loged in, the signup form will be shown, and the invited organization will be added as default.

Probably we could add a inviteCode parameter when sending the signup form and provably will need a table that relation invite codes and emails.

But i can be wrong, @jpaulet could you explain detailed how the UX should work?

[jpaulet]

Right now the backend needs some information about new users to create them in the database. It is needed because of the validations we implement in the database, such as uniqueness and non-empty first and last name, or phone number.
If we want to support invitations for non-users without this information, we need to implement an intermediate status for these users, to give them the possibility to fill this information before receiving the invitation code.
The current behavior has been defined to use the current "reset password" flow for simplicity.

Imho we cannot create a user on the database only inviting it from the admin control panel.

In addition, an admin could not know the phone number or the last name. After talk with @jpaulet we talk that the only thing needed to invite someone is to use the email.

If when accessing to the invite link the user is not loged in, the signup form will be shown, and the invited organization will be added as default.

Probably we could add a inviteCode parameter when sending the signup form and provably will need a table that relation invite codes and emails.

But i can be wrong, @jpaulet could you explain detailed how the UX should work?

Yes, the flow is as follows:

1 - Send a invitation (via only mail)
2 - Receive the invitation in your mail
3-
3.1 - If there is already a user with that mail, create a new relation between the user and the org
3.2 - If there isn't a user, show the form creation, with the code and the org in the URL. When the user register, it get automatically redirected to the invited org with the email validated.

I think that the best way to do it, is create a new table for the org - mail - invite code relation, and when the user enters the step 3, in the 3.1 we need to remove this relation, and in the step 3.2, create the new user and delete the relation.

In this way, the admin that invites another one, only needs to fill the mail (as the design) and is not "creating" the user, only the invitation. When the user performs the action (accept the invite / register) then the new user is created.

@selankon @emmdim @lucasmenendez if there is any more doubts, let me know or comment it in the tech weekly.

[lucasmenendez]

I have some doubts about the behavior:

• Our notifications are based on email but also on SMS. Are the admin invitations supported by email only?
• Can an admin renounce? Can admins be kicked out by other admins with higher role?
• Are the invitations valid for ever? We need to implement a mechanism to keep the table that stores the relations between new_admins-invitations-orgs clean?

cc/ @jpaulet

[jpaulet]

I have some doubts about the behavior:

* Our notifications are based on email but also on SMS. Are the admin invitations supported by email only?

* Can an admin renounce? Can admins be kicked out by other admins with higher role?

* Are the invitations valid for ever? We need to implement a mechanism to keep the table that stores the relations between new_admins-invitations-orgs clean?

cc/ @jpaulet

1 - By now yes. Only via mail. We will think if it's make sense in the future to send a SMS or do the same mechanism but instead of receiving it in a email, receiving it in a SMS (with a link and everything).

2 - Renounce = "delete account" (we will have to implement this). Be kicked out, right now no, but in the end we will have to implement something similar to this, admins can kick out administrators and viewers, and the "founding" admin (owner) can kick other admins. But right now, we stick to an MVP (but if it helps to the design, go ahead).

3 - No, after one week they expire. This way we keep the table clean (delete them after accepting or after 1 week).

If you have more doubts, let me know.

[lucasmenendez]

Update

• Now the invitations are stored in the database and there are removed when their expiration time is reached (by default 5 days from the creation).
• If an existing user is invited to join into an organization, only the invitation code is required to complete the process.
• If a new user is invited to join into an organization, the new user info is required to complete the process, including the password, first and last name, and phone number.