These are the event types built into Saltcorn. Plugins may supply additional event types.
- Insert: a new row has been inserted into a table. Add triggers to this event to enable additional logic upon creation of some new resource. In particular, this can be used on the “users” table to perform actions when a new user signs up
- Update: an existing row has been changed on a table
- Delete: a row has been deleted from a table
- Weekly: an event that occurs once a week.
- Daily: an event that occurs every day
- Hourly: an event that covers every hour
- Often: an event that occurs every five minutes
- API call: used to create triggers that can be reached by API calls.
- Never: an event that never occurs. Triggers created with this event type can however be associated with buttons in the user interface
- Login: an event that occurs when a user logs in
- LoginFailed: a user has tried to login with a wrong password or username
- Error: an error has occurred
- Startup: the server process has started. Use this to monitor the frequency of restarts.
Creating custom event types
You can also create custom event types using the custom tab in the events settings. This is useful because you can emit these events using the Emit Events block, or using emitEvent in run_js_code actions, and create new triggers based on these custom event types. When you create a new custom event, you must decide whether it has channels or not.
Time based events and system restart
The timer-based events (weekly, daily, hourly, often) have a slightly different treatment of their start times in relation to system restarts. The next scheduled occurrence of the weekly, daily and hourly events are stored in the database. This means that if the system restarts, the timing of the next occurrence will not be affected as long as the restart is short. You can therefore be reasonably assured that these events really do occur with the frequency they state. If however this system has not been running for some time, such that when the system starts next occurrence of a periodically scheduled event (weekly-hourly) is in fact in the past, the system will choose a new time for the next scheduled event which is a random time point between the current time and the maximum time period, e.g. 7 days for weekly, 24 hours for daily etc.
The often event type, which occurs every five minutes, is treated slightly differently. The next scheduled occurrence is not stored in the database. Rather this event type will occur on system start up and then every five minutes after that. If your system experiences several restarts in quick succession, this event can be fired more frequently than every five minutes.