Default time was set to default=fields.Datetime.now() instead of
default=lambda self: fields.Datetime.now(),
resulting in a discrepancy when printing the report.
opw 1917523
closes issue #29352
The Dutch taxes will change the low tax 6% to 9% on 01/01/2019. Please add these tax code in the system and also change the affected fiscal positions. Both 6% and 9% needs to exist during the transition period.
closesodoo/odoo#29374
Currently name_search on res_partner holds code to be done by a customized SQL
query allowing to speedup the search [1]. However when dealing with given args
there may be a crash if there is a domain based on user_ids fields.
Indeed this field is defined as auto_join [2]. It means the result of get_sql
returns where parameters based on joined tables. Those tables are not available
in the from clause in the original query.
This commit fixes that issue by correctly taking the from_clause from get_sql.
That way joined tables are available. Small update of the query is necessary
as fields are now res_partner.{id/email/vat/reference} as there may be several
tables linked in the query.
A test has been added to avoid regression.
[1] See https://github.com/odoo/odoo/commit/05ec12692f99b69924765fd0ce384632547f03f9 for a recent modification
and implementation of this query, even if it exists since a looooong time
[2] See https://github.com/odoo/odoo/commit/db8203c27a21acdbcad2cf1c394b6fea3cf13688 for the auto_join addition
closesodoo/odoo#29827
This revision is related to
12df3c6a98
The above revision serve its purpose as well,
but by avoiding to store the result in a variable,
and using the records cache instead,
we gain some memory, which is noticeable
when there are hundred of thousands products.
The sudo() is important, as it must be the
same environment then the above call to read
to use the same cache.
Otherwise the values won't be in the cache
of self (without sudo),
and it will go get it and prefetch other fields
in the database.
Oversight in revision
a91ffcf1a7
Multiple products can have the same template.
Passing multiple times the same template id
to the search domain to get the sellers
works, but better avoid the repetition
for the performances.
closes issue #29352
The Dutch taxes will change the low tax 6% to 9% on 01/01/2019. Please add these tax code in the system and also change the affected fiscal positions. Both 6% and 9% needs to exist during the transition period.
closesodoo/odoo#29375
During the installation of a module, an IntegrityError can be raised,
e.g. if some module data already exists in the database
(as in the case of a module which uninstallation did not remove its data).
In Python2 it was possible to use such a psycopg2.IntegrityError with i[0]
to get its error message, while this raises an exception in Python3,
i.args[0] is needed.
As a result the log would contain an exception within an exception instead of
displaying an error to the user.
opw 1916374
closesodoo/odoo#29787
Create a vendor payment of 100€
Create a bank statement line with an amount lower than the payment
Open bank reconciliation view
Reconcile the bank statement line with the blue line of 100€, the triangle for partial reconcile appear.
Current behavior:
If you click the triangle, you can reconcile this payment with the statement line but it becomes unbalanced.
Expected behavior:
The triangle should not appear.
Fixes odoo#29654
closesodoo/odoo#29718
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
By prefetching only the fields required for the `name_get`
`product.product` & `product.template`
have a huge number of fields,
and prefetching them just to compute
the name is overkill.
Especially, as the browse was done using
sudo, the prefetch was a bit useless as
it was stored in the sudo user cache,
which was most-likely not used afterwards
by the callee of name_get
For a database with 50.000 products,
this reduce the processing time
by 15 (from 60 seconds to 4 seconds measured)
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
- Install a second language, e.g. French
- Set Parter A language to French
- Create an invoice for A with a date due in the past
- On the partner form view, print the 'Due Payments'
The body of the letter is not translated in French.
Something quite weird appears:
- The corresponding string is exported in the `stock` module
- It is linked to the demo data `stock.res_company_1`, which corresponds
to 'My Company, Chicago'.
Therefore, the translation cannot be found by the corresponding query
generated in `_generate_translated_field` and `_read_from_database`:
```
SELECT "res_company"."id" as "id",COALESCE("res_company__overdue_msg"."value", "res_company"."overdue_msg") as "overdue_msg" FROM "res_company" LEFT JOIN
(SELECT DISTINCT ON (res_id) res_id, value
FROM "ir_translation"
WHERE name='res.company,overdue_msg' AND lang='fr_BE' AND value!=''
ORDER BY res_id, id DESC)
as "res_company__overdue_msg" ON ("res_company"."id" = "res_company__overdue_msg"."res_id")
WHERE "res_company".id = 1 ORDER BY "res_company"."sequence" ,"res_company"."name"
```
Indeed, `res_company.id` is 1, while `res_company__overdue_msg.res_id`
is 3.
The root cause has been solved in v11, to we only export the necessary
term.
opw-1908337
closesodoo/odoo#29525
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
Christophe Simonis