Title,Description,Issue ID,URL,State,Author,Author Username,Assignee,Assignee Username,Confidential,Locked,Due Date,Created At (UTC),Updated At (UTC),Closed At (UTC),Milestone,Weight,Labels,Time Estimate,Time Spent
Criar um schema para o usuário,"# Onde
Na pasta `src/db/schema.ts`.
# O que deve ter?
O schema deve bater com esse (em SQL)
```SQL
CREATE TABLE users (
id SERIAL PRIMARY KEY UNIQUE NOT NULL,
name VARCHAR(255) NOT NULL,
password VARCHAR(255) NOT NULL,
email VARCHAR(255) UNIQUE NOT NULL,
birthday TIMESTAMP NOT NULL,
cpf VARCHAR(11) UNIQUE NOT NULL,
money NUMERIC NOT NULL DEFAULT 0,
cyberpsychosis NUMERIC NOT NULL DEFAULT 0,
cyberLimit NUMERIC NOT NULL DEFAULT 100,
created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);
```",1,https://gitlab.c3sl.ufpr.br/c3sl/treinamento-2025.1-backend/-/issues/1,Open,Richard Fernando Heise Ferreira,rfhferreira,"","",No,No,,2025-03-12 00:34:24,2025-03-12 00:34:24,,,,,0,0
Criar um schema para implantes,"# Onde
Na pasta `src/db/schema.ts`.
# O que deve ter?
O schema deve bater com esse (em SQL)
```SQL
CREATE TABLE implants (
id SERIAL PRIMARY KEY UNIQUE NOT NULL,
name VARCHAR(255) NOT NULL,
created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
price NUMERIC NOT NULL,
cyberCost NUMERIC NOT NULL DEFAULT 5,
bodyPart VARCHAR(255) NOT NULL,
updated_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
);
```",2,https://gitlab.c3sl.ufpr.br/c3sl/treinamento-2025.1-backend/-/issues/2,Open,Richard Fernando Heise Ferreira,rfhferreira,"","",No,No,,2025-03-12 00:36:22,2025-03-12 00:36:22,,,,,0,0
Criar uma rota de inserção de usuário,"# Onde
A rota é definida no `index.ts`. Mas deve ser criada na pasta `handlers.ts`, em um arquivo `userHandlers.ts`.
# O que deve ser feito?
Deve ser possível inserir um usuário na base de dados através da interface do Express pelo backend. Primeiro, validamos a requisição do usuário através do Zod; depois criamos uma hash para a senha do usuário (senhas jamais devem ser guardadas diretamente no banco) e, por fim, inserimos o usuário no banco. Qualquer erro deve ser tratado apropriadamente com uma resposta adequada para quem fez a requisição (incluindo código HTTP apropriado).",3,https://gitlab.c3sl.ufpr.br/c3sl/treinamento-2025.1-backend/-/issues/3,Open,Richard Fernando Heise Ferreira,rfhferreira,"","",No,No,,2025-03-12 00:43:05,2025-03-12 00:43:05,,,,,0,0
Criar uma rota de deleção de um usuário,"# Onde
A rota é definida no `index.ts`. Mas deve ser criada na pasta `handlers.ts`, em um arquivo `userHandlers.ts`.
# O que deve ser feito?
Deve ser possível remover um usuário da base de dados.
Primeiro, validamos a requisição do usuário através do Zod.
Em seguida, verificamos se o usuário existe antes de tentar excluí-lo.
Caso o usuário não seja encontrado, retornamos um erro (`404 Not Found`).
Se encontrado, removemos o usuário da base e retornamos uma resposta adequada (`200`).",4,https://gitlab.c3sl.ufpr.br/c3sl/treinamento-2025.1-backend/-/issues/4,Open,Richard Fernando Heise Ferreira,rfhferreira,"","",No,No,,2025-03-12 00:44:33,2025-03-12 00:44:33,,,,,0,0
Criar rota de atualização de um usuário,"# Onde
A rota é definida no `index.ts`. Mas deve ser criada na pasta `handlers.ts`, em um arquivo `userHandlers.ts`.
# O que deve ser feito?
Deve ser possível atualizar os dados de um usuário existente na base de dados.
Primeiro, validamos a requisição do usuário através do Zod para garantir que os dados enviados são válidos.
Caso o usuário tente atualizar a senha, criamos uma nova hash antes de armazená-la.
Depois, atualizamos apenas os campos enviados na requisição.
Caso o usuário não seja encontrado, retornamos um erro adequado (`404 Not Found`).
Se houver sucesso, retornamos uma resposta apropriada (`200 OK`).",5,https://gitlab.c3sl.ufpr.br/c3sl/treinamento-2025.1-backend/-/issues/5,Open,Richard Fernando Heise Ferreira,rfhferreira,"","",No,No,,2025-03-12 00:45:40,2025-03-12 00:45:40,,,,,0,0
Criar rota de leitura de um usuário,"# Onde
A rota é definida no `index.ts`. Mas deve ser criada na pasta `handlers.ts`, em um arquivo `userHandlers.ts`.
# O que deve ser feito?
Deve ser possível obter os dados de um usuário específico através da interface do Express pelo backend.
Primeiro, validamos a requisição do usuário através do Zod, garantindo que os parâmetros recebidos são válidos.
Em seguida, buscamos o usuário no banco de dados.
Caso o usuário não seja encontrado, uma resposta apropriada deve ser retornada com um código HTTP adequado (`404 Not Found`).
Se encontrado, retornamos os dados do usuário (exceto a senha) em uma resposta JSON.",6,https://gitlab.c3sl.ufpr.br/c3sl/treinamento-2025.1-backend/-/issues/6,Open,Richard Fernando Heise Ferreira,rfhferreira,"","",No,No,,2025-03-12 00:46:34,2025-03-12 00:46:34,,,,,0,0
Criar um CRUD de implantes,"# Onde
A rota é definida no `index.ts`. Mas deve ser criada na pasta `handlers.ts`, em um arquivo `implantHandler.ts`.
# O que deve ser feito?
## Leitura de um implante
Deve ser possível obter os dados de um implante específico através da interface do Express pelo backend.
Primeiro, validamos a requisição utilizando o Zod, garantindo que os parâmetros recebidos são válidos.
Em seguida, buscamos o implante no banco de dados.
Caso o implante não seja encontrado, uma resposta apropriada deve ser retornada com um código HTTP adequado (`404 Not Found`).
Se encontrado, retornamos os dados do implante em uma resposta JSON.
## Atualização de um implante
Deve ser possível atualizar os dados de um implante existente na base de dados.
Primeiro, validamos a requisição utilizando o Zod para garantir que os dados enviados são válidos.
Depois, atualizamos apenas os campos informados na requisição.
Caso o implante não seja encontrado, retornamos um erro adequado (`404 Not Found`).
Se houver sucesso, retornamos uma resposta apropriada (`200 OK`).
## Deleção de um implante
Deve ser possível remover um implante da base de dados.
Primeiro, validamos a requisição utilizando o Zod.
Em seguida, verificamos se o implante existe antes de tentar excluí-lo.
Caso o implante não seja encontrado, retornamos um erro (`404 Not Found`).
Se encontrado, removemos o implante da base e retornamos uma resposta adequada (`200 OK`).
Qualquer erro deve ser tratado apropriadamente com uma resposta adequada para quem fez a requisição, incluindo código HTTP apropriado.",7,https://gitlab.c3sl.ufpr.br/c3sl/treinamento-2025.1-backend/-/issues/7,Open,Richard Fernando Heise Ferreira,rfhferreira,"","",No,No,,2025-03-12 00:48:02,2025-03-12 00:48:02,,,,,0,0
Atualizar banco de dados com tabela de compras e partes do corpo,"# Parte 1
## Onde
No arquivo `src/db/schema.ts`.
## O que deve ser feito?
Precisamos fazer uma alteração na tabela de implantes para indicar que as partes do corpo são, na verdade, um Enum no banco: dessa forma não há como se referir a uma parte do corpo inválida. Para isso, adicionem um enum no `schema.ts` de forma que o SQL bata com este:
```SQL
CREATE TYPE bodyParts AS ENUM (
'FrontalCortex',
'OperatingSystem',
'Arms',
'Skeleton',
'NervousSystem',
'IntegumentarySystem',
'Face',
'Hands',
'CirculatorySystem',
'Legs'
);
```
# Parte 2
## Onde
No arquivo `src/db/schema.ts`.
## O que deve ser feito?
Agora que temos usuários e implantes, essas são nossas *entidades*, para que um usuário possa realizar uma compra, precisamos de uma tabela de chaves estrangeiras que realize esse tipo de representação, para tanto vamos criar uma tabela de compras chamada `purchases`.
Ela deve bater com esse SQL:
```SQL
CREATE TABLE purchases (
id SERIAL PRIMARY KEY UNIQUE NOT NULL,
-- Chaves estrangeiras
user_id INTEGER NOT NULL REFERENCES users(id) ON DELETE CASCADE,
implant_id INTEGER NOT NULL REFERENCES implants(id) ON DELETE CASCADE,
created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
);
```",8,https://gitlab.c3sl.ufpr.br/c3sl/treinamento-2025.1-backend/-/issues/8,Open,Richard Fernando Heise Ferreira,rfhferreira,"","",No,No,,2025-03-12 00:53:45,2025-03-12 00:53:45,,,,,0,0
"Criar função de validação de usuário, usando Zod","# Onde
No arquivo `src/validators/userValidator.ts`.
# O que deve ser feito?
É necessário validar nossos dados de entrada, pois não podemos aceitar qualquer coisa na nossa plataforma. Para isso, a biblioteca Zod fornece-nos uma interface simples e eficaz para validar nossos dados. Crie um validador para esses dados de modo que ele retorne erros apropriados para violações de restrições.",9,https://gitlab.c3sl.ufpr.br/c3sl/treinamento-2025.1-backend/-/issues/9,Open,Richard Fernando Heise Ferreira,rfhferreira,"","",No,No,,2025-03-12 00:56:09,2025-03-12 00:56:09,,,,,0,0
Criar um validador para implantes com Zod,"# Onde
No arquivo `src/validators/implantsValidator.ts`.
# O que deve ser feito?
É necessário validar nossos dados de entrada, pois não podemos aceitar qualquer coisa na nossa plataforma. Para isso, a biblioteca Zod fornece-nos uma interface simples e eficaz para validar nossos dados. Crie um validador para esses dados de modo que ele retorne erros apropriados para violações de restrições.",10,https://gitlab.c3sl.ufpr.br/c3sl/treinamento-2025.1-backend/-/issues/10,Open,Richard Fernando Heise Ferreira,rfhferreira,"","",No,No,,2025-03-12 00:56:38,2025-03-12 00:56:38,,,,,0,0
Criar uma rota de login de usuário,"# Onde
No arquivo `src/handlers/userHandler.ts`.
# O que deve ser feito?
O login de um usuário consiste em validar sua senha e seu email/nome. Uma vez validado, um token (JSON web token, JWT) deve ser criado e enviado para quem fez a requisição. Esse token é que, efetivamente, garante que o usuário está ""logado"" no site. Para garantir seu login deve ser feito um middleware de autenticação, que será outra issue.",11,https://gitlab.c3sl.ufpr.br/c3sl/treinamento-2025.1-backend/-/issues/11,Open,Richard Fernando Heise Ferreira,rfhferreira,"","",No,No,,2025-03-12 13:29:49,2025-03-12 13:29:49,,,,,0,0
Criar middleware de autenticação,"# Onde
No arquivo `src/middleware/auth.ts`.
# O que deve ser feito?
Middlewares são funções especiais que rodam antes de alguma função em uma determinada rota. Ou seja, digamos que meu usuário quer acessar seu perfil e editá-lo, outro usuário não pode editar meu perfil para edição, correto? Essa validação é feita através do token de login, que deve ser passado como uma espécie de ""cartão de checagem"" para algumas rotas que não são públicas (como edição de perfil). Dessa forma, o middleware de autenticação serve justamente para garantir que nem toda rota seja pública. Ele deve realizar uma checagem do token e retornar um erro caso o usuário não tenha autorização para acessar aquela rota.",12,https://gitlab.c3sl.ufpr.br/c3sl/treinamento-2025.1-backend/-/issues/12,Open,Richard Fernando Heise Ferreira,rfhferreira,"","",No,No,,2025-03-12 13:38:01,2025-03-12 13:38:01,,,,,0,0
