saucy

Hugo Peixoto 76df4d41b7 Redo notification system 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.	2024-03-23 15:31:32 +00:00
app	Redo notification system	2024-03-23 15:31:32 +00:00
bin	rails new	2022-06-20 20:48:08 +01:00
config	Implement button to remind members to pay their initial dues	2024-03-22 23:34:34 +00:00
db	Adds payment page	2023-07-12 19:13:08 +01:00
lib	Redo notification system	2024-03-23 15:31:32 +00:00
log	rails new	2022-06-20 20:48:08 +01:00
public	Improve branding mechanisms	2023-09-20 14:19:35 +01:00
storage	rails new	2022-06-20 20:48:08 +01:00
test	Redo notification system	2024-03-23 15:31:32 +00:00
tmp	rails new	2022-06-20 20:48:08 +01:00
vendor	rails new	2022-06-20 20:48:08 +01:00
.dockerignore	Add .git to dockerignore	2022-09-28 21:07:58 +01:00
.gitattributes	rails new	2022-06-20 20:48:08 +01:00
.gitignore	Configure database	2022-06-20 20:53:38 +01:00
.ruby-version	rails new	2022-06-20 20:48:08 +01:00
config.ru	rails new	2022-06-20 20:48:08 +01:00
Dockerfile	Add docker stuff	2022-07-16 11:27:56 +01:00
entrypoint.sh	Precompile assets in entrypoint	2022-09-29 18:41:22 +01:00
env.example	Allow customizing whethere the cookie is secure or not	2023-11-13 09:08:12 +00:00
Gemfile	Implement letter generation	2022-07-16 11:27:43 +01:00
Gemfile.lock	bundle update	2024-03-22 23:39:06 +00:00
LICENSE	Add license file	2022-08-20 11:11:04 +01:00
Rakefile	rails new	2022-06-20 20:48:08 +01:00
README.md	Adds payment page	2023-07-12 19:13:08 +01:00

Hugo Peixoto 76df4d41b7 Redo notification system

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.

README.md

saucy

Licença

Funcionalidades

Contribuir

Como reportar ou corrigir problemas

Traduções

Introduzir funcionalidades novas

Requisitos técnicos

Pôr isto a dar