Feedback on v26: Request for Synchronous SMTP Notifications and Calendar Event Management

[MarcoGreg86]

In Group-Office v26+, the shift to an asynchronous JMAP-based queue for notifications causes significant issues on restricted shared hosting (e.g., Aruba.it). The process often hits resource limits during JMAP sync, leaving stale lock files in tmp/locks and preventing email delivery.

I suggest adding a toggle to bypass the queue and allow immediate SMTP delivery upon saving an event, similar to legacy versions. This would ensure reliability for small installations where Cron/JMAP overhead is problematic.

Bug/Issue: Event Deletion
I have also noticed a regression in calendar management. In previous versions, Administrators could delete individual events. Now, it appears impossible to remove a single occurrence or event without deleting the entire calendar. This is a major workflow hindrance for administrative tasks.

Environment

Version: Group-Office 26.x

Hosting: Shared Advanced Hosting (Linux) + MySql

PHP: 8.4+

Thank you for your support.

[MarcoGreg86]

I investigated the database directly to understand why single events cannot be deleted. I found that the operation fails silently due to a missing cascade deletion. When attempting to manually delete an event from the calendar_event table via phpMyAdmin, I receive this exact error:

#1451 - Cannot delete or update a parent row: a foreign key constraint fails ('database_name'.'calendar_calendar_event', CONSTRAINT 'fk_calendar_calendar_event_calendar_event1' FOREIGN KEY ('eventId') REFERENCES 'calendar_event' ('eventId'))

It appears the system is trying to delete the parent record without first clearing the linked child records in calendar_calendar_event, or the ON DELETE CASCADE rule is missing in the database schema.

[mschering]

Hi Marco,

I don't understand your issue with SMTP / JMAP. Emails are directly sent after saving an event and there's no queue. Could you share errors you're experiencing?

The same goes for the calendar events as deleting single events works fine in my tests.

Best regards,
Merijn

[MarcoGreg86]

Hi, find attached screenshots. You can see that the event cannot be deleted even if I'm logged in as an Admin.

In addition, see also the lock files generated after saving an event.

Thanks a lot for your help, the notification system is quite relevant for us.

eenshots.

[MarcoGreg86]

Hi Merijn, I've been dealing with my hosting provider. They increased the limits in the .ini file (I don't think they are too bad, see below), and for a small number of attendees, the system works perfectly (invitations are sent, and the event can be managed or deleted). However, when dealing with a larger group (e.g., 30-40 attendees), the system crashes. It leaves .lock files in the temporary folder, no emails are sent, and the event becomes a "zombie" that can no longer be deleted from the interface.

I am afraid that in strict shared hosting environments, sending all emails at once is simply too much. The server instantly kills the background process when the HTTP connection closes, aborting the script mid-way.

I would like to propose three possible solutions:

1. Database Mail Queue: Instead of direct sending, put the iMIP emails in a DB table and let cron.php process them in small batches (e.g., 4-5 per run).

2. Synchronous Sending with Progress Bar: an option to keep the browser connection alive while sending emails synchronously, perhaps with a progress bar and a slight delay (5 seconds?) between each email to prevent SMTP rate-limiting.

3. Native PHP Mail (very last option): ensure there is a clear fallback or documentation for the calendar module to use native PHP mail (sendmail) instead of pure SMTPS, letting the local server handle the queue natively.

Making Group Office compatible with shared hosting environments through these minimal workarounds would greatly increase its widespread adoption.

Thanks for your precious work.