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
B. some action increments std_counter
In that case, the std_counter becomes -1 whereas we would like it to be -2.
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.
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 !) :
1. after a makeup service where a member has been present is closed [TODO :we are actually doing the right thing there now so we do it twice... we should simplify]
2. after a bdm admin increments the makeup counter
TODO : check that this process is the one we want in all other cases
Note that all of this is only valid in the on std shift members as makeups are not supposed
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 : _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 ?