A name_search on attribute line would possibly ends up with a domain like:
['|', ('attribute_id', '=', 'm'), ('value_ids', '=', 'm'),
('attribute_id', '=', 'm')]
which would just search the attribute.
This is caused by calling the default name_search. This commit forgo
the default name_search when we are in this attribute line special case.
courtesy-of: @fmdl
opw-813505
closes#22619closes#22760
Name of scripts piped to `odoo shell` were `__builtin__` (`builtins` in
python3), which is not really obvious (and awful if your script must
handle python2 and python3).
Change it to `__main__`, allowing to use to common pattern
`if __name__ == '__main__':`
Before this commit, when connected as a portal user, the user was not
able to post replies to existing replies. This is because the textarea
section was marked to be displayed for connected internal users only.
This commit removes the whole group restriction. Indeed, it makes sense
(as a fix), to show the textarea section for public users too. Indeed,
the "Reply" button is already shown to public users but does not do
anything. With this commit, clicking the "Reply" button shows the
textarea section for everybody and, if the user is not connected,
redirects to the login page when posting the message. This of course
needs usability improvements in master.
Note: the problem had originally been fixed for regular answers with
commit https://github.com/odoo/odoo/commit/b81b03c82d282dc94595a9beb94444041509ef25
Note 2: both mentioned problems were originally introduced by commit
https://github.com/odoo/odoo/commit/9069d0127c176317436b67b23ae5677dd9d53de7
Closes https://github.com/odoo/odoo/issues/22648
When saving a modified mass mailing, the editor will do a number of
things to improve the mail readability accross mail client.
One of those is replacing font awesome icons by image, but firefox acts
differently than other browser. On a display:none iframe, doing
.css('color') or .height() on an element returns respectively
`undefined` and 0.
This caused an error when getting the color that we could solve by
doing a fallback for firefox like this:
window.parent.getComputedStyle($font[0]).color
But to get the height() of an element, it seems we always need the
iframe displayed.
With this change, when the iframe is hidden and the browser is firefox,
the code try to display the iframe (with "visibility:hidden;height:1px")
when this part of the code happen.
note: backport of 10.0 13c326caaa
opw-807180
closes#22701
When saving a modified mass mailing, the editor will do a number of
things to improve the mail readability accross mail client.
One of those is replacing font awesome icons by image, but firefox acts
differently than other browser. On a display:none iframe, doing
.css('color') or .height() on an element returns respectively
`undefined` and 0.
This caused an error when getting the color that we could solve by
doing a fallback for firefox like this:
window.parent.getComputedStyle($font[0]).color
But to get the height() of an element, it seems we always need the
iframe displayed.
With this change, when the iframe is hidden and the browser is firefox,
the code try to display the iframe (with "visibility:hidden;height:1px")
when this part of the code happen.
opw-807180
closes#22639
In order to detect if a barcode scanner is being used, we detect the
delay between keypresses. The value is hardcoded to 55 ms. However, in
the case of a bluetooth scanner, this delay is often not enough,
resulting in an incorrect capture of the barcode.
We add the config parameter `barcode.max_time_between_keys_in_ms` which
allows the user to fine tune this delay for his hardware.
opw-806398
When using product variants, the product page shows:
- The product variant if different from the product image
- The product image
- Extra product images
The product variant image has to be switched dynamically when the user
choose another variant. This was broken with commit https://github.com/odoo/odoo/commit/f98bb2b86bb7c3ff0a549f24b31616c1539420a7
Indeed, it was switching the product image with the product image
variant instead.
This was because the variant/template order changed without switching
their classes. This commit changes their order again.
Also see opw-784737
Instead of looking for the "denied" permission, rather look for the "granted"
since there are three permissions: "default", "denied", "granted" - only
"granted" counts toward permission actually being granted
Closes#22633
- Create 2 companies A & B
- Create a product P with 2 phantom BOMs:
Component C1 for company A, with sequence = 10
Component C2 for company B, with sequence = 0
- Create a SO in company A for P, validate
The picking contains C2, while one would expect C1 since C2 is only for
company B.
opw-807640
On a production database with ~10000 products and multiple stock
locations, uunning the 'Inventory at date' tales ~50 minutes. Most of
the time is spent in the loop populating `group_lines` thanks to
multiple search queries.
We get rid of this loop by selecting the stock history lines and making
the match between these lines and the `read_group` result manually. On
the reference database, the duration falls to ~30 seconds.
Based on preliminary work by amoyaux
opw-803460
on account.payment, when changing the payment type to Internal Transfer,
the result of the onchange was erroneous as inbound and outbound methods
lack relevance in that case
After this commit, We choose to display all bank and cash journals in this case
OPW 804214
When clicking on a link in the editor, the "center" alignment button
was always marked as active whatever the real alignment of the link.
This was because it considered the alignment of the text inside the
link instead of the link's one inside its parent.
- Main currency: USD
- Create a PO in EUR
- Create an invoice from the PO
- The invoice is in USD and the exchange rate is applied
- Change the currency to EUR
The conversion is not applied anymore.
The original issue was that changing the date would overwrite any amount
modified in the invoice. Actually, the dependency on the date is not
really necessary. Indeed, this is supposed to help enconding invoices,
but it is likely that:
- If the PO is issued in a currency A, the bill received is in currency
A.
=> no conversion necessary (solved from 11.1).
- If the PO is issued in a currency A and the bill received is in
currency B, the exchange rate used by the vendor is different from
ours.
=> manual corrections are necessary
Therefore, we remove the dependency on the date for the amount
recomputation. However, we still use it in the onchange. This way:
- the amount estimated should be close to the amount requested
- we avoid unexpected recomputation of amounts
Introduced with d8112b0238.
opw-805926
$('web_editor.base').ready() returns a deferred that:
- wait at least for $(document).ready()
- wait at least for require('web.ajax').loadXML()
- at most once starts translations configuration
But there is an issue since there is unexpectedly no reference to the
translations, whilst it should have also been ready when ready was
resolved.
This commit keep the reference so translations can be used after
$('web_editor.base').ready() is resolved as it was before 7dfdfa0103.
note: in 11.0 it should be solved with 29729769 (so fix is for [10,11[)
opw-804148
closes#22522
Sometimes the formatting buttons had no effect or formatted more than
they should (like a whole column when triple clicking on a paragraph
only). This was because of the `listBetween` function implementation.
This is supposed to return all the nodes between one element and another
one... but the logic is wrong without saying from which *point* to start
and which *point* to end. For example, when asking the list between an
element and its parent, the result is very wrong as there is no way to
go from the beginning of an element to the beginning of its parent using
the `walkPoint` function as the `listBetween` function is doing.
Ideally, the function should be entirely fixed but this can be tricky.
For now, the function is just extended to allow to specify points
instead of nodes, and those are used by the `formatBlock` function to
solve the current problem.
... hopefully.
This *must* be forward-ported.
Depending on the browser, the triple-click behavior is different. This
is especially problematic on Chrome, where blank characters at the start
of the neighbor of the clicked element are selected.
A weak attempt to solve that was made by commit https://github.com/odoo/odoo/commit/b85bd358234684974f9af63bc5f28cfabb527767
This commit hopes to solve all the issues once and for all by fully
reimplementing the triple-click for all browsers. The concept is simple:
when a triple-click occurs, select the whole *inner* content of the
deepest DOM *element* that was clicked.
For some unknown reasons, the editor sometimes crashes when dropping a
snippet. As a temporary fix, the non-critical line that causes the
problem is try/catch protected by this commit.
In the case where:
create an invoice with payment terms that contains at least 2 term lines
Validate
create a refund by clicking cancel and reconcile
Before this commit, the refund move lines were wrongly created and reconciled with the invoice's move lines
After this commit, since payment terms are irrelevant on refunds, we set it to false and the problem doesn't raise
OPW 804752
The case: create an invoice of 2000 euros. Payment terms have been configured as:
1) fixed amount 150, 0 days after invoice date.
2) fixed amount 200, 10 days after invoice date.
3) fixed amount 200, 20 days after invoice date.
4) balance, 30 days after invoice date
Before this commit, when issuing a payment of 150 at day 0, that payment got reconciled with the balance line.
After this commit, the payment is reconciled with the right payment term line
OPW 805006
On the payment confirmation page, when the payment is still pending.
Before this commit:
the user friendly message disappeared and a warning icon took its place
After this commit, the warning icon is prepended to the message.
OPW 787799
Step to reproduce:
- Go to 'Blog' > 'Blog Posts' in the 'Website Admin' module
- Select several blog.post on the list view
- Click on 'Archive' in the 'Action' dropdown
This will throw a server error since write() is overriden for blog.post and
do an ensure_one()
This commit closes#22208
- Set the OS to a GMT- timezone (e.g. 'America/Los Angeles')
- Set the format of the date to '%d/%m/%Y'
- Go to 'Account > Adviser > Journal Entries'
- Type '02-01-2018'
The suggested date is 31/01/2018.
Setting the moment object as UTC will lead to a conversion of the date
to the OS timezone when calling `toDate`, e.g.:
Mon Jan 31 2018 16:00:00 GMT-0800 (PST)
UTC should only be used in case of datetime, not date.
opw-803466
In any piece of code, execute the following:
```
self.env['account.config.settings'].create({})
```
It overwrites the values of `fiscalyear_last_day` and
`fiscalyear_last_month` to 31 and 12.
Setting a default value on a related field will automatically write
these values on the related.
opw-805205
In the case where:
1- Do an order on the pos selling a product A (amount = 10)
2- Do another order returning a certain quantity of A (with a quantity < 0)
3- Do a third order selling something else (amount = 5)
Before this commit, the account move lines of the payment move and of the sale move of operation 2 weren't reconciled
This was because the credit to the receivable account of the return was reconciled with the debit of the first operation,
leaving the debit of the payment of the return alone
(i. e. the lines number 1 & 3 & 5 were reconciled together, instead of 1 & 2 & 5, and 3 & 4)
We end up in a situation like this (at validation time)
RECEIVABLE
D | C || OPERATION | Line Number
----------------------------------------------------------------------------
15 | || (1 & 3-Engaging Sale) | 1
| 10 || (1-Payment) | 2
| 10 || (2-Engaging Return) | 3
10 | || (2-Payment Return) | 4
| 5 || (3-Payment) | 5
After this commit, we reconcile the returns for each order before reconciling other transaction chains
The fix is limited in its scope as the automatic reconciliation for the pos transaction is fairly recent
and a "nice to have"
OPW 787298