Daily updates from Odoo
Navigate
Branch
Wednesday, December 4, 2019
32 changes
New functionality added to Odoo
Adds an Italian accounting tax report with lines VP2 to VP6, giving businesses the required structure for local VAT reporting. This helps Italian companies prepare tax information directly in Odoo instead of relying on external or manual reporting.
Original PR description
Description of the issue/feature this PR addresses: Add a tax report for Italian accounting Current behavior before PR: no tax report Desired behavior after PR is merged: tax report, lines VP2 to VP6 as defined by [ticket](https://www.odoo.com/web#id=2079462&action=333&active_id=1691&model=project.task&view_type=form&menu_id=4720) -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Adds a new Italian accounting tax report covering lines VP2 to VP6. This gives businesses operating in Italy a dedicated report structure for required VAT/tax reporting, reducing manual preparation work.
Original PR description
Description of the issue/feature this PR addresses: Add a tax report for Italian accounting Current behavior before PR: no tax report Desired behavior after PR is merged: tax report, lines VP2 to VP6 as defined by [ticket](https://www.odoo.com/web#id=2079462&action=333&active_id=1691&model=project.task&view_type=form&menu_id=4720) -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Enhancements to existing features
The return process now shows each serial-numbered item as its own return line, making it easier for users to select the exact items being sent back. This reduces mistakes when handling returns for tracked inventory and improves visibility in stock operations.
Original PR description
task-1945885
Static template inheritance now follows expected XML targeting rules more closely, including allowing changes to the template root element. This keeps internal inheritance details hidden from callers while preserving useful template attributes, making web template behavior clearer and more consistent.
Original PR description
This commit aims at clarifying the way inheritance is applied onto static templates It also make the system more respectful of the XPATH specs. These improvements, to sum up are: - Hard coded comments are not returned to the caller - An Xpath can now target the root node of a template (the one that defines it with the t-name) to replace it for example - t-inherit and t-inherit-mode are not returned to the caller - t-name and all other root node attributes are returned to the caller Task 2118965
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
Stock reports and product views now better distinguish available quantities from reserved stock. Users can also remove default warehouse filters to see inventory in locations such as subcontracting or repairs, making stock visibility more complete and consistent.
Accounting reconciliation rules can now handle more than two generated lines without duplicating setup fields. Centralizing the calculation logic should make reconciliation behavior more consistent, easier to maintain, and less prone to repeated bugs.
Original PR description
Instead of having all the fields duplicated with second_*, we have now a o2m allowing us to * have more than 2 lines * reduce duplicated code * fix bugs and add features at only one place We also remove the computation of writeoff and suggestions from the client side as some code was 4-upled before (twice in in client and twice in server side). The logic is now only at one place. 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
Website visitors are now informed in the chat window if all live chat operators become unavailable during an active visit. The message is removed when an operator comes back online, reducing confusion and setting clearer expectations for customers waiting for support.
Original PR description
…hannel purpose of this commit is to show a message that 'no operator is available' if a live chat operator disconnects while a visitor accesses the website. Before this commit: it shows an alert message only when a visitor opens the chat window the first time. But when operator disconnects while a visitor accesses the website then a visitor don't get any message. After this commit: 1) when live chat operator disconnects (internet access issue or offline), then a visitor will be notified by the message 'No operators are available' in the chat window. Task: https://www.odoo.com/web#id=1935830&action=327&model=project.task&view_type=form&menu_id=4720 Pad: https://pad.odoo.com/p/r.fb41be5ff313449ec89f357841b60368 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Bank reconciliation rules can now manage multiple adjustment lines instead of being limited to duplicated fields for two lines. This simplifies maintenance, reduces duplicated logic, and centralizes calculation handling on the server for more consistent reconciliation results.
Original PR description
Task [2046908](https://www.odoo.com/web#id=2046908&action=333&active_id=967&model=project.task&view_type=form&menu_id=4720) Community PR https://github.com/odoo/odoo/pull/38119 Instead of having all the fields duplicated with second_*, we have now a o2m allowing us to * have more than 2 lines * reduce duplicated code * fix bugs and add features at only one place We also remove the computation of writeoff and suggestions from the client side as some code was 4-upled before (twice in in client and twice in server side). The logic is now only at one place.
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