Saltcorn 0.5.2 brings several improvements to the event system, including:

• Event log – a record of events that have occurred. You can configure which events are to be recorded. For create, update and delete events on tables, you can configure these events to be recorded for some tables but not for others.
• New event types – events for system start-up, login, failed login attempts, and errors. These events can be tracked in the event block and you can attach triggers to them, so you could for instance send a message on errors or logins.
• Emit events in action - JavaScript code actions can now emit new events. This allows you to break down a complex event handler into multiple handlers, or coordinate built-in or plugin-provided actions.
• Custom events – you can declare new event types in the admin UI. This is useful in combination with emitting events in JS code actions. Customer events can have triggers attached and can optionally be logged.
• Event plugins – plug-ins can supply new event types and can emit these events. As a proof of concept, the mqtt plugin connect to a MQTT broker and can emit events when messages occur on MQTT channels. This plug-in also supplies an action to post a message on a channel on that MQTT broker. Similar plug-ins can be implemented for other protocols, e.g. AMQP or Kafka, but I lost track of what is trendy in that space.

These new features are laying the foundation for a no-code event driven process automation capability, which will be further implemented in the next release.

Other improvements introduced in 0.5.2 are:

• API Trigger Role protection – API triggers can now be figured to require a minimal user role (implemented by Aleksandr Sokolov)
• Verification plugins – plug-ins can supply alternative methods of user account verification. The twilio-verify-sms plug-in uses the Twilio API to verify accounts with SMS.
• Edit formula destination – In Edit viewtemplates, you can now use formulae to send the user to different views on completion depending on the contents of the data submitted in the form. Unfortunately this made the last page of the Edit viewtemplate configuration a bit more complicated. Ideas for making things simpler and less confusing are welcomed.
• Metadata API – a new API for with the application meta data, that is the table, view and page configuration. For the moment this is read only but may evolve into a larger API to control the application (implemented by Aleksandr Sokolov)
• Watchdog – internal and systemd-based health monitoring.
• Airgap operations – it is now possible to operate the core system in an “air gap” environment, that is without a connection to the wide-area Internet. Previously we relied on assets served through content distribution networks, these have been moved to be served locally through npm installing the appropriate resources. Many plug-ins will not work in this way as they still rely on CDN resources, but they will gradually be migrated.