Ihre erste Sitzung

Erstelle einen neuen Endpoint /users/stats, der ein JSON-Objekt mit der Nutzeranzahl und der durchschnittlichen Zeit seit der Registrierung zurückgibt. 

Verwende unsere bestehende users-Tabelle in PostgreSQL. 

Du kannst den Endpoint /orders/stats in statsController.js als Referenz dafür verwenden, wie wir Responses strukturieren. 

Stelle sicher, dass der neue Endpoint in der Test-Suite StatsController.test.js abgedeckt ist.

Füge in UserProfileComponent ein Dropdown hinzu, das eine Liste von Benutzerrollen (admin, editor, viewer) anzeigt. 

Verwende das Styling von DropdownBase. 

Wenn eine Rolle ausgewählt wird, rufe die bestehende API auf, um die Benutzerrolle zu setzen. 

Validiere, indem du prüfst, dass die Auswahl die Benutzerrolle in der DB aktualisiert. Greife auf dein Knowledge zurück, um zu sehen, wie du korrekt testest.

Schreibe Unit-Tests und füge Jest-Tests für die AuthService-Methoden login und logout hinzu. 

Stelle sicher, dass die Testabdeckung für diese beiden Funktionen mindestens 80 % erreicht. 

Verwende UserService.test.js als Beispiel.

Führe nach der Implementierung `npm test -- --coverage` aus und überprüfe, dass im Coverage-Bericht für beide Funktionen > 80 % angezeigt wird. 

Bestätige außerdem, dass die Tests sowohl mit gültigen als auch mit ungültigen Zugangsdaten erfolgreich sind und dass logout die Sitzungsdaten ordnungsgemäß löscht.

Migriere logger.js von JavaScript zu TypeScript. 

Wir haben bereits eine tsconfig.json und eine LoggerTest.test.js-Test-Suite zur Validierung. 

Stelle sicher, dass der Code ohne Fehler kompiliert und ändere auf keinen Fall die bestehende Konfiguration!

Überprüfe nach der Migration, indem du:
1) `tsc` ausführst, um sicherzustellen, dass es keine Typfehler gibt
2) die Test-Suite mit `npm test LoggerTest.test.js` ausführst, um sicherzustellen, dass alle Tests bestehen
3) prüfst, dass alle bestehenden Aufrufe der Logger-Methoden im gesamten Code weiterhin ohne Typfehler funktionieren.

Wir wechseln von pg zu Sequelize (siehe https://sequelize.org/api/v6/identifiers). 

Bitte aktualisiere die UserModel-Abfragen so, dass sie Sequelize-Methoden verwenden. 

Sieh dir das OrderModel an, um zu sehen, wie wir das in dieser Codebasis machen.

Überprüfe nach der Implementierung:
1) Führe `npm run test:integration UserModel.test.js` aus, um sicherzustellen, dass alle Integrationstests bestehen
2) Bestätige, dass sich die Abfrageleistung nicht verschlechtert hat, indem du die Ausführungszeit auf einem Testdatensatz mit 1000 Benutzern überprüfst
3) Stelle sicher, dass alle CRUD-Operationen weiterhin die Datenintegrität gewährleisten, indem du `npm run test:e2e user-flows.test.js` ausführst

## Overview
Die Aufgabe besteht darin, einen schnellen Pull Request für ein Repository zu erstellen.
Da dies ein „schneller“ PR ist, musst du keinen Code ausführen oder etwas testen; erstelle einfach einen PR, und der Nutzer übernimmt das Testing. Deine einzige Verantwortung ist das Lesen und Schreiben von Code.

## Was vom Nutzer benötigt wird
- Das Repository, für das ein Pull Request erstellt werden soll

## Vorgehen
### Richte deinen Workspace ein
1. Navigiere auf deinem Rechner zu dem entsprechenden Repository (kläre dies mit dem Nutzer, falls du es nicht herausfinden kannst).
    - Checke den main-Branch aus und notiere dir den Namen des main-Branches.
    - Checke einen neuen Branch aus, da du einen Pull Request erstellen wirst. Der Name des Branches muss das Format `devin/<your-branch-name>/X` haben, wobei X eine zufällige Zahl ist. Zum Beispiel `devin/fix-popup/3234`. Führe `git remote -v && git pull && git checkout -b devin/{branch-name}/$RANDOM` aus und ersetze `{branch-name}` mit dem Namen des Branches, den du erstellen möchtest.
2. Studiere die Anfrage, die Codebasis und plane die Änderungen
    - Überprüfe die relevantesten Dateien und Codestellen und identifiziere relevante Ausschnitte.
    - Informiere den Nutzer über deinen Plan
### Arbeite am PR selbst
3. Nimm die Codeänderungen vor
    - Ändere nichts, was nicht ausdrücklich vom Nutzer angefordert wurde
4. Erstelle den PR
    - Commite und pushe die Änderungen und informiere den Nutzer.
    - Siehe den Abschnitt „Advice“ für den genauen Befehl zum Erstellen des PR
    - Erstelle einen Pull Request und überprüfe den PR, um sicherzustellen, dass alles in Ordnung ist.
    - Stelle sicher, dass alle GitHub Actions erfolgreich durchlaufen, und nimm bei Bedarf weitere Änderungen vor, bis sie erfolgreich sind
    - Sende den PR-Link an den Nutzer und fasse zusammen, was du geändert hast.
5. Bearbeite jedes Feedback aus dem Review; sende den PR-Link erneut, jedes Mal wenn du Änderungen vornimmst
    - Wenn du Aktualisierungen vornehmen musst, pushe einfach weitere Commits auf denselben Branch; erstelle keinen neuen Branch


## Task Specification
- Der PR-Link ist in deinen Nachrichten an den Nutzer enthalten
- Der PR wurde nach seiner Erstellung überprüft
- Der PR enthält keine fremden/versehentlichen Änderungen
- Der PR ändert nichts, was nicht ausdrücklich vom Nutzer angefordert wurde
- Die PR-Beschreibung sollte eine Zusammenfassung der Änderungen enthalten, formatiert als Checkliste
- Die PR-Beschreibung sollte erwähnen, dass der Code ohne Tests geschrieben wurde, und den Punkt - [ ] Test the changes als Eintrag enthalten
- Die PR-Beschreibung sollte folgenden Footer enthalten: "This PR was written by [Devin](https://devin.ai/) :angel:"
- Die PR-Beschreibung sollte alle Metadaten enthalten, die der Nutzer bereitgestellt hat (z. B. Linear-Ticket-Tags in der entsprechenden Syntax)
- Die PR-Beschreibung sollte nicht fehlerhaft formatiert sein (verwende --body-file statt --body, falls Zeilenumbrüche zerstückelt werden!)

## Forbidden Actions
- Versuche NICHT, über den Browser auf github.com zuzugreifen, du wirst dort nicht authentifiziert sein.
- NIEMALS Force-Push auf Branches ausführen! Bevorzuge Merging statt Rebasing, damit keine Arbeit verloren geht.
- Pushe NICHT direkt auf den main-Branch.

## Advice and Pointers
- Überprüfe den Namen des main-Branches sorgfältig (dies könnte `main` oder `master` sein) mit `git branch`.
- Für Repositories mit CI/CD über GitHub Actions kannst du Build-Logs mit der `gh`-CLI überprüfen. Wenn du gebeten wirst, einen Build zu reparieren oder Lint-Fehler zu beheben, solltest du mit den aktuellen Build-Logs beginnen.
- Überprüfe `git status`, bevor du Dateien committest oder hinzufügst.
- Verwende `git diff`, um dir die von dir vorgenommenen Änderungen vor dem Committen anzusehen.
- Wenn du ein bestehendes Repository aktualisierst, verwende die `gh`-CLI, um Pull Requests zu erstellen.
- Sende den PR-Link bei jeder Aktualisierung an den Nutzer und bitte ihn um ein erneutes Review, damit es für ihn bequem ist.
- Du solltest bereits berechtigt sein, auf alle Repositories zuzugreifen, die der Nutzer dir nennt. Falls nicht, bitte den Nutzer um Zugriff.