Friday, May 31, 2024
18 changes · 17.0
Resolved issues and error corrections
This fix prevents an error that could occur when users add or edit a “Pick From” entry in the Detailed Operations list during inventory receipt returns. It avoids a confusing crash and keeps warehouse return workflows running smoothly.
Original PR description
Currently, an error occurs when creating a stock quant (Pick From) in the 'Detailed Operations' list view. Step to produce: - Install the 'stock' module. - Go to Inventory / Operations / Transfers /…
Currently, an error occurs when creating a stock quant (Pick From) in the 'Detailed Operations' list view. Step to produce: - Install the 'stock' module. - Go to Inventory / Operations / Transfers / Receipts and create a receipt, add 'Receive From', and also add 'Product' and 'Demand' in Operations. - Click on 'Validate' then click on 'Return', and open 'Detailed Operations'. - Now try to create a new stock quant (Pick From) from a list view. ```ValueError: Wrong container value 'WH/Stock'``` An error occurs when attempting to create or edit a 'picked'(Pick From) in the list view of 'Detailed Operations' and the system raises a value error at [1] as 'product_id takes a string instead of an integer' in default values. link[1]: https://github.com/odoo/odoo/blob/259cba71690c500c335a4a2c43e4c606697bc817/odoo/fields.py#L3582-L3583 To resolve the issue, restricted to creating a stock quant from the 'Detailed Operations' list view sentry-5089715517 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix makes the transporter document number and date field visible when the transport mode is set to By Road. It helps users enter required e-waybill shipment details without confusion from labels appearing while the actual input field is hidden.
Original PR description
Before this commit: The label for Transporter Doc Number and Date was visible but the field was seemed to be hidden After this commit: We fix the above issue, now the field is visible when the mode is selected to `By Road` task-3959862 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
The PDF quote builder now avoids trying to fill form fields in malformed PDFs generated by Google Sheets. This prevents an error during PDF merging and lets users continue creating quotes with those files.
Original PR description
Currently, when trying to merge a PDF generated from Google sheet in the PDF quote builder, a traceback happens due to a known problem in older versions of pypdf2. This was fixed in pypdf2 2.4.2 (see: https://github.com/py-pdf/pypdf/commit/02c601c86819578d9796479a1b8953accefea92b ) It doesn't seem to happen with other editors, and google sheet doesn't allow the use of form fields anyway.
This fix prevents an error when users create a stock move line and change the source stock quantity before the related stock move exists. It keeps warehouse operations smoother by using information already available on the line instead of relying on a record that has not been created yet.
Original PR description
Before PR: when creating a SML and changing the quant_id (pick from), you get a traceback as the stock_move is not yet created After PR: Since the issue appears before the real creation of the SML (and thus the SM), reading the uom of the product directly from the SML should not pose any issue opw-3931980 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The payment registration screen no longer shows a payment difference when the difference exactly matches an early payment discount. This avoids confusion for users and treats the payment as fully reconciled in that situation.
Original PR description
When the Payment Difference amount equals Early Payment Discount, Don't show the payment difference field and consider full reconciliation. task-3944830 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Spreadsheet pivot formulas now display a blank value instead of FALSE when a filtered pivot has no matching records. This prevents confusing results in spreadsheets and better matches expected business reporting behavior.
Original PR description
## Description: Previously, when entering a pivot and applying a filter domain, the pivot formula (without domain field and domain value in function parameter) would return 'FALSE' if it did not match any records. The code now checks the value and returns an empty string if it's 'FALSE'. Task - [3888401](https://www.odoo.com/web#id=3888401&cids=2&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Swedish customer and company addresses now display in the correct local order, with postal code before city and country shown last. This improves address accuracy on documents, labels, and customer records for Sweden.
Original PR description
[FIX] Correcting the address format for Sweden. The format should be like this: %(street)s %(street2)s %(zip)s %(city)s %(country_name)s
The accounting dashboard now shows miscellaneous bank entries in the bank journal's own currency instead of the company's currency. This prevents misleading balances for companies using journals in different currencies and improves confidence in dashboard figures.
Original PR description
Steps - Create a bank journal in a different currency than company's currency. - Make a misc entry in the default bank account used by the bank journal. - Misc amount displayed for the journal in the accounting dashboard shows the amount in company's currency. Fix Display the misc amount in the journal's currency instead of the company's currency. opw-3767010
This update fixes a test in the Mexican electronic invoicing module that was incorrectly configured with an external dependency. The test date was corrected to prevent errors and ensure the test properly validates the invoice locking functionality without unnecessary external dependencies.
Original PR description
It makes no sense to have this test working with external since we're not checking CFDI content. Plus we fix the date to avoid errors. task-no
Miscellaneous changes
Description of the issue/feature this PR addresses: Before this fix, It was not possible to issue a credit note code 61 to be applied to an invoice of type '46' when the vendor was foreign. Typically, credit notes for foreign vendors are code 112; however, code 61 is necessary to reverse a type 46 invoice. After this PR: In the validation included in this PR, we allow this credit note type 61, provided there is a reference to a code '46' invoice, included in the document reference model.
Original PR description
Description of the issue/feature this PR addresses: Before this fix, It was not possible to issue a credit note code 61 to be applied to an invoice of type '46' when the vendor was foreign. Typically, credit notes for foreign vendors are code 112; however, code 61 is necessary to reverse a type 46 invoice. After this PR: In the validation included in this PR, we allow this credit note type 61, provided there is a reference to a code '46' invoice, included in the document reference model. This PR corresponds to the odoo/enterprise PR enabling the issuance of type 46 invoices referenced below: this PR replaces: https://github.com/odoo/odoo/pull/166400 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166793
## Description On firefox, when posting a message from the full composer with a template with some modifs, the browser falls into an infinite loop of processing events `selectionchange` in a loop ad-infinitum. When processing the `_onSelectionChange` handle, `_fixSelectionOnEditableRoot` has an assertion that the cursor would be placed on another place than the editable root. But after inlining, the cursor is collapsed in the beginning of the composer, and when normalizing the selection via `g
Original PR description
## Description On firefox, when posting a message from the full composer with a template with some modifs, the browser falls into an infinite loop of processing events `selectionchange` in a loop…
## Description On firefox, when posting a message from the full composer with a template with some modifs, the browser falls into an infinite loop of processing events `selectionchange` in a loop ad-infinitum. When processing the `_onSelectionChange` handle, `_fixSelectionOnEditableRoot` has an assertion that the cursor would be placed on another place than the editable root. But after inlining, the cursor is collapsed in the beginning of the composer, and when normalizing the selection via `getNormalizedCursorPosition` in `setSelection`, the cursor is back in the editable root because it is not editable anymore, which violate the previous assertion. Instead of fixing `setSelection`, as it's too risky for a stable patch, we enforce the assertion of `_fixSelectionOnEditableRoot` to return early if we are not on the editable root. ## Reference opw-3950957 PS: special thanks to (nby) and (dmo) for the help :) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167226
To handle some advanced taxes setups, we changed the behavior of the 'Update taxes' so that it would recompute the prices before recomputing the taxes, but some business do not expect that recomputation, despite modifying the taxes. The businesses needing the prices recomputation will have to trigger it manually, and shouldn't rely on the Update Taxes button for that. Introduced by 537df32897494f94962637bd2b45d2618ff83e7c opw-3953806 --- I confirm I have signed the CLA and read th
Original PR description
To handle some advanced taxes setups, we changed the behavior of the 'Update taxes' so that it would recompute the prices before recomputing the taxes, but some business do not expect that recomputation, despite modifying the taxes. The businesses needing the prices recomputation will have to trigger it manually, and shouldn't rely on the Update Taxes button for that. Introduced by 537df32897494f94962637bd2b45d2618ff83e7c opw-3953806 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167321
Removed odoo domain from blacklist, so that emails from odoo.com can be used for enrichment for demo/testing purposes. Task-3939876 Forward-Port-Of: odoo/odoo#166239
Original PR description
Removed odoo domain from blacklist, so that emails from odoo.com can be used for enrichment for demo/testing purposes. Task-3939876 Forward-Port-Of: odoo/odoo#166239
Mailing Trace are available to every base.group_user but it is too wide. No current use case justify it. task-3906727 Forward-Port-Of: odoo/odoo#165803
Original PR description
Mailing Trace are available to every base.group_user but it is too wide. No current use case justify it. task-3906727 Forward-Port-Of: odoo/odoo#165803
When a "we-list" button, like the "add item" button, is clicked while a list input is focused, the click event doesn't trigger. Steps to reproduce the bug: - Drag and drop a "Form" snippet onto the page. - Click on the "+ Field" in the options. - Select "Multiple Checkboxes" for the "Type" option of the field. - Rename "Option 1" to "ABC" in the Checkbox list. - Click directly on the "Add new Checkbox" button. - Bug: nothing happens. The new checkbox is not added to the list. This
Original PR description
When a "we-list" button, like the "add item" button, is clicked while a list input is focused, the click event doesn't trigger. Steps to reproduce the bug: - Drag and drop a "Form" snippet onto the page. - Click on the "+ Field" in the options. - Select "Multiple Checkboxes" for the "Type" option of the field. - Rename "Option 1" to "ABC" in the Checkbox list. - Click directly on the "Add new Checkbox" button. - Bug: nothing happens. The new checkbox is not added to the list. This bug arises because when clicking the button, the "change" event of the input is triggered first before the "click" event of the button. Since the "change" event refreshes the widget, the "click" event is lost. This commit adds a "setTimeout" in the "change" event handler to prioritize "click" events within the "we-list". task-3859207 Forward-Port-Of: odoo/odoo#163952 Forward-Port-Of: odoo/odoo#161506
Backport of https://github.com/odoo/odoo/commit/225d52559e693728f72ca1f00302f69c7901361e \+ add Test. Previously, when following those steps: - create SO with one line with a tax - create a down payment for 30% - remove tax on invoice line - post invoice - create new down payment for 30% A line with 0 amount and no tax was created in addition of other lines. This because, during the calculation of the down payment lines, and the ventilation between all taxes, it would take the line w
Original PR description
Backport of https://github.com/odoo/odoo/commit/225d52559e693728f72ca1f00302f69c7901361e \+ add Test. Previously, when following those steps: - create SO with one line with a tax - create a down payment for 30% - remove tax on invoice line - post invoice - create new down payment for 30% A line with 0 amount and no tax was created in addition of other lines. This because, during the calculation of the down payment lines, and the ventilation between all taxes, it would take the line with no tax into account. Note in this example we remove the tax from the invoice, but it would be the same if we changed the tax for another one. This is done by excluding the down payment lines. This should already have been the case before, but had no real effect because their quantity & price_subtotal = 0. Forward-Port-Of: odoo/odoo#166688 Forward-Port-Of: odoo/odoo#166520
Since python 3.11, the patch.dict method changed [0] to use pkgutil to resolve names. This new method is not able to patch our `odoo.tools.config.options`. Fixed by using the object instead of a string literal. [0]: python/cpython@ab7fcc8fbdc11091370deeb000a787fb02f9b13d Forward-Port-Of: odoo/odoo#167306
Original PR description
Since python 3.11, the patch.dict method changed [0] to use pkgutil to resolve names. This new method is not able to patch our `odoo.tools.config.options`. Fixed by using the object instead of a string literal. [0]: python/cpython@ab7fcc8fbdc11091370deeb000a787fb02f9b13d Forward-Port-Of: odoo/odoo#167306
The test web:TestImage.test_04_web_content_filename_secure is failing on the runbot for the version 16 (16.0, saas-16.3 and saas-16.4). The error is 'str' object has no attribute 'removeprefix' and this method has been introduced in python 3.9 while version 16 only support python 3.7. To solve the problem we replace that method call with a supported equivalent in python 3.7. Task-3944583 Forward-Port-Of: odoo/odoo#167303
Original PR description
The test web:TestImage.test_04_web_content_filename_secure is failing on the runbot for the version 16 (16.0, saas-16.3 and saas-16.4). The error is 'str' object has no attribute 'removeprefix' and this method has been introduced in python 3.9 while version 16 only support python 3.7. To solve the problem we replace that method call with a supported equivalent in python 3.7. Task-3944583 Forward-Port-Of: odoo/odoo#167303