ccsa-ufrn / sigeva Goto Github PK

Front-End

• User Dashboard (M)
  • Menu do User Dashboard (M)
    • Adicionar links de acesso para os dashboards dos Eventos.
  • Eventos diponíveis (M)
    • Utiliza o mesmo componente da tela inicial (EventBoard) ✅
• Layout do Dashboard (M) ✅
  • Menu superior com dropdown para Conta/Dashboard/Sair (M) ✅ 487d50b
• Página do Evento
  • Informações do evento (T)
  • Inscrição (M)
• EventBoard (T)
  • Se estiver no período de inscrição aparecerá uma label "Inscrições Abertas" (T)
  • Se o usuário logado estiver inscrito aparecerá o link para "Dashboard do Evento" (T)

Back-end

• Criar rota para inscrição em evento: POST "/event/:id/enroll" body: {roleId} Autorização simples (só necessário estar logado) (M) ✅
• Modificações nos modelos (M)
  • Criar o modelo "Relationship" (M) ✅ 7d0fbee
  • Criar o modelo "Role" (M) ✅ c55c5f8
  • Alterar "Event" para receber "ofRelationships" e "ofRoles" (M) ✅ 7d0fbee
  • Na criação do evento são gerados não editáveis: "Coordenador do evento" Privado. (M) ✅
  • Alterar "User" para receber "ofEvents" (M)

Ao efetuar um registro é lançado um TypeError por promise

Unhandled promise rejection (rejection id: 2): TypeError: this.DAO.createObject is not a function

http://redux.js.org/docs/advanced/AsyncActions.html

No RegisterForm, caso o usuário preencha somente o password e deixe o repeat_password vazio, não vai dar erro pelo fato dos campos não combinarem. O esperado é que um erro seja lançado.

Olhar documentação do Date() em java.
Manipular as datas para sair no formato:
'2 a 4 de maio'

Modelo System
Deve conter, inicialmente apenas um campo ofRegisterFieldRequirement[] para armazenar as solicitações de campos requeridos (por referência).

Classe System

• retornar campos requeridos

Rotas System

• retornar campos requeridos pelo sistema

DAO System

• Controlar SystemObject

Tipo de issue: Implementação

Stacks: Back-end

Entidades: PaymentModule

Descrição

Os módulos devem conter a função act() que recebe uma ação e um conjunto de informações através de uma requisição POST e deve verificar se o usuário logado possui permissão adequada para realizar tal ação e por fim, realizar a ação.

Atributos: user (objeto do usuário logado), roles (papéis que o usuário possui no evento), body (corpo POST da requisição), entitySlug (slug da entidade), subaction (subação a ser executada).

Fluxo:

• Busca a entidade pelo slug
• Pega as permissões da entidade pelo ID da entidade retornada
• Pega a subaction (dentro de um switch, por exemplo), assim sabe-se qual a ação da permissão é necessária. Faz o filtro das permissões retornadas pela permissão desejada.
• Chama uma função auxiliar que verifica se a permissão daquela subaction é possuida por pelo menos um dos roles passados (ex: matchPermission(roles, permission):boolean )
• se o matchPermission retorna true, o usuário possui a permissão para executar a ação
• executa a ação
• retorna uma promisse com o resultado do tipo Response

Desenvolver rotas + funções + DAO para desativar um usuário

Somente Administrador e o próprio usuário podem desativar uma conta

A rota GE /api/event/all deve retornar todos os eventos considerando filtros, ordenação e paginação da API.
Exemplos de requisições:

• Pegar título e subtitulo de todos os eventos com até 10 por página
  • Requisição: https://sigeva.ccsa.ufrn.br/api/event/all/?f=title,subtitle&size=10
  • Retorno:

  "data": {
    "pagination": {
      "total_pages": 13,
      "links": {
        "self": "https://sigeva.ccsa.ufrn.br/api/event/all/?f=title,subtitle&size=10&page=1",
        "first": "https://sigeva.ccsa.ufrn.br/api/event/all/?f=title,subtitle&size=10&page=1",
        "prev": null,
        "next": "https://sigeva.ccsa.ufrn.br/api/event/all/?f=title,subtitle&size=10&page=2",
        "last": "https://sigeva.ccsa.ufrn.br/api/event/all/?f=title,subtitle&size=10&page=13"
      }
    },
    "events": [ ]
  }

Os tipos CPF e telefone, no formulário de cadastro, deve ter os campos CPF e Telefone (caso existam nos register fields) com uma máscara para facilitar a inserção pelo o usuário

Quando o usuário estiver logado, a barra de menus superior será sensível ao usuário. Permitindo que acesse configurações da conta, volte ao Dashboard ou fazer logout do Sigeva. Parecido com a imagem a seguir:

Desenvolver rotas + funções + DAO para autenticação de usuário

Quando o usuário está logado e tenta acessar a página inicial ele é redirecionado para o dashboard. Não é possível lançar esta ação em renderização back-side por quê depende do storage do navegador. Assim, na situação em que o usuário abre a tela inicial estando logado, é mostrada a tela inicial por um curto período enquanto o front-end verifica o storage.

Isso indica que a forma com a qual o state da aplicação está sendo manipulada/armazenada não é a ideal para esta aplicação. É necessário rever os ideais de isomorfismo e reformular as interações com o state para que a renderização back-end leve em consideração o state da aplicação já existente.

O mesmo componente da página inicial que mostra os eventos disponíveis na página inicial deve ser utilizado no UserDashboard. Vale notar que o EventBoard deve ser sensível a contexto do usuário.

Correlatos: #42 #43
Este issue contribui para a finalização do #31

Após o registro com sucesso, deve renderizar mensagem de sucesso ou redirecionamento adequado. O RegisterForm possui o state register_success inicial em false, e é resolvido para true após a recepção dos dados de registro (POST no /api/user).

Problemas identificados:

• O buffer JSON da requisição não está se comportando como esperado (linha ~187)
• o else do json.error nunca é atingido (linha ~190)

• Remover sessão
• Limpar userSession

• Usar o pacote bcrypt para criptografar o campo senha do usuário, ao fazer cadastro #3

• Usando o mesmo pacote, a senha deve ser descriptografada para fazer autenticação do usuário #12

Pendencia de criação de usuário #3

Na classe User foi criado a função que retorna um Promise e que realiza a busca de um usuário por email, retornando o userObject caso encontrado, e retornando false caso contrário.

❗ Problema: Como chamar esta função asyncrona na função setData ?

Esse componente é sensível ao contexto de usuário.

• Se o usuário está logado deverá aparecer um componente que permite a inscrição no evento, a partir da escolha do Papel público
• Se o usuário não está logado deverá aparecer o componente de login (o mesmo da página inicial)
• Se o usuário já está inscrito no evento o componente deverá ser um link para o Dashboard do Evento

Os dois primeiros componentes são similares a estes:

Tipo de issue

• Implementação
• Melhoria
• Bug

Stack relacionada

• Back-end
• Front-end
• Banco de dados

Descrição

Issues relacionadas

Commits relacionados

[ex: cm1h3, ch51gh]

Relationship representa a ligação entre um evento e um usuário. É instanciado na lista "ofRelationships" de Evento quando o Usuário se inscreve no evento.

Estar melhor documentado no mapa geral de classes e em evento

Desenvolver rotas + funções + DAO para criação de um novo usuário

Front-end

• Event Board (T) #42
  • Event Card deve ser sensível ao contexto (T) #43
• Página de evento
  • Carregar o estado com informações pelo ID #48 (M) ✅
  • Detalhes do evento (T) #41

Back-end

• Finalizar rota de inscrição em evento (M) #44 ✅
• Rota que retorna os papéis do evento (M) #49 ✅
• Resolver pendências da inscrição no evento (M) #44

O componente deverá imprimir todas as informações fundamentais do evento.

• Local do evento
• Período de atividade do evento
• Período de inscrições
• Label "Inscrições abertas" caso o período de inscrições esteja em curso
• Detalhes do evento.
• Imagem do evento

O componente se localizará na esquerda da Página de Evento, como na imagem:

Quando o usuário está logado o sistema se comporta como antes da resolução do bug #32, mas desta vez não é um problema do isomorfismo, mas sim dos redirecionamentos.

Percebe-se que o estado não chega ao Dashboard a tempo de verificar se o usuário está logado, assim ele repassa para o "/" que percebe o login e passa para o Dashboard novamente. ❓

Criar middleware de autorização de usuário a partir do token.
O token é passado pelo campo Authorization do header da requisição

Terrível bug que permite, após o logout, fazer login sem preencher email e senha. Para resolver o estado do login deve ser reiniciado após sucesso do login.

Deve-se criar uma nova rota na API '/user/me' que retorna os dados formatados do usuário atualmente logado. Esta rota exige a passagem do Token e autorização.

Deve-se passar o token pela header: Authorization

Desenvolver rotas + funções + DAO para retornar informações de usuário pelo ID

Ver: https://trello.com/c/SbIXHa8K/9-lista-de-eventos

A página inicial deve, essencialmente, conter:

• Formulário de login
• Listas de eventos

Desenvolver rotas + funções + DAO para encerrar sessão de usuário

Desenvolver rotas + funções + DAO para retornar todos os usuários

** Administrador **
O administrador pode solicitar todos os usuários do sistema

** Coordenador de evento **
O coordenador de evento pode solicitar todos os usuários do evento

O menu lateral do User Dashboard, deverá possuir o título: "Meus eventos" (ou similar) e conterá links para acessar Event Dashboards dos eventos em que o usuário está inscrito.

Pré-requisitos:

• O modelo de usuário deve possuir o campo ofEvents que possui os eventos com os quais o usuário se relaciona.

Este issue contribui para a finalização do #31

O formulário de registro no sistema merece ser revisado e receber melhorias. Provavelmente seja interessante utilizar um pacote específico para formulários.

O EventCard será sensível ao contexto de usuário e de evento.

• Evento
  • Se o evento está em período de inscrição deverá aparecer um label "Inscrições abertas"
  • Se estiver passado do período de inscrição deverá aparecer um label "Inscrições encerradas"
• Usuário
  • Se o usuário estiver logado e já inscrito no evento deverá aparecer o botão "Dashboard" (ou similar)
• Em todos os casos aparecem o botão "Acessar" que leva para a Página de Evento e as seguintes informações:
  • Período do evento
  • Local
  • Descrição curta (descrição com limite de caracteres)

Um EventCard se assemelha a imagem:

O modelo "Role" representa papeis (públicos ou privados) que um usuário pode ter em relação a um evento, firmado pela ação de inscrição no evento.

A documentação Papel requer melhorias.

Tipo de issue

• Implementação
• Melhoria
• Bug

Stack relacionada

• Back-end
• Front-end
• Banco de dados

Descrição

[descrição aqui]

Issues relacionadas

[ex: #1, #2 ]

Commits relacionados

[ex: cm1h3, ch51gh]

Atualmente os testes estão gerenciando os registros no banco de dados. Seria melhor que ao inicializar o servidor no modo "DEV", inicializa o banco de dados caso seja necessário. E os testes vão ser feitos em cima desse banco de dados.

Deve-se criar uma nova página que é carregada depois que o usuário loga-se com sucesso no sistema. A partir de então, se o usuário (logado) acessar a página inicial ele será redirecionado para o seu dashboard.

O dashboard do usuário contempla todas as funcionalidades sensíveis ao usuário logado. Deve:

• Permitir alteração de informações pessoais do usuário
• Listar eventos que o usuário participa Substituido por #38
• Listar eventos disponíveis para inscrição #39
• Acessar área de evento #38

A zona de administração é uma área separada do dashboard. Como o usuário administrador é, também, um usuário comum, sua área de dashboard é também a mesma dos usuários comuns.

Rota para inscrição de um usuário em um evento. A inscrição obriga a passagem de um papel do tipo público que existe dentro do evento. A inscrição pode ser feita mediante autorização do tipo Simples (necessita apenas estar logado)

Rota:

POST /api/event/:id/enroll
body: { roleId }

A inscrição no evento, a nível de banco de dados, faz:

• Criar uma instancia de Relationship ( #45 ) na lista ofRelationships de Evento
• Criar uma referência para evento na lista ofEvents de Usuário

Esta rota é utilizada pelo container do componente desenvolvido em #40

Utilizando a rota /api/user/authorize e passando email e password pelo corpo de uma requisição POST

Adicionar campos:
Local do evento,
Flag de indicação da atividade do evento.

O componente EventBoard deverá receber do back-end os eventos considerados ativos. Esses eventos serão impressos em um componente EventCard, que é sensível ao contexto do evento e usuário.

Será similar a imagem: