Hugo Peixoto
76df4d41b7
Previously, saucy generated each member's future notification every day
(marked as scheduled). And every day saucy would deliver every unsent
notification scheduled for that day.
This means that each member with expiration date in the future had ~6
notifications scheduled for them in the database.
This was troublesome because if the cron job that delivers notification
was down or the server was down for more than 24h, notifications were
silently skipped and we had no easy way of detecting it: we had to check
every member for missing sent notifications.
It also had the disadvantage that we were deleting and recreating
hundreds of database entries for no good reason.
To fix this, the new system no longer stores future scheduled
notifications. Instead, it now only stores sent notifications and
notifications currently being delivered. Every day, the deliver task
checks every member if there's a notification that needs to be sent in
that day, by checking if we're past the date of sending a particular
notification type and checking if in that window of time no
notifications of that type have been sent.
Let's suppose we send 6 notifications, one per month starting 60 days
before the membership expires until 90 days after:
-60d -30d t=0 30d 60d 90d
----|------|------|------|------|------|------
A B C D E F
If we're on day t=-60d, we need to deliver a notification of type A. But
first we check if no notifications of type A have been sent to that
member on that day.
From days t=-59d to t=-31d, we check if in the time range t=[-60d, -31d]
any notification of type A was sent to that member. If not, we need to
deliver it.
If we're on days t=[-30d, -1d], we do the same but for notification of
type B.
|
||
|---|---|---|
| app | ||
| bin | ||
| config | ||
| db | ||
| lib | ||
| log | ||
| public | ||
| storage | ||
| test | ||
| tmp | ||
| vendor | ||
| .dockerignore | ||
| .gitattributes | ||
| .gitignore | ||
| .ruby-version | ||
| Dockerfile | ||
| Gemfile | ||
| Gemfile.lock | ||
| LICENSE | ||
| README.md | ||
| Rakefile | ||
| config.ru | ||
| entrypoint.sh | ||
| env.example | ||
README.md
saucy
Uma plataforma de gestão de sócies para associações. Desenvolvido e usado pela ANSOL - Associação Nacional para o Software Livre.
Licença
saucy - Copyright (C) 2022 ANSOL
This program is free software: you can redistribute it and/or modify it under the terms of the GNU Affero General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Affero General Public License for more details.
See the LICENSE file for full details.
Funcionalidades
A plataforma tem o mínimo necessário para os requisitos da ANSOL:
- Gestão da equipa da direçcão
- Actualizar membros da direccao (desactivar, criar novos, etc)
- Registar sócio (informação base, assumindo que falta o pagamento)
- Endereço de email
- Nome ("display name"/"preferred name")
- Número de BI/CC/Passaporte
- Morada completa, incluindo código postal/localidade
- estudante/reformade/desempregade/empregade
- Adicionar à mailing list?
- Preferência de contacto: postal ou electrónico (comunicações das AGs)
- Integração com ifthenpay para pagamento de quotas anuais
- Lista de sócios, com filtros e ordenação
- em cada sócio:
- editar informacao base (incluindo end date)
- poder registar nova contribuição, estendendo o end-date 1 ano
- excluir sócio (eliminação de dados pessoais, mantendo historico de contribuições)
- corrigir dados de/apagar contribuição
- mandar lembretes de renovação de quotas, cada um com o seu texto
- gestão de estado de inscrição automático:
- pendente (pré-aprovação/pagamento)
- activa (quotas em dia)
- expirada (quotas expiradas)
- excluída (90 dias após expiração / manualmente excluído)
Contribuir
Obrigado pelo interesse em contribuir para o projecto saucy.
Como reportar ou corrigir problemas
Se tiveres conta no git.ansol.org, basta criar um Issue ou Pull Request em
https://git.ansol.org/ansol/saucy. Caso não tenhas conta, envia um email para
direccao@ansol.org ou fala connosco na sala de matrix comunitária da
ANSOL
Traduções
As traduções existentes encontram-se em config/locales/{pt,en}.yml. Caso haja
alguma mensagem que não seja traduzível, fala connosco para corrigirmos o
problema (ver ponto anterior).
Introduzir funcionalidades novas
Novas funcionalidades muito distantes dos casos de uso da ANSOL podem ser recusadas, por isso recomendamos que fales connosco antes de começar uma funcionalidade grande.
Funcionalidades que gostaríamos de implementar mas ainda não tivemos tempo:
- Parameterização do
saucyde modo a não haver referências à ANSOL no código; - "Multitenancy", onde uma única instalação do
saucypermite servir várias instituições; - Melhorias genéricas ao estilo da plataforma.
Requisitos técnicos
Para o projecto funcionar a 100%, precisa de algumas dependências externas:
- Uma base de dados postgresql, onde são armazenados todos os dados;
- Configuração de SMTP, para enviar lembretes de pagamentos de quotas e mensagens de recuperação de senha para a administração;
- Configuração ifthenpay, para suportar pagamentos multibanco/mbway.
Todas estas coisas são configuráveis via variáveis de ambiente. A lista de
variáveis está disponível no ficheiro env.example.
NOTA: o projecto ainda não está pronto para ser personalizado à imagem de
outras associações, estando o contexto da ANSOL codificado em vários pontos da
aplicação. Alguns destes detalhes podem ser definidos em app/lib/config.rb.
Pôr isto a dar
Para simplificar a instalação, disponibilizamos uma imagem docker:
docker pull git.ansol.org/ansol/saucy:latest
A imagem está configurada para lançar o servidor web no porto 3000. É recomendado configurar um reverse-proxy, como o nginx ou o apache, à frente deste serviço que trate de fazer o TLS.
Quando se acede à plataforma pela primeira vez, é-nos pedido um endereço de email para criar a primeira conta de administração. Este endereço precisa de conseguir receber mensagens para o processo de recuperação de senha funcionar.
Depois deste processo terminado, é possível gerir até 6 contas de administração. Atenção que qualquer uma delas consegue apagar as restantes (e até a si própria).