Thursday, May 15, 2025
21 changes · 17.0
New functionality added to Odoo
The Swiss localization now includes two additional accounting entries for managing 13th month salary provisions. This helps businesses track these payroll-related provisions more accurately in their chart of accounts.
Original PR description
For proper provision management we introduce accounts 2350 and 2351 task-4797323
Enhancements to existing features
Self-billed invoices sent through Malaysia e-invoicing now use the supplier bill reference when it is available, instead of always using Odoo’s internal bill name. This helps align submitted invoice identifiers with supplier-provided numbers and reduces platform submission issues.
Original PR description
Fixes an issue when issuing self-billed invoices to the platform. So far we have been using Odoo's bill name as ID, but we should instead use the bill reference (if set) to use the supplier number. task-4777585 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
The Peppol status footer in email templates was updated with clearer wording and more compatible colors. Tracking was also removed, making the footer simpler and less intrusive for recipients.
Original PR description
Better phrasing, better compatilibity of the colors. Removal of tracking. task-4782004
Miscellaneous changes
Some services or applications (Outlook, Google Messages) display previews of links sent through messages or email. In an effort to strengten user privacy, these services fetch the previews from their own servers rather than from the user's device. Since these services' requests had not been added to the list of known bot identifiers, they generate parasite "clicks" which don't match their user. This commit adds identifiers for the Outlook and Google Messages service requests to the l
Original PR description
Some services or applications (Outlook, Google Messages) display previews of links sent through messages or email. In an effort to strengten user privacy, these services fetch the previews from their own servers rather than from the user's device. Since these services' requests had not been added to the list of known bot identifiers, they generate parasite "clicks" which don't match their user. This commit adds identifiers for the Outlook and Google Messages service requests to the list of known bot IDs, thereby preventing the parasite clicks from generating. task-3672491 Forward-Port-Of: odoo/odoo#167799
This fixes a rounding issue that could slightly understate working hours for employees with shifts crossing midnight. Payslips now show cleaner, accurate hour totals instead of fractional values caused by tiny time-calculation differences.
Original PR description
To reproduce: ============= - have an employee with a working schedule of night shifts like 18:00 to 00:00 break to 01:00 then continue to 03:00 - create payslip for this employee for January 2025 - print the payslip, the working hours will be 183.9936 The problem: ============ 00:00 is represented as 23:59:59.99999 in python, that missing microsecond impacts the computation of the duration of the work entry. The solution: ============= round the total seconds opw-4702410 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix makes Jordanian electronic invoicing handle incomplete draft data more safely during automated checks. It reduces the risk of avoidable crashes in internal validation scenarios without changing normal invoicing behavior for users.
Original PR description
Ensure `_get_payment_method_code` and invoice name handling in `_export_invoice_vals` work safely with incomplete records during this test `test_computed_fields_without_dependencies`. This test creates unsaved records where required fields like `company_id.l10n_jo_edi_taxpayer_type` and `invoice.name` are missing they are intialized in module testsuite . Attempting to access these directly led to a `KeyError` (due to missing taxpayer type) and an `AttributeError` when calling `.replace()` on a boolean. These failures do not occur in the module test suite because records are fully populated, but for test robustness and future-proofing, we now handle missing or falsy values gracefully. build_error-161152
The payment page now keeps the QR code area from shrinking when a payment message contains a very long line. This prevents cropped QR codes, helping customers complete payments reliably.
Original PR description
__Current behavior before commit:__ The QR code on the payment page is cropped when the Pending Message of the payment provider has a long line. __Description of the fix:__ Set `flex-shrink-0` to the QR code card so it doesn't shrink. __Steps to show the cropped QR code:__ 1. Install sale_management and website 2. Set company currency to EUR 3. Enable QR Codes under Customer Payments in Settings 4. Enable Online Payment (and disable Online Signature) under Quotations & Orders 5. In Payment Providers, install SEPA Direct Debit. Select Test mode, check Enable QR Codes, and publish it. 6. **In Messages tab, put a very long line as Pending Message** 7. Go to the Journal "Bank" and set a random IBAN as Account number 8. Create a new Quote with a non 0 price and click on Preview and pay the order 9. The QR code is cropped opw-4735003
Shared project Kanban views now show different progress bar colors for tasks in Done and Approved stages. This makes it easier for portal users to quickly understand task status when viewing shared projects.
Original PR description
### Issue
In project sharing, tasks in the "Done" and "Approved" stages were not shown with distinct progress in the Kanban progress bar. As a result, users were unable to identify the task status easily.
### Reason:
The color class was set incorrectly.
### Fix:
We have updated the color class in this commit to correctly reflect the task stages.
issue-https://github.com/odoo/odoo/commit/1a44b849970d3e39111a99ea35db5b586b184dd3
### Steps to Reproduce:
- Create a project with 2 tasks:
- Task 1 in the "Done" stage
- Task 2 in the "Approved" stage
- Share the project with a portal user
- Open the project in the portal
- Navigate to the project sharing Kanban view and check the progress bar
task-4551177Automated actions now have access to the dynamic date and context values they need when checking their conditions. This prevents rules that depend on values like today's date from failing or behaving incorrectly, improving reliability for scheduled and automated business processes.
Original PR description
Similar to: odoo/odoo#204172 This commit makes sure base.automation evaluated domains have all the dynamic elements they need, such as `context_today`, which is defined in `py_builtin.js` and dynamically retrieves the current date. Task id: opw-4737292
The Swiss payroll configuration menu has been restored so payroll administrators can access salary journal settings and rule parameters again. This helps ensure required payroll setup options are available without workarounds.
Original PR description
To be able to configure salary journals and access rule parameters, we reintroduce back the salary menu in configuration
The Spanish Mod 347 BOE export no longer includes partners who only have cash payments below the reporting threshold. This prevents misleading zero-value lines in the tax file and helps businesses submit cleaner, more accurate reports.
Original PR description
Fix a bug where account moves paid with cash appears in a line with full 0 in the boe export of mod347 tax report. But it shouldn't create a line at all, so this commit remove the lines in this case. task-4613012
This update disables or adjusts failing automated checks related to bank statement imports and expense extraction. It helps keep the development validation process stable while the affected tests are reviewed, with no direct change expected for end users.
**Description of the issue/feature this PR addresses:** - The contact-us form allows task creation without a project (project_id = None). These tasks are assigned to odoobot, have no followers, and no project, making them inaccessible due to ACL restrictions. **steps to reproduce** 1. Install website_form_project. 2. Edit the contact-us form submit button. 3. Set action to 'Create a task' and select 'None' for the project. 4. Save and submit the form. **Observation** - Tasks creat
Original PR description
**Description of the issue/feature this PR addresses:** - The contact-us form allows task creation without a project (project_id = None). These tasks are assigned to odoobot, have no followers, and…
**Description of the issue/feature this PR addresses:** - The contact-us form allows task creation without a project (project_id = None). These tasks are assigned to odoobot, have no followers, and no project, making them inaccessible due to ACL restrictions. **steps to reproduce** 1. Install website_form_project. 2. Edit the contact-us form submit button. 3. Set action to 'Create a task' and select 'None' for the project. 4. Save and submit the form. **Observation** - Tasks created under such configuration are hidden in the UI and trigger access errors when trying to open them.  Desired behavior after PR is merged: - Making the project field required, the created tasks will now be accessible/visible [opw-4664601](https://www.odoo.com/odoo/project/49/tasks/4664601) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207871
When posting the vendor bill before validating the receipt, and the currency rate changed between the bill and receipt: - An Exchange diff account move would be created, and the Stock Input Account would not be balanced This is because the balance of the receipt would perfectly match the balance of the vendor bill, but not the Amount in currency. So, when we try to reconcile the 2 lines, because they are in the same currency, we are reconciling the Amount in Currency. Hence, the exchange rat
Original PR description
When posting the vendor bill before validating the receipt, and the currency rate changed between the bill and receipt: - An Exchange diff account move would be created, and the Stock Input Account…
When posting the vendor bill before validating the receipt, and the currency rate changed between the bill and receipt:
- An Exchange diff account move would be created, and the Stock Input Account would not be balanced
This is because the balance of the receipt would perfectly match the balance of the vendor bill, but not the Amount in currency. So, when we try to reconcile the 2 lines, because they are in the same currency, we are reconciling the Amount in Currency. Hence, the exchange rate journal entry is created, and a discrepancy in the Stock Input Account balance is introduced.
When the bill is posted before the receipt is validated, we want the receipt to have the value of the bill, and there is no reason to have only the balance or the amount in currency from the bill, so we can take both of them.
https://github.com/user-attachments/assets/c6dc5e72-8f5b-4c0f-99fa-c5e98a9574ff
## How to reproduce:
- Install stock_account,purchase
- Create product P:
* Valued in AVCO automated.
* Control Policy to 'On ordered quantities'
- Add currency rates for the EUR currency:
* 2.0 on the 2025-01-01
* 2.1 today
- Create and Confirm a new purchase for 1 unit of P and a price of 100 Euros
- Create the Bill:
* Set the bill's accounting date & bill date to the 2025-01-01
* Confirm the bill
=> Amount in Currency: 100 Euros - Balance: $50 USD - Rate used: 2.0
- Go back to the PO and receive the product.
=> Amount in Currency: 105 Euros - Balance: $50 USD - Rate used: 2.1
- Check the created Journal Entries:
=> Currency exchange rate difference: $2.38
=> (105 - 100) / 2.1
OPW-4631348
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#209118Previously, the code attempted to delete an element using order_id, but ordersToSync is an array of order objects, not order IDs. The fix updates the loop to use order.id instead of order_id, ensuring the correct removal from self.syncingOrders. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197080
Original PR description
Previously, the code attempted to delete an element using order_id, but ordersToSync is an array of order objects, not order IDs. The fix updates the loop to use order.id instead of order_id, ensuring the correct removal from self.syncingOrders. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197080
Description: This PR adjusts the alignment of the `TOTAL` and `CHANGE` labels on the POS receipts by modifying the CSS. Specifically, it changes the `padding-left: 6em` rule to `text-align: start`. The reason for this update is to ensure that the labels are consistently aligned at the start, improving readability and layout in different screen sizes and environments. Previous behavior: The `TOTAL` and `CHANGE` labels used excessive left padding (`padding-left: 6em`), which caused misalignme
Original PR description
Description: This PR adjusts the alignment of the `TOTAL` and `CHANGE` labels on the POS receipts by modifying the CSS. Specifically, it changes the `padding-left: 6em` rule to `text-align: start`.…
Description: This PR adjusts the alignment of the `TOTAL` and `CHANGE` labels on the POS receipts by modifying the CSS. Specifically, it changes the `padding-left: 6em` rule to `text-align: start`. The reason for this update is to ensure that the labels are consistently aligned at the start, improving readability and layout in different screen sizes and environments. Previous behavior: The `TOTAL` and `CHANGE` labels used excessive left padding (`padding-left: 6em`), which caused misalignment in some cases.  New behavior: The labels are now aligned to the start using `text-align: start`, resulting in a cleaner and more consistent layout.  This change enhances the overall appearance of the POS receipts and maintains consistency across different locales and layouts. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185014
This PR proposes reducing the default font size for POS receipts from 16px to 14px to align with the --body-font-size introduced in Odoo 18.0. The adjustment ensures a more consistent design, optimizes receipt layout, and saves paper when printing. | Before | After | |--------|-------| |  |  | --- I con
Original PR description
This PR proposes reducing the default font size for POS receipts from 16px to 14px to align with the --body-font-size introduced in Odoo 18.0. The adjustment ensures a more consistent design, optimizes receipt layout, and saves paper when printing. | Before | After | |--------|-------| |  |  | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188766
Description of the issue/feature this PR addresses: Additional information is needed in the error log to identify the method causing the error. Current behavior before PR: Prior to this change, the log received when an error occured was as follows but no information about the code was shown: `odoo.addons.point_of_sale.models.pos_order: Could not fully process the POS Order: Record cannot be modified right now: This cron task is currently being executed and may not be modified Please try
Original PR description
Description of the issue/feature this PR addresses: Additional information is needed in the error log to identify the method causing the error. Current behavior before PR: Prior to this change, the log received when an error occured was as follows but no information about the code was shown: `odoo.addons.point_of_sale.models.pos_order: Could not fully process the POS Order: Record cannot be modified right now: This cron task is currently being executed and may not be modified Please try again in a few minutes. Desired behavior after PR is merged: Information about the method causing the error must be displayed --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195184
Because an exception raised by the `_unlink_forbid_parts_of_chain` method when attempting to delete journal entries. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190019
Original PR description
Because an exception raised by the `_unlink_forbid_parts_of_chain` method when attempting to delete journal entries. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190019
After more discussion and consideration, this error is considered to have relatively low value and furthermore to possibly be triggered by the chrome shutdown itself e.g. `Page.stopLoading` is documented as > Force the page stop all navigations and pending resource fetches. so that can be the source of "failed to fetch" errors, maybe (didn't actually test it). Note that this is hooked to `_result.done()` aka `not _result.running()`, so there is a window where the issue can still occur (
Original PR description
After more discussion and consideration, this error is considered to have relatively low value and furthermore to possibly be triggered by the chrome shutdown itself e.g. `Page.stopLoading` is documented as > Force the page stop all navigations and pending resource fetches. so that can be the source of "failed to fetch" errors, maybe (didn't actually test it). Note that this is hooked to `_result.done()` aka `not _result.running()`, so there is a window where the issue can still occur (at least as a result of `stopLoading`) while we're waiting for service workers to shut down as well as pending responses. If this is still an issue, we may want to add a separate flag and set it right before or after the `Page.stopLoading` call. Hides runbot errors 54858, 55676, 109214, 109473, 110840, 134469, 162284, 162340, 193182, 198562, and 199232 Forward-Port-Of: odoo/odoo#209902
When the `odoo-enterprise/iot/x509` encounters an unexpected error, we still get an OK response but the result is empty and instead there is an error object returned. Before this commit, we never checked for this error object and so continued to process an empty result, causing a crash. After this commit, we check for these errors and log them, with a different message to distinguish them from the existing errors that we already check for. task-4793795 --- I confirm I have signed the C
Original PR description
When the `odoo-enterprise/iot/x509` encounters an unexpected error, we still get an OK response but the result is empty and instead there is an error object returned. Before this commit, we never checked for this error object and so continued to process an empty result, causing a crash. After this commit, we check for these errors and log them, with a different message to distinguish them from the existing errors that we already check for. task-4793795 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209819