Thanks for the v10 release — much appreciated, and the migration was smooth on our side (MariaDB untouched, rebuild ran clean).
Sharing one behavioral change that caught a piece of our custom code, in case it helps anyone else with server-side extensions.
The problem is we have a custom handler that creates all-day Meeting records from inbound ICS email invites (DTSTART;VALUE=DATE). It sets dateStartDate / dateEndDate and lets Event::beforeSave derive dateStart / dateEnd. This worked fine through 9.3.x. On 10.0.0 those meetings started persisting NULL dates.
The cause is a new guard added to Espo\Core\Repositories\Event::beforeSave:
Since this lives in the repository beforeSave, it runs on every save and isn't bypassed by SKIP_HOOKS. Our handler was setting the date-only fields but never isAllDay — and a meeting loaded from the DB has isAllDay = false by default — so the guard nulled both date attributes before the derive step.
The fix on our end was one line: set isAllDay explicitly to true in the all-day path (and false when converting back to a timed meeting) before setting the date fields. Once isAllDay is truthy, the guard leaves the values alone and everything derives correctly again. Clean and reasonable behavior in hindsight.
One small suggestion: since this changes the contract for anyone who writes to dateStartDate / dateEndDate programmatically, it might be worth a line in the upgrade notes for developers — something like "all-day date fields are now cleared unless isAllDay is set." It's an easy fix once you know, but the symptom (silent NULLs, no error) makes it non-obvious to trace back to Event::beforeSave.
Thanks again for the work on v10.
P.S.: Could we put a markdown editor into the forum?
Sharing one behavioral change that caught a piece of our custom code, in case it helps anyone else with server-side extensions.
The problem is we have a custom handler that creates all-day Meeting records from inbound ICS email invites (DTSTART;VALUE=DATE). It sets dateStartDate / dateEndDate and lets Event::beforeSave derive dateStart / dateEnd. This worked fine through 9.3.x. On 10.0.0 those meetings started persisting NULL dates.
The cause is a new guard added to Espo\Core\Repositories\Event::beforeSave:
PHP Code:
if (
$entity->hasAttribute(Meeting::FIELD_IS_ALL_DAY) &&
$entity->get(Meeting::FIELD_IS_ALL_DAY) === false
) {
$entity->setMultiple([
Meeting::FIELD_DATE_START_DATE => null,
Meeting::FIELD_DATE_END_DATE => null,
]);
}
The fix on our end was one line: set isAllDay explicitly to true in the all-day path (and false when converting back to a timed meeting) before setting the date fields. Once isAllDay is truthy, the guard leaves the values alone and everything derives correctly again. Clean and reasonable behavior in hindsight.
One small suggestion: since this changes the contract for anyone who writes to dateStartDate / dateEndDate programmatically, it might be worth a line in the upgrade notes for developers — something like "all-day date fields are now cleared unless isAllDay is set." It's an easy fix once you know, but the symptom (silent NULLs, no error) makes it non-obvious to trace back to Event::beforeSave.
Thanks again for the work on v10.
P.S.: Could we put a markdown editor into the forum?
