Use case: a x2m (ex: attribute values) displayed in a x2m (ex: attributes on
product) using different fields in different views (ex: tags in product form view
and list in product attribute form view). When opening the x2m record (in a
wizard) then going back on the form view, the tags are empty because the
`display_name` value has been lost when fetching x2m for the second time.
In this case, the list `fieldsInfo` needs to be updated with the existing
(default for tags) one so all the fields will be correctly loaded.
Task 1916891
closesodoo/odoo#29598
When filtering the calendar view on search filters, the filter `context`
was not taken into account during the reload.
For example, in the Calendar app, the filter 'My Meetings' has a `context`
{'mymeetings': 1} which was not passed to `search_read`.
Task 1917628
closesodoo/odoo#29531
opw-1916064
Have a sales order line on which you decrease the quantity.
Before, this commit, the warning message that says to update the
delivery order did not show. This was because, the onchange in the
python side compared the new quantity against the saved one, and did
not find any difference. This is caused by the onchange itself, which,
in a o2m setting, received from the JS, the changed order
(already containing the changed line) and only then proceeded to the
onchange of the line. The first operation wrote onto _origin the new
line value, which corresponded subsequently to the new value.
After this commit, we compare the real value explicitly retrieved from
the database to the one just entered by the user as an onchange.
The warning message works as expected.
Long story short, _origin in an onchange doesn't guarantee to yield
persisted values in all cases.
closesodoo/odoo#29582
After this fix, the field `partner.street` is correcly rendered,
but as the test shows the `street_name` and `street_number` fields
are not correct.
But as there are tests that validate that wrong use case, I
consider it a *feature* and not a bug.
opw-1896773
closesodoo/odoo#29520
- Buy on product on the eCommerce with a partner having a single address
- At address selection, edit the shipping address
The billing address is also modified.
From the Odoo PoV, this is expected since they point to the same
partner. But from a user PoV, this is totally unexpected and confusing.
Therefore, we only allow the edition of the shipping addresses which are
different from the billing address. Yet, if the user modifies the
billing address, it will change the corresponding shipping address as
well. However, the usual flow is to set the billing address, then the
shipping address. So that should cause less issues. In v12, a warning
message is added.
opw-1914185
closesodoo/odoo#29509
opw-1916148
The city, state and zip code are shown behind the street name and
street number, and not in a new line.
This only occurs in the read-only view.
This was changed to use the field 'street', which is a text of the
street name, number and door number in the street formatted in the
format of the partner's country. This only for the read-only view,
leaving the 3 fields separated for the edit.
closesodoo/odoo#29467
If the price section goes on two lines because of crossed
prices or many icons, then it would overlap with the product title.
See before/after on the PR.
opw 1913521
closesodoo/odoo#29388
Commit 5804246e0f introduced some improvements to speed up performances.
One of them was to check if a customize_show view was active or not but the
condition was on view.customize_show instead of view.active.
Thus, as that view is always a customize_show, the condition would always be
met.
closesodoo/odoo#29414
The definition of `attachment_ids` on model `email_template.preview` is wrong,
because its table/columns refer to the model `mail.template`. As the field is
only used to preview a result in a wizard form, it does not need to be stored.
closesodoo/odoo#29349
used to fetch debit & credit recorded in Tax Cash Basis Journal Entries
Main
-
By allowing to change the `amount_mnt` var we will be able to change the
values recorded in Tax Cash Basis Journal Entries, i.e, debit & credit
values.
Explanation
-
We want to keep the `amount` just the way it has been computed because
that is right. We don't want to change that.
Our issue is the`rounded_amt` which is the value that is passed to the
debit and credit downwards.
We have only hooked a new method to allow us later inherit that method
and make our own computations regarding the `rounded_amt` which is the
main subject of this PR and later pass it down to the debit & credit
fields as need for localizations that could be facing the problem of
having the computation of taxes at date of invoicing instead of date of
payment.
`amount` var is used here:
`
'amount_currency': self.amount_currency and
line.currency_id.round(-line.amount_currency * amount / line.balance) or
0.0,`
and we are not intending to change that because the value written to the
`amount_currency` field is right.
What we intend is to compute the values for debit and credit fields
which were computed in this method at invoice date, some l18n need them
at payment date, e.g, l18n_mx.
Be aware
-
Do not be mislead by the fact that `rounded_amt` var is the one taken to
do those computations. It is just a mean to the final goal. Rounding is
not an issue and has never been.
Background
-
By allowing this merge to flow we will be able to address the following issues:
https://github.com/odoo/odoo/issues/25057https://github.com/odoo/odoo/pull/17196https://github.com/odoo/odoo/issues/9972
Final Goal
-
Being able to perform the computation of the debits and credits
according to l10n_mx in odoo/enterprise#3137closesodoo/odoo#28991
required: [('chart_template_id','!=',False)] doesn't work because you need to fill the chart_template_id
to install a chart of accounts for your company. Then, the transfer_account becomes required before its installation
and then, you are not able to install a chart of accounts for your company.
If installed along with `auth_signup`, it sends an email when creating a missing user authenticated through LDAP.
It is a confusing message that makes no sense, because the user is, from his POV, not actually creating a new user, but just authenticating with a new app with his known company-wide credentials.
Besides, that invitation leads the user to change his password in Odoo, although he probably doesn't want to do that and have a password for Odoo and another in the LDAP server.
The best option is to disable that email completely, which is what this commit does.
closesodoo/odoo#29243
The module `vatnumber` (which is not maintained anymore) uses an
incorrect validation method for Albanian VAT numbers. Therefore, we use
the library `stdnum`, on which `vatnumber` relies for most cases.
opw-1912680
closesodoo/odoo#29280
Modifying a source term in an XML/HTML translated field can lose translations
if the same term is translated in several languages.
closesodoo/odoo#29078
The other methods do test password length before verifying it, so even
if check_credentials() is not meant to be called directly, it's better
to keep it consistent with the alternatives.
Closes#29023
Suppose you have a workorder to create n units of product P,
using raw material R (suppose we use one for one, the following can be extended
to any number of raw materials and factors in a straightforward manner).
Produce j < n units of P. Next, update the quantity to produce to j < k < n.
Since any number m of units between j and n may already have been reserved,
in particular values such that m > k, the move will unreserve the material R.
However, while doing so it will unlink the move_lines, and lose the
quantity_done (j).
The newly created move lines have a quantity_done of zero by default.
Therefore, we store in a dictionary the quantities done for each move line,
and reset these values once the unreservation/reservation of k units is done.
opw 1911969
closesodoo/odoo#28990
Before this fix products in a pricelist would not be grouped when there
is a decimal value in the price.
This problem was caused by a trailing rounding error, for instance a
price of 29.90 could give a pricelist price of 29.900000000002. To solve
this we check if Math.round((price - pricelist-price)/currency-rounding)
gives 0 as a result, if so, the price is equal to the pricelist price
and the product can be grouped.
solves: https://github.com/odoo/odoo/issues/28521#issuecomment-443148920closesodoo/odoo#29185
When activating a filter on a list view,
the environment of the action contained a context with an orderedBy key
which was then used by every controller and model in the various
parallel flows, i.e. changing actions
After this commit, we prevent it by excluding the key when executing an action
OPW 1913190, 1914019
closesodoo/odoo#29186
Changing the journal of a reconcialiation model to a journal not
reconciliable resulted to the model not accessible from any
menu.
opw-1913079
closesodoo/odoo#29249
We now support version 0.12.5(.1), which is available for all recent Debian and Ubuntu versions,
and contains quite a few bug fixes. An up-to-date version of Odoo 10 or later is required, for
pixel-perfect compatibility with the result of 0.12.1.3.
See also the wiki for more info: https://github.com/odoo/odoo/wiki/Wkhtmltopdf
Firefox for android gives atraceback when clicking the print receipt
button. This traceback is caused becaus Firefox for Android does not
support printing.
This fix replaces the traceback by an explanation why it is not possible
to print.
Also backport for safari-fix
closesodoo/odoo#28919
/!\ Should not be forward-ported in *12.0* /!\
Because of the mechanism to bind change / click event in the 10.0
implementation, when we are in edit mode on a product page, the event
handlers that are in charge of updating the cart quantity can still be
triggered.
After this commit, click / change event while updating cart qty will
not be effective in edit mode.
task-1825889
Closes https://github.com/odoo/odoo/pull/24211closesodoo/odoo#29224
Martin Geubelle