Organizar os itens registrados aqui (Issues do repositório Github)

[vitorsouza]

Organizar os itens daqui do controle de issues do Sigme no github.

Questões a serem verificadas e transformadas em issue:

• Antigo problema nos CRUDs: http://forum.primefaces.org/viewtopic.php?f=3&t=14128&p=43494#p43490 -- ver se ainda é o caso;
• Re-testar CRUDs, em especial filtros e informações master-slave (telefone, frequências);
• Checar se mensagens globais estão sendo mostradas direito. Usar http://localhost:8080/Sigme/secretariat/sendMailing/report.faces?uuid=blabla pra testar. Ver se <p:notificationBar /> é adequado para o Sigme;
• Autorização! Verificar se classes / páginas estão protegidas contra acesso ilegal;
• Adicionar cadastro de instituição à instalação do Sigme, registrando a federativa cadastrada como dona daquela instância do sistema. A página inicial faz referência à mesma.

Extraídos dos TODOs e FIXMEs no código:

• Conferir se todos os elementos dos resource bundles i18n estão sendo utilizados e excluir os que não estiverem;
• Conferir também nos resource bundles se ! e : são necessários (se precisa barrá-los) e se #{...} funciona mesmo ou se funcionava somente antes com o Seam;
• CrudAction calcula um bundle name default a partir do pacote da Action class, mas no final das contas o CRUD de instituições está sobrescrevendo o método. Ajustar o default para a situação atual?
• CRUD de Espíritas já tem filtro por attendance. Verificar se funciona;
• As MailingAddressees por regional e por instituição não têm seus métodos getEmailAddresses() implementados;
• Implementar integração com Email Manager para envio de Mailing;
• Na implementação do mailing falta validação de um passo para poder passar para o próximo. Porém com a integração do Email Manager e/ou a utilização do componente wizard do PrimeFaces isso teria que mudar de qualquer forma;
• Implementar controle de acesso: muda o Install System, muda o validadeDelete() de Manage Spiritists, muda o initMenuModel() do SessionController;
• Falando em validateDelete(), verificar se não há regras de validação de exclusão que estou esquecendo. Um espírita pode excluir a se mesmo? Uma instituição relacionada com Attendance pode ser excluída? Etc.;
• Testar todos os tipos de filtro implementados no BaseJPADAO;
• Também em BaseJPADAO, remover os @SuppressWarnings, colocando os tipos genéricos corretos nos métodos;
• Mudar o auto-login pra autorizar o primeiro usuário cadastrado e não só vitorsouza@gmail.com;
• Mudar o digest da senha de MD5 para SHA-1, que é o default do GlassFish 3.1.

Próximos passos:

Abaixo seguem algumas notas antigas. Hoje em dia a Feees utiliza um CMS integrando várias ferramentas diferentes (ex.: Google Calendar) para resolver alguns dos problemas citados abaixo. Seria melhor integrar o Sigme com estas ferramentas ao invés de reinventar a roda.

• Login redirection: testar acessar uma funcionalidade que precisa de login. O sistema deve redirecionar pra login.xhtml e, depois de feito o login, deve retornar à página que eu queria abrir inicialmente. P. 260 do Seam Reference.

Issues canceladas pois o sendMailing foi colocado como baixa prioridade (o DECOM já está usando o MailChimp):

Send Mailing: adicionar resumo e filtro ao relatório

No relatório de envio de mailing, adicionar:

• Resumo: total de mensagens, quantas mensagens enviadas, quantas a enviar, quantos erros;
• Filtro: mostrar somente mensagens já enviadas, somente a enviar, somente erros. Os termos (total, enviadas, a enviar, erros) do resumo podem ser os links que ativam os filtros.

Send Mailing: implementar envio via SMTP

Em 4 passos:

1. Adicionar configuração do SMTP durante instalação do Sigme;
2. Utilizar o dumbster para fazer envio fake;
3. Adicionar possibilidade de alterar configuração SMTP depois do Sigme instalado;
4. Testar um envio de verdade, usando o SMTP da Feees.

Send Mailing: permitir formatação e anexos na mensagem

Adicionar editor rich-text e tentar enviar mailings como os que eram enviados antigamente com o Spammer.

Send Mailing: ver mailings já enviados

Adicionar nova funcionalidade que mostra os mailings já enviados. Algumas questões:

• Os mailings são associados a um usuário? A uma instituição? Mostrar sempre todos?
• Permitir filtro por data? Por destinatário?
• Separar claramente os mailings que ainda estão sendo enviados dos que já foram.
• O usuário poderá abrir o relatório de cada mailing. Porém o relatório é session-scoped, então se abrir dois relatórios em janelas separadas teremos problemas. Podemos trocar pra conversation-scoped, mas não há um ponto claro para end-conversation. Refletir...

Implementar sendMailing (funcionalidade pedida pelo Rodrigo):

• Uma mailing list contém destinatários. Destinatários podem ser:
  1. Um espírita em particular;
  2. Todos os espíritas que frequentam uma instituição;
  3. Todos os espíritas que frequentaram uma instituição;
  4. Todos os espíritas que frequentam instituições de um CRE;
  5. Todos os espíritas que frequentaram insttuições de um CRE;
  6. No futuro, diretoria, trabalhadores, etc...
• Ver outras funcionalidades no final deste documento (opt-out, etc.).
• Para implementar o opt-out, terá que ser implementado o "Cadastrar-se" e o "Reconhecer Cadastro" (o visitante coloca o e-mail e, caso o e-mail já esteja cadastrado, ele recebe um código por e-mail para atribuir uma senha para o seu e-mail).
  • Implementar o "Cadastrar-se" com base no Matchnizer.
• Quando queremos enviar SPAMs somente para jovens, ou somente para evangelizadores... Como fazer? -- DEPOIS, com a inclusão das áreas...
• Procurar saber de problemas de uso de AJAX em acessos concorrentes. Tem que usar a eventQueue do a4j, eu acho.

Implementar cadastro de modelos de gestão e atribuição à instituição:

• Faz sentido deixar as casas cadastrarem seus próprios modelos de gestão. Por isso, os modelos deveriam ser atrelados às casas;
• Seria interessante também compartilhar modelos, caso 2 instituições utilizem o mesmo modelo. Por isso, os modelos devem ser livres;
• Qual caminho seguir?
• Obrigar a instituição à registrar sua data de fundação para poder ter um modelo atribuído, porque os modelos possuem um tempo de vigência. O primeiro modelo cadastrado vai da data de fundação até os dias atuais (sem endDate);
• Quando criar os próximos modelos, não pode ter uma diretoria já cadastrada no período do novo modelo;
• Departamentos entram em gestão?
• Um modelo de gestão pode ser criado usando um outro como base. Faz uma cópia e deixa alterar.

Implementar cadastro de gestões (diretorias - atual e passadas):

• Primeiro pede o período de gestão e faz as seguintes verificações:
  1. Não pode cadastrar se não houver modelo de gestão;
  2. Não pode começar num modelo de gestão e terminar em um outro;
  3. Não pode começar em uma data futura, mas pode terminar...
  4. Liberar o cadastro de uma diretoria que começa no próximo ano para não ficar sem administradores?

Implementar o sistema de delegação:

• Pensar nos diferentes "roles" que existem. Cada "role" pode/deve (alguns podem ser opcionais e a funcionalidade fica desabilitada?) ser atribuído a um elemento do modelo de gestão;
• Uma das instituições deve ser escolhida como "A" federativa. O mais simples seria ser a primeira a ser cadastrada (seria cadastrada durante a instalação e não pode ser excluída);
• Por esta discussão parece que modelos de gestão da federativa devem ser separados da casa espírita...

Alterar "Instalar Sistema":

• Cadastrar, de cara, a federativa, um modelo de gestão, depois o presidente da instituição e dar a opção do presidente delegar a administração pra alguém;
• O delegado do presidente e o presidente são os administradores;
• Os administradores podem, depois, cadastrar outras pessoas e colocá-las como membros da diretoria atual ou delegados de um membro da gestão;
• Para que o tipo "Federativa" seja escolhido automaticamente, é preciso que ele tenha ID = 1 ou exista alguma flag boolean dizendo qual é ele;
• Pensar no que acontece quando "vence" uma gestão da federativa e não tem outra.

Package planning:

• core
  • Instalar Sistema
  • Efetuar Login
  • Cadastrar Instituições
  • Cadastrar Pessoas
  • Cadastrar-se
  • Busca
• secretariat
  • Envio de mala-direta via e-mail
  • Geração de etiquetas para correspondência;
  • Controle financeiro com geração de boletos para cobrança (controle de sócios);
  • Controle de assinantes do informativo;
  • Agendamento e registro (ata) de atividades;
  • Documentação de padrões (manuais de atividades);
• cms
  • Gerência de conteúdo do site
  • Site das casas espíritas adesas
  • Cadastro completo das casas espíritas adesas (atividades, etc.);
• events
  • Calendário de eventos do movimento espírita;
  • Controle de eventos, com inscrição pela Internet;
• unification
  • Relatório de atividades das casas espíritas e recenseamento online;
• business
  • Livraria online (loja virtual);
• community
  • Enquetes para coleta de opiniões, fóruns para solução de dúvidas;

Plano de Desenvolvimento:

03 - Montar Listas de Distribuição de E-mails

Permitiria que você montasse diferente listas de e-mails para envio de mala direta. Ao cadastrar uma pessoa, você poderia inclui-la numa lista, exemplo: DIJ-Evangelizadores, DIJ-Jovens, DECOM-Assinantes-A-Senda, Feees-Sócios, etc.

Poderíamos ter algumas listas de distribuição montadas automaticamente. Exemplos: todos os cadastrados, todos os espíritas (cadastrados que frequentam), todos de uma cidade, etc.

Também teríamos que pensar em algum opt-out (uma pessoa que não quer receber e-mails). Provavelmente seria mais um dado relativo ao cadastro da pessoa, ou seja, quer receber e-mails da Feees: (  ) SIM   (   ) NÃO

Ou um opt-in! Se criarmos listas de distribuição "públicas", a pessoa pode optar por se inscrever em uma. Cada departamento pode ter uma.

04 - Enviar Mala Direta

Um editor HTML que permita que você crie uma mensagem a ser enviada para uma das listas de distribuição montadas no item anterior.

05 - CMS

Prover um CMS (Sistema de Gerenciamento de Conteúdo) para o site. Assim, poderemos desativar o site atual da Feees e usar o novo sistema também como site.

Com isso podemos dar a opção às instituições espíritas de, além da página com informações básicas, inserir novas páginas com conteúdo em aberto, pra divulgar eventos, grupos de estudo especiais, temas das próximas palestras, e o que mais quiserem.

06 - Integração com o Mailing

Com o novo sistema substituindo o site anterior, podemos implementar integração com o mailing:

• Ao clicar em um link enviado via e-mail, registrar quem e quando;
• Prover um link opt-out que leve a pessoa a um formulário de confirmação de que não deseja mais receber e-mails da Feees;
• Prover um relatório de cada mailing com informações estatísticas, tipo quantas pessoas clicaram, quantas pediram opt-out desta vez, etc.

07 - E tudo mais...

Tenho várias idéias pro futuro, por exemplo:

• Calendário de eventos do movimento espírita;
• Geração de etiquetas para correspondência;
• Controle financeiro com geração de boletos para cobrança (sócios);
• Controle de assinantes do informativo;
• Relatório de atividades das casas espíritas e recenseamento online;
• Enquetes para coleta de opiniões, fóruns para solução de dúvidas;
• Controle de eventos, com inscrição pela Internet;
• Livraria online (loja virtual);
• Agendamento e registro (ata) de atividades;