fix(userstatus): trigger absence start job even for absences starting in the past

[miaulalala]

Fixes #47058

Summary

The absence start job was not created for absences in the past - which could also mean an absence starting today (absence timestamp is midnight, but time for $now is larger).

Since absences that start in the past and are still ongoing should be considered nonetheless, absences are now only evaluated by their end date. if that is in the past, no jobs are created.

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)

[st3iny]

I'm not sure about this change.

I deliberately chose not to emit the start event when an absence period already started in the past. An app may always listen to OutOfOfficeScheduledEvent or OutOfOfficeChangedEvent to handle those cases. So that the OutOfOfficeStartedEvent is reserved for when a scheduled absence starts without user interaction.

In a sense this could be seen as a breaking change. Although I'm not sure if there actually is a use case that would break (at least in our code).

[st3iny]

Suggested change

	$runJobAt = ($eventData->getStartDate() < $now) ? $now : $eventData->getStartDate();
	$this->jobList->scheduleAfter(
	OutOfOfficeEventDispatcherJob::class,
	$runJobAt,
	[
	'id' => $absence->getId(),
	'event' => OutOfOfficeEventDispatcherJob::EVENT_START,
	],
	);
	$this->jobList->scheduleAfter(
	OutOfOfficeEventDispatcherJob::class,
	$eventData->getStartDate(),
	[
	'id' => $absence->getId(),
	'event' => OutOfOfficeEventDispatcherJob::EVENT_START,
	],
	);

Can always use getStartDate() here as the job will be picked up if it is in the past IIRC.

[miaulalala]

I'm not sure about this change.

I deliberately chose not to emit the start event when an absence period already started in the past. An app may always listen to OutOfOfficeScheduledEvent or OutOfOfficeChangedEvent to handle those cases. So that the OutOfOfficeStartedEvent is reserved for when a scheduled absence starts without user interaction.

In a sense this could be seen as a breaking change. Although I'm not sure if there actually is a use case that would break (at least in our code).

good point, that is indeed something to be considered. Although a case could be made that an event should be thrown regardless as it is indeed starting right now, so event listeners could do their thing.

[miaulalala]

Superseded by #47201