Daily updates from Odoo
Tuesday, August 5, 2025
15 changes · master
New functionality added to Odoo
A new Cambodia reporting module adds core financial statements and a WT003 withholding tax export. This helps Cambodian businesses meet local reporting needs directly in Odoo with localized balance sheet, profit and loss, and tax export support.
Original PR description
Adds basic reporting module for Cambodia, including: - Balance sheet - Profit & loss - WT003 export task-4383330 Forward-Port-Of: odoo/enterprise#91592 Forward-Port-Of: odoo/enterprise#89831
Enhancements to existing features
This update reorganizes how discussion channels are represented across messaging-related apps, including AI chat, live chat, and WhatsApp. It helps keep chat behavior more consistent and easier to extend, with limited direct impact for end users.
Signature requests opened from a record now automatically choose the partner linked to that record as the signer, instead of defaulting to the current user. This helps teams send documents to the right customer or contact with less manual correction, with added test coverage across related business apps.
Original PR description
**Before this PR:** - when using the "Signature Request" action from a form view, the current user was automatically set as the default signer (as the customer). **In this PR:** - if the record has a related partner_id, that partner will now be used as the default signer instead of the current user. - This makes the signature process more accurate by automatically selecting the right partner linked to the record. **New Module : test_sign**: - Added a new test module for the Sign app. - This module includes test cases for other modules like Sale, CRM, and MRP to check if the correct partner_id is being set as the default signer. **Impact:** - This change improves the accuracy and usability of the signature process across modules like Sale, CRM, and MRP. By using the record's partner_id as the default signer instead of the current user. task-4246455
Payroll pay run cards are now handled separately in the main kanban view and in payslip lists filtered by pay run. This makes each view easier to adjust independently, helping maintain a clearer and more consistent payroll workflow across screen sizes.
Original PR description
Problem ---------- Change the pay run in the kanban view to stay standard Use a custom component for the pay run card displayed in the filtered list view of payslips. Objective ---------- Unlink the card in the kanban and the card in the payslip list filtered So each one can be modified separately. Solution ---------- A template is defined in the kanban view of payrun. The menu template uses a new compiler to display buttons depending on the screen size in the payrun card. For the list view of payslip filtered by pay run. The card is a custom component call in a Record component to fetch the payslip_run record. Kanban arch is used to fetch fields. The card and menu template can be used too. But as we choose to unlink the 2 payrun card, custom component is used with the same PayrunButtonBox Component to display buttons, with all buttons duplicated task-4873744
Exported accounting report files now include more context in their names, making PDFs and spreadsheets easier to identify after download. This helps users distinguish similar reports quickly and reduces confusion when sharing or archiving files.
Original PR description
Before this commit, exported PDFs, XLSX... were named only after the report, making them hard to identify. Now, filenames include more context to help users recognize reports at a glance. Task ID: 4502264
Payroll extra input types are being removed and replaced with simpler text-based codes and salary-rule references. This reduces setup complexity and makes payroll calculations easier to maintain across payroll, expenses, commissions, and localization modules.
Original PR description
In this PR we remove model `hr_payslip_input_type` and repalce the relation to it with plain text `code` Task: 4930632
AI draft writing is now integrated with AI agents, making draft assistance more configurable and easier to launch. Users can see ready-made prompt buttons when opening AI chats, and the AI entry point is moved into the form header for faster access.
Original PR description
Integrate the AI draft functionality introduced in 18.3 with the AI agents also introduced in 18.3. We heavily updated the ai.composer model in order to act more like AI draft configurations that are…
Integrate the AI draft functionality introduced in 18.3 with the AI agents also introduced in 18.3. We heavily updated the ai.composer model in order to act more like AI draft configurations that are editable and extensible by the user. We introduced the `interface_key`, 'ai_agent', 'focused_models', and the 'available_prompts' fields. We also introduced a new model, the `ai.prompt` model, which holds str of the available prompts that users can click on when opening a AI draft chat. Finally, we made some UI changes to the chat windows of AI chats - they now have configurable prompt buttons that the users can immediately click when opening the chat. We also moved the chatter button from the chatter to the form view header. (Also we edited some tests, and some legacy qunit tests, because the `aiChatLauncher` service needed to be added since it's not being used by the `form_controller`) Task-4794888 Related Community PR: https://github.com/odoo/odoo/pull/221219 Related Upgrade PR: https://github.com/odoo/upgrade/pull/8143
Selected Gantt views now support creating and deleting multiple entries at once, matching similar capabilities already available in calendar views. This helps users manage schedules and planning records faster with fewer repetitive actions.
Original PR description
We make available for some gantt views the same multi creation/deletion feature developed for calendar views in https://github.com/odoo/odoo/pull/219098. Task ID: 4938831
Field service sales and stock workflows now support section lines in the product catalog. This helps teams organize items more clearly when preparing service quotes, orders, and stock tracking, improving readability for customers and staff.
Original PR description
Community PR: https://github.com/odoo/odoo/pull/203258 task-4593041
Resolved issues and error corrections
Upsell invoices for yearly subscriptions now show the correct billing duration when a current partial period is followed by a full renewal period. This prevents customers from seeing misleading invoice line descriptions and helps keep subscription billing clearer and more accurate.
Original PR description
**Steps to Reproduce:** - Install `sale_subscription`. - Create a product (recurring product) with: - Type: Service - Invoicing Policy: Prepaid/Fixed Price - Create a subscription plan Yearly with: -…
**Steps to Reproduce:**
- Install `sale_subscription`.
- Create a product (recurring product) with:
- Type: Service
- Invoicing Policy: Prepaid/Fixed Price
- Create a subscription plan Yearly with:
- Billing Period: 1 year
- Align to period start: enabled
- Create and confirm a subscription for the product using the Yearly plan.
- Create and confirm the first invoice (shows remaining days like
185 days – 06/30/2025 to 12/31/2025 in product description).
- Create and confirm second invoice (check 1 year – 01/01/2026 to 12/31/2026).
- Go back to the subscription and create an upsell.
- Confirm the upsell and generate its invoice.
**Observation:**
- The upsell invoice line shows the wrong duration:
1 year (06/30/2025 to 12/31/2026).
- This is incorrect because the expected duration is:
185 days (from 06/30/2025 to 12/31/2025) + 1 year (01/01/2026 to 12/31/2026)
**Issue:**
- The duration calculation is based on the ratio of the first date and the end
date, but for the Upsell's ratio is always 1, so it considers fix duration,
i.e 1 year, 1 month
https://github.com/odoo/enterprise/blob/4bb43da79dba7ac1d0772fde814b3da6bade7db6/sale_subscription/models/sale_order_line.py#L346-L347
**Solution:**
- Corrected the logic to calculate the upsell duration by combining the remaining
current period (e.g., 185 days) with the standard 1-year period ratio.
Reference PR: https://github.com/odoo/enterprise/pull/68163/commits/cfed2d369960896f0f4d91a90eb24f3641627419
opw-4853426
Forward-Port-Of: odoo/enterprise#91362
Forward-Port-Of: odoo/enterprise#88963Fixes an issue where Mexican point-of-sale refunds failed when a gift card was used. Refunds can now correctly reload the gift card balance, preventing checkout errors and allowing legitimate positive gift card lines during refund transactions.
Original PR description
**Problem:** When trying to make a refund in Mexico, with a gift card in the order, the order should be refunded on said gift card. But when doing so, two problems arise: - In the case of a gift…
**Problem:** When trying to make a refund in Mexico, with a gift card in the order, the order should be refunded on said gift card. But when doing so, two problems arise: - In the case of a gift card, *line[2].refunded_orderline_id* is not set, so we are trying to read the property of an undefined variable. - Another problem is that the order can not have any line that have a positive subtotal in the case of a refund. This was not taking the gift cards into accounts, as it makes sense for them to be positive in such a case. **Steps to reproduce:** - Set your company to a Mexican company - Make a purchase for a gift card - Make another purchase for a random product - Start the refund process and enter the gift card code we created before - Try to finalize the purchase, a traceback appears - If we were not trying to read an undefined variable, the purchase would still not go through as some lines are positive in a refund **Why the fix:** When refunding with a gift card, we should refill the gift card by the order's cost instead. With this in mind, it makes sense for the gift card to have a positive price even though we are in the context of a refund, which usually only permits negative priced lines. opw-4892935 Forward-Port-Of: odoo/enterprise#91385 Forward-Port-Of: odoo/enterprise#89892
This fix prevents WinBooks accounting imports from failing when imported data contains special tax accounts, missing journal references, or accounts later marked as deprecated. It helps businesses complete legacy accounting data imports more reliably without manual cleanup or interrupted migration workflows.
Original PR description
When importing a winbooks file the following issues and or inconsistencies may be found **Issue 1** We may import an account with CENTRALID 'V03' and code 45100000 Having this centralID means that it…
When importing a winbooks file the following issues and or inconsistencies may be found **Issue 1** We may import an account with CENTRALID 'V03' and code 45100000 Having this centralID means that it will be set as tax payable account id according to https://github.com/odoo/enterprise/blame/d8d4812414dba8825a1c785c29d00f7d0fd98360/account_winbooks_import/wizard/import_wizard.py#L174 However, this means it needs to be a `liability_payable` account with reconcile enable, in order to comply with the following check https://github.com/odoo/odoo/blame/ad6c9001b447f5ffebafe1581512f48708c7d746/addons/account/models/account_tax.py#L80 *Note* Even if we set it as liability_payable, the import may fail later on in case the same account is used in a sales move where those types of account are not allowed https://github.com/odoo/odoo/blame/1b657cf1e1ce43874a3ede307b2f8ad68216aa56/addons/account/models/account_move_line.py#L1247 A solution is to skip the `_check_payable_receivable` check for winbooks lines **Issue 2** Move line data may reference an unkown journal, causing a validation error because no journal is retrieved from the database and a move always need a journal **Issue 3** Account created during import may be marked for deprecation, which occurs at the end of the import process. However, if the account has been used in a tax repartition line, trying to set it as deprecated will raise an error. https://github.com/odoo/odoo/blame/2cdc41c012f637849ba030989ce928b6b1152e7e/addons/account/models/account_account.py#L1028 opw-4850314 Forward-Port-Of: odoo/enterprise#91581 Forward-Port-Of: odoo/enterprise#89426
This update improves accounting return workflows by preserving selected dates in the return creation wizard and keeping audit completion status in sync. It also adjusts period-locking behavior so audit returns are not incorrectly blocked, making audit-related processes smoother and less error-prone.
This fix prevents the Barcode app from storing invalid empty values when scanning lot numbers during receipt processing. It avoids a crash when users scan multiple lots, helping warehouse teams continue receipt operations reliably.
Original PR description
## How to reproduce: https://github.com/user-attachments/assets/bf44f9fd-0402-4d70-8b55-5baf192d42e8 - Enable Consignment - On Receipt operation type, enable 'Use existing lots' - Create product P,…
## How to reproduce:
https://github.com/user-attachments/assets/bf44f9fd-0402-4d70-8b55-5baf192d42e8
- Enable Consignment
- On Receipt operation type, enable 'Use existing lots'
- Create product P, tracked by lot
- Create lot SN-001 & SN-002
- Add 1 unit on hand with lot SN-001
- Create Receipt for 10 units of P -> Confirm
- Open receipt on Barcode App
- Scan "SN-002" => 'undefined' value added to 'dbQuantCache'
- Scan "SN-001" => Uncaught Promise > quantsByLocation is not iterable (cannot read property undefined)
---
## Test result without fix:
```
2025-07-18 09:30:33,801 20801 ERROR oes_test_18 odoo.addons.stock_barcode.tests.test_barcode_client_action_picking: FAIL: TestPickingBarcodeClientAction.test_barcode_lazy_cache_scan_two_lots
Traceback (most recent call last):
File "/home/odoo/projects/odoo-src/multiverse/src/18.0/enterprise/stock_barcode/tests/test_barcode_client_action_picking.py", line 3508, in test_barcode_lazy_cache_scan_two_lots
self.start_tour(url, 'test_barcode_lazy_cache_scan_two_lots', login='admin')
File "/home/odoo/projects/odoo-src/multiverse/src/18.0/odoo/odoo/tests/common.py", line 2264, in start_tour
return self.browser_js(url_path=url_path, code=code, ready=ready, timeout=timeout, success_signal="tour succeeded", **kwargs)
File "/home/odoo/projects/odoo-src/multiverse/src/18.0/odoo/odoo/tests/common.py", line 2235, in browser_js
self.fail('%s\n\n%s' % (message, error))
AssertionError: The test code "odoo.startTour('test_barcode_lazy_cache_scan_two_lots', {"stepDelay": 0, "keepWatchBrowser": false, "debug": false, "startUrl": "/odoo/147/action-stock_barcode.stock_barcode_picking_client_action", "delayToCheckUndeterminisms": 0})" failed
TypeError: quantsByLocation is not iterable (cannot read property undefined)
at LazyBarcodeCache.getQuants (http://127.0.0.1:8565/web/assets/3d6bda7/web.assets_web.min.js:21482:279)
at BarcodePickingModel._processBarcode (http://127.0.0.1:8565/web/assets/3d6bda7/web.assets_web.min.js:21748:631)
at async http://127.0.0.1:8565/web/assets/3d6bda7/web.assets_web.min.js:21661:75
```
OPW-4942192
Forward-Port-Of: odoo/enterprise#91433
Forward-Port-Of: odoo/enterprise#90492This fix prevents barcode scanning from crashing on iOS when the scan confirmation sound cannot be played. It improves reliability by choosing a better-supported sound format and safely logging sound playback issues instead of interrupting the user.
Original PR description
Issue ----- On iOS 18.5, users can get a `NotSupportedError` when trying to scan a barcode from the (barcode) main menu. Steps to reproduce ----- - Open barcode - Click the center scan button - Scan…
Issue ----- On iOS 18.5, users can get a `NotSupportedError` when trying to scan a barcode from the (barcode) main menu. Steps to reproduce ----- - Open barcode - Click the center scan button - Scan a barcode --> Traceback Discussion ----- There are 2 issues occuring here. 1. We play either an ogg or mp3 file. However, the method to know if the format is supported by the browser returns one of 'probably', 'maybe', ''. https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement/canPlayType#return_value This means that when we do https://github.com/odoo/enterprise/blob/70e5013ea022ed04ff27db71ea3ecccb55ae1f70/stock_barcode/static/src/main_menu/main_menu.js#L37 We might end up using ogg even if the browser doesn't actually support it, as 'maybe' is truthy. To reduce the risk of this happening, we can specify the codec as "vorbis" (all ogg files of Odoo are vorbis). This is already done in mail: https://github.com/odoo/odoo/blob/cd4c1d599ea9403ce3791e239ad765d946446a47/addons/mail/static/src/core/common/sound_effects_service.js#L46 2. The browser might not have the permission to play the sound. In such cases, the best we can do is try to play the sound and log potential errors. ----- Ticket: opw-4820022 Forward-Port-Of: odoo/enterprise#91579 Forward-Port-Of: odoo/enterprise#91158