Daily updates from Odoo
Wednesday, December 4, 2019
24 changes · master
Enhancements to existing features
The Indonesian localization module now uses English as its main source language, with Indonesian provided as a translation. This improves consistency for users and maintainers working with Odoo’s standard English interface while preserving Indonesian language support.
Original PR description
Task [2148441](https://www.odoo.com/web?debug=1#id=2148441&action=333&active_id=1691&model=project.task&view_type=form&menu_id=4720) The main language is now english, translated in indonesian. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This update adjusts an automated website eLearning test so it matches recent product changes. It helps keep quality checks reliable and reduces the risk of false test failures during development.
Original PR description
Since a recent commit[1], a tour was broken because the changes were not adapted in the tour. This commit fixes the tour by adapting the related changes. commit[1] : https://github.com/odoo/odoo/commit/07f70e3c1026b4cbe6edcb6e875584c868da3eb1#diff-c04965d90e4f0bf837cc3f5c4f512040L35 Task ID: 2146189 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Code cleanup and technical improvements
Stock product quantity views now rely on a standard computed value instead of special internal context options. This reduces maintenance complexity and helps keep inventory quantities consistent across product screens.
This change updates rental stock logic to use the standard valued-quantity field instead of a special context flag. It reduces internal complexity and helps keep rental inventory valuation behavior aligned with the rest of Odoo.
Original PR description
The correct way to get what quantities are valued is to used the `quantity_svl` computed field.
Miscellaneous changes
The method `unlink` checks whether any of the records to delete is used as the default value of a company-dependent field. The query simply blows up when deleting several millions of records. The fix consists in performing the check in batches. Forward-Port-Of: odoo/odoo#41293 Forward-Port-Of: odoo/odoo#41263
Original PR description
The method `unlink` checks whether any of the records to delete is used as the default value of a company-dependent field. The query simply blows up when deleting several millions of records. The fix consists in performing the check in batches. Forward-Port-Of: odoo/odoo#41293 Forward-Port-Of: odoo/odoo#41263
Description of the issue/feature this PR addresses: Keep the session object JSON serializable. e.g. when using an external session storage (like Redis) Current behavior before PR: Error like `TypeError: {4} is not JSON serializable` when trying to convert the session object into JSON Desired behavior after PR is merged: No error when serializing session object for external storage -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Po
Original PR description
Description of the issue/feature this PR addresses:
Keep the session object JSON serializable. e.g. when using an external session storage (like Redis)
Current behavior before PR:
Error like `TypeError: {4} is not JSON serializable` when trying to convert the session object into JSON
Desired behavior after PR is merged:
No error when serializing session object for external storage
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#40850If a module add a state field on another table used by this report, PostgreSQL will report a: ```psycopg2.ProgrammingError: column reference "state" is ambiguous``` Forward-Port-Of: odoo/odoo#41325
Original PR description
If a module add a state field on another table used by this report, PostgreSQL will report a: ```psycopg2.ProgrammingError: column reference "state" is ambiguous``` Forward-Port-Of: odoo/odoo#41325
tax grouping key from base and tax line that will be used as a key to group taxes together so both functions must have the same dictionary key. (you can check comment here https://github.com/odoo/odoo/blob/13.0/addons/account/models/account_move.py#L412) here we have three key (product_id,product_uom_id,quantity) in _get_tax_grouping_key_from_base_line and only one key (product_id) in _get_tax_grouping_key_from_tax_line. so we get wrong tax calculation. now we remove that extra key(pr
Original PR description
tax grouping key from base and tax line that will be used as a key to group taxes together so both functions must have the same dictionary key. (you can check comment here https://github.com/odoo/odoo/blob/13.0/addons/account/models/account_move.py#L412) here we have three key (product_id,product_uom_id,quantity) in _get_tax_grouping_key_from_base_line and only one key (product_id) in _get_tax_grouping_key_from_tax_line. so we get wrong tax calculation. now we remove that extra key(product_uom_id, quantity) because we don't need group by these key values. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#40558
Task : https://www.odoo.com/web#id=2121584&action=327&model=project.task&view_type=form&menu_id=4720 Pad : https://pad.odoo.com/p/r.e6065a0dc05baf16c88e057afb752eed -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#40110
Original PR description
Task : https://www.odoo.com/web#id=2121584&action=327&model=project.task&view_type=form&menu_id=4720 Pad : https://pad.odoo.com/p/r.e6065a0dc05baf16c88e057afb752eed -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#40110
Forward-Port-Of: odoo/odoo#41292
Original PR description
Forward-Port-Of: odoo/odoo#41292
-- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#40958
Original PR description
-- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#40958
opw-2148101 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#41258 Forward-Port-Of: odoo/odoo#41210
Original PR description
opw-2148101 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#41258 Forward-Port-Of: odoo/odoo#41210
The reconciliation would fail on any move with many lines (order of about 1000) because Python would could reach the max recursion depth (exactly 1000 by default). To avoid that, just use the while. opw 2121587 Closes #40005 Forward-Port-Of: odoo/odoo#41212 Forward-Port-Of: odoo/odoo#41013
Original PR description
The reconciliation would fail on any move with many lines (order of about 1000) because Python would could reach the max recursion depth (exactly 1000 by default). To avoid that, just use the while. opw 2121587 Closes #40005 Forward-Port-Of: odoo/odoo#41212 Forward-Port-Of: odoo/odoo#41013
The only good solution is to set `show_reserved` to `True` to avoid any kind of weirdness... This reverts commit eed3171f2f057223c3fbedd95ce6bcde2124f46c. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#41276
Original PR description
The only good solution is to set `show_reserved` to `True` to avoid any kind of weirdness... This reverts commit eed3171f2f057223c3fbedd95ce6bcde2124f46c. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#41276
If we do a payment with: - a currency different than the journal - the journal currency the same as company currency => it fails, because of the constraint on account.move.line: > The amount expressed in the secondary currency must be positive when > account is debited and negative when account is credited. with code: ``` CHECK(currency_id IS NULL OR company_currency_id IS NULL OR ((currency_id != company_currency_id) AND {conditions on balance})) ``` This happens because in this use case,
Original PR description
If we do a payment with:
- a currency different than the journal
- the journal currency the same as company currency
=> it fails, because of the constraint on account.move.line:
> The amount expressed in the secondary currency must be positive when
> account is debited and negative when account is credited.
with code:
```
CHECK(currency_id IS NULL OR company_currency_id IS NULL OR
((currency_id != company_currency_id) AND {conditions on balance}))
```
This happens because in this use case, a NON-NULL currency_id means that
the currency is different than the company currency, this was not taken
into account when creating a liquidity line.
opw-2150267
Forward-Port-Of: odoo/odoo#41244task - https://www.odoo.com/web#id=2060330&action=327&model=project.task&view_type=form&menu_id=4720 pad - https://pad.odoo.com/p/r.470f9e234d27418158a91e111dc3f7d6 Studio shouldn't let user drop notebook in a group since it generates issues with the notebook. Due to this in "documents" and "payment" form view, user can't access tab in studio enable. Reference commit - ea5ccd548bb6781e5ccdf76cf11255c6fd6aa3cb Forward-Port-Of: odoo/odoo#40846 Forward-Port-Of: odoo/odoo#36375
Original PR description
task - https://www.odoo.com/web#id=2060330&action=327&model=project.task&view_type=form&menu_id=4720 pad - https://pad.odoo.com/p/r.470f9e234d27418158a91e111dc3f7d6 Studio shouldn't let user drop notebook in a group since it generates issues with the notebook. Due to this in "documents" and "payment" form view, user can't access tab in studio enable. Reference commit - ea5ccd548bb6781e5ccdf76cf11255c6fd6aa3cb Forward-Port-Of: odoo/odoo#40846 Forward-Port-Of: odoo/odoo#36375
When we post multiple draft moves at the same time, the numbering should be done by starting with the oldest one up to the newest. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#40848
Original PR description
When we post multiple draft moves at the same time, the numbering should be done by starting with the oldest one up to the newest. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#40848
The `session_info` dictionnary is used to bootstrap some JS code client side (usually in the backend). It includes relevant information, such as some parameters key for the OdooBot onboarding, the Enterprise subscription expiration alert, etc. to avoid triggering a lot of RPC calls upon webclient start. `session_info` is also called by the remote authentication mechanism located at `/web/session/authenticate`, which can be used by external mechanism to obtain a valid session remotely.
Original PR description
The `session_info` dictionnary is used to bootstrap some JS code client side (usually in the backend). It includes relevant information, such as some parameters key for the OdooBot onboarding, the…
The `session_info` dictionnary is used to bootstrap some JS code client
side (usually in the backend). It includes relevant information, such
as some parameters key for the OdooBot onboarding, the Enterprise
subscription expiration alert, etc. to avoid triggering a lot of RPC
calls upon webclient start.
`session_info` is also called by the remote authentication mechanism
located at `/web/session/authenticate`, which can be used by external
mechanism to obtain a valid session remotely.
Revision odoo/odoo@8a28cc2 introduced the concept of cache keys for
some oft-requested data (such as menus, translations and dynamic qweb
templates) to avoid requesting them on each webclient start, since they
tend not to change often. Unfortunately, it introduced a read on the
ir.ui.menu model that raised an `AccessError` if the authenticating user
was not a member of the `base.group_user` group ('Internal' user type).
While fixing that issue, it became apparent that `session_info`
returns a whole lot of information through this remote connection route
which is entirely unnecessary if not used in the context of a webclient
start, such a currencies, the state of the enterprise subscription, etc.
This commit fixes the access right issue by removing this non-relevant
information from the returned dict (including cache keys) if the user
is not an internal one.
X-original-commit: 6e99ac2c6cd5ca9af87b4fc7a3a1394359e30b02
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#41219If we have eg. a report with a page break (eg. `Print On New Page` enabled on a financial report section) the encoding is broken. The reason is that lxml.html fragments_fromstring function accepts text string (OK in unicode) or bytestring => the encoding will be guessed (by chardet library) if guess_charset argument is set to true. So since we do not pass guess_charset option, the encoding is not recognized. In this changeset, we give a text string to the fragments_fromstring function since i
Original PR description
If we have eg. a report with a page break (eg. `Print On New Page` enabled on a financial report section) the encoding is broken. The reason is that lxml.html fragments_fromstring function accepts text string (OK in unicode) or bytestring => the encoding will be guessed (by chardet library) if guess_charset argument is set to true. So since we do not pass guess_charset option, the encoding is not recognized. In this changeset, we give a text string to the fragments_fromstring function since it seems that all our input should be in UTF-8. note: lxml.html itself uses html5lib.HTMLParser parseFragment that takes a charset argument, but there is no interface through fragments_fromstring to specify the charset. opw-2146715 Forward-Port-Of: odoo/odoo#41255
If a visitor logs in (and has a visitor_id in his cookie), the partner will be linked to the visitor. If, after 1 week, the visitor tries to connect again with a different session (or another visitor_id in cookies), the authenticate will crash because * _cron_archive_visitors applies on visitor inactive since at least a week * there can be only one visitor per partner (sql constraint) * the visitor linked to the partner is not retrieved (because archived) and we try to link the
Original PR description
If a visitor logs in (and has a visitor_id in his cookie), the partner will be linked to the visitor. If, after 1 week, the visitor tries to connect again with a different session (or another visitor_id in cookies), the authenticate will crash because * _cron_archive_visitors applies on visitor inactive since at least a week * there can be only one visitor per partner (sql constraint) * the visitor linked to the partner is not retrieved (because archived) and we try to link the partner to a new visitor. Further than that, if the visitor is archived and the linked partner wants to login again with a new visitor_id, we should * reactivate the previous visitor, * copy history from newest to previous one, * delete the newest one Note that last two points were already done before this commit. Task ID: 2120464 PR #40199 Fixes #40077 Fixes #40301 Forward-Port-Of: odoo/odoo#41220
task - https://www.odoo.com/web#id=2060330&action=327&model=project.task&view_type=form&menu_id=4720 pad - https://pad.odoo.com/p/r.470f9e234d27418158a91e111dc3f7d6 Studio shouldn't let user drop notebook in a group since it generates issues with the notebook. Due to this in "documents" and "payment" form view, user can't access tab in studio enable. Reference commit - ea5ccd548bb6781e5ccdf76cf11255c6fd6aa3cb Forward-Port-Of: odoo/enterprise#5392
Original PR description
task - https://www.odoo.com/web#id=2060330&action=327&model=project.task&view_type=form&menu_id=4720 pad - https://pad.odoo.com/p/r.470f9e234d27418158a91e111dc3f7d6 Studio shouldn't let user drop notebook in a group since it generates issues with the notebook. Due to this in "documents" and "payment" form view, user can't access tab in studio enable. Reference commit - ea5ccd548bb6781e5ccdf76cf11255c6fd6aa3cb Forward-Port-Of: odoo/enterprise#5392
OPW 2126259 Winbooks uses unique ids for things that should be different. * The journal entries numbers: we do it the odoo way. Concatenate the journal, the year and the number separated by a '/'. Without this, we cannot post the entries as Odoo has a constraint that prevent from having the same number for an entry, regardless of the journal/fiscal year. * The matching numbers: we give a different number for each account when there is a single number in Winbooks that matches lines in mul
Original PR description
OPW 2126259 Winbooks uses unique ids for things that should be different. * The journal entries numbers: we do it the odoo way. Concatenate the journal, the year and the number separated by a '/'. Without this, we cannot post the entries as Odoo has a constraint that prevent from having the same number for an entry, regardless of the journal/fiscal year. * The matching numbers: we give a different number for each account when there is a single number in Winbooks that matches lines in multiple accounts. Forward-Port-Of: odoo/enterprise#6862
The `session_info` dictionnary is used to bootstrap some JS code client side (usually in the backend). It includes relevant information, such as some parameters key for the OdooBot onboarding, the Enterprise subscription expiration alert, etc. to avoid triggering a lot of RPC calls upon webclient start. `session_info` is also called by the remote authentication mechanism located at `/web/session/authenticate`, which can be used by external mechanism to obtain a valid session remotely.
Original PR description
The `session_info` dictionnary is used to bootstrap some JS code client side (usually in the backend). It includes relevant information, such as some parameters key for the OdooBot onboarding, the…
The `session_info` dictionnary is used to bootstrap some JS code client
side (usually in the backend). It includes relevant information, such
as some parameters key for the OdooBot onboarding, the Enterprise
subscription expiration alert, etc. to avoid triggering a lot of RPC
calls upon webclient start.
`session_info` is also called by the remote authentication mechanism
located at `/web/session/authenticate`, which can be used by external
mechanism to obtain a valid session remotely.
Revision odoo/odoo@8a28cc2 introduced the concept of cache keys for
some oft-requested data (such as menus, translations and dynamic qweb
templates) to avoid requesting them on each webclient start, since they
tend not to change often. Unfortunately, it introduced a read on the
ir.ui.menu model that raised an `AccessError` if the authenticating user
was not a member of the `base.group_user` group ('Internal' user type).
While fixing that issue, it became apparent that `session_info`
returns a whole lot of information through this remote connection route
which is entirely unnecessary if not used in the context of a webclient
start, such a currencies, the state of the enterprise subscription, etc.
This commit fixes the access right issue by removing this non-relevant
information from the returned dict (including cache keys) if the user
is not an internal one.
X-original-commit: 820e54cfc869b5640a6ea19340e45ba667dabbc4
Forward-Port-Of: odoo/enterprise#6999Steps to reproduce the bug: - Let's consider a customer C with a fiscal position FP called 'Import/Export' - Let's consider a subscription template ST with payment_mode = 'manually' - Let's consider a subscription product P with a 21% tax with template ST - Create a SO for C with P - 21% tax is automatically mapped by 0% tax thanks to FP - Confirm the SO and a subscription is automatically created - Click on 'Create invoice' Bug: The 21% tax was not mapped by FP in the created inv
Original PR description
Steps to reproduce the bug: - Let's consider a customer C with a fiscal position FP called 'Import/Export' - Let's consider a subscription template ST with payment_mode = 'manually' - Let's consider a subscription product P with a 21% tax with template ST - Create a SO for C with P - 21% tax is automatically mapped by 0% tax thanks to FP - Confirm the SO and a subscription is automatically created - Click on 'Create invoice' Bug: The 21% tax was not mapped by FP in the created invoice opw:2129516 Forward-Port-Of: odoo/enterprise#6942