This code helps keeping the consistency between std_counter and makeup total count.
It solves very specific discrepancy occuring when following conditions are met :
A. the total makeup count (makeups_to_do + makeups_to_come) is more than 2 and std_counter = -2
A. the total makeup count (makeups_to_do + makeups_to_come) is more than |suspension_limit| and std_counter = suspension_limit
B. some action increments std_counter
In that case, the std_counter becomes -1 whereas we would like it to be -2.
In that case, the std_counter becomes -1 whereas we would like it to be suspension_limit.
The idea behind the restriction to the [std_counter = -2] situation is that discrepancy
is always due to the fact that we are adding more makeups to a member where std_counter = -2.
is always due to the fact that we are adding more makeups to a member where std_counter = suspension_limit.
TODO : take into account historically corrupted data where there is discrepancy with std_counter = -1
Below typical scenario where A and B are met (there are probably more than those two !) :
...
...
@@ -31,15 +31,16 @@ class ShiftCounterEvent(models.Model):
to be use on ftop shift members.
TODO : WARNING odoo openerp.models: shift.registration.read() with unknown field 'final_standard_point' : is it caused by this piece of code ?
TODO : understand difference in relative position of update_partner_target_status and actual value write in "CREATE" and "WRITE" methods below
TODO : nderstand difference in relative position of update_partner_target_status and actual value write in "CREATE" and "WRITE" methods below
TODO : _update_partner_target_status looks similar to run_process_target_status... is it necessary to call run_process_target_status in update_members_makeups_core ?