When the iap sever is called, it is possible that the request timeout
or that the webserver returns an error code (if the Odoo server is down
for example) and we should warn the user instead of throwing an
exception in a traceback
closesodoo/odoo#29667
In this commit: https://github.com/odoo/odoo/commit/a0b7802a5e7646a896f54cf125f0136ff489d4d9
We've added the possibility to send the dbuuid in the authorize request,
this as been added to allow to give free credits of a service to a
database.
As some services developped in 11.0 are using this mecanism, we have to
add that support in 11.0
Fine-tuning of commit e7fab23420
In a one2many with more than one page with a limit of k records, add a line l.
It increments the list limit to k+1. Remove a line above (of index <= k).
It will try to load a line l' to replace it, that it will find on page 2.
However when deciding if it should read missing fields on that record, it will
scan at most u records, skipping virtual ids.
Here u is the min between the current number of lines and the list limit
without the temporary increase due to the added record.
Since there are at least two pages, u = k.
However since l is in the list at index k, then l' won't be read, and since it
was on page 2 its data hasn't been loaded.
Therefore the js would traceback when trying to evaluate it.
opw 1913361
closesodoo/odoo#29338
Backport of commit 771f65ecf5
Payments created without partner_type (field not required)
were previously not shown anywhere, as well as internal transfers.
opw 1910590
closesodoo/odoo#29647
Currently when recording global leaves on the ressource calendar
the worked line has no code or description, which are required.
Specify a default value to allow the saving of the payslip.
closesodoo/odoo#29655
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
Pierre Masereel