Steps to reproduce the bug:
- Create a customer invoice I with an amount of 100$ and validate it
- Register three payments P1 at 11/10, P2 at 12/10 and P3 at 13/10
- Click on button "Print" and the report displays the payments in the right order
P3, P2, P1
- Click on button "Send by email" and click on the attachment with the report
Bug:
The report didn't display the payments in the same order, it displayed P1, P2, P3
opw:1888251
closesodoo/odoo#27895
In JS, the groupBy attribute is a list of strings
The default_group_by key that is sometimes present in the XML views
gets converted to a list at somepoint.
Before this commit, the task action couldn't be used in the app Dashboard
After this commit, it can
OPW 1894751
closesodoo/odoo#27908
Before this commit, when accessing journals through the menu item
Bank Account, one was able to enter an partner.bank account number
But, in case the partner.bank already exsited, there was no way to select it
and a cryptic unicity constraint was raised
After this commit, one can select an account already existing
OPW 1884515
closesodoo/odoo#27840
When creating a "purchase.requisition" record, the default Operation Type was
always the one defined in the company 1 even if the user was not in the company 1.
opw:1890190
closesodoo/odoo#27830
Steps to reproduce the bug:
- In CRM, create an new Sales Channel
- Go to Reporting/Sales Channels
- Click in the new channel on "Click to define a target"
Bug:
Two input fields called "Set an invoicing target" appeared in the new channel
opw:1889406
closesodoo/odoo#27781
Producing a manufacturing order on components with more than one unit
could leads to multiple move line reserved on this component. Marking the
workorder as done, in that case, will trigger an error saying "Cannot set
the done quantity from this stock move, work directly with the move
lines". Instead of setting the quantity done directly, this commit
uses the magical function _set_quantity_done() that manage the case
of more than one move lines.
OPW-1888780
closesodoo/odoo#27773
Swiping a credit card through pos_mercury no longer worked on the
payment screen.
3a74afd21e introduced some special code
in BarcodeEvents for mobile Chrome. This code relies on an invisible
input being filled in by barcode device. On the payment screen the POS
uses a keypress event handler on body to manage input. This handler
preventsDefault which stops the input from being filled in.
It's worth noting that this new approach in
3a74afd21e is not fully equivalent to
the original barcode events handler. Events are not redispatched, so
this effectively disables keyboard input on the payment screen (or
anywhere where it is used).
opw-1888466
closesodoo/odoo#27820
Producing a manufacturing order on components with more than one unit
could leads to multiple move line reserved on this component. Marking the
workorder as done, in that case, will trigger an error saying "Cannot set
the done quantity from this stock move, work directly with the move
lines". Instead of setting the quantity done directly, this commit
uses the magical function _set_quantity_done() that manage the case
of more than one move lines.
OPW-1888780
closesodoo/odoo#27773
The code ignored return of return when computing the delivered quantity
of a so line (in this part of the code, if a move has a destination
location set a customer, it'd be a return of return of a delivery).
We now update the delivered quantity is the return of return as the
`to_refund` flag enabled, meaning the user ticked the option to update
the quantity on the so line.
opw-1884683
- Activate the `group_website_multiimage` in the website settings
- Add several images on a product
- On the eCommerce, click on the second image, then the first one
The click on the first image doesn't work.
This is because `t-att-data-slide-to="0"` is removed from the attributes
(probably because evaluated as falsy).
opw-1884368
Co-authored-by: Nicolas Martinelli <nim@odoo.com>
If resetting a background color was the only edition that was done on a
page and that this page was saved, the change was not properly saved
as the page was not marked as dirty.
Closes https://github.com/odoo/odoo/pull/27625
task-1879524
65;5401;1c
Line contains the value returned by a select clause on inventory lines.
postgresql result returns None instead of False when no value is set.
Avoid having a stock_histories_by_group dict with a key to None
Having a None value is problematic as the key is used based on the read_group
result returned by the super call above.
e.g. grouping the inventory history by lot numbers, while some moves have no
inventory, used to produce a KeyError
Closes#27591
On Safari, when editing the template of a mail.mass_mailing,
clicking the "Read more" button (or any button that can
have a link to the website) didn't open pop up to set
the URL of the website.
PS: inspired from https://github.com/textAngular/textAngular/issues/762
opw:1889643
Before this commit, when clicking on a link in a kanban
record having `href` that is set, it was opening the record
and accessing the `href`.
The intended behaviour is to not open a record if any children
component of the record contains either a click event or is
a link with `href`. The former was correctly handled, but not
the latter.
This commit fixes the issue by preventing opening the record
when clicking on a inner link with href from a kanban record.
Closes#24664closesodoo/odoo#27529
Have a user in English, put a sale report as "favorite" (pinned to dashboard app)
Change the user's language
Before this commit, the pinned view was in English (because it was recorded that way)
After this commit, the pinned view is in the user's language.
OPW 1890664
closesodoo/odoo#27574
The reference widget is expecting a models list as selection attribute
in the field declaration.
It does not exist in the case of the char field.
Support for char fields was added to allow for external identifiers,
but it only works in readonly.
As a consequence, it tracebacks in Edit mode when used in studio.
We thusly remove char field from the list of supported fields.
opw 1892602
closesodoo/odoo#27708
1. Create a SO with a product that creates a task on a new project
2. Create a timesheet on the task, with time = 0:00
3. Open the project overview from the projects dashboard or from the SO
A crash occurs because of a division by zero.
opw-1893397
closesodoo/odoo#27712
Commit:
https://github.com/odoo/odoo/commit/818c18e55d0718286ff5bf332186a10f4d7a58ef
Updated the resequence logic in a way that was almost falser than before.
The added test however did work by coincidence, as index values were equal to
the sequence field values.
To be sure that we synchronize with what happens on the server, we do a read
after the resequence.
Additionnally, we take into account the result of the server resequence return;
if it is false, it means no resequencing happened, so we should not do a read.
opw 1867049
closesodoo/odoo#27184
Since those two modules do not have a bridge, there was no support for changing the freeshipping line
when changing the delivery carrier
Now it has, at the price of ugly code
OPW 1871526
closesodoo/odoo#26935
Multicurrency is ON
Your company in USD
Make a bank journal in EUR
Create a statement and push reconcile
In the widget, create a line with a tax and hit reconcile
Before this commit, the amount_currency field of the tax move line was not filled
After this commit it is
OPW 1885014
closesodoo/odoo#27592
Let's consider an aged partner balance with a period of 30 days as of
2019-02-08. The specific dates used in the report are:
``` python
bisou = datetime.strptime('2019-02-08', "%Y-%m-%d").date()
for x in [0, 1, 30, 31, 60, 61, 90, 91, 120, 121]:
print(x, bisou + relativedelta(days=-x))
0 2019-02-08
1 2019-02-07
30 2019-01-09
31 2019-01-08
60 2018-12-10
61 2018-12-09
90 2018-11-10
91 2018-11-09
120 2018-10-11
121 2018-10-10
```
However, the current periods generated are incorrect:
```
{'name': '0-30', 'stop': '2019-02-08', 'start': '2019-01-09'}
{'name': '30-60', 'stop': '2019-01-08', 'start': '2018-12-09'}
{'name': '60-90', 'stop': '2018-12-08', 'start': '2018-11-08'}
{'name': '90-120', 'stop': '2018-11-07', 'start': '2018-10-08'}
{'name': '+120', 'stop': '2018-10-07', 'start': False}
```
There is a clear inconsistency between the name of the period and the
date used. Moreover, the name is misleading: 0-30 includes the -0 date,
while 30-60 doesn't include the -30 date.
After the fix, the name and the periods are consistent. We also change
the first period to 1-30 since including 0 would mean to include amounts
which are not due yet.
```
{'name': '1-30', 'stop': '2019-02-07', 'start': '2019-01-09'}
{'name': '31-60', 'stop': '2019-01-08', 'start': '2018-12-10'}
{'name': '61-90', 'stop': '2018-12-09', 'start': '2018-11-10'}
{'name': '91-120', 'stop': '2018-11-09', 'start': '2018-10-11'}
{'name': '+120', 'stop': '2018-10-10', 'start': False}
```
opw-1886633
closesodoo/odoo#27294
The stock refactoring between version 10.0 and 11.0 changes lots of views
in the inventory app. The picking form view lost in the refactoring the
'note' field.
This commit put it back in the view under the 'Additionnal info'. It was
not been removed from the pdf reports
closesodoo/odoo#27658
In Firefox, the input behavior and visual representation (navigation, caret
placement, value selection, etc.) was broken when using a datepicker (easily
reproductible on date and datetime widgets).
This was due to the `focus` event being stopped on the input, which doesn't
seem to be correctly supported by Firefox.
The deleted code was supposed to toggle the picker when the field was clicked
(see odoo/odoo@89093a1) (toggle on click and disable focus) but the lib
correctly supports on focus without extra code.
This also fixes the fact that the datepicker was not open on focus (only on
clicked). In some tests where the field was the first in the form view, it is
now correctly autofocused.
Forward-port: not useful from 12.0 because the code has changed with BS4 and
this has already been applied in odoo/odoo@6692919 and odoo/odoo@c63630d.
Closes#23438closesodoo/odoo#27657
When there are many values, the axis would be unreadable.
We also added a margin so that the values would be displayed entirely,
as opposed to cropped in the middle of a word.
opw 1890109
closesodoo/odoo#27656
Steps to reproduce the bug:
- Create Product P: with BOM type - Kit and BOM components > Set - Invoicing: on delivered quantity
- Create PO with P and confirm - shipment 1 will be generated
- Cancel the PO - shipment 1 - will also get canceled
- Reset the canceled PO to quotation and confirm it - new shipment 2 will be generated
- Validate the shipment and receive product KIT
Bug:
Check PO - 'Received Qty' was not updated
Inspired from: https://github.com/odoo/odoo/commit/c2dfdc3081764a492a94024f1fb57e15636b04c9
opw:1889303
closesodoo/odoo#27622
If a user creates a paperformat, he should be able to modify it too.
Employees have no reason to modify the paperformat though (nor create).
Having a malicious employee modifying an existing report may be dangerous.
[CLA] signature for stijnh92
Fixes#26292closesodoo/odoo#27444
Suppose user A creates a sale order S in company X. He then changes to company Y
Sales manager B, in company X, creates the invoice for sale order S.
Bug: the compilation of the report fails because of the user.name in the
template. Then the tracking update fails, making it impossible to validate the
invoice.
opw 1884915
Luis González