The tree view of the stock locations displayes the field
`complete_name`, which is not translated. This is disturbing since
everywhere else, the `display_name` (translated) is used.
opw-693723
- When opening a mass mailing
- Editing it and making a change (e.g. add a block)
- Click on the breadcrumb
- Click "OK" on the warning popup telling your changes will be discarded
- Choose another mass mailing
A crash occured. This is basically the same case than in the revision
7bf80d22dd
but for Firefox, for which `window` is still there
`!window` returns False
but is `closed`
opw-702211
The company currency is EUR, and GBP rates are:
- 0.8414 at day 1
- 0.8389 at day 2
Then:
- Create a SO in GBP at day 1 and confirm
- Create an expense in GBP at day 2 and choose the analytic account of
the SO
- Validate the expense and post the journal entries
Problem:
- The amount of the expense is 93 GBP
- The amount of the sale order line is 93.28 GBP
opw-696375
When syncrhonizing an allday event while being in a negative timezone
e.g. Dec 22 in US/Eastner (-5:00)
The event was synchronized the day before
e.g. Dec 21
because `context_timestamp` of `start date-time-` was used,
and then the time was removed to have the date of the all day event
e.g. 2016-12-22 00:00:00 converted to 2016-12-21 19:00:00 and then the time
removed 2016-12-21.
Instead of using the `start_datetime`, we now use the start
date which stores only the date, without timezone information
(and this is what you would like in the case of an all day event).
opw-697202
While choosing a start/stop datetime in a timezone hour
were the UTC value is within the next day,
e.g.
Start time Dec 22 20:00 in US/Eastner (UTC -5:00)
Therefore, start time Dec 23 01:00 in UTC
Checking the "all day" box made the start time set to
Dec 23 instead of what the user expected, Dec 22.
This is because the onchange simply took the UTC datetime
(Dec 23 01:00) from which it removed the time (Dec 23).
This revision make sure to remove the time from the
user timezoned datetime instead, so the day set
remain the same day than what was set in the datetime.
opw-702065
The revision
8f48baeda6
broke the ability to search pages in the dialog
allowing to add a menu to the website from the website
(From the website, Content > Edit menu)
as `request.website` was not defined in this case
opw-702020
Currently when someone is added as follow to a document default subtypes
are computed if no specific subtypes are given to the subscription. However
if internal subtypes are set as default those are added to all new
followers. It should take into account customers and shared users and avoid
adding them internal subtypes.
Customers and shared users are not notified of messages using an internal
subtype. So currently there is no information leak. However with this fix
we ensure internal subtypes are not followed by external people even if
no notification is created.
From #14704, backport of 03ac47b9
Event with interval > 1 was not correctly computed.
This patch doesn't fix existing event but only the new one created after this fix.
Event 1/1/2015 repeat every 3 months, 6 times
Before this commit : end recurrency = 1/1/2015 + 6 * 1 month
After this commit: end recurrency = 1/1/2015 + 6 * 1 month * 3 (interval)
This commit closes#14332
Fix datetime where the return of rrule is sometime a list,
sometime a set according to the datetime version.
list(set) == list(list) and works in both cases.
Similar fix: #9f09c62
DO NOT FORWARDPORT!!!
An issue occurs when a PO line is updated following a reordering rule or
a MTO rule.
As an example, a product is configured as follow:
- UoM: Units
- Purchase UoM: Box of 25 Units
To reproduce:
- Sell one unit of product, then run the scheduler
=> it creates a procurement for one unit, but since the product is
purchased by box of 25, it creates a PO with a box of 25.
- Sell one unit of product, then run the scheduler
=> it creates a procurement for one unit, find the existing PO line,
round in the purchase UoM (so it gives one box of 25), then add it to
the PO line.
The solution is to recomputed the necessary quantity at the very end of
the process. For a given PO line, list all procurements and adjust the
quantity.
This is a partial fix, since it doesn't take into account the potential
new price of the seller. However, that would require a major rewrite of
this part of the code, since it was originally written for v8 which
handles the PO line quantity recomputation sequentially instead of
batch.
opw-688916
The amount (=credit - debit) of the first line must be equal to the total included
to reconcile balanced entries.
Before the fix, it just worked with included taxes because the amount of
the first line was already equal to the total included.
But with excluded taxes, it didn't work because in this case the amount was equal
to the total excluded. Then it raised: "Cannot create unbalanced journal entry"
due to the second line which includes all the taxes.
opw:697129
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
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
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
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
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
Nicolas Martinelli