The default value for the optional parameter `date` was evaluated at server
launch while it should have been at method execution.
The bug was not detected as it is always called with a date value in standard
modules.
Noticed at #11413
Avoid traceback 'list indices must be integers, not str' when country_id not in sidebar.
env.browse(id).read(['name']) return a list, so country['name'] should be country[0]['name']
This reverts commit 8b64bf7682.
This should have been fixed in 8.0, a moment of distraction made me
push it in 10.0.
This is not the branch you are looking for, carry on.
Do these steps:
1. Create a partner.
2. Grant him portal access through *Actions > Portal Access Management*.
3. Delete the created user.
4. Delete the partner.
You will get this error:
```
Odoo Warning - Validation Error
The operation cannot be completed, probably due to the following:
- deletion: you may be trying to delete a record while other records still reference it
- creation/update: a mandatory field is not correctly set
[object with reference: Portal User Config - portal.wizard.user]
```
This happens because the wizard (which is a transient model) does not let the partner to be deleted.
With this patch, we avoid that bug.
Closes#12608
In the payslip name, the month name was set
within the server locale, rather than the
user language.
Therefore, if you had your server default locale
in English but your user in French, the
month name was displayed in English anyway.
opw-692590
There was several issues with this method:
- the workflow is incorrectly called (`purchase.signal_workflow(...)` instead)
- the workflow no longer exists (`purchase.state = 'sent'` instead)
- the code is only triggered when sending an actual mail and not a notification
- the code is never executed as the change is already changed
The last point is due to the override of `send_mail` in mail.compose.message.
The state is changed before `_postprocess_sent_message` is called (if called at
all).
Similar change of state is already done for sale.order.
This commit replaces and closes#14760
As the number of holidays are float, we may get a flloating point error when
comparing and having -0.0000000001 instead of 0 for the number of remaining
leaves, making the test fail.
Closes#12809Fixes#14643
The requirement for somebody to choose a ticket product should be that it is an
event, not that it has an event type attached, mostly when `event_type_id` is
not a required field.
The event has been improved in upper version but as this field is only
informative, relaxing a bit the domain.
Closes#12475
When editing the website, adding a gallery, choosing the grid mode
and then adding images, an extra, empty, image was
added to the grid, in the first position, making it looking weird
or at least not aligned.
This was due to the `start` method of the widget, which
is trying to focus the image in the images browser when
you double click on an image (in the big image building block
for instance) and set an image without url in the case
where `o.url` was undefined, and the url of one of the records
was also undefined.
opw-692205
The 'note' field on account.fiscal.position is the "Legal mentions that have to
be printed on the invoices." As the invoice is translated in the customer
language, it makes sense to be able to translate this note too.
Closes#14735
For example l10n_ch has default included purchase tax on products. This
would impact the valuation of the product and fail the tests.
This commit removes these taxes in the purchase test (they are tested
elsewhere anyway) and also use python to change the company currency
(since the current way didn't seem to work).
opw-691996
The issue is that if you block a workorder when you exceeded the
expected time, the workcenter is not blocked.
The workcenter state is computed according to its productivity lines.
The productivy lines are marked with a loss type type that define the
reason of the time loss (availability problem like missing equipment or
quality problem like broken equipment). There are also two magic loss
type that define if the work on the workcenter is done in the expected
time (fully productive time) or is done exceeding the expected time
(reduced speed). The unblock button appears if the workcenter is
blocked.
To compute the workcenter state, we have to look through the last
productivity line of the workcenter having no end_date. Before the
patch, we look for the last productivity line and it could return one
with an end_date while there was a productivity line without one and it
was this one that would define the workcenter state.
This is solved by immediately searching for a record without end date.
We also add some comment to the code to understand a little more what's
going on.
The progress bar of a task with sub tasks must be recomputed each time
a timesheet_ids.unit_amount is changed on one of its sub tasks.
Sorting the project.task records set in a reverse sens order ensure
to compute first the child tasks first and afterwards the parent tasks.id
opw:695210
Some code prevents to modify or delete an `ir.model.field` if another field
depends on it (like one2many depending on many2one). Make a special case when
the code is executed during a module deinstallation.
OPW 694009
It has been done outside of the previous commit
to give the possibility to point the comment
to the according revision, as this is a really tricky
case.
opw-687201
On an invoice, when registering a payment in a foreign currency
for which the payment pays entirely the invoice,
and even more thanks to the change gain(write off),
but for which the foreign currency rate to the company currency is higher than 100,
(higher than the currency decimal precision of 2 digts),
e.g. Invoice in CDF, Payment in USD (1 USD = 948 CDF),
and choosing the option "Mark invoice as fully paid" for the difference handling,
the invoice could not be marked as paid, according to the result
of the currency rate rounding.
This is because the debit or credit of the writeoff was computed
from the payment difference, in the foreign currency,
to the company currency, which lead to two currency rate computation,
one in each way,
company currency to foreign currency,
then foreign currency to company currency,
and some precision was lost in the process.
Instead of computing the debit or credit of the writeoff from
the payment difference, we now compute it from the
payment amount in the company currency minus the
invoice residual amount in the company currency,
to avoid the double currency computation rate,
so the precision is not lost in the process,
and the invoice move is finally fully reconciled
e.g.:
Invoice of 247590.40 FC
Payment of 267 USD (1 USD = 948 FC)
Payment difference: (247590,40 / 948) - 267 = -5.83 (Gain of 5.83 USD)
Before the revision, the credit of the writeoff was computed as:
`((247590,40 FC / 948) - 267 USD) * 948 = 5526,84`
After the revision, the credit of the writeoff is computed:
`247590.40 - (267 * 948) = 5525.6`
Notice in the first formula that the rate computation is performed two
times, once in each way (`/948` then `*948`), while only once
in the second, and this avoid the loss of 1.24 FC in the process.
Without this precise debit/credit of the writeoff, the invoice
could not be marked as fully paid, as the move was not fully
reconciled.
opw-687201
Jeremy Kersten