Daily updates from Odoo
Friday, January 24, 2025
18 changes · 18.0
Enhancements to existing features
Payment receipt PDFs now include a dedicated table listing checks used for payment, including check number, issuer VAT, payment date, and amount. This gives businesses clearer supporting details on receipts and makes check-based payments easier to review and reconcile.
Original PR description
Description of the issue/feature this PR addresses: This PR aims to improve PDF payments receipt report. Following the example of withholdings table, we added a new table with the information of the checks used to pay, such as check number, issuer VAT, payment date and check amount. Current behavior before PR: The PDF report contains only the amount paid and a table showing the withholdings related to the payment. Desired behavior after PR is merged: The payment receipt PDF includes additional payment information including the checks table. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Kitchen order tickets are now routed to the correct category-specific printers, so each printer receives only the items it is responsible for. Tickets also keep all order lines when the dining mode changes, reducing missing or incorrect kitchen printouts.
Original PR description
Before this commit: ------------------------ - If we enable 2 different printers for 2 categories the kitchen prints were not as per the category. It was not filtered. - When we change mode of sitting (dinein, takeout) it doesn't have any orderlines. After this commit: ----------------------- - Now if category wise printers are set the tickets will follow and printers will have that category tickets only, - Now all the orderlines will be there on the tickets when dinning mode updated. task: 4422475
Payroll SEPA payments now stop with a clear error when an employee's private or contact address has no country set. The payroll dashboard also highlights affected employees, helping teams fix missing address data before payment processing.
Original PR description
If you do a sepa payment and the employee has no country defined on their private address or the address of their contact, we should raise an error. We also add a warning on the dashboard for such employees with no country. Task: 4334868
Resolved issues and error corrections
Messages sent in group chats with an @ mention are now correctly recognized as the sender's own messages, so they use the expected green bubble. The fix also prevents hidden errors during mention lookup from disrupting message display updates.
Original PR description
Before this commit, when posting a message with a `@` mention in group chat, the message had blue bubble instead of green bubble. This color means that the message is not recognized as a self…
Before this commit, when posting a message with a `@` mention in group chat, the message had blue bubble instead of green bubble. This color means that the message is not recognized as a self message. Steps to reproduce: - make group chat - post a message with `@` mention => the message bubble is blue rather than green This problem is a consequence of https://github.com/odoo/odoo/pull/176758 In this PR, when mentioning from any channel, the `groups_id` of partners from mention suggestions could be returned. If the users are in the group of group_public of channel, this means these partners could be invited in the channel. This is useful to make them elligible for `@` mention even when they are not member. This partial knowledge of the group id of partner is provided to client code so that the suggestions are shown too, since the list results in the JS modeling. This PR however introduced a silent crash in JS code from this LOC: https://github.com/odoo/odoo/pull/176758/files#diff-515b5eba2d7fbff9826774f16c701063cfd9c95967287eaec36b16db66ef8c48R102 The server data may send `[ADD, null]` for partner `groups_id`, which is the case in group chat. The internal code of JS models does not expect this kind of command data: it crashes because `ADD` command assumes the other part is genuine data or record(s). However `null` means nothingness, so internally the `target` is missing thus it leads to a crash in the internal code of JS models. Why is the crash not bubbled then? Well, this is silently ignored in business code by the fetch mention function, in `fetchSuggestions`. The silent crash is suspicious, but not necessarily the primary cause of the problem... No no no. Internal code of JS models has made a bigger sin: the silent crash aborts the pending update cycle, thus not flushing it. This is a huge problem, because the implementation of update cycle is made in a way that its integrity depends on no crash during the update cycle. That's because the synchronous processing of update cycle defines layers of update cycle with a global counter that is incremented and decremented. The 1st update cycle layer manages the flush, while the other layers do the operations without flush. If there's a crash during the update cycle, the update cycle is aborted but its counter is preserved. Let's say the counter is 4: that means the update queues are never flushed, because the only way to change this value is through `MAKE_UPDATE`, and this function only preserves its value or temporarily increases it. So what's the deal with the green bubble being blue? Well, there's a computed field `isSelfAuthored` that was never computed because of the silent crash. Thus it had the default value `false` rather than `true` for self messages. While the symptoms show blue bubble instead of green bubble, which feels cute but not a big deal... This was actually a side-effect of a much much bigger issue that compromises the overall modeling of JS. Yes, that's like having an eye tickling, thinking that we're just tired but it's actually a symptom of final stage cancer. Do not worry though: this commit doesn't cure cancer, but it fixes this problem as follow: `fetchSuggestions` in business code should not silently catch non-abort errors, and bubble it.
Fixes a payment reconciliation issue that prevented commission purchase requests from being generated when invoices were paid through bank reconciliation without an outstanding account. This ensures commission-related follow-up documents are created reliably after customer invoices are paid.
Original PR description
## Issue: Commission RFQ is not auto-generated for journals(payment method lines) without outstanding accounts when an SO invoice is created, a payment is created for it, and it gets reconciled with…
## Issue: Commission RFQ is not auto-generated for journals(payment method lines) without outstanding accounts when an SO invoice is created, a payment is created for it, and it gets reconciled with a bank statement. ## steps to reproduce: 1. go to bank journal and remove the outstanding account from the manual payment method line 2. on the CRM app create a partner commission program with a percentage and attach it to a partner 3. create a sale order with the partner as a referrer and confirm it 4. create an invoice from the sale order and validate it 5. register a payment for the invoice using the manual payment method 6. create a bank statement line and reconcile the invoice with it in the bank reconciliation widget 7. check the purchase app and see that no RFQ was created ## Solution: - Before version 18.0 (see [this PR](https://github.com/odoo/odoo/pull/180813)), automatically assigning a default outstanding account ensured that every payment created a journal entry. This journal entry was reconciled with the invoice, triggering `invoice_paid_hook` as the invoice transitioned from `not_paid` to `in_payment`. `_reconcile_pre_hook` filtered out payments already marked as `in_payment` to avoid double-triggering `invoice_paid_hook`. However, since the default outstanding account is no longer assigned automatically, `invoice_paid_hook` is not triggered when an invoice transitions from `not_paid` to `in_payment` and then to `paid` by reconciling it with a bank statement line. - to address this issue we edited `_reconcile_pre_hook` and `_reconcile_post_hook` to handle in payment invoices in these cases. OPW-4282724 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents invalid fixed tax rate values from being sent to Egypt's electronic invoicing authority. It helps keep Egyptian EDI tax submissions compliant with official ETA requirements and reduces the risk of rejected invoices.
Original PR description
To comply with Egyptian tax law, we need to remove rate for fixed taxes when sending data to ETA. Official docs say: "if Channel = “ERP” OR Channel = “POS” and itemData[*].taxableItems[*].subType is fixed, itemData[*].taxableItems[*].rate should be zero or omitted" Source (point 36): https://sdk.invoicing.eta.gov.eg/main-calculations/ This fix ensure no values are sent for fixed tax type. Currently using null, which is invalid. opw-4457780
Payments made in Philippine pesos through Xendit no longer fail because of decimal amounts. This ensures customers can complete PHP payments without seeing an “Amount must be integer” error.
Original PR description
Steps to reproduce: 1) Configure Xendit provider 2) Try paying in PHP currency 3) Observe: 'Amount must be integer' error Xendit does not allow decimal places for PHP. opw-4415419
The Quote Builder tab now appears as soon as a product with linked documents is added to a sales order, without needing to save and reopen it. This removes an extra step for sales users and ensures document availability is consistent across users with different access rights.
Original PR description
Steps to Reproduce: - Ensure no headers or footers are in Configuration > Headers/Footers. - Create a new Sale Order (SO). - Add a partner to the SO. - Add a product to the SO that has a document…
Steps to Reproduce: - Ensure no headers or footers are in Configuration > Headers/Footers. - Create a new Sale Order (SO). - Add a partner to the SO. - Add a product to the SO that has a document linked to it. - The `Quote Builder` tab does not appear until the SO is saved and reopened. Issue: The `Quote Builder` tab did not appear immediately after adding a product with linked documents. This required saving and reopening the SO to make the tab visible, causing inconvenience to users. Cause: The `_compute_available_product_document_ids` method lacked an `@api.depends` decorator for fields `product_id` and `product_template_id`. As a result, the dependent field `is_pdf_quote_builder_available` was not updated dynamically. Fix: Added the `@api.depends` decorator to `_compute_available_product_document_ids`, ensuring the computation is triggered immediately when `product_id` or `product_template_id` changes. This ensures that `is_pdf_quote_builder_available` is recalculated dynamically, making the `Quote Builder` tab visible immediately. - Also added `compute_sudo` on `available_product_document_ids` field to ensure available documents consistancy even though users have different access. opw-4364152
Egyptian electronic invoices with withholding tax now report the withheld amount correctly as a positive value. This prevents validation failures when businesses submit invoices with withholding tax to the tax authority.
Original PR description
Steps to reproduce:
- With an EG Company setup
- Create an invoice with a '3% WH' tax
- Confirm invoice and send for validation
Issue: Validation will fail with error
```
{'code': '2', 'message': 'Validation Error', 'target': 'INV/2025/00001', 'propertyPath': None, 'details': [{'code': None, 'message': 'ArrayItemNotValid', 'target': '[0]', 'propertyPath': '#/invoiceLines[0]', 'details': None}, {'code': None, 'message': 'ArrayItemNotValid', 'target': '[1]', 'propertyPath': '#/taxTotals[1]', 'details': None}]}
```
This is caused by the withholding tax amount being reported as negative, while it should be reported as positive
opw-4453002
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-prThis update improves how Odoo calculates and displays tax totals, especially when invoices use different tax rates, no-tax lines, cash rounding, or globally rounded amounts. It helps produce clearer customer documents and more accurate tax data for markets with strict reporting requirements, including Mexico and Portugal.
Original PR description
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
This fixes an issue where list views did not apply certain custom settings because a setup step was not being run. Businesses using tailored list views should now see expected behavior when dynamic options or custom display rules are used.
Original PR description
Before this fix, the list widget's extractProps function was never called due to an incorrect method reference in the web module. This caused issues when rendering dynamic props or customizing the list view behavior. After the fix: - The extractProps function is properly invoked. - The list widget can now retrieve props values as expected. 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 Barcode app no longer fails when users update and validate produced quantities for manufacturing orders. This prevents an error that blocked completion of the workflow, helping production teams process manufacturing orders smoothly.
Original PR description
Issue: ========== A traceback occurs when validating the quantity produced through the Barcode app, causing the process to fail. Steps to Reproduce: ======================= 1. Create a new database and install the Manufacturing module. 2. Create and confirm a manufacturing order (MO) from the backend. 3. Open the Barcode app, access the MO, edit the quantity produced, and validate. With this commit: ==================== Prevent error when lot_producing_id is undefined during form save and allow smooth validation of produced quantities. task-4443489
Fixes issues in the Documents app where edits made from the details panel could be lost, applied to the wrong selected documents, or fail to show contact information after reload. This improves reliability when users preview, tag, rename, move, or update documents and folders.
Original PR description
Several things addressed on the details panel. A. When editing a previewed document, no data was saved. When editing a previewed document, no data was saved. Reproduce: 1. Without selecting any…
Several things addressed on the details panel. A. When editing a previewed document, no data was saved. When editing a previewed document, no data was saved. Reproduce: 1. Without selecting any document, open a preview 2. Rename the document or add a tag 3. Close the preview 4. Reload the page 5. See that changes were not saved BTW, tags could not be created from the inspector, it's not clear why. Technical note: for previewed record, that are not "selected" when we update them, we need to force saving immediately. For records that are selected, we can leave the webclient behavior for saving records (urgent save). This can lead to having tracked fields being immediately reported (seen in chatter) when editing previewed documents but not the others. This is acceptable for simplicity. B. When showing data for the current folder opened, the contact info was missing (partner_id). Reproduce: 1. Go inside any folder 2. Without selecting any documents, add a contact to the current folder via the details panel 4. Reload the page 5. The partner doesn't show up in the field (even though it is updated on the record). C. U pdate previewed document only Reproduce: 1. Select two records 2. Preview one of them 3. Change a value in the details panel 4. Both records were modified instead of the previewed one only We're also fixing the removal of the correct documents from the kanban view when documents are moved and making sure we do not try to edit this document again as it could likely not be in the view anymore at all. Task-4465443
This fixes an issue that prevented users from exporting batch payments as XML files. Businesses can again generate the required payment export files for bank processing without manual workarounds.
Original PR description
Since this commit:https://github.com/odoo/enterprise/commit/7bfeb39f64bfecde2960c6f6678062ac515589cb it wasn't possible to export in xml a batch payment. no-task-id
Recruitment-related attachments now open in the expected document location instead of sending users to the broader documents view. Recruiters and interviewers are granted the needed folder access automatically, and that access is removed when they no longer have those roles.
Original PR description
Steps to reproduce: 1) install document_hr_recruit module 2) create an application and upload an attachment to it 3) go to the kanban view and click on the attachment icon on the right bottom 4) it will lead you to the document view instead of the document Cause : In the document settings, there’s a recruitment option to select the folder for job positions and application documents. By default, the setting should be 'Recruitment', but the visibility is not configured in the code Fix: We will provide 'view' access to the folder Task-4348197
Embedded document actions now keep all stored translations instead of copying only one language, so multilingual users see the correct labels. The accounting document actions are also prepared for easier journal customization, helping less technical users configure them more confidently.
Original PR description
1. [FIX] documents: keep translations when embedding action When creating an embedded action from a server action, only one language was copied. Note that we are using `_get_stored_translations` instead of `get_languages` to identify values to write as a simple method to avoid storing too much unnecessary data as possible (e.g., 100 languages installed but only `en_US` on the record). 2. [IMP] documents_account: prepare actions journal customization This can be helpful to guide less technical users. Task-4486261
Timesheet overtime now uses the configured average hours per day for employees on flexible schedules, instead of relying on detailed work intervals. This makes daily and weekly overtime totals match the intended schedule setup while keeping standard schedules unchanged.
Original PR description
#### Issue: - When an employee is assigned a resource calendar with the `flexible_hours` option enabled, the daily/weekly overtime on the timesheet calendar is not calculated based on the 'Average…
#### Issue: - When an employee is assigned a resource calendar with the `flexible_hours` option enabled, the daily/weekly overtime on the timesheet calendar is not calculated based on the 'Average Hour per Day' that we set for the flexible resource, it is instead being calculated based on the specific work intervals. #### Steps to reproduce: 1. Assign a resource calendar with `flexible_hours` enabled to an employee. 2. Ensure the calendar has a defined `hours_per_day` value. 3. Verify that the timesheet grid correctly shows the daily/weekly overtime hours as per `hours_per_day`. 4. Test with non-flexible schedules to confirm existing behavior remains unchanged. #### Solution: - In the frontend, the method `fetchDailyWorkingHours` retrieves daily working hours data by calling the backend method `get_daily_working_hours`. - This method computes working hours based on the employee's `resource_calendar_id` and its associated work intervals. However, It does not check if the `flexible_hours` flag is enabled on the `resource_calendar_id`. For employees with flexible schedules, the backend still calculates working hours based on detailed intervals instead of simply using the `hours_per_day` value defined in the `resource_calendar`. - To fix this I ensure we respect flexible schedules by using `hours_per_day` directly when `flexible_hours` is enabled. opw-4407910
This update fixes rounding differences in Mexican electronic invoices so tax authority validation accepts the generated documents. It also updates related localization logic and tests to prevent the issue from returning.
Original PR description
See test in this commit to reproduce.