Message queue

Only for production environment

Messaging (e-mails, mostly) in Chamilo 2 is a bit different from Chamilo 1, because of using Symfony.

The general logic is that we use the Messenger transport component, which is highly configurable.

By default, we use a simple synchronous messaging mechanism, which works similarly to Chamilo 1: we send e-mails through the MailHelper class (Send() method) directly. So if you send 10k e-mails through a slow SMTP connection, it will take a considerable amount of time.

However, and this is where we enjoy Symfony's large palette of options, you can use new messenger transports by defining MESSENGER_TRANSPORT_DSN in .env, loading the required dependency, and updating messenger.yaml by enabling (uncommenting) the when@prod section towards the end.

Once enabled (and the cache has been cleared), any message sent through Chamilo will pass through the configured messenger.

Setting up Doctrine Transport

Doctrine transport is a DB table-based message queue.

To enable:

• Edit config/messenger.yaml file
• Uncomment the 2-parts when@prod block at the end
• Edit .env file and set MESSENGER_TRANSPORT_DSN=doctrine://default
• Setup the transport php bin/console messenger:setup-transport mail_async
• Clear cache php bin/console cache:clear

Then you can check the count of queued messages php bin/console messenger:stats mail_async.

Or execute the queue to send the mails php bin/console messenger:consume mail_async

Mail types and volumes

Chamilo sends e-mail notifications for many events, to a varied public. This list is an attempt to maintain a list of all e-mail sending events with an idea of the expected volumetry and frequency.

It is important to note that users in Chamilo can have various states which may affect the e-mail sending process. For example:

• Disabled users will not be sent any e-mails
• Anonymized users will not be sent any e-mails
• Users pre-deleted will not be sent any e-mails
• Depending on their role and their affectation to certain courses or sessions, e-mails might be sent or not to each user

In the "Volume" column, we try to express a relative volume in terms of active users:

• "ALL" means all active users (on a portal with 1000 active users, 1000 e-mails would be sent). This includes notifications from global announcements, which can be filtered by role or class, but we only take into account the widest range here.
• "AFF" means only the affected users of this particular context (they are part of a course, of a session, etc).
• "SEL" means only the manually selected users (which could be selected as part of a class)
• "ONE" means a notification meant for only one user (like registration, password change, etc)
• "TWO" means a notification is usually sent to 2 or more users (but not many) because they have specific roles involved. For example, a privacy request could be sent to all the admins and as a copy to the initiating user.

No e-mail is sent across URLs, so in the case of a multi-URL setup, "ALL" means all users active in the URL in use when sending the e-mail notification.

Finally, the "Frequency" column tries to reflect an expected frequency for the sending of those notifications:

• MANUAL: means someone has to click on a button for those notifications to be sent (even if indirectly)
• DAILY: means the notifications are sent daily
• CUSTOM: means the notification can be configured to be sent at a specific time. This is usually equivalent to a MANUAL operation, meaning it is only sent once, although there can be several notifications configured around the same context, like before and after the beginning of a course, or before and after the end of a course. This depends largely on usage by your staff.

Category	Event	Volume	Frequency
Class	Group invitation	ONE	MANUAL
Class	Group message addition	AFF	MANUAL
Class	Group message edition	AFF	MANUAL
Class	Message sent to group	AFF	MANUAL
Course	Course Expiration emails/reminders	AFF	MANUAL
Course	New course creation	TWO	MANUAL
Course	Student started test notification	TWO	MANUAL
Course	Open question submission notification	TWO	MANUAL
Course	Oral question submission notification	TWO	MANUAL
Course	Test corrected/evaluated notification	ONE	MANUAL
Course	Certainty-type question corrected/evaluated notification	ONE	MANUAL
Course	Forum post abuse report	TWO	MANUAL
Course	Forum: new answer to post/thread/forum	AFF	MANUAL
Course	Course announcement	AFF	MANUAL
Course	Course announcement self-test	ONE	MANUAL
Course	Subscription of user(s) to a course	AFF	MANUAL
Course	Test results notification	ONE	MANUAL
Course	New terms & conditions for course access	AFF	MANUAL
Course	Message to all users in course	AFF	MANUAL
Course	New post in portfolio tool	AFF	MANUAL
Course	Portfolio notification of answer (to author and teachers)	TWO	MANUAL
Course	Learning path completed by student sent to teacher	TWO	MANUAL
Course	Assignments: new feedback available	ONE	MANUAL
Course	Assignments: new doc in assignment	AFF	MANUAL
Course	Assignments: New assignment created	AFF	MANUAL
Course	Test: Attempt notification to teacher	TWO	MANUAL
Course	Survey: Invitation to participate	SEL	MANUAL
Course	Assignment: Send notification to users not sending	SEL	MANUAL
Course	Assignment: Send notification of new assignment to HRM	SEL	MANUAL
Cron	Course spent time fix	TWO	CUSTOM
Cron	LP spent time fix	TWO	CUSTOM
Global	Global announcement	ALL	MANUAL
Global	Installer e-mail testing page	ONE	MANUAL
Global	Contact form submission (public!)	TWO	MANUAL
Global	Notification to all admins	TWO	MANUAL
Global	New promoted message	AFF	MANUAL
Plugin	BuyCourses: Notification of bank transfer	TWO	MANUAL
Plugin	CourseLegal: agreement approval link	AFF	MANUAL
Plugin	PauseTraining: Inactivity reminder	ONE	MANUAL
Scripts	Notify all inactive users of de-activation	AFF	CUSTOM
Session	Scheduled announcements in session	AFF	CUSTOM
Session	Subscription of my account to course in session	ONE	MANUAL
Session	Notify superior of subscription to session	TWO	MANUAL
Session	Subscription of my account to session	ONE	MANUAL
Skills	Skills obtained allow for mother skill	TWO	MANUAL
Tickets	New ticket created	TWO	MANUAL
Tickets	Ticket updated	TWO	MANUAL
User	Registration of user	TWO	MANUAL
User	Edition of user (self-notification)	ONE	MANUAL
User	Password reminder	ONE	MANUAL
User	Password expiry	ONE	CUSTOM
User	2FA activation	ONE	MANUAL
User	Suspicious access notification (N/A)	ONE	MANUAL
User	GDPR/Privacy data request	TWO	MANUAL/CUSTOM
User	Legal conditions acceptance request	ONE	MANUAL
User	Account approved	ONE	MANUAL
User	Account requires approval	TWO	MANUAL
User	Assignation of subordinate (for student bosses)	ONE	MANUAL
User	User diagnosis completed	TWO	MANUAL
User	User accepted legal agreement	TWO	MANUAL
User	Social network: Message sent from user to user	TWO	MANUAL

Note: Some settings or extra fields can affect the sending to individual users. For example, an extra field called "disable_emails" an disable all messages sent to one particular user, even if the user itself is not disabled. The PauseTraining plugin can put one user in "pause" and will thus use the "disable_emails" extra field to prevent e-mails from being sent to this use during the pause.

Method to collect: Most e-mail notifications are sent through the MessageManager::send_message_simple() method, the api.lib.php::api_mail_html() function (which uses MailHelper::send()) or the Notification::saveNotification() method. Track these for an accurate list of e-mail notifications.

Although work is in progress to implement this, there is currently no dripping effect in the sending of e-mails: all e-mails for a particular event are sent at once. Some exceptions to this are implemented, like for the course announcements, which process each e-mail individually to try to reduce the impact of sending them all at once. This can affect performance of the platform to the benefit of more reliable e-mail sending.