Problem with daily Cartridge Alarms

[FreeMacs]

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

Is there an existing issue for this?

• [X] I have searched the existing issues

Version

10.0.12

Bug description

For some weeks now, we have the problem that the emails for the cartridge alarm are sent separately. For example, the 2 alarms are sent on 31.01:

and on 01.02. there are these 2 alarms:

although all 4 are set to alarm. Why do the alarms come separately? Before, the cartridge alarms were actually sent together every day.

Relevant log output

No response

Page URL

No response

Steps To reproduce

No response

Your GLPI setup information

No response

Anything else?

No response

[FreeMacs]

Update on this problem:

I have the alarm option "Each day" in the entity.

"Each day" is also selected in the automatic action.

This is probably also the problem. The email is sent out and when trying to send the email the next day at the same time, it is blocked and only sent the following day because for GLPI the day is apparently not yet over. I have now set the automatic action to hourly execution while the action in the entity is still set to Each Day. I now receive the email daily but it is always delayed by an hour as it cannot be sent at the same time as the previous day.

[cedric-anne]

Hi,

There are 2 potential problem in the alert logic.

1. See https://github.com/glpi-project/glpi/blob/bf82c73e85574f7e304a48de61e28f5415c5776b/src/CartridgeItem.php#L430 If on day 1 the alert is sent at 10:00:00, then on day 2, it will be considered as already sent until 10:00:01. A solution could be to replace < by <=, but a better solution would probably be to adapt the query to the periodicity. For instance, if the periodicity is "day", we should probably consider that it can be sent as soon at the new day starts, i.e. at midnight.

2. The comparison that is made is between a MySQL timestamp (NOW()) and the PHP timestamp set when row is created in glpi_alerts table (i.e. $_SESSION['glpi_currenttime']).

Some refactor should probably be done on alerts management to have a better handling on both points, and to do this globally.