jug-vale / jug-call4papers Goto Github PK

Fazer controle de entrada, para melhorar o sorteio e também a emissão de certificados =D

Criar a view da aplicação com a seguinte lógica (passível de mudanças)

A página inicial deverá conter:

• Um menu com acesso:
  • A página inicial
  • Aos eventos já fechados e seus respectivos papers
  • A página de login para usuários
    Se o usuário estiver logado como autor, adicionalmente devermos ter no menu acesso:
  • Aos papers criados por esse autor
  • ao perfil para edição
  • ao formulário para submeter novos papers
    Se for admistrador
  • A uma página de administração que permita operações CRUD com todas as entidades do sistema.

A página inicial deverá conter listada todos os eventos aceitando papers, com link para a página de submissão ou para ver os papers para aquele evento. E caso não haja eventos em aberto, exibir uma mensagem e um link para ver os eventos já fechados.

Caso seja ele o dono do Paper e esteja logado

na interface rest

Configurar o Travis no projeto para rodar CI.

Criar função de enviar e-mail para os papers aceito

Adicionar versionamento em todos os Endpoints, para controles futuros. Algo como

... /rest/v1/eventos

Criar builder para todos os modelos

A relação deles é tensa.

Para apagar um evento fazemos o seguinte:

• Apagamos seus papers;
• Apagamos o evento.

Os autores ficam lá. É importante modificar a view para termos algum mecanismo na submissão de paper para reusar autor em outros eventos. Talvez verificação por e-mail...

Melhorar a formatação de data dos campos usando o ContextResolver

Assim fica fácil criar as páginas WEB.

Isso é mencionado aqui:

https://docs.jboss.org/resteasy/docs/2.3.6.Final/userguide/html/AJAX_Client.html#d4e1923

Segurança usando JAAS

Usa o plugin do JBoss AS para facilitar o deploy de aplicações...

Gerar relatórios automaticamente para todos os participantes presentes no evento, enviando por e-mail!

Melhorar o README.md com instruções mais claras de como fazer o build.

Gostaria muito de contribuir, mas não tenho a minima ideia de como subir o ambiente.. seria legal um tutorial bem for dummies mesmo, incluindo dicas de plugins e IDE.

Desculpem, foi minha ideia e eu implementei. Mas essa budega não vai pra frente:

• Tokens devem ser gerados por ambiente;
• Problema de cache de DNS atrapalha o funcionamento em produção;

O captcha deverá ser completamente removido e uma verificação de cookie/IPdeverá ser feita, assim evitamos um possível flood de usuário.

Também deverá ser atualizado o README para tirar as instruções do Recaptcha.

Usar o Lombook para tirar um pouco os getters e setters dos modelos

Alguns métodos JAX-RS (rest) não devem ser acessados diretamente. Todos os métodos de deleção, atualização e criação da API REST deverão ser acessível somente a usuários com role de administrador. O método de listagem de autores também deverá ser acessível somente por administradores.

Os métodos:

• Listar eventos
• Listar papers

Serão públicos.

Criar uma entidade para o Participante que inicialmente deverá conter:

• Os campos do Issue #45
• A Data de criação;
• O Evento que ele está se inscrevendo;
• Comparecimento (boolean para marcar se ele foi ou não; pode ser ignorado por enquanto)

Restrições:

• Campo RG e e-mail deverão ser únicos para um dado evento;

O mesmo deverá ter um recurso REST para operações CRUD.

Adicionar um campo para adicionar outro autor para a submissão caso o usuário queira.

Add função para palestrante subir sua apresentação (.ppt/.pdf) para disponibilizarmos e centralizarmos tudo.

@jesuino disse:

//TODO: Abrir issue para carregar isso de um arquivo. Os dados deverão ser diferentes em teste.

Adicionar:

• Categoria
• Tipo (palestra, mini-curso, etc)

É um saco.

O script do captcha depende de domínio e eu criei um para a nossa versão no OpenShift. Mas isso custou ter que modificar dois arquivos HTML.

Isso é chato. Veja onde é modificado:

Temos que criar uma forma melhor de fazer isso...

Em aplicações JEE 6, o web.xml não é mais necessário.

Remover ele e ajustar o maven para não "reclamar" na hora de fazer o build da aplicação

Criar o arquivo participante.html em src/main/webapp com os campos:

Nome Completo*
Email*
RG*
Empresa que trabalha
Instituição de Ensino
Nível em Java*

Onde * são campos obrigatórios ;
O Nível em Java deverá ser um ComboBox com:

• Iniciante
• Básico
• Intermediário
• Avançado

Futuramente também deverá incluir o captcha;

A submissão dele será para um WS REST.

Listar Evento com os Papers Cadastrados

Após a inscrição ser confirmada, enviar e-mail para o inscrito com os dados do evento e a confirmação de efetivação da inscrição.

Isso deveria ser blocking se formos para PROD como está.

Colocar Google para ver acessos

Página para Autor editar suas informações.
Autor deve estar Logado e Validado.

Adicionar CORS Filter para conseguirem consumir os serviços

Criar testes que consomem a interface REST usando a API client do RESTEasy e faz as operações com as principais entidades.

O testes devem cobrir, também, acesso aos recursos REST, ou seja, a segurança dos WS REST deverão ser terminados antes de criar esse teste.

Verificar se na busca de todos os elementos há a chance de termos um NPE

https://github.com/jesuino/jug-call4papers/blob/master/src/main/java/org/jugvale/call4papers/service/ServiceAbstrato.java

@jesuino o que acha?

Só rever isso... Quando temos mais de um evento fica um em cima do outro e fica dificil de ver... :(

https://docs.jboss.org/resteasy/docs/2.3.7.Final/userguide/html/Validation.html

@jesuino Poderia fazer isto?

Atualizar projeto para JavaEE 7 e CDI 1.1. Porque VRaptor só suporta eles:

O VRaptor 4 depende diretamente do CDI versão 1.1, portanto só funcionará nos servidores que suportem essa versão do CDI. Também é necessário possuir JDK 1.7 ou superior.

Temos classes REST que repetem os códigos: AutorEndpoint, EventoEndpoint e PaperEndpoint. Seria interessante tentar minizar esse código.

Refatorar endpoint com interface para testes com Arquiliam

Usar o JAX-RS activator e tirar o web.xml da aplicação.

Assim podemos saber quem criou o que.

Atualmente as funções admnistrativas são todas sem view! Usamos REST para fazer PUT e DELETE e modificar o que é necessário.

Criar páginas sob o contexto admin para realizar funções administrativas.

Essas páginas deverão ser protegidas por autenticação e as funções devem ser:

• acesso às inscrições feitas em determinado evento
• edição dos dados de determinado evento
• edição de paper e seus autores.

Para evitarmos um problema sério de segurança, devemos adicionar os usuários ADMIN em um properties e o mesmo ser ocultado usando .gitignore.

Assim, teremos o usuário admin carregado com dados de login e senha desse property, mas o mesmo só seria local e em prod também.

Se o mesmo não for carregado, os dados iniciais vão falhar, então em prod deverá ter esse properties, mesmo não estando no git.

Dois Roles são necessários no sistema:

• Administrador: faz tudo, habilitado a realizar operações de CRUD de todas as entidades;
• Autor: Criar Papers e altera seu próprio perfil;

Uma entidade nova chamada Usuario para definir credenciais será criada.

Um autor deverá ter um campo para definir o usuário do sistema que é ligado a ele, mas um usuário do sistema não necessariamente poderá ter um perfil de autor.

Infelizmente...

id: 7,
titulo: "Java para javeiros",
descricao: "Java para quem ama Java. Java para javeiros",
dataSubmissao: 1410306007650,
nota: 0,

Irá retornar backup de todos os dados do evento via rest e possibilitará subir o backup também.

Somente disponível para administradores.