Wednesday, April 24, 2024
34 changes
Resolved issues and error corrections
This fix resolves a test failure in the Manufacturing Accounting module that occurred when running tests without demo data. The test was unable to properly validate user access permissions because a required field wasn't visible. The fix enables the necessary product variant settings for the test user, ensuring the test runs successfully in all environments.
Original PR description
The test needs to set `product_id` field in order to check user's access. However, the field is not visible without enabling product variants, which makes the test fail in an environment with no demo data. This commit fixes the issue by adding the MRP manager to the 'product.group_product_variant' group. The issue was introduced in #162107 . Related build error: https://runbot.odoo.com/web#id=61998&cids=1&menu_id=405&action=573&model=runbot.build.error&view_type=form 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#162814
This fix prevents the system from overriding custom reconciliation settings that customers have configured on their accounts during database upgrades. Previously, the upgrade process would reset these settings and cause errors when accounts had pending partial reconciliations, disrupting the upgrade process. Now, custom settings are preserved, ensuring smooth upgrades without data conflicts.
Original PR description
In some databases, customers have changed the `reconcile` value of an account from its standard `False` value to `True`. This action causes related journal items, which are partially reconciled, to raise the following constraint error. during the upgrade process: ``` You cannot switch an account to prevent the reconciliation if some partial reconciliations are still pending ``` so we delete changes in the `reconcile` values from the reload to avoid overriding user customer setting & triggering the constraint error. 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#160086
This fix corrects a bug in the delivery/shipping module where free shipping thresholds set for fixed-price providers were incorrectly still being applied when users switched to rule-based pricing. The fix ensures that rule-based shipping methods ignore these thresholds while keeping the data intact in the system.
Original PR description
Problem: when configuring a provider (from the form view) in shipping methods, after: * setting the provider to "Fixed Price" * setting the free_over / amount field * changing the provider to "Based on Rules" the free_over / amount still applies even though the field becomes hidden. Desired behavior after: When the provider is "Based on Rules", ignore the `free_over` / `amount` if it is set (but don't unset it, still hide it in the view). opw-3852858 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160975
This fix prevents the system from crashing when users upload image files (like WEBP or SVG) with incorrect file extensions (JPG or PNG). The system now properly detects mismatched file types and handles them gracefully with a user-friendly error message instead of a technical failure.
Original PR description
Uploading a WEBP or SVG file disguised with a proper file extension (JPG, PNG) will cause a traceback because img.image is not populated when there is an empty source, SVG, or WEBP file uploaded as…
Uploading a WEBP or SVG file disguised with a proper file extension (JPG, PNG) will cause a traceback because img.image is not populated when there is an empty source, SVG, or WEBP file uploaded as this code should not be reached with these file types. The reason this occurs is because we check for the file extension when deciding to post process an image, but when we get to initializing the ImageProcess object, we then check the actual file structure to verify the type of file. This is a workaround for the time being, but should not be a final solution in future versions. Adding a null check on img.image in the _postprocess_contents method in order to avoid attempting to access the size of this image when it is null. Raises a user error in order to trigger the catch and exit the code while logging the error and 'Post processing ignored:'. opw-3672250 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156209
This fix addresses an oversight in the zeep client tool that was preventing Spanish EDI (Electronic Data Interchange) services from properly configuring test environments. The Spanish invoicing module requires access to binding options when connecting to the SII service, which was missing. This fix restores that functionality so companies can correctly switch between production and test environments for their electronic invoicing.
Original PR description
`l10n_es_edi_sii` requires `Client.bind` as well as `_binding_options` in the service returned by this `bind` call.
```py
serv = client.bind('siiService', service_name)
if company.l10n_es_edi_test_env and connection_vals.get('test_url'):
serv._binding_options['address'] = connection_vals['test_url']
```
Can be tested with a external l1On unit test,
tested only in nightly builds,
not by regular runbot builds / mergebot.
`--test-tags=external_l10n:TestEdiWebServices`
opw-3888257
opw-3888559
opw-3888155
opw-3890269
opw-3889683
Manual forward port of odoo/odoo#163119 to expedite the merge as quick as possible.This fix corrects a bug where unbuild orders were creating incorrect inventory movements when the actual quantity produced in a manufacturing order differed from the planned quantity. Specifically, when more items were produced than expected, an extra unintended inventory movement was being generated. This ensures accurate inventory tracking when reversing manufacturing orders.
Original PR description
When the Manufacturing Order 'qty_produced' is different from the 'product_qty' (we produced more or less than expected), then unbuild order had the wrong quantity for the finished product, and if 'mo_id.qty_produced > mo_id.product_qty', then an extra confirmed move was generated upon the validation of the unbuild order. --- FYI: note that in `mrp_unbuild.py` at line 245, there is almost the same function, and the factor uses `qty_produced` instead of `product_qty`, so this PR mostly synchronize the logic. --- OPW-3860612
When archiving a company branch, all of its sub-branches are now automatically archived as well. This prevents configuration issues where inactive parent branches leave orphaned child branches, which was causing features like the tax report closing entry button to become disabled unexpectedly.
Original PR description
Original issue: 1) Create a company "main", with 2 branches: "A" and "B" 2) Create a sub-branch for "A": "A1" 3) Archive company A 4) In the company selector, make "main" the active company. It will…
Original issue:
1) Create a company "main", with 2 branches: "A" and "B" 2) Create a sub-branch for "A": "A1"
3) Archive company A
4) In the company selector, make "main" the active company. It will auto-select branch B as well. 5) Open the tax report, and try clicking the "Closing Entry" button ==> The button is disabled ; it shouldn't be.
This happens because Odoo considers the full hierachy of branches to submit together is not selected. The problem originates in the way _get_branches_with_same_vat searches for sub-branches, doing
self.env['res.company'].sudo().search([('id', 'child_of', current.root_id.ids)])
In our example, this search will return main, B and A1. We then compare that with the company selector, which only contains main and B.
This configuration of companies does not make sense functionally speaking, as a branch whose parent is inactive will not be usable anyway. Therefore, we now archive all the sub-branches when archiving a company.
opw-3877368
task-3878070
Forward-Port-Of: odoo/odoo#162638This update upgrades the XRechnung electronic invoice standard from version 2.x to version 3.0.1 in Odoo's accounting module. Previously, invoices generated in XRechnung format would trigger validation warnings when submitted to official German validation services. This fix ensures invoices now comply with the latest standard requirements and pass validation without warnings.
Original PR description
Before this fix, any XRechnung xml will raise a warning when being submitted on https://erechnungsvalidator.service-bw.de/. The warning states: "[BR-DE-21] Das Element "Specification identifier" (BT-24) soll syntaktisch der Kennung des Standards XRechnung entsprechen." This is because the version 3.0.1 has been released. issue-160644 Forward-Port-Of: odoo/odoo#162187
This fix ensures that when creating cut-off journal entries from vendor bills that include vehicles, the vehicle information is properly retained in the generated journal items. Previously, the vehicle ID was being lost during the cut-off process, which could cause tracking and reporting issues for fleet-related expenses.
Original PR description
Create a Vendor Bill Add on the invoice line a vehicle Confirm In "Journal Items" tab hit 'Cut-Off' Fill the necessary info and create journal items Issue: Created journal items will not have the vehicle id opw-3802919 Forward-Port-Of: odoo/odoo#162914 Forward-Port-Of: odoo/odoo#159434