La tua prima sessione

Crea un nuovo endpoint /users/stats che restituisca un oggetto JSON con il numero di utenti e l'età media al momento dell'iscrizione. 

Usa la nostra tabella users già esistente in PostgreSQL. 

Puoi fare riferimento all'endpoint /orders/stats in statsController.js per vedere come strutturiamo le risposte. 

Assicurati che il nuovo endpoint sia coperto dai test nella suite StatsController.test.js.

In UserProfileComponent, aggiungi un menu a discesa che mostri l'elenco dei ruoli utente (admin, editor, viewer). 

Usa lo stile di DropdownBase. 

Quando viene selezionato un ruolo, chiama l'API esistente per impostare il ruolo utente. 

Verifica che la selezione aggiorni il ruolo utente nel DB. Fai riferimento alla tua Knowledge per eseguire i test correttamente.

Aggiungi test Jest per i metodi di AuthService: login e logout. 

Assicurati che la copertura dei test per queste due funzioni sia almeno dell'80%. 

Usa UserService.test.js come esempio.

Dopo l'implementazione, esegui `npm test -- --coverage` e verifica che il report di copertura mostri >80% per entrambe le funzioni. 

Conferma inoltre che i test vengano superati sia con credenziali valide che non valide e che il logout svuoti correttamente i dati di sessione.

Esegui la migrazione di logger.js da JavaScript a TypeScript. 

Disponiamo già di un tsconfig.json e di una suite di test LoggerTest.test.js per la validazione. 

Assicurati che compili senza errori e non modificare la configurazione esistente!

Dopo la migrazione, verifica quanto segue: 
1) esegui `tsc` per confermare che non ci siano errori di tipo
2) esegui la suite di test con `npm test LoggerTest.test.js` per assicurarti che tutti i test vengano superati
3) verifica che tutte le chiamate esistenti ai metodi del logger in tutto il codebase continuino a funzionare senza errori di tipo.

Stiamo effettuando la migrazione da pg a Sequelize (vedi https://sequelize.org/api/v6/identifiers). 

Aggiorna le query di UserModel per usare i metodi di Sequelize. 

Fai riferimento a OrderModel per vedere come lo gestiamo in questo codebase.

Dopo l'implementazione, verifica:
1) eseguendo `npm run test:integration UserModel.test.js` per verificare che tutti i test di integrazione vengano superati
2) confermando che le prestazioni delle query non siano peggiorate, controllando il tempo di esecuzione su un dataset di test di 1000 utenti
3) verificando che tutte le operazioni CRUD mantengano ancora l'integrità dei dati, eseguendo `npm run test:e2e user-flows.test.js`

## Panoramica
Il compito è creare una pull request rapida in un repository.
Poiché questa è una PR "rapida", non avrai bisogno di eseguire alcun codice o testare nulla; limitati a creare una PR e l'utente si occuperà dei test. La tua unica responsabilità è leggere e scrivere codice.

## Cosa è necessario dall'utente
- Il repository su cui creare una pull request

## Procedura
### Prepara il tuo ambiente di lavoro
1. Vai al repository rilevante sulla tua macchina (chiarisci con l'utente se non riesci a capirlo).
    - Fai il checkout del branch principale e annota il nome del branch principale.
    - Fai il checkout di un nuovo branch dato che creerai una pull request. Il nome del branch deve avere il formato `devin/<your-branch-name>/X` dove X è un numero casuale. Ad esempio `devin/fix-popup/3234`. Esegui `git remote -v && git pull && git checkout -b devin/{branch-name}/$RANDOM` e sostituisci `{branch-name}` con il nome del branch che vuoi creare.
2. Studia la richiesta, il codebase e pianifica le modifiche
    - Esamina i file e le sezioni di codice più rilevanti, identificando gli snippet pertinenti.
    - Informa l'utente del tuo piano
### Lavora sulla PR
3. Apporta le modifiche al codice
    - Non cambiare nulla che non sia stato specificamente richiesto dall'utente
4. Crea la PR
    - Effettua il commit e il push delle modifiche e avvisa l'utente.
    - Consulta la sezione dei consigli per il comando esatto con cui creare la PR
    - Crea una pull request e rivedi la PR per assicurarti che sia tutto a posto.
    - Assicurati che tutte le GitHub Actions vadano a buon fine e apporta le modifiche necessarie finché non succede
    - Invia all'utente il link della PR e riassumi ciò che hai cambiato.
5. Gestisci qualsiasi feedback dalla review; invia di nuovo il link della PR ogni volta che apporti modifiche
    - Se hai bisogno di fare aggiornamenti, esegui semplicemente il push di altri commit sullo stesso branch; non crearne uno nuovo


## Specifiche del task
- Il link della PR è incluso nei tuoi messaggi all'utente
- La PR è stata rivista dopo la creazione
- La PR non include modifiche spurie
- La PR non cambia nulla che non sia stato specificamente richiesto dall'utente
- La descrizione della PR deve includere un riepilogo delle modifiche, formattato come checklist
- La descrizione della PR deve menzionare che il codice è stato scritto senza essere testato e includere - [ ] Test the changes come elemento
- La descrizione della PR deve includere il seguente footer: "Questa PR è stata scritta da [Devin](https://devin.ai/) :angel:"
- La descrizione della PR deve includere tutti i metadati forniti dall'utente (ad es. tag dei ticket Linear nella sintassi appropriata)
- La descrizione della PR non deve essere malformattata (usa --body-file invece di --body se le nuove righe risultano illeggibili!)

## Azioni vietate
- NON provare ad accedere a github.com tramite il browser, non sarai autenticato.
- NON fare mai force push sui branch! Preferisci il merge al rebase così da non perdere alcun lavoro.
- NON eseguire push direttamente sul branch principale.

## Consigli e suggerimenti
- Controlla due volte il nome del branch principale (che potrebbe essere `main` o `master`) usando `git branch`.
- Per i repository con CI/CD su GitHub Actions, puoi controllare i log di build usando la gh cli. Se ti viene chiesto di sistemare una build o di correggere errori di linting, dovresti iniziare guardando i log delle build recenti.
- Controlla `git status` prima di effettuare commit o aggiungere file.
- Usa `git diff` per vedere quali modifiche hai fatto prima di effettuare il commit.
- Se stai aggiornando un repository esistente, usa `gh cli` per creare pull request.
- Invia all'utente il link della PR ogni volta che effettui un aggiornamento e chiedi di rivederla di nuovo, in modo che sia comodo per loro.
- Dovresti essere già autorizzato ad accedere a qualsiasi repository che l'utente ti segnala. In caso contrario, chiedi all'utente l'accesso.