Friday, March 14, 2025
28 changes
2 changes
Resolved issues and error corrections
Manufacturing workcenter costs now use the intended hourly employee cost from the workcenter setup instead of being overwritten by an employee-specific rate. This helps keep inventory valuations using average cost and FIFO methods accurate.
Original PR description
The workcenter employee cost per hour was always being replaced by the employee's individual cost per hour, impacting the valuation of AVCO and FIFO. To fix this, if the employee's cost per hour is set in the employee form and is greater than zero, we will use the value defined in the workcenter form. task: 4300974
Performance tests now allow test emails to be sent safely to a dummy server, keeping email-related checks realistic without contacting real recipients. This helps maintain confidence in appointment, knowledge, activity, and WhatsApp performance behavior after recent test-environment changes.
26 changes
Resolved issues and error corrections
Fixes a typo in the Romanian electronic invoicing workflow so failed invoice sending is recorded with the correct status. This helps ensure failed submissions are detected and handled consistently instead of being missed due to an invalid status name.
Original PR description
It should be `invoice_sending_failed`, we don't have `invoice_sent_failed` :D (for more info see `ciusro_document.py`, the `state` selection field) task-None
Fixed an issue where manufacturing orders could miss operations and byproducts tied to product options that do not create separate variants. This ensures production plans correctly reflect the selected product configuration, reducing manual corrections and production errors.
Original PR description
Steps to reproduce: - Create a Product with an attribute that 'Never' create variants, with two attributes - Create a Bom for that product that has: - 2 components, one restricted to the first variant - 2 operations, one restricted to the first variant - 2 byproducts, one restricted to the first variant - Set that product to MTO/Manufacture - Create a sale order for that product, and pick the first variant - Confirm the sale order and check the linked MO. Issue: Both the operation and byproduct set for that specific variant won't be in the Manufacturing Order, despite the variant-specific component being properly added. Since the requirements to skip the bom/operation/byproduct line is the same, regardless of the model, extract it and use it in the three `_skip` methods so we handle it in each case. opw-4636956 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Printing a delivery order for a kit no longer fails when the kit uses one unit of measure and its component uses another, such as units and kilograms. This prevents an error screen and lets warehouse users produce delivery documents as expected.
Original PR description
Steps to reproduce the bug:
- Create a storage “P1”:
- UoM: Kg
- Create a storable “Kit 1”:
- UoM: unit
- BoM:
- 1 Kg of P1
- Create a delivery order for 1 unit of Kit 1
- Mark it as to do
- Set the quantity of P1 to 1kg
- try to print
Problem:
A traceback is triggered because we try to convert 1kg to unit:
```
odoo.addons.base.models.ir_qweb.QWebException: Error while render the
template
UserError: L'unité de mesure kg définie sur la ligne de commande
n'appartient pas à la même catégorie que l'unité de mesure unités
définie sur le produit. Veuillez corriger l'unité de mesure définie
sur la ligne de commande ou sur le produit, elles doivent appartenir à
la même catégorie.
Template: stock.stock_report_delivery_has_serial_move_line
```
opw-4619140Fixes a document layout issue where invoice titles could wrap onto two lines when using the Bubble template for Indian companies. This keeps printed invoices cleaner and more professional-looking without changing invoice content.
Original PR description
### Steps to reproduce: - Install "l10n_in" and switch to an Indian company - Settings > Document Layout > Configure Document Layout and select the "Bubble" layout - Create a customer invoice and print it - The title is on two lines ### Cause: Adding a `t-field` for the journal name seems to break the layout. ### Solution: Add `text-nowrap` on the layout_document_title to force the display on one line. opw-4496715
This fix ensures manufacturing labor cost entries are posted only once when a production order is validated. It prevents duplicate accounting entries in cases where extra confirmation steps, such as overconsumption warnings, appear before final validation.
Original PR description
By overriding `button_mark_done` to post labor entries, multiples entries could be posted in case of action returned (overconsumption wizard for instance) before the actual validation. This commit change the override by `_post_inventory()` which is called only once per validation. opw: 4571535 opw: 4532096 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
Spanish TicketBAI identification now correctly treats NIE numbers starting with X, Y, or Z as freelancer IDs. This helps avoid misclassifying freelancers as companies when processing Spanish electronic invoicing data.
Original PR description
In order to determine if the vat provided is for an autonomo (freelancer) or a juridical person (company), we checked 8 digits and a letter for the freelancer, but NIEs that start with X/Y/Z are also freelancers, so we added that option in the regex. opw-4616635 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
Invoices for Spanish freelancers using TicketBAI now show a clear warning when the required epigrafe tax activity code is missing. This prevents users from reaching submission only to receive a confusing XML schema error from TicketBAAI/Bizkaia, making the issue easier to understand and resolve before sending.
Original PR description
Previously, the epigrafe validation error was only triggered for non-'is_sale' documents. As a result, invoices without a defined epigrafe failed silently until submission to TicketBAI, causing an unclear TicketBAI error.
This fix ensures that the user error appears for invoices as well, preventing the misleading "El XML no cumple el esquema" error.
Steps to reproduce:
- Set up a Spanish freelance company
- Change tax agency to Bizkaia
- Try to send an invoice
The TicketBAi error `B4_1000001: El XML no cumple el esquema.[Linea:17 Columna:5] Error:cvc-complex-type.2.4.b: The content of element 'Ingreso' is not complete. One of '{Renta}' is expected.`
opw-4559069This fix prevents access errors when opening contacts whose billing settings depend on a related commercial partner in another company. It helps multi-company users continue viewing accessible contacts without being blocked by behind-the-scenes invoice format calculations.
Original PR description
Relevant conversation: https://github.com/odoo/upgrade/pull/7113 The error happens when a partner record doesn't have a company_id, making him accessible for the user, but its commercial_partner_id…
Relevant conversation: https://github.com/odoo/upgrade/pull/7113
The error happens when a partner record doesn't have a company_id, making him accessible for the user, but its commercial_partner_id has a company_id that is different from the user's current company, causing an issue here:
https://github.com/odoo/odoo/blob/18.0/addons/account/models/partner.py#L643
```
File "/home/odoo/src/odoo/18.0/addons/account_edi_ubl_cii/models/res_partner.py", line 190, in _compute_invoice_edi_format
super()._compute_invoice_edi_format()
File "/home/odoo/src/odoo/18.0/addons/account/models/partner.py", line 643, in _compute_invoice_edi_format
if partner.commercial_partner_id.invoice_edi_format_store == 'none':
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1266, in __get__
recs._fetch_field(self)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4058, in _fetch_field
self.fetch(fnames)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4101, in fetch
raise self.env['ir.rule']._make_access_error('read', forbidden)
odoo.exceptions.AccessError: Uh-oh! Looks like you have stumbled upon some top-secret records.
Sorry, Omar Ahmed Omar Al Himyari (id=2) doesn't have 'read' access to:
- Contact (res.partner)
If you really, really need access, perhaps you can win over your friendly administrator with a batch of freshly baked cookies.
This seems to be a multi-company issue, you might be able to access the record by switching to the company: Overseas Warehouse Management.
```
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-prUsers without Time Off management rights can now search by leave name in the Time Off overview without encountering an access error. This fixes a permission issue that blocked normal overview searches for regular employees.
Original PR description
Before this commit, making a search on name in the overview of the Time Off application without Time Off rights would give an access error. To reproduce: - Connect with a user without Time Off rights (Marc Demo for example) - Go on Time Off > Overview - Make a search on the name - An access error is raised while it shouldn't This commit changes the _search_name method by removing the explicit call to `leave_id` in the domain part not restricted to officers.
This fixes a small typo that could prevent the phone validation fallback from working when the preferred import is unavailable. It helps keep phone number region detection reliable in edge cases without changing normal user workflows.
Original PR description
Before this commit, since the introduction of the `phone_get_region_data_for_number` function (2d027ad), there was a fallback in case the import failed. However, the fallback method had an incorrect name.
Fixed an issue where POS session reports could show the counted card payment amount incorrectly after closing adjustments. This ensures business users see accurate expected versus counted payment totals when reviewing register sessions.
Original PR description
- In POS, open a register and add Product A with a price of 100. Proceed with the payment using a card. - Close the register, increase the cash count by 20, and reduce the card count to 80. In the…
- In POS, open a register and add Product A with a price of 100. Proceed with the payment using a card. - Close the register, increase the cash count by 20, and reduce the card count to 80. In the session report, the difference in the card payment is not displayed correctly. It shows the expected amount as 100 and the counted amount as 100, whereas it should be expected at 100 and counted at 80. Commit https://github.com/odoo/odoo/commit/01b87f1230beac0568f4e3b1b76e547909506892#diff-143d17de807d23650088a8c12f0a5b5cc2246b1b51e0bb7634e85247b6e535ea made journal entry optional for payments and removed the `synchronize_from_moves` method from `account_payment`. This mean that there is no longer a synchronization between account_payment and its potential journal entries. The source (here pos_session) is now responsible for creating and linking the moves to the payment. The amount field of account_payment, which is used to construct the session report and created in `_create_combine_account_payment` was not updated with the new balance created in `_apply_diff_on_account_payment_move`. opw-4494656 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an export error that could occur when users exported fields from grouped lists, such as Lots / Serial Numbers grouped by Location. The export process now passes the expected field information correctly, preventing a traceback and allowing the export to complete.
Original PR description
**Problem**: When exporting, the field dictionary is expected to have a `type` key. However, when adding `parent_field`, the `type` value is stored in `field_type` instead of `type`, causing issues. **Solution**: Ensure that `parent_field` creates a `type` key in the dictionary. **Steps to Reproduce**: 1. Go to **"Lots / Serial Numbers"**. 2. Group by **"Location"** (or any other field). 3. Select any item from the list. 4. Open the **Export** modal. 5. In the modal: - Add **"Product/External IDs"** to the fields to export. - Click **Export**. 6. **Issue**: A traceback occurs. **opw-4563055** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Event follow-up emails set to go out after registration were previously delayed until after the event had started. This fix ensures those messages are sent at the intended time, improving communication with attendees.
Original PR description
Until now, the after_sub are only sent after the start of the event
This fixes a point-of-sale loyalty issue where changing a product quantity in a specific way could fail to update the number of free products. The correction helps ensure loyalty rewards are calculated consistently during checkout.
Original PR description
This commit fixes an undeterministic behavior error in POS. Changing the number of products with "⌫", "8" does not recalculate the number of free products. To recalculate, you must type "⌫", "⌫", "1", "8". 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
Branch company users can now find and select products assigned to their parent company when using Barcode inventory counts. This fixes a product lookup issue that blocked inventory adjustments in multi-company branch setups.
Original PR description
Issue ===== When logged in a branch company, it is not possible, in the Barcode app inventory adjustment, to select a product with its `company_id` set on the parent company. How to reproduce ================ 1. Create a branch company; 2. Create a product and set its company field on parent company; 3. Select the branch company as the current user company; 4. Go to Barcode > Inventory Count > Add Product; 5. In the product field, search the parent company's product -> Nothing found. Cause of the issue ================== There was a domain on the `product_id` field who restrain products only to the current company (both for quants and stock move line.) [OPW-4603831](https://www.odoo.com/odoo/project/49/tasks/4603831)
Fixed an issue that prevented users from scanning lot numbers from the barcode kanban view. This ensures inventory teams can identify and process tracked products correctly even when lots are not tied to a specific company.
Original PR description
It doensn't work to scan a lot in the kanban view of stock.barcode. It's not recognize since the company_id is not required on the lot since 18.0 but the domain was not adapt and expect it. opw-4626206
Documents created inside a company-specific folder now automatically use that same company, restoring the expected behavior. When a folder's company is changed, the update is also applied to accessible child documents so company ownership stays consistent.
Original PR description
Documents created in a company folder should by default be assigned to the same company, as it was before sharepocalypse. Editing a folder company should then propagate to the accessible children. Task-4491333
Users working in a child company can now open the General Ledger without being blocked by access errors tied to the parent company. This improves day-to-day accounting access in multi-company and multi-branch setups for non-admin users.
Original PR description
Use case: -Create a parent company and a child company. -Create two journals, assigning one to each company. -Connect with a normal user (not an admin, I connected with marc demo) after adding both companies to their allowed companies list. -activate the child company, and attempt to access the General Ledger. --> there is an access right error raised because the user doesn't have access to the parent company. ticket - 4577222
Fully discounted invoices using external tax services can still require tax, but the related accounting tax lines were sometimes missing. This fix creates the needed tax lines so journal entries better match the externally calculated tax amount and invoice total.
Original PR description
Tax lines are not created in cases where Odoo expects them to be $0 [1]. This is problematic for cases where tax is computed externally and the tax is not in fact $0. There is now no tax line to…
Tax lines are not created in cases where Odoo expects them to be $0 [1]. This is problematic for cases where tax is computed externally and the tax is not in fact $0. There is now no tax line to adjust to the right amount. To reproduce: 1. Configure Avatax 2. Configure the Discount product to have the "Non-taxable product" Avatax category 2. Create an invoice to Azure Interior 3. Select the Avatax fiscal position 3. Add 1 FURN_6667 with default unit price $295 4. Add 1 Discount with unit price -$295 5. Click "Compute Taxes" The invoice is fully discounted but $30.24 tax must still be paid. This is correct. It's reflected in the invoice total, but the tax lines are not in the journal items. `_set_external_taxes()` goes through the summary to set the right tax amounts, but cannot find the line. We handle this case by manually creating the omitted tax lines. This is only a rough approximation but should hopefully be enough to handle these special cases. opw-4493544 [1] https://github.com/odoo/odoo/blob/9201c60f6a3a9ab6546f190cec0293eea273ce60/addons/account/models/account_tax.py#L2405-L2413 ## PR note Alternative to https://github.com/odoo/enterprise/pull/80097.
The barcode app no longer shows the Sign button when working with batch delivery orders, because batch pickings cannot be signed. This prevents users from hitting an error during validation and keeps the workflow clear.
Original PR description
Steps to reproduce the bug: - Enable “Signature” option in inventory settings - Go to barcode → delivery orders > batch: - select any batch: - settings: - Operations > sign: - Sign and validate Problem: A traceback is triggered: “ValueError: Invalid field 'signature' on model 'stock.picking.batch'” Solution: It is not possible to sign a batch picking, so the button should not displayed. opw-4610471
This fixes an issue where paying multiple invoices by SEPA direct debit could create separate payments instead of one grouped payment. Keeping eligible payments grouped helps avoid unnecessary bank transaction fees and preserves the user’s chosen payment option.
Original PR description
…sepa Steps to reproduce: - have EU loca (l10n_be) - activate sepa - activate a mandate for a customer - create two invoices for this customer - in invoice list view, select the two invoices > click on pay > select sepa and group payment > create payments Issue: Two separate payments are being created, which significantly increases transaction fees. Cause: A write operation on line_ids triggers a chain of computations that deactivates group_payment. Solution: To minimize unnecessary writes, we prevent modifications when wizard.line_ids.partner_id consists of partners with valid mandates. Additionally, we explicitly include the current group_payment state in the write operation. This ensures that if multiple partners are selected—some with valid mandates and some without—the group payment setting remains correctly applied. opw-4551825
This fixes an error that could stop users from validating UK BACS Direct Debit Instructions. The change updates the accounting lookup to use the correct stored payment information, restoring the expected workflow for BACS direct debit setup.
Original PR description
### Steps to reproduce: - install "l10n_uk_bacs" - Go to Accounting > Customers > BACS Direct Debit Instruction and create a new one - Fill necessary values and validate - Traceback ### Cause: This [commit](https://github.com/odoo/enterprise/commit/54965c8d62301ba1fa8409709a1a1fd77150f722#diff-e00ec661d761679265d152ef44c96f9f1bb896e7dc148ea8ad7ce94cd3c28e11) changed the field `bacs_ddi_id` in `account.move` to a computed field and moved the storage to `account.payment`. But it did not change `_compute_from_moves` which was using SQL queries with `move.bacs_ddi_id`. So the method crashes because the table account_move does not have a column named bacs_ddi_id anymore. ### Solution: Adapt the SQL queries to use `payment.bacs_ddi_id`. opw-4593098
Commission report details now include sales that do not have a sales team, such as many POS sales, so salesperson commissions are visible consistently. Team-based commission calculations for subscriptions were also corrected to better reflect the right salespeople and teams.
Original PR description
Sales made without a team (like in POS by default) did not show up in the commission report "details". This commit backports the change made in later versions. **Steps to reproduce** - Create a commission plan for a Salesperson. - Create an invoice from a sale in POS. - The commission appears in the `sale.commission.report`, but not in the details (`sale.commission.achievement.report`) if there are other invoices for that period with a team set. opw-4488615
The Colombian reports now correctly expand all report lines when users choose the unfold all option. This prevents missing detail in reports and makes it easier for users to review complete Colombian reporting data.
Original PR description
The unfold all options wasn't working correctly in the colombian reports since we added the line, and we only checked if the line was unfolded manually. Now we also check if the unfold all options is activated opw-4621274
Service sale confirmations can now create project documents correctly in multi-company setups, even when a shared documents folder is linked to another company's website. This avoids blocking sales order confirmation with an access error during automated project setup.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Have a second company & select it; 2. create a project w/out `company_id`; 3. set its documents folder to "Projects"; 4. create a service product that creates…
Versions -------- - 18.0+ Steps ----- 1. Have a second company & select it; 2. create a project w/out `company_id`; 3. set its documents folder to "Projects"; 4. create a service product that creates a project on confirm; 5. set created project as its project template; 6. add service product to a quotation; 7. confirm quotation. Issue ----- Access Error. Cause ----- Commit ac051d00e96c added a constraint on the `website_id` of documents: - OR the document's `company_id` has to match the website's `company_id`; - OR the website's `company_id` has to be in `self.env.companies`. The Projects folder was created without `website_id`, but was assigned company 1's website by the `_compute_website_id` method. When a document gets created by the sale order, it inherits the `website_id` of the Projects folder. Hence having a shared folder between companies can lead to access errors if the website's `company_id` isn't selected in the company selector. Solution -------- Bypass the constraint when in sudo mode, so you don't have to enable the website's company in the company selector when setting up a sale order. opw-4548619
The signing workflow now waits for document pages using the correct page area, preventing an automated HR contract signing check from crashing. This improves reliability for sign-related HR contract processes without changing user-facing functionality.
Original PR description
In this commit, we fix the following error that can occurs in tour hr_contract_salary_tour_hr_sign.
```
AssertionError: The test code "odoo.startTour('hr_contract_salary_tour_
hr_sign', {"stepDelay": 0, "keepWatchBrowser": false, "debug": false,
"startUrl": "/", "delayToCheckUndeterminisms": 0})" failed
UncaughtTypeError: Cannot read properties of null
(reading 'querySelector')
```