KSIDol documentation > KSIDol modules > Login notification

Module guide: Login notification

Non-technical user guide: what the module is for, how to use it and how it fits together with Dolibarr.

TriggerOn every successful login

Email contentIdentity, date/time, IP, instance

Sending modes3 (PHP mail, Dolibarr, SMTP)

Dolibarr core0 modifications

1. Module overview

The Login notification module (loginnotify) monitors access to your Dolibarr: every time a user logs in successfully, you automatically receive an alert email. It is a simple monitoring tool, particularly useful for keeping an eye on who is entering a demonstration or production instance, without having to consult any technical log. The module deliberately stays lightweight and unobtrusive: it never modifies the Dolibarr core and relies on the standard trigger mechanism. It adds no menu, no new section and no extra screen to your daily work: once enabled and set up by an administrator, it runs on its own in the background.

Receive an automatic email at every login of a user to your Dolibarr instance
Ideal for effortlessly monitoring access to a demo or a production environment
Runs in the background, without changing users' habits
No modification of the Dolibarr core: clean and reversible installation
Centralised setup on a single configuration page reserved for administrators

2. Automatic notification at every login

This is the module's central function. As soon as a user opens a session in Dolibarr, the module activates and prepares to send an alert email to the address you have chosen.

The alert is triggered on every successful login, whichever user is involved
The triggering is fully automatic: nothing to do for the user who logs in
A master switch lets you enable or suspend email sending at any time
If the module is disabled or sending is turned off, the login proceeds normally without any email

3. Content of the notification email

Each email received summarises the key details of the login, in plain terms, so you can immediately identify who logged in, when and from where.

The subject line states the login and the identifier of the user involved
The user's identity: their login identifier and full name
The exact date and time of the login
The IP address from which the login took place
The address (URL) of the Dolibarr instance concerned, useful if you monitor several instances

4. Choosing the recipient address

You freely decide who receives the login alerts. The address is set on the module's configuration page.

Enter one or more destination email addresses (separated by a comma; the semicolon is only fully supported in manual SMTP mode)
The configuration page pre-fills the recipient field with the company email defined in Dolibarr; at runtime, if no destination address is saved, no email is sent
Without a valid address, no email is sent (the login itself remains normal)

5. Choosing the email sending mode

Depending on your hosting and your email configuration, you choose how the emails are sent. Three modes are offered to suit most situations.

PHP mail() mode: direct sending via the server's mail function, the simplest option
Dolibarr configuration mode: reuses the email settings already configured in your Dolibarr
Manual SMTP mode: you enter your own outgoing server parameters (host, port, username, password, TLS/SSL security, authentication mode)
A custom sender address can be defined; it is used whatever the sending mode
Automatic fallback: if direct sending fails or is unavailable, the module switches to Dolibarr's email configuration to maximise the chances of delivery

6. Sending a test email

To check that everything is correctly set up before relying on the alerts, the configuration page offers a test button.

A button immediately sends a test email to the specified recipient address
A confirmation message is displayed on success, or an error message if sending fails
A warning is shown when Dolibarr is set to redirect all emails to a forced address, to avoid any confusion about the real recipient

7. Error logging

To make diagnosis easier when an email does not go out, the module can record sending incidents in the Dolibarr log.

Option that can be enabled to record sending errors in Dolibarr's technical logs
Helps the administrator or the service provider understand a messaging problem without blocking usage
Fallback alerts (switching from one sending mode to another) are also noted there

8. Configuration and adaptation of the module

All settings are grouped on a single configuration page, accessible only to administrators from the modules list. No setting is required from users.

Enable or disable the sending of login emails
Define the address(es) that receive the alerts
Choose the sending mode (PHP mail, Dolibarr configuration or manual SMTP) and, where applicable, the sender
Enter the SMTP parameters in manual mode (host, port, username, password, security, authentication)
Enable error logging
Test sending and save the configuration

9. Links with Dolibarr

The module does not work in isolation: it integrates with the native building blocks of Dolibarr.

Dolibarr users : The module relies on the native login event of Dolibarr user accounts. The email reproduces the identifier and full name of the person who has just logged in, as recorded in their user record.
Dolibarr email system : The Dolibarr sending mode reuses the messaging configuration already set up in your instance (the same sending engine as Dolibarr's other emails). This mode also serves as an automatic fallback if direct sending fails.
Company record (general settings) : In the absence of a recipient address or a custom sender, the module automatically reuses the company email address defined in Dolibarr's general settings, to stay consistent with the rest of the application.
Dolibarr technical logs : When logging is enabled, errors and sending switch-overs are written to Dolibarr's native logs (syslog), which makes it possible to diagnose a messaging problem via the ERP's standard tools.
Email sending preferences (redirection) : The module respects the Dolibarr setting that forces the redirection of all emails to a single address: it warns the administrator on the configuration page to avoid any confusion about the real recipient of the alerts.