To have the same behavior as `_compute_decimal_places` in python
When setting rounding of currency > 10, POS will get negative decimals
instead value 0 and crash
Closes#22199
Before this commit, all the mailto:xx@ww.com in emails were transformed into
http://web.base.url/xx@ww.com
This was due to the url parsing of werkzeug urls.py, which definitely get the scheme
(mailto), but doesn't get the netloc of the url -- because it has no //
Ater this commit, we transform links to local ones, except if the scheme is mailto,
and the issue disappears.
OPW 807795
- Create a bill for partner A of an amount X
- Create a bill for partner B of an amount Y
- Validate both bills
- Select both and register a payment by check.
Two payments are created with the same amount in words: X + Y.
In this specific case, we recompute the amount in words automatically.
opw-805842
When we pass two disjoint intervals the behaviour of _interval_and is a
little strange, it returns an interval wich begins after it finishes.
In order to fix that we return None when the intervals are disjoint.
If you have stock installed before 0322f6e5 and try to install stock_account
today, the installation fails.
Should not rely on a field added after the stable freeze
Fixes#21823
opw-802767
It seems that firefox has some difference of behavior from other
browsers as said in:
- https://bugzilla.mozilla.org/show_bug.cgi?id=548397
- https://github.com/whatwg/html/issues/1813
- https://github.com/w3c/csswg-drafts/issues/571
It seems that at least in one instance (a html field hidden on the pos
configuration), firefox fails because of something similar:
window.getComputedStyle(element) returns `null` instead of the element
styles.
In my tests, using the parent window (possible if current frame and
parent have the same origin which should be the case) worked in this
instance, this is examplified by this jsfiddle:
https://jsfiddle.net/Lpv898ve/2/
This work with window.parent and not using window directly.
So this commit adds fallback on doing getComputedStyle from the parent
window (when testing on chromium this gave exactly the same result that
before).
opw-813363
fixes#22211closes#22610
- Create a product with name 'EN' in English and 'FR' in French
- Connect to the POS interface with a user having the French language
set up.
The product name is loaded as 'EN' instead of 'FR'.
The language is missing from the context of the `search_read` calls.
Therefore, the product names (as well as categories, UOM...) are loaded
in the default language.
opw-805431
This action was not working as the tree view has been removed
This feature was replaced by hr_org_chart module
Just display a list of the employee and subordinates
Fixes#20203Fixes#22312Fixes#22536
onchange function getting called when modifying the 'amount' field of account.payment always changed the journal of the payment when this amount was equal to zero. This caused a bug with batch deposits, when trying to create a new payment from the tree view contained in the form view of account.batch.deposit: passed default value for journal_id was ignored.
The result of the following:
```
float_round(2.5, precision_rounding=0.05, rounding_method='DOWN')
```
is 2.45. Instead, 2.5 is expected.
In case of the `DOWN` method, epsilon should be added, not subtracted.
In the meantime, we introduce a slight reorganization of the method to
make it clearer.
opw-805008
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
Before this commit, the dashboard pill taht allows the user to consult
his iap accounts was hidden for saas users as it is grouped with the
app store and theme buttons which are not supposed to be shown since
they are not available in saas.
This commit ensures taht the button will be shown both on saas and premise instances.
In the alternative products with 66994856 the thumbnail blocks were
restricted in size.
This is not very nice in the basic theme (the text of a product is cut
unexpectedly by the block border) but seems outright wrong on other
theme without border.
This commit forces the alternative product name to be on only one line
and be ellipsed. There was a lot of possible solution but for supported
browser compatibility and not breaking possible existing customization,
this one was choosen.
A better solution would probably use "flex" but we can't use it
currently (because of internet explorer support).
opw-806285
closes#22547
Mail content is wrapped in a table to properly allow centering the
layout in all mail clients. The problem was that this table was able
to be customized by the editor while it should not.
When duplicating a project, a command [(6, _, ids)] may be generated.
This fail with the commit aa8a39fc4f because all comodels records with
id not in `ids` will have their inverse field unset.
But eg. in the case of copy, this would trigger an error because this
would be done to an empty recordset and unexpectedly trigger an error.
opw-807655
closes#22525
- 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
Url in the web client are supposed to open in a new tab. This was the
way it worked in v10.0 and was lost with the refactoring of the new
views.
We just reintroduce that behaviour with this commit.
Closes github issue #22389
$('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.
If some orders have no taxes (e.g. manual reimbursement with a negative amount)
the sum of taxes lines gave a different result than the total amount sold.
e.g.:
order 1: price 10€, including 2€ for taxes
order 2: price -5€, no taxes
report:
taxes:
20%, 2€ taxes, 8€ base amount
total sold:
5€
2+8 != 5
Also change line.price_subtotal as it was computed twice if there was two taxes
on a line (although it will probably never happen in the pos)
opw-805415
As some flows were broken, this set of fixs improve the different routes for all acquirers
See commit messages for more information
Thanks to @jpr-odoo for his first implementation and to @tde and @fgi
... 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.