Votre première session

Créez un nouvel endpoint /users/stats qui renvoie un objet JSON avec le nombre d'utilisateurs et l'âge moyen à l'inscription. 

Utilisez notre table users déjà existante dans PostgreSQL. 

Vous pouvez vous référer à l'endpoint /orders/stats dans statsController.js pour comprendre comment nous structurons les réponses. 

Assurez-vous que le nouvel endpoint est couvert par la suite de tests StatsController.test.js.

Dans `UserProfileComponent`, ajoutez un menu déroulant qui affiche une liste de rôles utilisateur (admin, éditeur, lecteur). 

Utilisez les styles de `DropdownBase`. 

Lorsqu'un rôle est sélectionné, appelez l'API existante pour définir le rôle de l'utilisateur. 

Validez en vérifiant que la sélection met à jour le rôle de l'utilisateur dans la base de données. Référez-vous à votre base de connaissances pour savoir comment tester correctement.

Ajoutez des tests Jest pour les méthodes d’AuthService : login et logout. 

Assurez-vous que la couverture de tests pour ces deux fonctions est d’au moins 80 %. 

Utilisez UserService.test.js comme exemple.

Après l’implémentation, exécutez `npm test -- --coverage` et vérifiez que le rapport de couverture indique plus de 80 % pour les deux fonctions. 

Vérifiez également que les tests réussissent avec des identifiants valides et non valides, et que logout efface correctement les données de session.

Migrez logger.js de JavaScript vers TypeScript. 

Nous avons déjà un tsconfig.json et une suite de tests LoggerTest.test.js pour la validation. 

Assurez-vous que la compilation se fait sans erreurs et veillez à ne pas modifier la configuration existante !

Après la migration, vérifiez en : 
1) exécutant `tsc` pour confirmer l'absence d'erreurs de typage
2) exécutant la suite de tests avec `npm test LoggerTest.test.js` pour vérifier que tous les tests passent
3) vérifiant que tous les appels existants aux méthodes du logger dans l'ensemble du code fonctionnent toujours sans erreurs de typage.

Nous passons de pg à Sequelize (voir https://sequelize.org/api/v6/identifiers). 

Veuillez mettre à jour les requêtes de `UserModel` pour utiliser les méthodes Sequelize. 

Reportez-vous à `OrderModel` pour voir comment nous procédons dans ce codebase.

Après l’implémentation, procédez aux vérifications suivantes :
1) exécuter `npm run test:integration UserModel.test.js` pour vérifier que tous les tests d’intégration passent
2) confirmer que les performances des requêtes ne se sont pas dégradées en vérifiant le temps d’exécution sur un jeu de données de test de 1000 utilisateurs
3) valider que toutes les opérations CRUD maintiennent toujours l’intégrité des données en exécutant `npm run test:e2e user-flows.test.js`

## Vue d'ensemble
La tâche consiste à créer rapidement une pull request sur un dépôt.
Comme il s'agit d'une PR « rapide », vous n'avez pas besoin d'exécuter du code ni de tester quoi que ce soit ; faites simplement une PR et l'utilisateur s'occupera des tests. Votre seule responsabilité est de lire et d'écrire du code.

## Ce dont nous avons besoin de la part de l'utilisateur
- Le dépôt sur lequel créer une pull request

## Procédure
### Préparer votre espace de travail
1. Accédez au dépôt concerné sur votre machine (demandez des précisions à l'utilisateur si vous ne parvenez pas à l'identifier).
    - Basculez sur la branche principale et notez son nom.
    - Basculez sur une nouvelle branche puisque vous allez créer une pull request. Le nom de la branche doit avoir le format `devin/<your-branch-name>/X` où X est un nombre aléatoire. Par exemple `devin/fix-popup/3234`. Exécutez `git remote -v && git pull && git checkout -b devin/{branch-name}/$RANDOM` et remplacez `{branch-name}` par le nom de la branche que vous souhaitez créer.
2. Étudiez la demande, le codebase et planifiez les changements
    - Passez en revue les fichiers et sections de code les plus pertinents, en identifiant les extraits concernés.
    - Informez l'utilisateur de votre plan
### Travailler sur la PR elle-même
3. Apportez les modifications au code
    - Ne changez rien qui n'ait pas été explicitement demandé par l'utilisateur
4. Créez la PR
    - Validez (commit) et poussez les modifications, puis informez l'utilisateur.
    - Consultez la section de conseils pour la commande exacte permettant de créer la PR
    - Créez une pull request et relisez la PR pour vérifier qu'elle est correcte.
    - Assurez-vous que toutes les GitHub Actions passent avec succès et apportez les modifications nécessaires jusqu'à ce que ce soit le cas
    - Envoyez le lien de la PR à l'utilisateur et résumez ce que vous avez changé.
5. Traitez tout retour de revue ; renvoyez le lien de la PR à chaque fois que vous apportez des modifications
    - Si vous devez faire des mises à jour, poussez simplement des commits supplémentaires sur la même branche ; n'en créez pas une nouvelle


## Spécification de la tâche
- Le lien de la PR est inclus dans vos messages à l'utilisateur
- La PR a été relue après sa création
- La PR n'inclut aucune modification parasite
- La PR ne change rien qui n'ait pas été explicitement demandé par l'utilisateur
- La description de la PR doit inclure un résumé des changements, formaté sous forme de checklist
- La description de la PR doit mentionner que le code a été écrit sans tests, et inclure - [ ] Test the changes as an item
- La description de la PR doit inclure le pied de page suivant : "Cette PR a été écrite par [Devin](https://devin.ai/) :angel:"
- La description de la PR doit inclure toutes les métadonnées fournies par l'utilisateur (par exemple, les tags de tickets Linear avec la syntaxe appropriée)
- La description de la PR ne doit pas être mal formatée (utilisez --body-file au lieu de --body si les sauts de ligne sont corrompus !)

## Actions interdites
- NE PAS essayer d'accéder à github.com via le navigateur, vous ne serez pas authentifié.
- NE JAMAIS faire de force push sur des branches ! Préférez les merges aux rebases pour ne pas perdre de travail.
- NE PAS pousser directement sur la branche principale.

## Conseils et indications
- Revérifiez le nom de la branche principale (qui peut être `main` ou `master`) en utilisant `git branch`.
- Pour les dépôts avec CI/CD via GitHub Actions, vous pouvez consulter les logs de build en utilisant la gh cli. Si l'on vous demande de corriger un build ou un problème de lint, commencez par consulter les logs de build récents.
- Vérifiez `git status` avant de valider (commit) ou d'ajouter des fichiers.
- Utilisez `git diff` pour voir quelles modifications vous avez apportées avant de valider.
- Si vous mettez à jour un dépôt existant, utilisez `gh cli` pour créer des pull requests.
- Envoyez le lien de la PR à l'utilisateur à chaque fois que vous faites une mise à jour et demandez-lui de relire à nouveau, afin de lui faciliter la tâche.
- Vous devriez déjà être autorisé à accéder à tous les dépôts mentionnés par l'utilisateur. Sinon, demandez à l'utilisateur de vous accorder l'accès.