Before this commit, the test aged report crashed on date Year/07/16 (and probably after, too) because:
- we create a partial reconcile today (create_date = Year/07/16) when making the payment to the invoice
- the report date is set as Year/07/15, so, the partial reconciliation, if tested after that date, always appears in another period,
which is not the use case we test, hence the crash of the test
After this commit, we force the create date of the partial reconciliation to *before* the report is called,
thus, no error occurs
closes#25785
On a database where many modules are installed (e.g. runbot all), with
the option "manage available packaging options per products", doing a groupby
"product" on the "package type" list view triggers a js error.
It comes from the fact that the fixed_group variable contains a "length"
attribute; the _().each function uses this to determine (erroneously)
that the object is an array.
It thus uses fixed_group[0] to get an undefined, and then tries to access
a method of undefined.
We replace the each by a simple js loop.
opw 1863576
Since ffda023295, the error is not 'OpenERP Server Error' but 'Odoo Server
Error'.
In case we change of name once again, check based on the name
Avoid "traceback not available" error in PoS when there is a traceback.
Set the rounding method to Round Globally
Create a tax A with rate = 1.1040 %
Create a bank statement with one line having amount = 1153.960
Go on to reconcile that bank statement
Reconcile with a new line on which the tax A applies
Create the write-off
Click on Reconcile
Before this commit, an error was thrown by the server (Move unbalanced)
This was because the amount of the write-off line sent by JS (which is the tax amount)
was 12.7397
The server though computes the taxes by forcing the rounding and gives off a tax amount of 12.74
Hence the error
After this commit, the JS will fetch the amount of the taxes by forcing the rounding there also
And the reconciliation process goes well
This fix is already present in v11.0 at 6fce298d70
OPW 1859939
closes#25733
Steps to reproduce the bug:
- configuration on sale:
- Unit of measure: Some products may be sold/purchased in different units of measure (Advanced)
- Sale Price: Advaced pricing based on formulas (discounts, margins, rounding)
- Discount: Allow discounts on sale order lines
- kg as the Reference UOM for weight
- create an uom 10 kg
- Category: Weight
- Type: Bigger...
- Bigger ratio: 10.0
- create a product P
- Sale price: 100
- Unit of measure: kg
- Purchase UOM: kg
- create a pricelist "My pricelist"
- Discount policy: Show public price & discount to the customer
- Items : All products - 10% discount
- create a SO with "My pricelist"
- create a SO line with P, the unit price is automatically 90 with 10 % of discount
- change the uom of the line with 10kg
Bug:
The unit price of the line didn't change and the discount on the line disappeared.
In function product_uom_change, the uom of the SO line has been set in the context
of the product(like in function product_id_change). So in funciton _get_display_price,
the function _get_real_price_currency must be called with the uom of product in the context.
In this way, the lst_price will be fetch on product with the right uom without any bad conversion
(because uom.id == product_uom with uom from the parameters and product_uom from the context).
But with function get_product_price_rule, no need to call this function with the uom in context as
it is already set in the product(check "if uom_id: ... else ..." in this function).
The same logic has been applied in function _onchange_discount
opw:186385
Display the address of the partner_id when available rather than using the partner id of the movelines. Important when the partner is changed after the movelines are created.
support ticket : 1857582
According to the CLA signing instructions, the date of signature must be
expressed in the following form:
> `<date>`: current date in the form `YYYY-MM-DD`
However, the date was wrongly expressed as "9-2-2015". That date not
only was following an incorrect format, but also it was ambiguous,
because it was not clear if the format was following M-D-YYYY or
D-M-YYYY (the latter one being the case).
This fixes the format, so it now fits the required one.
Closes#25665
If a user A deletes the res.users record of user B while B is connected,
the verification of the session token fails with a comparison of a boolean and
bytes values.
While the check should obviously fail, this patch gracefully inform the user B
its session has expired and redirect him to the login page.
Without the patch, the session is never invalidated in the user browser,
redirecting to a forbidden error page as long as the session has not been manually
cleared from the browser.
Fixes#25530Closes#25654Closes#25682
Cherry-Pick of 96f01c08f8
When merging two or more leads, a traceback was generated when attempting
to merge some selection field, if any.
closes https://github.com/odoo/odoo/issues/25644
opw 1864870
Two use cases must work:
Should hide payment AND display errors when order contains deliverable product
Should show payment AND not display errors when order contains only services (event tickets)
Linked OPW 1864744
Linked PR v11.0 #25679closes#25692
When creating an event using the list view, no value is set in the
fields start and stop.
If selecting all day, we could only change the value of start_date and
stop_date which does not change the value in start or stop.
This makes it impossible to create an event from the list view.
This problem is not present in the calendar view since this view sets a
value in start and stop, and the start and stop are recomputed via the
inverse fields.
Closes#25680
The call to /web/session/authenticate should return an empty session_info
in case of wrong login/password.
It was producing a traceback (due to self.ensure_one() and search)
Introduced at d1cd293ece and fdb250942Fixes#24071
Company is in USD
Do an invoice in EUR with a specific rate (and post it)
Do a payment on this invoice with another rate (and post it)
revert the payment's move
Before this commit, the move_lines of the original/reverted move pair were not reconciled
to one another
This could cause problems in some reports (aged reports for example)
After this commit, the lines in the original/revert move pair are reconciled
provided that they *can* be reconciled
Which is either belonging to a reconciliable account, or to an account of type liquidity
OPW 1861273
closes#25592
This is essentially a backport of 7544c22de9
and
4f40c9da7b
Company is in USD
Do an invoice in EUR with a specific rate (and post it)
Do a payment on this invoice with another rate (and post it)
revert the payment's move
Before this commit, the move_lines of the original/reverted move pair were not reconciled
to one another
This could cause problems in some reports (aged reports for example)
After this commit, the lines in the original/revert move pair are reconciled
provided that they *can* be reconciled
Which is either belonging to a reconciliable account, or to an account of type liquidity
OPW 1861273
closes#25600
Open a new session with user A, the cashier is A.
Close the session and post the entries.
The responsible for the session is user A and the salesman on the sale order is A.
Then log in to the database with user B.
Open a new session on the same pos.
Before this commit, the cashier on the second session was A
After this commit, the cashier on the second session is B
OPW 1864207
closes#25628
This reverts commit ef444da57a.
Changing a function signature is not supposed to happen in stable;
we have already received 3 opw's about broken customizations or
modules that extend the stock because code such as:
res = self.do_next_transfer()
if not res:
<bla bla>
stops without any warning.
As `pre-` migration scripts may use the registry, we must ensure that
all fields are set up before execution in order to have a consistent
registry.
This is required when loading a registry which contains modules to
install/upgrade without `-u` flag. In this case, the setup was only done
*after* module loading.
The function _get_graph computing the dashboard graph must take the timezone of the user
into account to compute the right start_date S and the right end_date E.
The query made on model 'report.pos.order' by read_group in _graph_data must take the
timezone of the user into account to substract the right offset to compute the start_date S
and end_date E in UTC because the result returned by read_group is formated in the timezone
of the user afterwards.
Example:
In function _get_graph:
Start_date in 'Asia/Ulaanbaatar' timezone = 2018-06-05
End_date in 'Asia/Ulaanbaatar' timezone = 2018-07-04
So End_date - Start_date + 1 = 30
In function _graph_data:
Start_date in 'Asia/Ulaanbaatar' timezone = 2018-06-05 00:00:00
End_date in 'Asia/Ulaanbaatar' timezone = 2018-07-04 23:59:59
So in UTC -9 hours:
Start_date in UTC = 2018-06-04 15:00:00
End_date in UTC = 2018-07-04 14:59:59
SELECT min("report_pos_order".id) AS id,
count("report_pos_order".id) AS "date_count" ,
sum("report_pos_order"."price_total") AS "price_total" ,
date_trunc('day', timezone('Asia/Ulaanbaatar',
timezone('UTC',"report_pos_order"."date"))) as "date:day"
FROM "report_pos_order"
WHERE (((("report_pos_order"."date" >= Start_date) AND
("report_pos_order"."date" <= End_date)) AND
("report_pos_order"."config_id" in (1,2,3))) AND
("report_pos_order"."state" in ('paid','done','invoiced')))
GROUP BY date_trunc('day', timezone('Asia/Ulaanbaatar', timezone('UTC',"report_pos_order"."date")))
ORDER BY "date:day"
And the result of this request will be between 2018-06-05 00:00:00 and 2018-07-04 23:59:59 but
before the fix the result was between 2018-06-05 00:09:00 and 2018-07-05 08:59:59 and then
End_date - Start_date + 1 was equal to 31. That's why a "IndexError: list index out of range"
can be raised in _get_graph.
In this way, no mismatch is possible between the datas computed by _graph_data and the dict
"values" allocated by _get_graph.
opw:1862996
Before this commit:
* Install module A
* Edit a view from module A, add a custom field
* Uninstall module A
* Reinstall module A
* Try to access the module A's previously modified view
-> Can't access the view, or even sometimes the app at all.
Cause:
When uninstalling module A, the custom field added to module A's is
properly unlinked, however the custom/studio view is not unlinked, therefore
the view references a field that no longer exists, when accessing the
view it will obviously crash (sometimes the traceback is not even
displayed to the user!).
Solution:
Emulate an ondelete cascade for child views only when in uninstall mode.
Steps to reproduce the bug:
- Create 3 stockable products P1, P2, P3
- P1 is tracked by serial numbers
- Create a BOM for P3 with one P1 and one P2 as components
- Set the quantity on hand to 5 for P1 and P2
- Create a MO for P3, produce it and mark the MO as done
- On the MO in the sheet "Consumed product", the quantity_done for
P1 and P2 are equal to 1.0
- Change the tracking of P1 to "No tracking"
Bug:
- Check the sheet "Consumed product" on the MO and the quantity_done
was equal to 0.0 instead of 1.0
opw:1856340
This changes the order in which the data and the views are loaded.
Caused a problem in some fringe cases.
Install then uninstall project, playing around with discuss, when reinstalling project ,
system is trying to notify a partner and the weird order
in which the data and the views are loaded makes it bite the dust
opw:1861157
Backport following opw-1851612
[FIX] google_calendar: do not create an event with an invalid id
The id is useful to update existing events but sometimes we are getting some
ids that are not accepted by Google
Getting an error:
odoo.addons.google_account.models.google_service: Bad google request : {
"error": {
"errors": [
{
"domain": "global",
"reason": "invalid",
"message": "Invalid resource id value."
}
],
"code": 400,
"message": "Invalid resource id value."
}
}
Looks like existing events can have a _ in their id but new one, no longer.
It seems that these events are created by outlook calendar when synchronized
with Google Calendar.
On an optimization done for not rendering each time the template, the possibility
of sending the template in the proper language when multiple recipients was lost.
This is being refactoring in master, but for this version, Odoo won't merge a
change in the behavior, although it's the correct one as in previous versions.
Extracted by pedrobaeza from https://gist.github.com/nim-odoo/8a9749037370343f05c7e6681324f576
(cherry picked from commit 386a936)
Christophe Simonis