# Autenticación de usuaries

Estamos pasando de un modelo integrado donde Usuarias son usuaries de
una red IMAP e Invitadxs son usuaries locales de la plataforma, a una
más "monolítica" donde las cuentas se gestionan desde la plataforma
misma.

Entonces, Usuaria e Invitadx se fusionan y su diferencia es solo de
privilegios sobre un sitio (puede hacer todo / solo puede cargar
artículos y modificar los propios).

No nos gusta la idea de implementar todo un sistema de privilegios,
primero porque queremos que Sutty sea una plataforma democrática y
segundo porque en nuestra experiencia nadie los usa y prefieren usar una
cuenta de administración.

La migración a Devise nos va a permitir tener recuperación de
contraseñas, registro independiente, correos de bienvenida y varias
cosas más.

Planeamos que Sutty también sea un proveedor de oAuth, para poder
integrarla con otras plataformas comunitarias
(rocket.chat/mattermost.com principalmente).

## Base de datos

Los Sitios tienen una contraparte física, de archivos, pero también se
crean en la base de datos para establecer relaciones con Usuaries.

Une Usuarie puede tener muchos Sitios y viceversa.  En Rails esto se
llama "tiene y pertenece a muchos" (HABTM en inglés).

Sin embargo también queremos saber qué rol tienen, con lo que
necesitamos dos tablas de HABTM, una de Invitades y otra de Usuaries.
De lo contrario necesitamos establecer roles y ya entramos en las
dificultades que decíamos más arriba.

No podemos saber desde cuándo se creo la relación, a menos que tengamos
una tabla de actividades por separado.

Podemos saber quién es invitade ingresando a un sitio y fijándonos si
está en su lista de invitade.  Lo mismo para usuaries.

Les usuaries pueden bloquear invitades y a otres usuaries, y sumar
usuaries e invitades a su sitio (via correo de invitación).

## Invitaciones a sitios

### Enviar invitación

Desde la gestión del sitio se puede invitar a nueves usuaries e
invitades.  Se les envía un correo (y cuando tengamos sistema de
notificaciones, una notificación) donde pueden confirmar su
participación.

Si no tienen cuenta, tienen que registrarse completando los datos en el
momento, sino se pueden loguear normalmente.

Si ya están logueades, se acepta la invitación inmediatamente.

Para poder hacer una invitación con consentimiento, se guarda la
relación en una tabla aparte.  Cuando la usuaria acepta la invitación
esa relación se borra y se aplican los cambios.

En el futuro cambiaríamos el sistema de permisos separados que tenemos
ahora por una tabla de roles (por qué no la hicimos desde el principio!)
con un campo binario que indique si ya se aceptó la invitación o no.

### Invitades desde la web

Al publicar la URL de invitación, les invitades se puedan registrar
por su cuenta.  Solo deben completar sus datos (correo y contraseña) y
reciben un correo de confirmación.

En la configuración del sitio hay que distinguir entre invitades por
invitación o por registro automático.