Previously special fields for the product template where only added on
the product template form view only. But these fields should be
available also on the product product form view. So I moved fields that
were easy to move from template view only to the product template view
that is used for product template and product product.
Now label info are also shown in the product.product view and not only
in product.template view.
This let you access to label info of an article when following this
path:
Select PO -> Select a line -> Click on article.
This adds a configurable limit under which the regular worker is
unsubscribed. The regular worker is unsubscribed when the sum of his
shift counter and his compensation shift counter reach the configured
limit.
When the worker has subscribed to a shift template but not yet to a
shift, the shift used to generate her next shift is the first shift
found in the shift template (so this is a shift that is attached to
another worker from the same shift template).
Now the system pays attention to not use a shift that has no start time
or end time defined.
Added a domain to filter proposed products on the reciept view.
Only products whose main seller are the reciept's partner are
proposed in the auto-complete/selection.
This improves the calculation of the future alert date in other to take
holidays and temporary exemption into account.
This also adds the date of the next countdown that also take holidays
and temporary exemption into account.
In the form to become a new cooperator, the field info_session_confirmed
was required but not in the form validation. This commit fixes that
incoherence but changing the form to let field info_session_confirmed
not required.
This adds, in the new cooperator form in the website, a checkbox that
the user can check if he already has taken part to an information
session.
This information will be saved in the partner object and will be used to
automatically check the info_session field of the cooperator_status when
it will be created by the wizard.
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.
There was an issue that shows an error message when trying to modify the
settings for shift in the website configuration.
This is due to a missing sequence in the database. I don't know why this
sequence where not present. But a simple query create it if it doesn't
exists.
This adds a field `supervisor_id` that aims to replace the `create_uid`
field. To prevent regressions, the old `create_uid` field is set to be a
computed field that has the same value as `supervisor_id`. This allow to
ensure that other part of the program that refer to `create_uid` as the
responsible for a purchase order will get the value of `supervisor_id`.
This new version comes with a migration script that fill the new
`supervisor_id` with the value of `create_uid` if `supervisor_id` is not
set yet.
This trick is done because the `create_uid` field is a magic field that
belongs to the ORM. This field cannot be modified in a form.