Daily updates from Odoo
Tuesday, February 25, 2020
29 changes · master
Enhancements to existing features
Odoo now skips an unnecessary database check when reading records whose identifiers are already known. This reduces database queries in common data-loading flows, improving performance while keeping access-rule checks in place.
Original PR description
When the `select` returns nothing more than ids that are already known, there is no need to make it at all. This removes one query from `_read` every time it has to fetch only fields that are stored in a different table (o2m, ...), which happens all the time when reading a stored field first (triggering prefetch) and then reading a o2m. The query that is now removed was used to check access rules, but the trick is to use `check_access_rule` to verify the rules in python instead. Part of task-2061122
When copying shifts from the previous week, Planning now respects the filters currently applied by the user. This helps managers duplicate only the relevant schedules, reducing cleanup work and preventing unwanted shifts from being copied.
Original PR description
taskID: 2201054
Helpdesk SLAs can now exclude specific ticket stages from deadline calculations. This lets teams pause SLA timers when tickets are waiting in agreed stages, making deadlines more accurate and fair.
Original PR description
Add exclude stage in SLA. If the ticket is in this stage, the deadline is extended. taskID: 2176362
Resolved issues and error corrections
Analytic accounting lines now refer to the currency set on the analytic account instead of defaulting to the company currency. This keeps currency references accurate in cases where analytic accounts use a different currency, with no expected change for standard setups where both currencies match.
Original PR description
Description of the issue/feature this PR addresses: #45995 Current behavior before PR: AAL is referring to company's currency, not analytic account's one. Even though those are the same out of the box. Desired behavior after PR is merged: AAL is referring to account's currency. Effectively, nothing is affected. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Odoo now safely ignores comments placed between conditional template branches, preventing crashes when rendering affected templates. This keeps templates more tolerant of harmless comments while still blocking unsupported content between branches.
Original PR description
Before this commit, when having ```xml <t t-if=""/> <!-- Comment --> <t t-elif=""/> ``` Both python and JS crashed because business node between branching directive is not supported After this commit, Comments of that sort are just ignored and deleted from the resulting DOM
This fixes a cleanup issue in invoice document extraction where repeated screen refreshes could leave unused invisible overlay elements behind. The change keeps the page structure cleaner, helping avoid unnecessary browser overhead without changing how users interact with invoice extraction.
Original PR description
Before this commit, at each thread re-rendering a box layer is created if the uploaded file is an image. When creating the box layer, the old one is replaced by the new one but the old one is not removed from the DOM. It does not cause any functional problem as you only interact with the last created layer, so the other ones are not accessible and useless and as they are transparent they don't cause any problem. By the way, it's not a good thing to have useless DOM elements. This commit fix this problem by removing all the previously created layers from the DOM before replacing them with the newly created one.
This update corrects a small configuration mistake in the Mexican electronic invoicing screens. It helps ensure invoice information is displayed or filtered correctly, reducing confusion for users working with Mexican localization.
Features or functions removed from Odoo
This update removes outdated menu actions and an unused repair cancellation wizard from logistics-related apps. It helps keep the system cleaner and easier to maintain without changing active business workflows.
Original PR description
Migration script : odoo/upgrade#840 Related to #45188
Miscellaneous changes
Revision on https://github.com/odoo/odoo/commit/8e5b6ab02aa95c204ea7bd241e6b8944d5972d43 Intent of commit above was to remove server-side synchronization of chat windows in mobile. To do so, it prevents sending RPCs for chat window state in mobile, in addition to not automatically adapt state of chat windows in mobile from longpolling notification. This fix introduced an issue where new chats were not visible from the messaging menu of discuss app in mobile, notably after receiving ne
Original PR description
Revision on https://github.com/odoo/odoo/commit/8e5b6ab02aa95c204ea7bd241e6b8944d5972d43 Intent of commit above was to remove server-side synchronization of chat windows in mobile. To do so, it…
Revision on https://github.com/odoo/odoo/commit/8e5b6ab02aa95c204ea7bd241e6b8944d5972d43 Intent of commit above was to remove server-side synchronization of chat windows in mobile. To do so, it prevents sending RPCs for chat window state in mobile, in addition to not automatically adapt state of chat windows in mobile from longpolling notification. This fix introduced an issue where new chats were not visible from the messaging menu of discuss app in mobile, notably after receiving new messages from them. Cause of bug was that prevention of opening chat window was done by not notifying widgets from new chat in mobile, thus avoiding auto- opening of chat window as a result. However, discuss app and messaging menu were not aware of this chat neither, so this chat was not visible. This commit fixes the issue by notifying all widgets on new chat, even in mobile, while still preventing auto-opening of chat window just in mobile. Related enterprise PR: https://github.com/odoo/enterprise/pull/8687 Forward-Port-Of: odoo/odoo#46072
- At invoice creation, the stored fields that depends on `invoice_lines` are computed to be stored. This can slow down the invoice creation for a database with a lot of records on `account_move`. This commit speed-up the invoice creation by using SQL Joins to speed-up the searches. We cannot use `auto_join` on the `invoice_lines` field since it is not supported on many2many, thus we do it in SQL. -- I confirm I have signed the CLA and read the PR guidelin
Original PR description
- At invoice creation, the stored fields that depends on `invoice_lines`
are computed to be stored.
This can slow down the invoice creation for a database with a lot of
records on `account_move`.
This commit speed-up the invoice creation by using SQL Joins to
speed-up the searches.
We cannot use `auto_join` on the `invoice_lines` field since it is
not supported on many2many, thus we do it in SQL.
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#46139- Select 'capture manually' in Authorize.net Payment acquirer - Do an online transaction - Click on the Capture button at Payment transaction windows. An error message is returned: The element 'transactionRequest' in namespace 'AnetApi/xml/v1/schema/AnetApiSchema.xsd' has invalid child element 'amount' in namespace 'AnetApi/xml/v1/schema/AnetApiSchema.xsd'. List of possible elements expected: 'splitTenderId, order, lineItems...'. This because the keys `amount` and `refTransId` are
Original PR description
- Select 'capture manually' in Authorize.net Payment acquirer - Do an online transaction - Click on the Capture button at Payment transaction windows. An error message is returned: The element…
- Select 'capture manually' in Authorize.net Payment acquirer - Do an online transaction - Click on the Capture button at Payment transaction windows. An error message is returned: The element 'transactionRequest' in namespace 'AnetApi/xml/v1/schema/AnetApiSchema.xsd' has invalid child element 'amount' in namespace 'AnetApi/xml/v1/schema/AnetApiSchema.xsd'. List of possible elements expected: 'splitTenderId, order, lineItems...'. This because the keys `amount` and `refTransId` are inverted in `createTransactionRequest`: https://developer.authorize.net/api/reference/index.html#payment-transactions-capture-a-previously-authorized-amount A simple fix is to swtich them. Indeed, the Odoo 13.0 requirements is Python 3.6+, in which the keys order at iteration is the insertion order. Although this was officially part of the specification in 3.7, the change is already available in 3.6. Closes #45891 opw-2201667 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#46176
When a binary field is added to studio, the system will try to write the name to {binary_field_name}_filename: this works if the field was created with studio but could not work eg. if just a binary field is created manually. opw-2191873 Forward-Port-Of: odoo/odoo#45994
Original PR description
When a binary field is added to studio, the system will try to write the
name to {binary_field_name}_filename: this works if the field was
created with studio but could not work eg. if just a binary field is
created manually.
opw-2191873
Forward-Port-Of: odoo/odoo#45994While sending payment request to acquirer the amount used was the amout_residual_signed This amound is in the currency of the company and may be negative. The currency send to the acquirer is the currency on the invoice so you expect the amount to be in the same currency and being positive amount_residual is exactly that amount Solution: user amount_residual instead of amount_residual_signed -- I confirm I have signed the CLA and read the PR guidelines at www.
Original PR description
While sending payment request to acquirer
the amount used was the amout_residual_signed
This amound is in the currency of the company
and may be negative.
The currency send to the acquirer is the
currency on the invoice so you expect the
amount to be in the same currency and
being positive
amount_residual is exactly that amount
Solution: user amount_residual
instead of amount_residual_signed
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#46039When a write on the active field is done, we only want to synchronize this value to the locations downward. Steps to reproduce the issue: Import this file to update Stock Locations on a fresh runbot instance: id,name,location_id,usage,active,comment stock.stock_location_stock,STOCK,WH,internal,1,comment STOCK Expected: * The location "Stock" is renamed to STOCK with a comment: "comment STOCK". Before the correction: * The location "Stock" is renamed to STOCK with a
Original PR description
When a write on the active field is done, we only want to synchronize this value to the locations downward. Steps to reproduce the issue: Import this file to update Stock Locations on a fresh runbot instance: id,name,location_id,usage,active,comment stock.stock_location_stock,STOCK,WH,internal,1,comment STOCK Expected: * The location "Stock" is renamed to STOCK with a comment: "comment STOCK". Before the correction: * The location "Stock" is renamed to STOCK with a comment: "comment STOCK". * All the children locations of "Stock" are renamed to STOCK with the same comment OPW: 2188690 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#46140 Forward-Port-Of: odoo/odoo#46129
- Create a kit which contains a stockable product and a service - Create a SO with the kit, validate The service is included in the picking, while it shouldn't be. opw-2201923 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#45954
Original PR description
- Create a kit which contains a stockable product and a service - Create a SO with the kit, validate The service is included in the picking, while it shouldn't be. opw-2201923 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#45954
Steps to reproduce: - install sales - install any rtl language and set your user language to it - go to sales Previous behavior: tooltip is not positionned properly and covers the create button Current behavior: toolips align the way they are supposed to opw-2193479 Forward-Port-Of: odoo/odoo#45951
Original PR description
Steps to reproduce: - install sales - install any rtl language and set your user language to it - go to sales Previous behavior: tooltip is not positionned properly and covers the create button Current behavior: toolips align the way they are supposed to opw-2193479 Forward-Port-Of: odoo/odoo#45951
Fine-tunning of 263131f49828d2d8f2177bae15d0af84af341c37 Before this commit, when printing in safari a receipt that contains products with long names, parts of the name were overlapped. This occurs because, in safari, the library that transforms the html into text mismanages the spaces. Now, the name is printed correctly in safari, same behaviour than the others browsers. opw-2169656 Forward-Port-Of: odoo/odoo#45409
Original PR description
Fine-tunning of 263131f49828d2d8f2177bae15d0af84af341c37 Before this commit, when printing in safari a receipt that contains products with long names, parts of the name were overlapped. This occurs because, in safari, the library that transforms the html into text mismanages the spaces. Now, the name is printed correctly in safari, same behaviour than the others browsers. opw-2169656 Forward-Port-Of: odoo/odoo#45409
Before this commit: when we have 'planning_expand_employee', they are a special read group to get all employees having a slot in the past and next 30 days. But if we select a filter with start_datetime (for example 'future'), we won't search employees having a slot around the calendar week but having a slot around today. After this commit: We search employees having a slot around the calendar date even a filter is selected. Forward-Port-Of: odoo/enterprise#8740
Original PR description
Before this commit: when we have 'planning_expand_employee', they are a special read group to get all employees having a slot in the past and next 30 days. But if we select a filter with start_datetime (for example 'future'), we won't search employees having a slot around the calendar week but having a slot around today. After this commit: We search employees having a slot around the calendar date even a filter is selected. Forward-Port-Of: odoo/enterprise#8740
If an IBAN has been detected by the OCR, the bank account linked to that account number will be set on the invoice. Forward-Port-Of: odoo/enterprise#8716 Forward-Port-Of: odoo/enterprise#8212
Original PR description
If an IBAN has been detected by the OCR, the bank account linked to that account number will be set on the invoice. Forward-Port-Of: odoo/enterprise#8716 Forward-Port-Of: odoo/enterprise#8212
**Task**: https://www.odoo.com/web?#id=2170063&action=327&model=project.task&view_type=form&menu_id=4720 **Description**: This commit will fixed error, in manual transfer receipt form view, stock move lines not displayed after barcode scanned. Forward-Port-Of: odoo/enterprise#7898
Original PR description
**Task**: https://www.odoo.com/web?#id=2170063&action=327&model=project.task&view_type=form&menu_id=4720 **Description**: This commit will fixed error, in manual transfer receipt form view, stock move lines not displayed after barcode scanned. Forward-Port-Of: odoo/enterprise#7898
Go to Accounting>General Ledger, export(xaf). Stacktrace will occur because the report is not adapted to the account changes occurred in 13 opw-2196844 Forward-Port-Of: odoo/enterprise#8526
Original PR description
Go to Accounting>General Ledger, export(xaf). Stacktrace will occur because the report is not adapted to the account changes occurred in 13 opw-2196844 Forward-Port-Of: odoo/enterprise#8526
Update the balance sheet for the fiscal location 'pequeñas y medianas entidades sin fines lucrativos (PYMESFL)'. The balance sheet is now based on the Boletín oficial del estado, Núm. 85, Sec. I. Pág. 26148 of 9 April 2013. opw-2174046 Forward-Port-Of: odoo/enterprise#8508 Forward-Port-Of: odoo/enterprise#8476
Original PR description
Update the balance sheet for the fiscal location 'pequeñas y medianas entidades sin fines lucrativos (PYMESFL)'. The balance sheet is now based on the Boletín oficial del estado, Núm. 85, Sec. I. Pág. 26148 of 9 April 2013. opw-2174046 Forward-Port-Of: odoo/enterprise#8508 Forward-Port-Of: odoo/enterprise#8476
Followup of 7ec2e85734f67cde1062070c225805afe9502458 . Forward-Port-Of: odoo/enterprise#8633
Original PR description
Followup of 7ec2e85734f67cde1062070c225805afe9502458 . Forward-Port-Of: odoo/enterprise#8633
Inventory>Reporting>Forecasted Inventory Group by something other than product (i.e. Warehouse) Click on the magnifying lens in a cell Traceback will occur because frontend and backend expect to deal always with product_id, instead the supplied data when grouping is relevant to the grouping subject, so will crash the interface. Adding an error display message to inform the user of the problem. opw-2199757 Forward-Port-Of: odoo/enterprise#8656
Original PR description
Inventory>Reporting>Forecasted Inventory Group by something other than product (i.e. Warehouse) Click on the magnifying lens in a cell Traceback will occur because frontend and backend expect to deal always with product_id, instead the supplied data when grouping is relevant to the grouping subject, so will crash the interface. Adding an error display message to inform the user of the problem. opw-2199757 Forward-Port-Of: odoo/enterprise#8656
Previously, the type of the account.move wasn't set in the context, this prevented the selection of the correct journal when calling _get_default_journal. Forward-Port-Of: odoo/enterprise#8559
Original PR description
Previously, the type of the account.move wasn't set in the context, this prevented the selection of the correct journal when calling _get_default_journal. Forward-Port-Of: odoo/enterprise#8559
In case we have a batch payment for SDD in example, it would be odd to assign always the whole batch amount on each statement line, so we add an additional xpath to identify the correct amount first. Forward-Port-Of: odoo/enterprise#8552
Original PR description
In case we have a batch payment for SDD in example, it would be odd to assign always the whole batch amount on each statement line, so we add an additional xpath to identify the correct amount first. Forward-Port-Of: odoo/enterprise#8552
Task :https://www.odoo.com/web#id=2170932&action=327&model=project.task&view_type=form&menu_id=4720 Pad :https://pad.odoo.com/p/r.eacb000f7905929aacfb317ded3cbef3 Forward-Port-Of: odoo/enterprise#7796
Original PR description
Task :https://www.odoo.com/web#id=2170932&action=327&model=project.task&view_type=form&menu_id=4720 Pad :https://pad.odoo.com/p/r.eacb000f7905929aacfb317ded3cbef3 Forward-Port-Of: odoo/enterprise#7796
If a payment ref has been detected by the OCR, it will now be set on the invoice. Forward-Port-Of: odoo/enterprise#8680 Forward-Port-Of: odoo/enterprise#8275
Original PR description
If a payment ref has been detected by the OCR, it will now be set on the invoice. Forward-Port-Of: odoo/enterprise#8680 Forward-Port-Of: odoo/enterprise#8275
When the status of an OCR request is checked in background, we previously ignored any errors that would occur. This is a bad idea, as the transaction will commit even though there was an error. Forward-Port-Of: odoo/enterprise#8678 Forward-Port-Of: odoo/enterprise#8563
Original PR description
When the status of an OCR request is checked in background, we previously ignored any errors that would occur. This is a bad idea, as the transaction will commit even though there was an error. Forward-Port-Of: odoo/enterprise#8678 Forward-Port-Of: odoo/enterprise#8563