fab-manager/config/schedule.yml

subscription_expire_in_7_days:
  cron: "0 0 * * *" # every day, at midnight
  class: SubscriptionExpireWorker
  queue: default
  args: [7]

subscription_is_expired:
  cron: "0 23 * * *" # every day, at 11pm
  class: SubscriptionExpireWorker
  queue: default
  args: [0]

generate_statistic:
  cron: "0 1 * * *" # every day, at 1am
  class: StatisticWorker
  queue: default

i_calendar_import:
  cron: "0 * * * *" # every day, every hour
  class: ICalendarImportWorker
  queue: default

reservation_reminder:
  cron: "1 * * * *" # every day, every hour + 1 minute
  class: ReservationReminderWorker
  queue: default

close_period_reminder_worker:
  cron: "0 12 * * 1" # every monday at 12pm
  class: ClosePeriodReminderWorker
  queue: default

free_disk_space:
  cron: "0 5 * * 0" # every sunday at 5am
  class: FreeDiskSpaceWorker
  queue: system

# this will prevent that all the instances query the hub simultaneously
<% h = DateTime.current - 1.minute %>
version_check:
  cron: <%="#{h.strftime('%M %H')} * * #{h.cwday}" %> # every week, at current day+time
  class: VersionCheckWorker
  queue: system

payment_schedule_item:
  cron: "0 * * * *" # every day, every hour
  class: PaymentScheduleItemWorker
  queue: default

accounting_data:
  cron: "0 0 * * *" # every day, at midnight
  class: AccountingWorker
  queue: default

<%= PluginRegistry.insert_code('yml.schedule') %>
release 2.0 rc 2016-03-23 18:39:41 +01:00			`subscription_expire_in_7_days:`
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database 2022-11-18 16:42:11 +01:00			`cron: "0 0 * * *" # every day, at midnight`
Removed unmaintained gem sidekiq-cron and replaced it with sidekiq-scheduler 2022-03-09 14:33:50 +01:00			`class: SubscriptionExpireWorker`
release 2.0 rc 2016-03-23 18:39:41 +01:00			`queue: default`
			`args: [7]`

			`subscription_is_expired:`
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database 2022-11-18 16:42:11 +01:00			`cron: "0 23 * * *" # every day, at 11pm`
Removed unmaintained gem sidekiq-cron and replaced it with sidekiq-scheduler 2022-03-09 14:33:50 +01:00			`class: SubscriptionExpireWorker`
release 2.0 rc 2016-03-23 18:39:41 +01:00			`queue: default`
			`args: [0]`

			`generate_statistic:`
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database 2022-11-18 16:42:11 +01:00			`cron: "0 1 * * *" # every day, at 1am`
Removed unmaintained gem sidekiq-cron and replaced it with sidekiq-scheduler 2022-03-09 14:33:50 +01:00			`class: StatisticWorker`
release 2.0 rc 2016-03-23 18:39:41 +01:00			`queue: default`
prepares schedule.yml to code insertion 2016-05-25 12:21:38 +02:00
import events asyncronously from icalendar 2019-12-02 15:53:24 +01:00			`i_calendar_import:`
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database 2022-11-18 16:42:11 +01:00			`cron: "0 * * * *" # every day, every hour`
Removed unmaintained gem sidekiq-cron and replaced it with sidekiq-scheduler 2022-03-09 14:33:50 +01:00			`class: ICalendarImportWorker`
import events asyncronously from icalendar 2019-12-02 15:53:24 +01:00			`queue: default`

[not tested] send reminder notification every hours for upcoming reservations 2016-08-17 17:39:12 +02:00			`reservation_reminder:`
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database 2022-11-18 16:42:11 +01:00			`cron: "1 * * * *" # every day, every hour + 1 minute`
Removed unmaintained gem sidekiq-cron and replaced it with sidekiq-scheduler 2022-03-09 14:33:50 +01:00			`class: ReservationReminderWorker`
[not tested] send reminder notification every hours for upcoming reservations 2016-08-17 17:39:12 +02:00			`queue: default`

notify admins when no accounting period closed for 1 year 2019-03-18 14:33:30 +01:00			`close_period_reminder_worker:`
			`cron: "0 12 * * 1" # every monday at 12pm`
Removed unmaintained gem sidekiq-cron and replaced it with sidekiq-scheduler 2022-03-09 14:33:50 +01:00			`class: ClosePeriodReminderWorker`
notify admins when no accounting period closed for 1 year 2019-03-18 14:33:30 +01:00			`queue: default`

prevent memory saturation with periodic checks 2019-02-26 15:18:19 +01:00			`free_disk_space:`
			`cron: "0 5 * * 0" # every sunday at 5am`
Removed unmaintained gem sidekiq-cron and replaced it with sidekiq-scheduler 2022-03-09 14:33:50 +01:00			`class: FreeDiskSpaceWorker`
[bug] version check is not working 2020-07-01 16:56:21 +02:00			`queue: system`

			`# this will prevent that all the instances query the hub simultaneously`
(bug) do not plan version check at invalid cron 2022-03-15 16:07:38 +01:00			`<% h = DateTime.current - 1.minute %>`
[bug] version check is not working 2020-07-01 16:56:21 +02:00			`version_check:`
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database 2022-11-18 16:42:11 +01:00			`cron: <%="#{h.strftime('%M %H')} * * #{h.cwday}" %> # every week, at current day+time`
Removed unmaintained gem sidekiq-cron and replaced it with sidekiq-scheduler 2022-03-09 14:33:50 +01:00			`class: VersionCheckWorker`
[bug] version check is not working 2020-07-01 16:56:21 +02:00			`queue: system`
prevent memory saturation with periodic checks 2019-02-26 15:18:19 +01:00
WIP: generate invoices for each payment schedule item 2021-01-20 17:00:23 +01:00			`payment_schedule_item:`
run the PaymentScheduleItemWorker more ofter and tell the users that they ahev only 24h to fix the payment 2021-02-08 10:05:54 +01:00			`cron: "0 * * * *" # every day, every hour`
Removed unmaintained gem sidekiq-cron and replaced it with sidekiq-scheduler 2022-03-09 14:33:50 +01:00			`class: PaymentScheduleItemWorker`
WIP: generate invoices for each payment schedule item 2021-01-20 17:00:23 +01:00			`queue: default`

(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database 2022-11-18 16:42:11 +01:00			`accounting_data:`
			`cron: "0 0 * * *" # every day, at midnight`
			`class: AccountingWorker`
			`queue: default`

prepares schedule.yml to code insertion 2016-05-25 12:21:38 +02:00			`<%= PluginRegistry.insert_code('yml.schedule') %>`