we detect if a user account is active or inactive by saving a date on a column on the user table called end_date, if the value of end_date is null, it means the account is active, if not, it is a deleted or inactive account.

when a user decides to delete his account, we give him 30 days to sign in again, and if he does, his account will be restored.
for that, what we need to do is:

• When the user signs in successfully, we check if the account is inactive
• if the account was inactive, we re-active it again, by setting the user column end_date to null
• if the account is active, we continue as usual.

add a library to manage and validate environment variables.

use the user adapter class to delete the inactive users from the API responses

• filter them on user routes

• Create an endpoint and validate if email is available
• If it is available, return ok, if not, return conflict

depends on #73

Elysia docs: https://elysiajs.com/plugins/cron

• Install @elysiajs/cron with bun add @elysiajs/cron
• Create a plugin for handling users deleting
• Set timer to 24hs, so we run the cron once each day
• On the cron function, look for all users that contain end date area with a date and not null
• Delete all users with end_date set to a date older than 30 days from new today
• add that plugin to the server, adding app.use(plugin) on src/app.ts

save the location of the user when he creates a journal entry and based on that, get the weather of that day and assign it to the journal entry.

add a line between the right side of the auth layout and the auth page.
remember to remove it on mobile

the cron plugin for deleting inactive users is deleting all the inactive users without validating if the user column end_date is in the past or future.

add role 'admin' and 'user'

• create table roles
• always create a role 'user' and a 'admin'
• assign roles to the user

after #50 is completed, we need to have a way to ban users from using the application if the admin decides to do so

• add an endpoint in /user to ban users
• check for the request authenticated user role
• if the role is admin, ban the target user by deactivating their account with UserProvider.delete()
• if not, reject the request

• get current user information
• update user information
• delete user

if the database connection is successful, it will continue to try to connect, instead of breaking the loop and returning.

migrate to another library.

right now, you can't run turbo setup or turbo clean-up from the root directory, you need to move into /apps/api to make it work.

• add turbo.json to apps/api/
• add setup script
• add clean up script
• make dev depend on setup

the set-up script has two errors

• the migration script never exists in the process after it finishes the migration
• the set up script never awaits for the docker database container to turn on and open the database connection
  so, we end with a script that turns on the docker container, and tries to migrate, but encounters an error because the database is not ready for connections yet, and if you run turbo run migrate, it never exits the process.

the solution can be to create a setup.ts file, where we:

• run docker compose up
• await until the database connection is ready
• generate the migration files for drizzle (running drizzle-kit generate:pg)
• run the migration
• exit the migration process after has been 5 seconds
• exit the process

when we work locally using docker volumes for the Postgresql database, we often need to delete the volumes and containers, so we can start with a clean database the next time we run "bun run dev" or "turbo dev".

• Add the "clean" script to the package.json on the API folder
• When the command is executed, clean up the docker container and volume

some options for random profile gradients are:

• https://avatars.jakerunzer.com/

• https://github.com/boringdesigners/boring-avatars

• create profile_picture_url column on db

• assign a random profile picture when user signs up