Your First Session

Create a new endpoint /users/stats that returns a JSON object with user count and average signup age. 

Use our existing users table in PostgreSQL. 

You can reference the /orders/stats endpoint in statsController.js for how we structure responses. 

Ensure the new endpoint is covered by the StatsController.test.js suite.

In UserProfileComponent, add a dropdown that shows a list of user roles (admin, editor, viewer). 

Use the styling from DropdownBase. 

When a role is selected, call the existing API to set the user role. 

Validate by checking that the selection updates the user role in the DB. Refer to your Knowledge for how to test properly.

Add Jest tests for the AuthService methods: login and logout. 

Ensure test coverage for these two functions is at least 80%. 

Use UserService.test.js as an example.

After implementation, run `npm test -- --coverage` and verify the coverage report shows >80% for both functions. 

Also confirm that tests pass with both valid and invalid credentials, and that logout properly clears session data.

Migrate logger.js from JavaScript to TypeScript. 

We already have a tsconfig.json and a LoggerTest.test.js suite for validation. 

Make sure it compiles without errors and make sure not to change the existing config!

After migration, verify by: 
1) running `tsc` to confirm no type errors
2) running the test suite with `npm test LoggerTest.test.js` to ensure all tests pass
3) checking that all existing logger method calls throughout the codebase still work without type errors.

We're switching from pg to sequelize (read https://sequelize.org/api/v6/identifiers). 

Please update the UserModel queries to use Sequelize methods. 

Refer to OrderModel for how we do it in this codebase.

After implementation, verify by:
1) running `npm run test:integration UserModel.test.js` to check all integration tests pass
2) confirming query performance hasn't degraded by checking execution time on a test dataset of 1000 users
3) validating that all CRUD operations still maintain data integrity by running `npm run test:e2e user-flows.test.js`

## Overview
The task is to make a quick pull request to a repository.
Since this is a 'quick' PR, you will not need to run any code or test anything; simply make a PR and the user will handle the testing. Your only responsibility is reading and writing code.

## What's Needed From User
- The repository to create a pull request to

## Procedure
### Prepare your workspace
1. Navigate to the relevant repository on your machine (clarify with the user if you can't figure it out).
    - Check out the main branch and note down the name of the main branch.
    - Checkout to a new branch since you'll be making a pull request. The name of the branch has to be of the format `devin/<your-branch-name>/X` where X is a random number. For example `devin/fix-popup/3234`. Run `git remote -v && git pull && git checkout -b devin/{branch-name}/$RANDOM` and replace `{branch-name}` with the name of the branch you want to create.
2. Study the request, codebase, and plan out the changes
    - Review the most relevant files and code sections, identifying relevant snippets.
    - Inform the user of your plan
### Work on the PR itself
3. Make the code changes
    - Don't change anything that wasn't specifically requested by the user
4. Make the PR
    - Commit and push the changes and tell the user.
    - See advice section for the exact command to make the PR
    - Make a pull request & review the pr to make sure it looks OK.
    - Ensure all GitHub actions pass successfully & make necessary changes until they do
    - Send the PR link to the user and summarize what you changed.
5. Address any feedback from the review; send the PR link again every time you make any changes
    - If you need to make updates, just push more commits to the same branch; don't create a new one


## Task Specification
- PR link is included in your messages to the user
- PR was reviewed after creation
- PR does not include any stray changes
- PR does not change anything that wasn't specifically requested by the user
- PR description should include a summary of the changes, formatted as a checklist
- PR description should mention that the code was written without testing, and include - [ ] Test the changes as an item
- PR description should include the following footer: "This PR was written by [Devin](https://devin.ai/) :angel:"
- PR description should include any metadata that the user has provided (e.g. linear ticket tags in the appropriate syntax)
- PR description should not be malformatted (use --body-file instead of --body if the newlines are garbled!)

## Forbidden Actions
- Do NOT try to access github.com through the browser, you will not be authenticated.
- NEVER force push on branches! Prefer merging over rebasing so that you don't lose any work.
- Do NOT push directly to the main branch.

## Advice and Pointers
- Double check the name of the main branch (which could be `main` or `master`) using `git branch`.
- For repos with CI/CD on github actions, you can check build logs using the gh cli. if you're asked to fix a build/fix lint, you should start by looking at recent build logs
- Check `git status` before committing or adding files.
- Use `git diff` to see what changes you have made before committing.
- If you're updating an existing repo, use `gh cli` to make pull requests.
- Send the PR link to the user every time you update & ask them to re-review so that it's convenient for them
- You should already be authorized to access any repositories the user tells you about. If not, ask the user for access.