Wednesday, July 30, 2025
6 changes · 17.0
Resolved issues and error corrections
Jordanian e-invoices now automatically remove spaces, plus signs, and other non-digit characters from buyer phone numbers before submission. This helps invoices meet JoFotara validation rules and reduces failed submissions caused by common phone number formatting.
Original PR description
Strip all non-digit characters from the partner phone so that the UBL XML complies with JoFotara’s XSD which requires `^[0-9]{1,15}$`. This prevents validation errors when submitting e‑invoices.
Steps to reproduce:
- Install l10n_jo_edi
- Set partner phone to “+962 79 123 4567”
- Create & post an invoice
- Send to JoFotara
OPW-[4945688](https://www.odoo.com/odoo/my-tasks/4945688)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThe package type dropdown in delivery package details now respects the configured sequence instead of showing options by creation order. This makes warehouse workflows more predictable when users arrange package types in a preferred business order.
Original PR description
#### Step to reproduce: - Go to Inventory > Configuration > Settings and enable Packages - Go to Inventory > Configuration > Package Types - Inverse the order of two packages types. The goal is for…
#### Step to reproduce: - Go to Inventory > Configuration > Settings and enable Packages - Go to Inventory > Configuration > Package Types - Inverse the order of two packages types. The goal is for the sequence order to differ from the id order. (you can display id with studio) - Go to Inventory > Overview > Delivery Orders - Create a new delivery order - Add a line - In 'Additional Info' add a Carrier - Go to Barcode > Operations > Delivery Orders - Select the delivery order (you might need to remove filters) - With the 'Add Product' button add a product - Click on 'Put in Pack' - A 'Package Details' wizard should have opened. In this wizard there is a field 'Delivery Package Type'. #### Current behavior: - In the delivery package type dropdown list, packages are ordered by id #### Expected behavior: - In the delivery package type dropdown list, packages should be ordered by sequence #### Cause of the issue: As no order was defined, stock.package.type was ordered by id which is the default behavior opw-4824064 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Archived time off types are now hidden from employee profile views, so employees and HR teams only see active, relevant leave balances. This prevents outdated or inactive leave categories from creating confusion in the Employee app.
Original PR description
In this bug, if a time off type is archived, it is still displayed in employee app. Steps to reproduce the bug: 1- Create a database with employee and time off modules installed 2- Allocate a time off to an employee 3- Archive the time off type 4- Open Employee app and go to the employee profile 5- The archived days are still displayed opw-4900060
Expense uploads now check whether the user has a valid employee linked to the current company before creating an expense. This prevents confusing technical errors and gives users clearer guidance when their employee or company setup needs to be corrected.
Original PR description
Currently, users in the group_hr_expense_team_approver group don’t necessarily have an assigned employee. As a result, when creating an expense with a user belonging to that group but without a…
Currently, users in the group_hr_expense_team_approver group don’t necessarily have an assigned employee. As a result, when creating an expense with a user belonging to that group but without a related employee, or with an employee assigned to a different company, the expense creation proceeds from an uploaded file (via the create_expense_from_attachments method). This causes a technical ValidationError that is difficult for the user to understand, unlike the clearer error implemented in the _default_employee_id method. This change proposes handling the error similarly to _default_employee_id by adding an explicit validation in the create_expense_from_attachments method to ensure that the current user has a related employee and that the employee belongs to the current company. Otherwise, the operation is halted with a clearer message so the user can perform the necessary configurations. Screenshot of the actual ValidationError:  Screenshot of the proposed ValidationError:  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#218260
A failing automated test was corrected by aligning it with the normal sales order flow. The change removes unnecessary manual handling of invoice and delivery partner fields, letting Odoo fill them automatically, with no change to business behavior.
Original PR description
the test `test_00_inter_company_sale_purchase` was failing with the following error: `AssertionError: can't write on invisible field partner_invoice_id` The issue comes from…
the test `test_00_inter_company_sale_purchase` was failing with the following error:
`AssertionError: can't write on invisible field partner_invoice_id`
The issue comes from `_generate_draft_sale_order()`, called by the test via `generate_sale_order()`. This method uses the Form API and explicitly sets `partner_invoice_id` and `partner_shipping_id`.
However, the `Form` respects field visibility constraints. In this case, these fields were invisible at the moment we tried to assign them (since `partner_id` is processed with `onchange` after saving). This led to the `AssertionError`.
We fix this by no longer setting `partner_invoice_id` and `partner_shipping_id` manually. Setting `partner_id` is enough — Odoo will compute the correct invoice and shipping partners automatically.
This makes the test more robust and closer to the real user flow. No functional behavior is changed — the Sale Orders created by the test will remain correct.
[runbot-163187](https://runbot.odoo.com/odoo/error/163187)
Forward-Port-Of: odoo/enterprise#87531Updating employee mappings on a field service project no longer triggers automatic changes to the project's customer details. This prevents related sales order information on the project and its tasks from being unexpectedly changed.
Original PR description
Before this commit, when the user updates an employee mapping in the project form view, the partner field of the project will be recomputed to add the partner of the SOL set on the project or in the first employee mapping if no partner is set. The problem is that field is recomputed too often and will recompute the SOL field of project and tasks related to that project. This commit makes sure the compute method of partner_id field in project model is no longer recomputed when the employee mappings linked to that project is altered to avoid altering the SOL of tasks. task-4477367