Before this commit, the alert_start_time was not erased when a status
change from 'alert' to 'ok' for an irregular worker.
People find that unintuitive (despite this date was in the past when
you are in 'ok' status).
Now, this alert_start_time was erased when the status change from
'alert' to 'ok'.
This fix the case where a worker is unsubscribed from a shift where he
is supercooperator.
In the function unsubscribed_from_today, when removing the supercoop,
the field is_regular was also set to False. I seams that this is not
correct as this field is related to the worker_id not to the supercoop.
Also, I found other issues as when removing a worker_id the fields
is_regular and is_compensation was not reset.
This let me think about other cases where worker_id is emptied, the
is_regular and is_compensation would be never been reset if the
programmer doesn't think to reset it.
So I modified the constrains on these field in order to have these field
reset properly when worker_id is changed.
This commit brings fix a bug that occur when a worker do a shift before
her future_alert_date and the shift was marked as attended after the
future_alert_date. In such a case, the worker fell in alert state and
get a -2. This don't fix the fact that the worker fall in alert. But
brings correction when the shift is finally marked as attended.
They become unsubscribe when the regular counter fall under a value that can be define in parameter
[FIX] don't show unsubscribed or resigning worker in the list of worker you can assign on a shift
The bug was that some shift are 'misstimezoned' near DST moment and for
timezone far from the UTC time. Now the date and time of a shift is
calculated in the local timezone then converted into UTC time to be
stored in database.
[FIX] Silent error when reverting counter info while status change of task when missing some access right
[IMP] Performance improvement in shift generation: Skip message generation
Rémy Taymans
nicolasjamoulle
Thibault Francois