Gestion des utilisateurs
===

Document de travail sur la gestion intégrale des utilisateurs au sein des applications HOPIMEDICAL.

# Contexte actuel

Cette partie décrit la prise en charge actuelle des utilisateurs dans les applications.

Cela inclut la gestion des accès standards par login/mot de passe/token/2FA ainsi que la gestion des données utilisateurs, qui elle, se fait actuellement grâce au backoffice de l'application Planning (ClinicAlpha).

## Modèle de données

Modèle de données de l'application Planning.
Etant donné que la gestion des utilisateurs se fait par le backoffice de cette application, on peut considérer que ce modèle est celui qui intègre le plus nos besoins actuels, à savoir, entre autre:

* Données liées à TELEMEDICA
* Informations concernant des médecins
* Données liées à eRosetta
* Disponibilitées des utilisateurs

À noter qu'il a été crée à partir de MySQL Workbench et ceci impose quelques limites pour schématiser des données NOSQL.
Quelques ajustements ont été faits:
* Des types de données supplémentaires ont été crées arbitrairement:
* `*List` (`StringList`, `FloatList`...etc...), il s'agit d'un tableau composé d'un type de donnée particulier.
* `Object`: Données clés => valeurs. Quand cela est nécessaire, le détail des clés est représenté à la suite de la déclaration, par exemple:

    sectionLocation: Object
    sectionLocation.address: String
    sectionLocation.city: String
    ...etc...

* Les relations N:N ne sont pas modélisées avec une table intermédiaire, comme MySQL l'imposerait. On utilise à la place une relation "non-identifiante" ("Non-Identifying Relationship" dans le logiciel, représenté par un trait en pointillé) avec un type de données `*List` du côté l'entité la plus logique.
* Exemple: Un utilisateur peut avoir N spécialités ***ou*** une spécialité peut concerner N utilisateurs. Le plus logique ici est d'utiliser une liste de spécialités dans les informations de l'utilisateur. Il s'agit d'une liste de quelques éléments (< 10) alors qu'à l'inverse, placer l'information dans les données de la spécialité reviendrait à gérer des listes à plusieurs centaines d'éléments.


Pour le moment, le patient n'a pas de compte propre. Il indique ses coordonnées lorsqu'il fait sa demande de RDV.
Celles-ci sont enregistrées avec les informations de l'évènement

## Resources

Liste des ressources utilisées pour les principales actions des utilisateurs.
*Remarque: Lorsque les bundles ne sont pas préfixés, il s'agit de `"hopi/"`
ex: `UserBundle` correspond à `hopi/user-bundle`*

### Web form user login:

Il s'agit de la page de connexion standard

- Bundles sollicités: `UserBundle` + `CryptographyBundle`
- `UserBundle:Repository:User`
->setHasher(`CryptographyBundle/Services/PHPCorePassword/Password`)
- `UserBundle:Entity:User`

**Explications supplémentaires:** `CryptographyBundle` propose un service `hasher` qui peut être implémenté de plusieurs manières.
Actuellement, nous utilisons uniquement l'implémentation faite par `PHPCorePassword` qui correspond aux fonctions `password_hash` et `password_verify` avec l'algorithme `PASSWORD_BECRYPT`. L'avantage est que le salt est inclu directement dans les hash produits par cet algo.

**Remarque:** `CryptographyBundle` a été développé de 2014 à 2016, époque à laquelle il nous semblait pertinent de placer divers modules liés au chiffrement des données au même endroit.
Depuis, avec le package `apicrypt` et `ApicryptBundle` qui l'utilise, il n'y a plus d'intérêt à maintenir ce code. Il faudra nettoyer les bundles qui en dépendent (surtout `UserBundle`) et déplacer les services (de `CryptographyBundle` vers `UserBundle` essentiellement).

### API

Le bundle PlanningBundle propose des webservices permettant de gérer les données utilisateurs.
Un token est nécessaire pour y accéder.
Pour le moment, celui-ci est généré en dur dans la base de données et partagé avec l'application utilisant le webservice.

#### API GET user data:

Webservice permettant de récupérer les données des utilisateurs (médecins, infirmières, secrétaires...).
Les utilisateurs enregistrés dans cette application peuvent se connecter au site via le formulaire de login standard (cf: [Web form user login](#Web-form-user-login)).
Au niveau de la base de données, la même collection (`"user"`) est utilisée avec les bundles `PlanningBundle` et `UserBundle` (donc plusieurs Repository différents).

Ressources logicielles utilisées:

- `PlanningBundle`
- `PlanningBundle:Repository:User`
- `PlanningBundle:Entity:User`

**Utilisation:** Une requête toutes les 15 minutes par instance lancée.

**Exemple d'utilisation:** [Récupération d'une liste de médecins avec leurs disponibilités](https://hackmd.io/sn6wlr0oRpSAo4PJu0zpiw). todo:Definition-de-l-api-visio

#### API POST/PUT user data:

Webservice permettant d'enregistrer ou mettre à jour des données utilisateur.

Ressources logicielles utilisées:

- `PlanningBundle`
- `PlanningBundle:Repository:User`
- `PlanningBundle:Entity:User`

**Remarque:** Un nettoyage devra être fait à ce niveau. Le backoffice étant complet, nous ne devrions plus avoir besoin d'API pour cela, d'autant plus que les utilisateurs disposant des droits pour l'API sont en général déjà admin.

**Exemple d'utilisation:** [Enregistrement d'un utilisateur](https://hackmd.io/3fwLyusDSAKI3DnGlvAC8g). todo:Definition-de-l-api-user

### BackOffice

Le back est une application symfony standard qui utilise les ressources de son bundle uniquement:

- `PlanningBundle`
- `PlanningBundle:Repository:User`
- `PlanningBundle:Entity:User`

Elle est structurée autour de vue TWIG séparées. Côté client, on se base sur jQuery pour implémenter des dynamiques simples.
Il ne s'agit pas d'une SPA en VueJS, par exemple, qui aurait utilisé un controlleur type `APIController` comme modèle (M du MVC) au sens large.


#### Agenda des médecins

Les médecins disponibles sont présentés sur cet agenda


#### Formulaire utilisateur

Edition / enregistrement d'un utilisateur


#### Création de liens users <-> centres


#### Planning de disponibilité


Pour un chariot:

#### Gestion des spécialités