Daily updates from Odoo
Tuesday, December 9, 2025
63 changes · 19.0
Enhancements to existing features
This pull request improves the user experience and stability of expense processing using Stripe virtual cards. Key changes include visual updates to card displays, automated expense approval for Stripe card users, and fixes related to data synchronization and error handling during card shipping status updates. These improvements streamline the expense workflow and ensure accurate tracking.
Original PR description
- Create Expense at the authorization instead of the capture
- Send a mail when a virtual card is assigned to someone
- Correct text inside card pause dialog
- Improve card look:
- Align date, pin and copy button on the card
- Fix physical card pin number not visible with dark mode
- Fix date horizontal alignment on pending physical cards
- Add Unlimited as placeholder on cards payement limits
task-4860676This update enhances the documentation system by enabling developers to receive complete server error tracebacks when errors occur. A new component, DocErrorDialog, manages the display of these tracebacks, providing more detailed information for troubleshooting. This improves the developer experience and helps quickly identify and resolve issues within the documentation.
Original PR description
This commit updates the /doc controllers from 'http' type to 'json2' to allow the frontend to receive the full server traceback on errors. This change required modifying `http.Json2Dispatcher.is_compatible_with` to also accept requests with no content-type when content-length is 0. It introduces a new component, `DocErrorDialog`, to manage error display and server traceback. The general error handling flow for the api_doc fetch calls is also improved. task-5172546 task-5349157
Resolved issues and error corrections
This update fixes an issue in the VAT Simple tax export report. It now accurately filters tax amounts to include only standard VAT taxes, as defined by the `l10n_ar_vat_afip_code` field. This ensures more precise and reliable financial reporting for Argentina.
Original PR description
The VAT Simple tax export should only report tax amounts from taxes that are standard VAT taxes, not all taxes. This is represented in l10n_ar via the `l10n_ar_vat_afip_code` field on the tax group. opw-5385508
This update fixes an accounting error related to invoices in Vietnam (l10n_vn). Previously, the system incorrectly created entries for both receivable and payable accounts for 'Unearned Revenue' (account 3387). Changing the account type to 'Current Liabilities' ensures accurate financial reporting and prevents mismatched balances.
Original PR description
When posting an invoice, the system creates: - Journal Entry: Dr 131 (Receivable) / Cr 511 Then the system creates a deferral entry: - Deferral entry: Dr 511 / Cr 3387 (Payable) Falsifying the…
When posting an invoice, the system creates: - Journal Entry: Dr 131 (Receivable) / Cr 511 Then the system creates a deferral entry: - Deferral entry: Dr 511 / Cr 3387 (Payable) Falsifying the Balance sheet report, in the accounts receivable and accounts payable indicators The issue was that account 3387 was configured as `Payable`, which caused the system to generate both Receivable (131) and Payable (3387) for the same partner. This is incorrect because account 3387 represents "Unearned Revenue", which is a current liability, not a payable account. By changing the account type from `Payable` to `Current Liabilities`, the deferral entry now correctly reflects that 3387 is a current liability account, preventing the incorrect reconciliation behavior where both receivable and payable entries were created for the same partner. After this fix: - Entry: Dr 131 (Receivable) / Cr 511 - Deferral: Dr 511 / Cr 3387 (Current Liabilities) 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 Forward-Port-Of: odoo/odoo#238807 Forward-Port-Of: odoo/odoo#237493
This update simplifies the handling of MPF payments in the Hong Kong accounting module. Previously, separate payments were registered, creating complexity. Now, MPF accounts are set to be unreconcilable by default, directing accountants to reconcile directly with the government platform, streamlining the process.
Original PR description
Currently, we register two separate payments for MPF at the same time as we do for the employee's wages. This is not what we want to do; as both are not paid at the same time. MPF is also handled separately, and paid outside of Odoo on the government platform, making the registration of separate payments more complex for not many benefits. Thus, we make these accounts un-reconcilable by default, and will expect accountants to reconcile the statement with the account directly. task-5349299 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238074
This update resolves an issue where email templates were not rendering correctly due to differences in how HTML was parsed. The change ensures that all HTML elements, except for void elements, are properly closed, resulting in consistent and accurate email formatting. This prevents errors and ensures emails display as intended.
Original PR description
**Step to Reproduce:** - install Subscription (with demo data) - try to edit `Subscription: Payment Reminder` email template **Observation:** - Traceback for faulty template **Cause** For outgoing…
**Step to Reproduce:**
- install Subscription (with demo data)
- try to edit `Subscription: Payment Reminder` email template
**Observation:**
- Traceback for faulty template
**Cause**
For outgoing mails, we are using output_method = 'xml' when normalizing html content
https://github.com/odoo/odoo/blob/cb5176df98490ef04c0aac481f010bd2ac2f2424/odoo/orm/fields_textual.py#L580-L587
when this content is parsed using DOMParser in browser,
https://github.com/odoo/odoo/blob/cb5176df98490ef04c0aac481f010bd2ac2f2424/addons/html_editor/static/src/html_migrations/html_upgrade_manager.js#L61-L63
we might get different result.
For a very basic template like this:
```
<div>
<t t-if="ctx.get('error')">
<pre t-out="ctx['error'] or ''" />.
</t>
<t t-else="">
<span>some text</span>
</t>
</div>
```
when parsed using Domparser(), return a faulty template:
```
<div>
<t t-if="ctx.get('error')">
<pre t-out="ctx['error'] or ''">.
<t t-else="">
<span>some text</span>
</t>
</pre>
</t>
</div>
```
Issue roots because of use of self-closing tags, which are valid for xml but not for html
**Fix:**
- we forcefully replace all self-closing tags(which are not void elements) with a closing tag.
- see list of void elements https://developer.mozilla.org/en-US/docs/Glossary/Void_element
opw-5234345
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#238695
Forward-Port-Of: odoo/odoo#235924This update fixes a problem where old work entries persisted across different version schedules. The change ensures that outdated work entries are automatically removed when a new version with a different schedule is created, maintaining accurate record-keeping. This improves data consistency and simplifies reporting.
Original PR description
Problem ---------- When we create a new version with a new working schedule, it will generate correct work entries (because no one was generated for this version before) But it will not remove the previous one for the other previous versions. Solution ---------- Nullify work entries if outside the valid period of the version if they were already created before. task-5065139 Forward-Port-Of: odoo/odoo#232658
This update resolves an issue where marking multiple manufacturing orders as done simultaneously caused an error. The fix ensures accurate handling of different unit of measure (UoM) quantities when completing multiple orders, improving data integrity and preventing disruptions to the workflow. This change focuses on a technical detail related to precision rounding within the MRP module.
Original PR description
Currently, an error occurs when user marks multiple Manufacturing Orders as Done. **Steps to Reproduce…
Currently, an error occurs when user marks multiple Manufacturing Orders as Done.
**Steps to Reproduce ([Video](https://drive.google.com/file/d/1XfkMB001rMiyulRGrP4dlJFDYByo_5Bv/view?usp=drive_link)):**
- Install the `mrp` module.
- Go to `Settings` and enable `Units of Measure & Packagings`.
- Go to `Products and `create two products` with different `units of measure`.
- Go to `Manufacturing Orders`, create a manufacturing order by `adding one of the products`, and then `create work order` in the Work Orders section and `confirm` it.
- Create another `manufacturing order` with the `same quantity` for the second product and add a `Work Order` for it as well and `confirm` it.
- Go to the `list view`, select `both orders`, and click `Mark as Done` from the `Actions` menu.
**Error:**
```
ValueError: ValueError('Expected singleton: uom.uom(4, 6)') while evaluating
"if records:\n res = records.filtered(lambda mo: mo.state in {'confirmed', 'to_close', 'progress'}).button_mark_done()\n if res is not True:\n action = res"
ValueError: Expected singleton: uom.uom(4, 6)
```
After [this commit], which improves the performance of button_finish, when a user marks multiple orders as done with the same quantity but different uom , it creates all_vals_dict based on the vals[1] data as the key and the work order as the value[2]. Then it stores two or more work orders with different UoMs under the same vals key. When attempting to write multiple work orders[3], the precision rounding is calculated, which raises the error[4] due to multiple UoMs.
The commit ensures that when writing records, precision_rounding is calculated separately for each Work Order's UoM.
[this commit]: https://github.com/odoo/odoo/pull/223715/commits/b857d192085a38b612335223d04f8bdff91b898c
[1]- https://github.com/odoo/odoo/blob/186a9eb4a6c55c9c4c2178d4b2492a9a23a267fe/addons/mrp/models/mrp_workorder.py#L698-L703
[2]- https://github.com/odoo/odoo/blob/186a9eb4a6c55c9c4c2178d4b2492a9a23a267fe/addons/mrp/models/mrp_workorder.py#L706
[3]- https://github.com/odoo/odoo/blob/186a9eb4a6c55c9c4c2178d4b2492a9a23a267fe/addons/mrp/models/mrp_workorder.py#L708
[4]- https://github.com/odoo/odoo/blob/186a9eb4a6c55c9c4c2178d4b2492a9a23a267fe/addons/mrp/models/mrp_workorder.py#L477
sentry-7050854871
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#238934
Forward-Port-Of: odoo/odoo#238086This update fixes an issue where timesheet values were incorrectly displayed in project updates. A recent change in how the system handles time conversions led to an extra conversion step, resulting in incorrect day counts. This change ensures accurate timesheet time is shown in project updates, particularly when using the 'Days/Half-days' encoding method.
Original PR description
Similar to: 0104cee Steps to reproduce: -------------------- 1. Install hr_timesheet 2. Create a new project and a task 3. On the task, add a timesheet line with some time (e.g., 16 hours) 4. Open…
Similar to: 0104cee Steps to reproduce: -------------------- 1. Install hr_timesheet 2. Create a new project and a task 3. On the task, add a timesheet line with some time (e.g., 16 hours) 4. Open the project dashboard > create a new project update > observe the timesheet time 5. Go to Timesheets > Configuration > Settings 6. Set "Encoding method" to "Days/Half-days" 7. Reopen the project dashboard > create another project update > observe the timesheet time again Issue: ------ Incorrect value displayed in the Timesheets. (e.g., 16 Days instead of 2 Days) Cause: ------- After commit 28b69da, the UoM model was restructured, changing how conversions between hours and days are computed. https://github.com/odoo/odoo/blob/aeda822db05b218fd1271c7666307950b7a98512/addons/hr_timesheet/models/project_project.py#L137-L143 The `total_timesheet_time` value is now already stored in the final unit (e.g., days). Whenever a new project update is created, the division in `create()` performs an unnecessary second conversion on an already converted value, causing the incorrect display. https://github.com/odoo/odoo/blob/583bacdc8ad2b87b99b11d1e12dacf6e42edf22b/addons/hr_timesheet/models/project_update.py#L36-L37 Solution: ---------- This commit ensures accurate conversion of timesheet values between hours and days. opw-5184077 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237532
This update resolves an issue where the 'picked' status on a stock move remained marked after undoing a package action. The fix ensures the 'picked' status is correctly reset when a package is undone, preventing disruptions in availability checks. This improves the reliability of inventory management.
Original PR description
### Issue: To reproduce the bug: 1. Activate `Packages` settings in Inventory: 2. Activate `Move entire packages` on picking type `delivery orders` 3. Create new product `Test move package` 4. Update…
### Issue:
To reproduce the bug:
1. Activate `Packages` settings in Inventory:
2. Activate `Move entire packages` on picking type `delivery orders`
3. Create new product `Test move package`
4. Update quantity in `WH/Stock` with a newly created package and a qty (eg 5)
5. Go to the delivery orders and create a new picking with the created product and a quantity of 5
6. Click on `Mark as Todo`, the picking is set as ready and a package level is created automatically to move the quantity we did put in stock in the package.
7. Mark the checkbox `Done` on the package level (this will mark the move line and the move as picked)
8. Unmark the checkbox `Done` on the package level.
The package level is deleted, as well as the stock move line,
but the stock move still has the checkbox picked that is
marked.
The picking is then in waiting state and we cannot check
availability again.
Currently to be able to check the availability, the picked
check should be undone manually.
### Cause of issue
Currently, in `_compute_picked` in `stock_move`, we don't
update value of move.picked if there is `no move_line_ids`
present which is wrong.
### Fix:
In the fix, picked is set to False when there no
`move_line_ids`
### Issue 2
This fix cause another issue, in which the move loses its `picked` status after manually setting the done quantity when no stock was initially available,
### Cause of issue 2
To be more specific this fix on `_compute_picked`
```diff
- elif move.move_line_ids:
move.picked = False
+ else:
move.picked = False
```
has the following side effect:
- On a confirmed picking, pick a move with a quantity of 0 then change the quantity to 10 the move is unpicked -> undesirable.
After you picked the move, when you set the quantity, you will set `move_line_ids` on your move to match the quantity increase here:
https://github.com/odoo/odoo/blob/57c0ce5f0af9b46c037759d85205bc3e88890af7/addons/stock/models/stock_move.py#L2157-L2165
However,`self._set_quantity_done_prepare_vals(qty)` does not return a `stock.move.line` record set but a `Command.create` whose values do not contain any info on the picked value of the move *line*:
https://github.com/odoo/odoo/blob/57c0ce5f0af9b46c037759d85205bc3e88890af7/addons/stock/models/stock_move.py#L1497-L1507
The fact that the `move_line_ids` is set on the move to this command.create, flags the `picked` field of the stock move to dirty and adds it to the field to recompute because of the dependency `move_line_ids.state`:
https://github.com/odoo/odoo/blob/57c0ce5f0af9b46c037759d85205bc3e88890af7/addons/stock/models/stock_move.py#L208-L209
https://github.com/odoo/odoo/blob/57c0ce5f0af9b46c037759d85205bc3e88890af7/odoo/api.py#L795-L800
THEN, the creation of the move.line happends and since the value of the picked was not set in the command.create, we populate it based on the picked value of the move:
https://github.com/odoo/odoo/blob/57c0ce5f0af9b46c037759d85205bc3e88890af7/addons/stock/models/stock_move_line.py#L347-L348
However, at this point since the picked value of the move has been flagged as dirty it is recomputed using the `compute_method` modified in our fix.
And since the move does not have any move line at this stage, it is computed to be picked = False resetting the picked value.
### Fix of Issue 2:
We should set the picked values in the vals here:
https://github.com/odoo/odoo/blob/57c0ce5f0af9b46c037759d85205bc3e88890af7/addons/stock/models/stock_move.py#L1497-L1507
opw-4964561
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#222034This update corrects a technical issue where text labels from buttons (specifically the 'confirm-title' attribute) were not being included in Odoo's translation files. This ensures these messages can be properly translated and displayed correctly in the user interface for all languages. This improves the localization process and user experience.
Original PR description
Description of the issue/feature this PR addresses: The texts from the "confirm-title" attribute of a <button> tag are missing from the POT files. Current behavior before PR: In this line there is a text (the caption of the confirmation window): https://github.com/odoo/odoo/blob/19.0/addons/mass_mailing/views/mailing_mailing_views.xml#L66 "Ready to unleash emails?" - This text is missing from the POT file. Desired behavior after PR is merged: * These texts will apeear in POT files. * Someone needs to translated them * It will show up as translated texts in UI --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue that previously stopped users from creating new Amazon accounts for new companies. The fix ensures that the system correctly handles the absence of warehouses and stock locations when a company is initially set up, preventing a technical error.
Original PR description
Currently, an error occurs when user tries to create a new amazon account on a new company. Steps to replicate: - Install `sale_amazon`. - Create a new company and switch to it. - Go to Settings >…
Currently, an error occurs when user tries to create a new amazon account on a new company.
Steps to replicate:
- Install `sale_amazon`.
- Create a new company and switch to it.
- Go to Settings > Amazon account > Try to Create a new account.
Error:
```
File /home/odoo/odoo18/enterprise/sale_amazon/models/amazon_account.py, line 214, in create
'location_id': parent_location_data[0]['view_location_id'][0],
IndexError: list index out of range
```
Cause:
- Whenever a new company is created, it doesnt have any warehouses [1] and amazon stock locations [2].
- This causes the `parent_location_data` to be an empty list and causes error at line [3].
Solution:
- Assigning the `location_id` if the `parent_location_data` exists.
[1]: https://github.com/odoo/enterprise/blob/23f085bdba333807a25a2d41214b25f474c7edf8/sale_amazon/models/amazon_account.py#L206-L210
[2]: https://github.com/odoo/enterprise/blob/23f085bdba333807a25a2d41214b25f474c7edf8/sale_amazon/models/amazon_account.py#L201-L204
[3]: https://github.com/odoo/enterprise/blob/23f085bdba333807a25a2d41214b25f474c7edf8/sale_amazon/models/amazon_account.py#L214
sentry-7086464738
Forward-Port-Of: odoo/enterprise#101465This update corrects a discrepancy in the number of employees flagged with invalid bank account warnings within the payroll dashboard. The fix ensures accurate reporting by uniquely identifying employees and optimizing database queries to avoid redundant data processing. This improves the reliability of payroll reporting.
Original PR description
description: - `warning_count` for `hr_payroll_dashboard_warning_employee_invalid_bank_account` is wrong when there are multiple versions for a single employee. steps to reproduce: - install `hr_payroll_account_iso20022` - open Payroll (note: have atleast one employee with multiple versions) - find "Employees With Invalid IBAN Bank Accounts" warning on the dashboard - note the count and click on it, the record count differs fix: - returned unique employee ids from `_get_invalid_iban_employee_ids` - also optimized the query in `_get_account_holder_employees_data` method. reasoning: we do not need bank account data from all the versions, because all the versions share same bank account data. task-5252854
A memory issue occurred during the search for sale order lines related to deferred revenue, specifically when filtering based on invoiced and delivered dates. This resulted in a crash due to excessive memory consumption during the optimization process. The fix addresses the underlying issue in the domain optimization logic.
Original PR description
**Description:** - The ir.actions.act_window [Invoices To Be Issued and Invoiced Not…
**Description:**
- The ir.actions.act_window [Invoices To Be Issued and Invoiced Not Delivered](https://github.com/odoo/enterprise/blob/19.0/sale_account_accountant/views/sale_order_line_views.xml#L73-L91) menus from the sale_account_accountant module were causing memory errors on databases with millions of sale.order.line records. These actions call [_search_invoice_to_be_issued and _search_deferred_revenue](https://github.com/odoo/enterprise/blob/master/sale_account_accountant/models/sale_order_line.py#L17-L29), which iterate over all lines and access the non-stored computed fields [qty_delivered_at_date](https://github.com/odoo/odoo/blob/master/addons/sale/models/sale_order_line.py#L905) and [qty_invoiced_at_date](https://github.com/odoo/odoo/blob/master/addons/sale/models/sale_order_line.py#L985) As a result, qty_delivered and qty_invoiced were repeatedly recomputed, leading to excessive memory usage.
- To fix this, we now pre-fetch these fields so the compute method can directly use the values already loaded in memory.
```
matu_3306966_19.0=> select count(*) from sale_order_line;
count
---------
2159957
(1 row)
```
**Traceback1:**
```
2025-12-03 07:02:25,973 9344 ␛[1;31m␛[1;49mERROR␛[0m matu_3306966_19.0 odoo.addons.base.maintenance.migrations.base.testsodoo.upgrade.base.tests.test_mock_crawl: Adding menu ('sale_account_accountant.menu_sale_order_line_accrual_to_bill_action', 1295, 'Accounting > Review > Sales > Invoices To Be Issued', 2690) to the failing menus
Traceback (most recent call last):
File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 333, in crawl_menu
self.mock_action(action_vals)
File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 346, in mock_action
return self.mock_act_window(action)
File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 506, in mock_act_window
mock_method(model, view, fields_list, domain, group_by)
File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 644, in mock_view_list
return self.mock_view_tree(model, view, fields_list, domain, group_by)
File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 655, in mock_view_tree
self.mock_web_read_group(model, view, domain, group_by, fields_list, limit_group=5)
File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 713, in mock_web_read_group
data = model.web_read_group(domain, [groupby], aggregates, limit=limit)["groups"]
File "/home/odoo/src/odoo/19.0/addons/web/models/models.py", line 397, in web_read_group
groups, length = self._formatted_read_group_with_length(
File "/home/odoo/src/odoo/19.0/addons/web/models/models.py", line 465, in _formatted_read_group_with_length
groups = self.formatted_read_group(
File "/home/odoo/src/odoo/19.0/addons/web/models/models.py", line 830, in formatted_read_group
groups = self._read_group(
File "/home/odoo/src/enterprise/19.0/sale_account_accountant/models/sale_order_line.py", line 33, in _read_group
return self._read_group_for_accrual(domain, groupby, aggregates, having, offset, limit, order)
File "/home/odoo/src/enterprise/19.0/account_accountant/models/analytic_mixin.py", line 21, in _read_group_for_accrual
return super()._read_group(domain, groupby, aggregates, having, offset, limit, order)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 1904, in _read_group
query = self._search(domain)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 5361, in _search
domain = domain.optimize_full(self)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 445, in optimize_full
return self._optimize(model, OptimizationLevel.FULL)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 459, in _optimize
previous, domain = domain, domain._optimize_step(model, next_level)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 653, in _optimize_step
children = self._flatten(child._optimize(model, level) for child in self.children)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 608, in _flatten
for child in children:
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 653, in <genexpr>
children = self._flatten(child._optimize(model, level) for child in self.children)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 459, in _optimize
previous, domain = domain, domain._optimize_step(model, next_level)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 957, in _optimize_step
domain = self._optimize_field_search_method(model)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 1016, in _optimize_field_search_method
return Domain.OR(Domain(field.determine_domain(model, '=', v), internal=True) for v in value)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 309, in OR
return DomainOr.apply(Domain(item) for item in items)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 595, in apply
children = cls._flatten(items)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 608, in _flatten
for child in children:
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 309, in <genexpr>
return DomainOr.apply(Domain(item) for item in items)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 1016, in <genexpr>
return Domain.OR(Domain(field.determine_domain(model, '=', v), internal=True) for v in value)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1921, in determine_domain
return determine(self.search, records, operator, value)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 81, in determine
return needle(*args)
File "/home/odoo/src/enterprise/19.0/sale_account_accountant/models/sale_order_line.py", line 28, in _search_invoice_to_be_issued
ids = [line.id for line in so_lines if line.qty_invoiced_at_date < line.qty_delivered_at_date]
File "/home/odoo/src/enterprise/19.0/sale_account_accountant/models/sale_order_line.py", line 28, in <listcomp>
ids = [line.id for line in so_lines if line.qty_invoiced_at_date < line.qty_delivered_at_date]
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1737, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1908, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/19.0/addons/base_automation/models/base_automation.py", line 907, in _compute_field_value
return _compute_field_value.origin(self, field)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 4949, in _compute_field_value
determine(field.compute, self)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 81, in determine
return needle(*args)
File "/home/odoo/src/odoo/19.0/addons/sale/models/sale_order_line.py", line 989, in _compute_qty_invoiced_at_date
line.qty_invoiced_at_date = line.qty_invoiced
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1693, in __get__
recs._fetch_field(self)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3769, in _fetch_field
self.fetch(fnames)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3809, in fetch
fetched = self._fetch_query(query, fields_to_fetch)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3930, in _fetch_query
field._insert_cache(fetched, values)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1600, in _insert_cache
collections.deque(map(field_cache.setdefault, records._ids, values), maxlen=0)
MemoryError
```
**Traceback2:**
```
2025-12-03 07:02:30,098 9344 ␛[1;31m␛[1;49mERROR␛[0m matu_3306966_19.0 odoo.addons.base.maintenance.migrations.base.testsodoo.upgrade.base.tests.test_mock_crawl: Adding menu ('sale_account_accountant.menu_sale_order_line_accrual_deferred_revenues_action', 1296, 'Accounting > Review > Sales > Invoiced Not Delivered', 2691) to the failing menus
Traceback (most recent call last):
File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 333, in crawl_menu
self.mock_action(action_vals)
File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 346, in mock_action
return self.mock_act_window(action)
File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 506, in mock_act_window
mock_method(model, view, fields_list, domain, group_by)
File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 644, in mock_view_list
return self.mock_view_tree(model, view, fields_list, domain, group_by)
File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 655, in mock_view_tree
self.mock_web_read_group(model, view, domain, group_by, fields_list, limit_group=5)
File "/tmp/tmpe9cqlr9_/migrations/base/tests/test_mock_crawl.py", line 713, in mock_web_read_group
data = model.web_read_group(domain, [groupby], aggregates, limit=limit)["groups"]
File "/home/odoo/src/odoo/19.0/addons/web/models/models.py", line 397, in web_read_group
groups, length = self._formatted_read_group_with_length(
File "/home/odoo/src/odoo/19.0/addons/web/models/models.py", line 465, in _formatted_read_group_with_length
groups = self.formatted_read_group(
File "/home/odoo/src/odoo/19.0/addons/web/models/models.py", line 830, in formatted_read_group
groups = self._read_group(
File "/home/odoo/src/enterprise/19.0/sale_account_accountant/models/sale_order_line.py", line 33, in _read_group
return self._read_group_for_accrual(domain, groupby, aggregates, having, offset, limit, order)
File "/home/odoo/src/enterprise/19.0/account_accountant/models/analytic_mixin.py", line 21, in _read_group_for_accrual
return super()._read_group(domain, groupby, aggregates, having, offset, limit, order)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 1904, in _read_group
query = self._search(domain)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 5361, in _search
domain = domain.optimize_full(self)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 445, in optimize_full
return self._optimize(model, OptimizationLevel.FULL)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 459, in _optimize
previous, domain = domain, domain._optimize_step(model, next_level)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 653, in _optimize_step
children = self._flatten(child._optimize(model, level) for child in self.children)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 608, in _flatten
for child in children:
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 653, in <genexpr>
children = self._flatten(child._optimize(model, level) for child in self.children)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 459, in _optimize
previous, domain = domain, domain._optimize_step(model, next_level)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 957, in _optimize_step
domain = self._optimize_field_search_method(model)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 1016, in _optimize_field_search_method
return Domain.OR(Domain(field.determine_domain(model, '=', v), internal=True) for v in value)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 309, in OR
return DomainOr.apply(Domain(item) for item in items)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 595, in apply
children = cls._flatten(items)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 608, in _flatten
for child in children:
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 309, in <genexpr>
return DomainOr.apply(Domain(item) for item in items)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 1016, in <genexpr>
return Domain.OR(Domain(field.determine_domain(model, '=', v), internal=True) for v in value)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1921, in determine_domain
return determine(self.search, records, operator, value)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 81, in determine
return needle(*args)
File "/home/odoo/src/enterprise/19.0/sale_account_accountant/models/sale_order_line.py", line 21, in _search_deferred_revenue
ids = [line.id for line in so_lines if line.qty_invoiced_at_date > line.qty_delivered_at_date]
File "/home/odoo/src/enterprise/19.0/sale_account_accountant/models/sale_order_line.py", line 21, in <listcomp>
ids = [line.id for line in so_lines if line.qty_invoiced_at_date > line.qty_delivered_at_date]
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1737, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1908, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/19.0/addons/base_automation/models/base_automation.py", line 907, in _compute_field_value
return _compute_field_value.origin(self, field)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 4949, in _compute_field_value
determine(field.compute, self)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 81, in determine
return needle(*args)
File "/home/odoo/src/odoo/19.0/addons/sale/models/sale_order_line.py", line 989, in _compute_qty_invoiced_at_date
line.qty_invoiced_at_date = line.qty_invoiced
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1693, in __get__
recs._fetch_field(self)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3769, in _fetch_field
self.fetch(fnames)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3809, in fetch
fetched = self._fetch_query(query, fields_to_fetch)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3930, in _fetch_query
field._insert_cache(fetched, values)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields_textual.py", line 243, in _insert_cache
super()._insert_cache(records, values)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1600, in _insert_cache
collections.deque(map(field_cache.setdefault, records._ids, values), maxlen=0)
MemoryError
```
- opw-5238152, 5269996
- upg-3306966, 3444833
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 change prevents distracting audio notifications during local testing of Odoo. It addresses a common frustration for developers encountering unexpected sounds from their systems, particularly old ringtones. This improves the testing experience and reduces interruptions.
Original PR description
When running tests locally, it's really annoying (and sometimes really jarring / surprising) to hear random beeps and boops from your machine, especially when it's an old timey ringtone from voip. Make it stop. Forward-Port-Of: odoo/odoo#238906 Forward-Port-Of: odoo/odoo#238882
This update fixes an issue where custom highlights with filling colors appeared darker than intended. By adjusting the opacity of these highlights, the blending of stroke and fill is now handled correctly, resulting in a cleaner and more consistent visual appearance. This improves the overall user experience when using the website's text editor.
Original PR description
We can use custom colors on highlights using the inline text editor, and when the highlight isn't a line (e.g., has a filling inside) and we set its color to have a different opacity than 100%, we can see the stroke and the filling overlap, and the semi-transparent colors blend together, creating a darker appearance along the edges. To see the issue: - Open the website and start editing - Select any text and apply a highlight with a filling, for example, freehand_3 - Click on Color, open the "Custom" tab, and slide the opacity slider down -> Observe the darker appearance along the edges of the highlight, which happens because the highlight svg has both `fill` and `stroke`. task-5104135
This update resolves an issue where the correct group wasn't being assigned to the teleworking field in the payroll module for Switzerland (l10n_ch_hr_payroll). This ensures accurate reporting and compliance with Swiss tax regulations related to remote work arrangements. The change improves the accuracy of payroll calculations.
Original PR description
Forward-Port-Of: odoo/enterprise#101691
This update addresses a restriction in the Enterprise version of Odoo's expense reporting system. Previously, expense reports using Stripe cards were automatically rejected based on validation rules. This change now allows for manual overrides, ensuring that expense reports can be approved regardless of the initial validation status. This improves flexibility and reduces potential delays in processing expense reports.
Original PR description
We need in the enterprise PR to change the autovalidation condition for stripe expense cards. task-4860676 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where product packages weren't correctly associated with their company during packing operations. The previous comparison logic incorrectly linked packages to company records, leading to inaccurate data. This change ensures packages are properly linked to their associated company, improving inventory tracking and reporting.
Original PR description
Steps to reproduce: - Have two packs, A & B - Put something in pack A - Put pack A in pack B Issue: Despite pack A having both a location & a company set, only the location is set on pack B. Due to a faulty comparison, we compare package records with company records, which means the `all()` condition will never be true. Fixes #236413 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where debugging employee records in the Saudi Arabia payroll module would generate errors due to a redundant, unused field. The field has been removed, streamlining the system and improving stability. This change aligns with our stable policy and ensures consistent data management.
Original PR description
### Issue: The field `l10n_sa_leaves_count_compensable` is a computed field with no compute method. When in debug mode, trying to look at the fields of an employee results in a traceback because of…
### Issue: The field `l10n_sa_leaves_count_compensable` is a computed field with no compute method. When in debug mode, trying to look at the fields of an employee results in a traceback because of this. ### Cause: This [forward port](https://github.com/odoo/enterprise/commit/4124dc4c13055d39d233d7ea9374b5191afdfcf2#diff-1d84d9d2c9ad02353f40d1b88baa5c66af063880df1e14459befd2d02d66cae5) had a conflict that was badly resolved by re-adding a previously deleted field. The field was replaced by `l10n_sa_remaining_annual_leave_balance` in [this commit](https://github.com/odoo/enterprise/commit/339bc032aa763c62d4dd27b73fc42488b3e1c3aa#diff-1d84d9d2c9ad02353f40d1b88baa5c66af063880df1e14459befd2d02d66cae5). [Failing FWP](https://github.com/odoo/enterprise/commit/b3f276d0d73a24faf322aa2ae8965c3d5aad4a87#diff-1d84d9d2c9ad02353f40d1b88baa5c66af063880df1e14459befd2d02d66cae5) ### Solution: We can no longer delete the field because of the stable policy. The solution is to remove the compute and add `store=False`. Then remove the field in master. opw-5352456
This update resolves an issue where the Website editor would crash when users pasted HTML code for embedded videos. The fix ensures the system correctly parses video URLs, preventing tracebacks and improving the reliability of video embedding functionality. This enhances the user experience when adding video backgrounds to website content.
Original PR description
Problem: A traceback occurs when adding an embedded video in the Website editor. Cause: The code uses `urlInput` as the URL source, but when an embed is pasted, `urlInput` contains HTML instead of a direct URL. Solution: Parse the `url` instead of using `urlInput` directly. Steps to reproduce: - Go to Website. - Add a slides snippet. - Change the background to video. - Paste embedded video HTML. - A traceback is triggered. opw-5265390 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where the approval date for expenses was incorrectly set to 1 AM. By using the current time, the system now accurately calculates the approval date, ensuring proper tracking of expense approvals. This improves the reliability of expense reporting.
Original PR description
When approving an expense, we compute the approval date. We used fields.Date.context_today(expense) that only the the date but the hours are set to 1 AM. By using field.Datetime.now() the hours are computed correctly. task-5262954 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where refund amounts in Point of Sale orders incorrectly inflated sales reports. The change ensures that refund totals accurately reflect zero, resolving miscalculations in the 'Untaxed Total' and 'Total' columns within the sales reporting interface. This improves the accuracy of sales data.
Original PR description
## Versions 19.0+ ## Issue Positive totals for refunds lead to miscalculation and wrong data in the sales report. A PoS order line and its refund should lead to a $0 total. ## Steps to reproduce *In…
## Versions
19.0+
## Issue
Positive totals for refunds lead to miscalculation and wrong data in the sales report. A PoS order line and its refund should lead to a $0 total.
## Steps to reproduce
*In the PoS app*
- Open a register:
- Sell 2 units of any product and process payment by cash;
- Validate payment;
- Navigate to "Orders" tab and filter on "Paid" orders (instead of "Active"):
- Select your latest order and refund 2 items;
- Process refund by cash and validate; *In the Sales app*
- Go to "Reporting > Sales" and change for list view:
- Display "Untaxed total" column;
- Filter on 2 last lines (by date and hour):
- The refund line has positive values for "Untaxed Total" and "Total column";
- The refund line has a "Untaxed Total" equal to the "Unit Price" but should be multiplied by the quantity;
- The bold totals are not equal to 0 for "Untaxed Total" and "Total" columns.
## Cause
Commit c5d4e4f73ac0474675414ee89555028b370f8e30 refactored all PoS taxes logic and there were some forgotten parts.
opw-5241438This update ensures Odoo IoT boxes can connect reliably, even with older database versions. The system now checks the IoT box's version and skips WebRTC usage if it's not compatible with the latest Odoo version, preventing connection issues. This improves compatibility and stability for IoT deployments.
Original PR description
Since odoo/odoo#238626, WebRTC support has been removed from the IoT box in `master` (19.1). However, since IoT boxes can now pair with older database versions, we need to be able to handle an IoT box that doesn't support WebRTC. This commit adds a check to the version field of the IoT box model, and if it matches the newer format used in 19.1+, WebRTC is skipped. task-5386539
This update corrects a bug in the Inventory at Date report that was preventing it from running correctly for certain products. The issue stemmed from the report incorrectly interpreting date inputs as strings, causing a comparison error. This change ensures the report accurately reflects inventory levels.
Original PR description
For products using lot valuation and real-time valuation, the Inventory at Date report may fail since the to_date value is provided as a string instead of a date or datetime object. This leads to a comparison error when generating the report. Steps to reproduce: - Create a product with lot tracking and real-time valuation, and lot valuated - Create and receive a purchase order for this product - Open Inventory > Reports > Inventory at Date - An error occurs due to a comparison between a string and a date opw-5362378
This update resolves a crash that occurred when users clicked the GIF picker within knowledge article comments. The fix adjusts how the composer picker identifies action placement, ensuring it correctly recognizes buttons within 'extra actions' like those found in chatter. This prevents the application from unexpectedly closing.
Original PR description
Before this commit, opening gif picker in a comment of a knowledge article would lead to crash. This happens because composer uses chatter visual, and pickers in composer picks either the quick or more node element as anchor of picker, depending on whether the action is in the quick or more action. In the case of knowledge article, the buttons are placed in extra actions like in chatter. However the picker placement was not taking into account this place, thus it fails to find action placement. This commit fixes the issue by adding support of extra actions as anchor for composer picker. Task-5163888
This update corrects a warning message related to date and duration calculations for work entries, specifically those linked to holidays. The change ensures that the system accurately prevents overlapping work entries, addressing a potential data inconsistency. This resolves a technical issue that could have impacted reporting accuracy.
Original PR description
Problem ---------- This warning message doesn't make sens with the transformation of work entries date_start/stop in date+duration. No overlap is possible. task-5349515
This update fixes an issue where attendance durations were incorrectly calculated when check-ins occurred before an employee's scheduled start time. Now, work entries are automatically generated upon attendance approval, streamlining the process and eliminating the need for manual intervention. This ensures accurate tracking of working hours and overtime.
Original PR description
Before this commit: - For an employee with a Working Schedule as the work entry source and a default overtime ruleset (which creates a specific work entry type for overtime hours), creating an…
Before this commit: - For an employee with a Working Schedule as the work entry source and a default overtime ruleset (which creates a specific work entry type for overtime hours), creating an attendance with a check-in earlier than the employee’s normal working schedule start was not handled correctly. The early portion was ignored, resulting in a wrong attendance work entry duration (e.g., 06:15 instead of 08:00). - Work entries were not created automatically when approving the attendance. The user had to click Reset to force the generation, which is not the intended workflow. After this commit: - Attendance boundaries are now correctly normalized against the employee’s Working Schedule, ensuring the full expected duration is taken into account, even when the check-in occurs before the official start time. - The overtime ruleset is applied correctly, and the generated intervals properly reflect both standard working hours and overtime hours. - Work entries are now automatically created upon approval of the attendance, removing the need for any manual Reset action. task-5082562
This update fixes an issue in the Purchase Order Comparison view where unit prices were incorrectly displayed based on the purchase order's unit of measure. The change now displays unit prices in the product's standard unit of measure, providing a more accurate comparison of purchase costs. This ensures better decision-making regarding purchasing quantities and pricing.
Original PR description
**Problem:** In the Purchase Comparison view the unit price is expressed in the uom of the purchase order line so two purchase order lines with different uom will be compared without the client…
**Problem:**
In the Purchase Comparison view the unit price is
expressed in the uom of the purchase order line
so two purchase order lines with different uom will
be compared without the client knowing it.
**Steps to reproduce:**
- create a new product
- set a unit cost of 1
- in the sales tab, in the packagings add
pack of 6
- Create and confirm a PO for 6 unit of this
product
- create and confirm a PO for 1 pack of 6 of
this product
- on the second PO click on the 'price comparison'
smart button
**Current behavior:**
The unit price average on the group by line
is 3.5.
If you click on the line you'll see that the
price unit for the second purchase order line
is expressed in the uom of the purchase order
line (so here it is 6$ per pack of 6).
So the average does not realy make sense.
**Cause of the issue:**
On the purchase order lines price_unit
is expressed in the UoM of the line and not the
uom of the product
**fix:**
We replace the unit price column by a column
with a unit price expressed in the uom of
the product.
The trade off is that, because the new field
is not stored, we don't have an average in
the group by line anymore.
opw-5220196This fix resolves an issue where the cost of goods sold (COGS) was incorrectly calculated for sales orders with partial deliveries. The update ensures accurate COGS calculation, either with a total COGS of 8.5 or separate values of 7 and 10, based on the order's delivery status. This improves financial reporting accuracy.
Original PR description
**Problem:** partial cogs are not correctly computed (no test in the commit, waiting for the new setup…
**Problem:**
partial cogs are not correctly computed
(no test in the commit, waiting for the new setup
https://github.com/odoo/odoo/blob/a3db18acf8010c989c17ea69ad8eb1f0d6bd6116/addons/sale_stock/tests/test_anglo_saxon_valuation.py#L15)
**Steps to reproduce:**
- create a storable product FIFO/Perpetual
- Order 1 unit of product at 7
- Receive
- Order a second unit at 10
- Receive
- Create SO of 2 units
- Deliver 1 with a backorder
- Invoice one
- Deliver the second
- Invoice remaining
**Current Behavior**:
The first invoice will show double the COGS it is
supposed to (14 instead of 7).
The second invoice shows proper COGS (10)
**Expected behavior:**
Either both cogs should be 8.5 or the first one 7 and
the second one 10.
**Cause of the issue:**
There is two issues here :
- *The first issue* is that when confirming the invoice,
_post() calls _set_value() on the moves.
https://github.com/odoo/odoo/blob/3ce8e3e4e8049eb009ed05bdc3a33275c9eec0d6/addons/stock_account/models/account_move.py#L42
In the case of a fifo move this is a problem because
run_fifo is going to be called and the value of the move
is going to be wrongly recomputed based on the current
fifo stack.
This issue can be illustrated by a simpler use case:
- fifo product
- one move in at 7, one move in at 10
- SO for one product and validate the delivery
- the value of the move is 7
- create and confirm invoice -> the value of the move is now 10
- *The second issue* is about the cogs computation :
in the case of a fifo product, _get_cogs_value() calls
_get_price_unit() on the moves of the sale order line
(fetched via _get_stock_moves()) to compute the unit price.
https://github.com/odoo/odoo/blob/a3db18acf8010c989c17ea69ad8eb1f0d6bd6116/addons/stock_account/models/account_move_line.py#L73
So when computing the cogs for the first invoice:
Inside _get_price_unit(), the value of our back order
move (not yet validated) will be taken into account
in the computation of total_value.
But because the stock move lines of this move are not
picked yet, it's quantity will not be taken into account in
the computation of total_qty (because get_valued_qty() calls
_get_out_move_line() which does not return the unpicked lines).
https://github.com/odoo/odoo/blob/a3db18acf8010c989c17ea69ad8eb1f0d6bd6116/addons/stock_account/models/stock_move.py#L217-L218
So the return value will be 14 (the value of the 2 moves)
divided by 1 (the quantity of only the first move)
**Fix**
There is two possibility for the cogs in this situation :
1) cogs of 7 on the first invoice and then later cogs of 10
on the second invoice
2) cogs of 8.5 on both invoices
In the current state of the code, the value of the second fifo
move (10) is not yet set, it will be set when the move is validated.
Therefore we have to go for option 1).
The first part of the fix is to be sure to fetch only 'done' moves
before using _get_unit_price.
The second part of the fix is to deduce the cogs already posted.
opw-5342803This update resolves an issue where the SHA512 hashing process in the Swedish SE-SIE import module was not correctly implemented. The fix ensures accurate data integrity for tax reporting, preventing potential errors and compliance issues. This update improves the reliability of the import process for Swedish businesses.
Original PR description
Forward-Port-Of: odoo/enterprise#101511
This update ensures that cart notification pop-ups accurately reflect the website's tax settings (included or excluded). Previously, the price displayed didn't align with the configured website tax rules. This change corrects a discrepancy between website and backend invoicing tax configurations, improving the customer experience.
Original PR description
The displayed price in the notification pop-up has to follow the website settings (tax included/excluded) and not the backend invoicing settings. **How to reproduce the issue:** Invoicing Taxes settings: Tax Prices = Tax Excluded Website settings: Display Product Prices = Tax Included **Description of the issue/feature this PR addresses:** The price on the cart notification doesn't include the tax while the website settings says it should. <img width="1107" height="569" alt="image" src="https://github.com/user-attachments/assets/629e89c9-a9c9-4932-b36b-97416e747d83" />
This update fixes an issue where form fields without labels weren't being submitted. Now, all form fields, even those without labels, are correctly transmitted when the 'send' button is clicked. Additionally, the system now prevents users from removing labels, ensuring data integrity.
Original PR description
Before this commit, a form input without a label would not send its data when clicking send. Steps to reproduce - go to the website editor - add a form - choose any field - delete the field label - save and exit the editor - now in the website, fill the form and click send => the fields without a name label are not sent After this commit fields without a label get sent with a placeholder "unknown_field" task-5062575 Forward-Port-Of: odoo/odoo#237805 Forward-Port-Of: odoo/odoo#225545
This update corrects a bug where work entry durations were not accurately calculated, leading to potential conflicts when editing or adding entries on the same day. The fix ensures that the system correctly sums the duration of all work entries for a given day, regardless of whether they are new or existing, improving data accuracy.
Original PR description
Problem ---------- Work entries on the same day were in conflict only if a work entry was created with a duration > 1000h Even if we write an existing work entry with a duration > 1000h => no conflict. Event if we create multiple work entries, it will only make the sum of work entries created and not existing ones Solution ---------- Check the sum of duration for a day between 0 and 24 hours. Fetch all work entries matching the date of the check to make the sum of durations task-5349515
This update fixes a bug that caused the system to crash when uninstalling the Invoicing module. The issue stemmed from leftover data related to the account.asset model, which wasn't being properly removed during uninstallation. The fix adds an uninstall hook to clean up this data, ensuring a smoother module removal process.
Original PR description
**Steps to reproduce:** - Install `Accounting` module without demo data. - Go to Accounting > Configuration > Settings > Set fiscal localization as `United States`. - Go to `Apps > Accounting >…
**Steps to reproduce:** - Install `Accounting` module without demo data. - Go to Accounting > Configuration > Settings > Set fiscal localization as `United States`. - Go to `Apps > Accounting > uninstall`. - Now try to uninstall `Invoicing` module. [`l10n_us_account`](https://github.com/odoo/odoo/blob/e1dd3852b118eacc8d77e9e3d8c7769195c6edb1/addons/l10n_us_account/data/template/account.asset-us.csv#L2-L8) defines data for the `account.asset` model. When removing `account_accountant`,`account_asset` module and model are removed, but their data is still in `ir.model.data`. As a result, when trying to uninstall the `Account` module, it attempts to delete records of a model that no longer exists, leading to a traceback. `KeyError: 'account.asset'` Since this issue occurs in multiple modules, we need to ensure that all related `account.asset` records are unlinked from `ir.model.data`. We added an `uninstall_hook` in the `account_asset` module to remove these records during uninstallation. Other modules are: `l10n_be,l10n_eg,l10n_pk,l10n_uk,...` **sentry-6938852090**
This update corrects a bug in Odoo 19.0 where setting an employee's timezone to 'None' would cause an error. Now, if the timezone field is left blank, Odoo will display a validation error, ensuring accurate data entry and preventing potential issues with employee records. This improves data integrity and reliability.
Original PR description
Description of the issue/feature this PR addresses: On Odoo 19.0 and master, setting an employee’s timezone to None would cause a traceback when creating or updating the employee. Current behavior before PR: a traceback when creating or updating the employee. Desired behavior after PR is merged: A Validation Error occurs because it missing required value for the field 'Timezone' (tz). Model: 'Resources' (resource.resource) task-5257749 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where accountants were blocked from opening invoices due to lack of POS access rights. The change adjusts how access rights are checked, allowing accountants to process invoices by searching in sudo mode and returning records without requiring POS permissions. This improves usability for a key user group.
Original PR description
The aim of this commit is to allow accountants to open the invoices without getting blocked because they don't own the pos access rights. Context: It seems that the ORM is now checking the access rights over M2M which creates a lot of access rights issues. Before this commit: The computation of `l10n_mx_edi_update_sat_needed` and the method `l10n_mx_edi_cfdi_try_sat` would cause an access right issue. Cause: The method `_get_update_sat_status_domain` could be override in l10n_mx_edi_pos and add a check on `<l10n_mx_edi.document>.pos_order_ids` on which the accountant might not have access. (The same issue would happens to a user processing a stock picking) After this commit: We search the domain in sudo mode and return unsudoed records allowing the user to pursue its task. opw-5263759 opw-5263824
This update ensures that VIES validation remains accurate when a company is created for a contact, even if the initial validation fails due to network issues. Previously, a failed VIES check could lead to incorrect B2C fiscal positions being applied to future orders. This fix maintains the validated status, guaranteeing correct B2B fiscal handling.
Original PR description
Use case: - prerequisite: enable "vies" validation on the company - a customer create from an account from the website - from /my/account he edit his information, filling in: * the company name * the…
Use case: - prerequisite: enable "vies" validation on the company - a customer create from an account from the website - from /my/account he edit his information, filling in: * the company name * the vat number The VIES validation succeed and for future orders/invoices the B2B fiscal position will be correctly applied. - then later, a backend user go the user's contact form and click on the `create company` button. Here when creating the new "company" partner and then linking the contact to it, we will trigger the recomputation of the `vies_valid` field on the new "company" partner. At that time, if the new VIES validation performed fail because of an network error or because the service is overloaded (`MS_MAX_CONCURRENT_REQ`) the `vies_valid` will be reset to `False`; and on future orders/invoices a wrong fiscal position (B2C) will be applied. This commit ensure we keep the previously performed VIES validation when creating the company of a contact. opw-5365258 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where inactive accounts were incorrectly displayed in financial reports. The change, related to a new 'active' field, prevents the system from processing inactive accounts in report calculations and auditing, ensuring accurate reporting. This improves data integrity and reporting reliability.
Original PR description
In replacing the deprecated field with the special `active` field the account_codes prefix engine no longer displays values for accounts that are inactive.
This disables the active test in:
- computing the domain for accounts
- auditing the value (since the domain is `('account_id.code', 'in'...)`
opw-5226153
Forward-Port-Of: odoo/enterprise#100885This update corrects an issue in the l10n_ar_stock delivery guide report where a critical message about invoice validity was missing. The fix also eliminates duplicate report names and numbers, ensuring consistent and accurate reporting. This improves the reliability of financial reports for Arabic-speaking customers.
Original PR description
The mention "Document not valid as an invoice" is missing in the delivery guide report. And we shouldn't duplicatethe report name and number. opw-5004345 Forward-Port-Of: odoo/odoo#234506
This update resolves an issue where clicking a record in the Field Service module's Kanban view with the middle mouse button opened the record in the same tab instead of a new one. The fix ensures that middle-mouse clicks correctly open records in new tabs, improving user workflow and efficiency.
Original PR description
Steps to reproduce: 1. Install `industry_fsm` 2. Open Field service module 3. In the kanban view, click a record with the middle mouse button Issue: - The record opens in the same tab instead of a new tab. Cause: - `FsmMyTaskKanbanRecord` overrides `onGlobalClick` without propagating the `newWindow` argument, preventing the expected new-tab behavior. Solution: - Forward the `newWindow` parameter to the parent implementation to restore the correct handling of the middle mouse click opw-5351842 Forward-Port-Of: odoo/enterprise#100926
This update ensures that online self-order and kiosk payments are automatically sent to the kitchen (PDIS) upon confirmation, regardless of whether the user sees a confirmation page. Previously, reliance on the confirmation page was unreliable, leading to potential delays and confusion. This change improves order processing efficiency and accuracy.
Original PR description
pos_online_payment* = pos_online_payment_self_order_preparation_display Task: [#5217268](https://www.odoo.com/odoo/project/1737/tasks/5217268) --- Previously, when an online payment was made, the…
pos_online_payment* = pos_online_payment_self_order_preparation_display Task: [#5217268](https://www.odoo.com/odoo/project/1737/tasks/5217268) --- Previously, when an online payment was made, the user was supposed to be redirected to a payment confirmation page which, once the transaction succeeded, sent the related order to the kitchen (PDIS). However, in some cases, the user never reaches this page. For example, the user may see the payment succeed in their banking app and close the tab before the redirection happens. For POS self-orders, we must send the order to the kitchen as soon as the payment is confirmed to avoid confusion between the customer, the cashier, and the kitchen staff. Relying solely on the confirmation page was therefore unreliable. --- To fix this, we now leverage the cron that post-processes payment transactions: we gather all transactions made in self-order or kiosk mode that are not yet post-processed, and send their corresponding orders to the kitchen. This ensures that orders reach the PDIS even when the user never lands on the confirmation page. Forward-Port-Of: odoo/enterprise#99249
This update fixes a bug that prevented invoices from being sent to Peppol when certain special characters were present in the data. The fix ensures that invoice data conforms to XML standards, preventing errors and ensuring successful Peppol communication. This improves the reliability of our Peppol integration.
Original PR description
## Issue: When a character that's not compatible with XML is in an invoice, and you send it to Peppol, a traceback was raised: `ValueError: All strings must be XML compatible: Unicode or ASCII, no NULL bytes or control characters` ## Cause: `dict_to_xml` converts each invoice field into XML, but certain control characters (e.g., `\x02`) are not allowed in XML according to the specification: https://www.w3.org/TR/xml/#charsets If such a character appears in the data (e.g., imported through a product CSV), the XML generation crashes ## Steps to produce: - Install `account_peppol` and `l10n_be` (to get the BE Company CoA) - Import a product containing a control character: `echo -e "name,default_code\nTest\x02Product,ABC123" > products.csv` - Create an invoice for the BE company using the product `Test\x02Product` - Send it via Send > by Peppol - A traceback is raised opw-5114648 Forward-Port-Of: odoo/odoo#239053 Forward-Port-Of: odoo/odoo#236836
This update fixes an issue where holiday pay recovery wasn't correctly applied to employees with older contracts. Previously, reopening contracts could incorrectly trigger the recovery process as if the employee was newly hired. This change ensures holiday pay recovery is applied accurately for all employees, regardless of contract history.
Original PR description
Purpose ======= Normally contracts start and end dates should be configured without being closed and reopened at each version date. But, if it is the case, holiday pay recovery could be applied on older employees because it is considered the employee just joined the company, and there is an amount to recover. Forward-Port-Of: odoo/enterprise#101564
This update resolves an issue preventing the payroll demo data installation from working correctly at the start of the year. The fix sets a fixed past year for Mitchell Admin's contract, ensuring the demo data aligns with current payroll calculations. This resolves a technical error reported by automated testing.
Original PR description
Before this commit, the relative date used to generate Mitchell Admin's contract was always at January 1st of the current year, making the payroll demo data install fail when at the start of the year. This commit sets a fixed year in the past for Mitchell's contract. runbot error 234623 and 234612 Forward-Port-Of: odoo/odoo#238711
This update ensures online payment orders are processed immediately, regardless of whether the user reaches the confirmation page. Previously, delays caused confusion for customers and cashiers. Now, the system automatically triggers order processing after receiving payment confirmation, leading to faster and more accurate order updates.
Original PR description
..., pos_online_payment_self_order Task: [#5217268](https://www.odoo.com/odoo/project/1737/tasks/5217268) --- Previously, when an online payment was made, the user was supposed to be redirected to a…
..., pos_online_payment_self_order Task: [#5217268](https://www.odoo.com/odoo/project/1737/tasks/5217268) --- Previously, when an online payment was made, the user was supposed to be redirected to a payment confirmation page, which triggered the payment transaction post-processing. However, in some cases, the user never reaches this page. For example: the user sees that the payment succeeded in their banking app and closes the tab before being redirected to the confirmation page. To still process the orders, a cron runs every 10 minutes to post-process transactions that were not processed yet. However, for POS self-orders this is not ideal: we need the order to be processed as soon as possible since we are in direct contact with the user. A situation where the customer insists their payment went through but the cashier sees no updated order creates unnecessary confusion. --- To fix this, we now trigger the cron directly after receiving the callback from the payment provider. This ensures that the transaction (and therefore the order) is always post-processed immediately and kept up-to-date, even if the user never reaches the confirmation page. Forward-Port-Of: odoo/odoo#238407 Forward-Port-Of: odoo/odoo#235254
This update fixes a technical issue within the HTML editor that caused a traceback when users selected a link and then applied a color. The fix ensures the editor correctly handles selections involving special characters like 'feff', preventing errors and improving the overall stability of the HTML editing functionality. This resolves a potential disruption for users.
Original PR description
Problem: When the user selects a link to color and the selection falls on a `feff` character, a traceback occurs. Cause: After commit 927f4b973932d14961c148e13473017651a60dc0, we preserve the…
Problem: When the user selects a link to color and the selection falls on a `feff` character, a traceback occurs. Cause: After commit 927f4b973932d14961c148e13473017651a60dc0, we preserve the selection at: https://github.com/odoo/odoo/blob/bee7fc1f955c52a88b527ad9a2ddf0021529bbc7/addons/html_editor/static/src/main/font/color_plugin.js#L247-L247 and then call `getFonts()`, which internally uses `this.dependencies.split.splitAroundUntil()`. If the selection is on a `feff` node, `splitAroundUntil()` can clear those nodes because `splitElement()` inside it dispatches to `clean_handlers` with the selected element containing the `feff`. Since the preserved cursor offset refers to the node before the `feff` was removed, restoring it throws: `The offset x is larger than the node's length (y).` Solution: After `splitAroundUntil()`, adjust the preserved cursor offsets if the nodes were mutated to ensure they remain valid. Steps to reproduce: It is difficult to reproduce manually, but the issue occurs when coloring a link with the selection on a `feff`. A test case replicating the situation can be based on the original failing template in the customer’s database. opw-4953943 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238922 Forward-Port-Of: odoo/odoo#234328
This update fixes an issue where timesheets weren't correctly reflecting new employee's time off requests. The change ensures that only global time off requests are considered, resolving a problem caused by incorrectly configured time-off records. This improves the accuracy of timesheet reporting.
Original PR description
**Steps to reproduce** 1. Have a future `resource.calendar.leaves` without a `calendar_id` but with a `resource_id`. To achieve this, you can for example install Payroll and Attendance, create a contract with the work entry source being attendances and with no working schedule. Then, create a time off in hours for that employee and validate it. In that case, the `hr.leave` has no `resource_calendar_id` as computed in `_compute_resource_calendar_id`. This leads to a `resource.calendar.leaves` record without a `calendar_id` once the time off is validated. 2. Create a new employee. A timesheet corresponding to the previously created time off is created. **Change** Make sure only global time offs are considered. opw-5248992 Forward-Port-Of: odoo/odoo#237773
This update corrects a critical issue where Swiss account translations were missing, particularly for payroll documents. This ensured all official documents were consistently translated, preventing mixed language content and maintaining compliance standards. The fix improves the accuracy and professionalism of Odoo's Swiss localization.
Original PR description
Some Swiss account translations were missing, mainly related to payroll. This resulted in payroll documents having mixed languages, which is not acceptable for official documents. opw-5343680 Forward-Port-Of: odoo/odoo#239122 Forward-Port-Of: odoo/odoo#239001
This update resolves a technical issue where setting image field widths in list views caused a system crash. The change clarifies that image field widths should be controlled through list view configurations, not the image field itself, ensuring stability and proper functionality for image displays in lists.
Original PR description
Before this commit, if one set the `width` attribute on an image field in a list view arch, there was a props validation crash (in debug mode). The `width` attribute is relevant to be set in list view archs as it allows to specify the width of the column. That attribute isn't meant to be used by the image field itself, where the option `size` can be used to specify the size of the image as a pair `[width, height]`. opw~5392068 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 Forward-Port-Of: odoo/odoo#239069
This update prevents a potential memory error that could occur during HR Timesheet installations on databases with many existing accounting records. The change ensures that new data fields are created efficiently, improving the installation process and reducing the risk of system slowdowns. This enhances the overall stability and performance of the HR Timesheet module.
Original PR description
Description ----------- On databases with a large count of existing `account.analytic.line` records, installing modules like `hr_timesheet`, which adds compute stored or related stored fields to this model can trigger a memory error due to the volume of records that need to be recomputed. This commit creates the columns manually with the correct default value that is inferred from the state and implementation of said fields. Reference --------- opw-5234833 opw-5255382 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239024
This update resolves a visual bug where the version timeline in the HR module would disappear when zoomed below 100%. Now, all versions remain visible regardless of the zoom level, ensuring a consistent and user-friendly experience for managing employee timelines.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: . When you zoom below 100%, the other versions from the version bar disapear, leaving only the active one Desired behavior after PR is merged: . When you zoom below 100%, all versions on timeline appears normally task-5401380 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents misleading 'Duplicate' warnings when reverting a payslip in the HR payroll module. Previously, reverting a payslip created related payslips flagged as duplicates, causing confusion. Now, the system correctly identifies these as related and avoids the duplicate warning, streamlining the payroll process.
Original PR description
## Steps to Reproduce 1. Create a payslip and validate it. 2. Mark it as Paid. 3. Click on Revert and it will create a new payslips related to the other payslip. ## Issue When reverting a payslip, it is flagged as a "Duplicate". When there is a payslip that has "Related payslips", it should not be considered as a duplicate. ## Fix Duplicate warnings now ignore the original and refund payslips linked to each other (`origin_payslip_id/related_payslip_ids`) are removed from the duplicate recordset. task - [5240436](https://www.odoo.com/odoo/project/1251/tasks/5240436)
This update resolves an issue where users couldn't select items within locked pills in the Gantt chart. Now, users can initiate selections on locked pills without the locking style being applied, providing a more intuitive and functional experience. This enhancement improves usability for managing tasks and dependencies.
Original PR description
This commit allows users to initiate multi-selection on locked pills. When starting a selection on a locked pill, the locked styling is no longer applied, and the selection behaves normally. task-5118978
This update fixes a potential issue where test results in Odoo's sale stock module could be inconsistent due to timing differences. The change ensures tests run predictably regardless of the machine's speed, improving the reliability of test results. This enhances the overall stability of the sale stock functionality.
Original PR description
In the case the test runs a machine not fast enough, by the time we reach either assert, there could be at least a millisecond difference between the two dates. Now freeze the time to ensure the test doesn't fail depending on its running speed. runbot-233470 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A test related to date handling in the stock account module was failing in community builds. This change corrects the issue by aligning the test's date locking behavior with established practices in the account module, ensuring consistent test results. This resolves a technical impediment to the stock account functionality.
Original PR description
…test_backdate_picking_with_lock_date ### Issue: The test `test_backdate_picking_with_lock_date` added in https://github.com/odoo/odoo/commit/4ea1853108a73f3d6b593785432f10b41ccc0041 fails in community builds. ### Cause of the issue: The `account.change.lock.date` model is defined in `account_accountant`: https://github.com/odoo/enterprise/blob/b3679bc04d4fcef1da7251e5ca061dfeabe89eae/account_accountant/wizard/account_change_lock_date.py#L11-L16 However, this module is not a dependency of the `stock_account` module. ### Fix: We set the lock_dates directly just as in the `account` tests: https://github.com/odoo/odoo/blob/e91c3817574af8bd48a634e3fb0b2f0e08b21ee9/addons/account/tests/test_account_move_date_algorithm.py#L52-L53 runbot-234673 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where rental receipts weren't being validated correctly in the barcode app. The change ensures that rental receipts, which are treated as partial deliveries, are handled properly, preventing validation errors. This improves the reliability of the rental process.
Original PR description
Steps to reproduce: - Enable Rental pickings - Create a rental for a product, for 4 quantity - Process the delivery - Open the barcode app and open the reception - Scan the product once and validate…
Steps to reproduce: - Enable Rental pickings - Create a rental for a product, for 4 quantity - Process the delivery - Open the barcode app and open the reception - Scan the product once and validate Issue: The receipt is validated without issues nor warning, despite being incomplete. This is due to a bad mix of two changes: - #60801, which always sets the rental receipt as return of the delivery - #48788, which removes the backorder check for returns in barcode For regular returns made in barcode, it makes sense to avoid the backorder check, as from here we're processing a full picking return and we'd have the confirmation pop every time. However, things are different for rental receipts, as despite them being set as returns of the delivery, they're proper receipts that need to handle the partial receipt. To avoid the issue, rather than removing the backorder check whenever there's a return linked to the picking, now also checks that there isn't a rental order linked to the picking. opw-5265874 Forward-Port-Of: odoo/enterprise#101387
This update corrects an issue where the payment term line name wasn't updated when changing the invoice's 'Customer Reference'. The fix addresses a technical detail within the system's calculations, ensuring consistent naming conventions for invoices and improving data accuracy. It resolves a discrepancy in how the system handles reference updates.
Original PR description
### Issue: When changing the "Customer Reference" on an invoice, the name of the payment term line is not updated. ### Steps to reproduce: - Create an invoice with payment terms, confirm it - Modify…
### Issue:
When changing the "Customer Reference" on an invoice, the name of the payment term line is not updated.
### Steps to reproduce:
- Create an invoice with payment terms, confirm it
- Modify its "Customer Reference" to 'test' for example
- In the page "Journal Items" the name of the terms line has been recomputed to "test - INV/2025/XXXXX"
- Modify again its "Customer Reference" to 'abcdef' for example
- In the page "Journal Items" the name of the terms line was not recomputed
### Cause:
In `_compute_name()` we only write the name if this condition is `True`:
```py
if n_terms > 1 or not line.name or line._origin.name == line._origin.move_id.payment_reference or (
line._origin.move_id.payment_reference and line._origin.move_id.ref
and line._origin.name == f'{line._origin.move_id.ref} - {line._origin.move_id.payment_reference}'
):
line.name = name
```
The purpose of this line is to keep the name of the line if it was manually inputted. So the logic is: we only write the computed name if the previous name was computed. To check this, we check if `line._origin.name == f'{line._origin.move_id.ref} - {line._origin.move_id.payment_reference}'`.
The issue comes from the use of `_origin` in a compute. `_origin` refers to the record before we make any change. But it is meant to be used for `onchange` methods, in these the values are not yet written so `_origin` refers to the record before saving.
Here, when saving, `line._origin` is the same as `line`, so
- `line._origin.move_id.ref` is the new ref.
- `line._origin.name` uses the old ref (it's currently being recomputed).
### Solution:
Unfortunately, in the compute, there are no trace left of what were the previous values as the write already occurred.
The initial complaint justifying to keep custom line names was that on bills, the line name is empty. So when inputting a custom line name, it was removed by the compute method. The previous fix wanted to be more general by always keeping custom line names.
Considering this, this commit removes part of the previous fix: Now we only keep the custom line name when the compute method wants to remove it. So we keep the previous fix for bills.
### Note
There was a test verifying exactly that when manually deleting the line name, in the end
the line does not have a name. This will no longer be the case but a decision must be made between:
1. updating the line name when changing the ref
2. not recomputing line name when it has been changed manually
3. removing the line name when it's manually deleted
We can have 2 and 3 but not with 1 afaik.
opw-5246917
Forward-Port-Of: odoo/odoo#237710This update fixes a limitation in how barcodes handle rental sales within Odoo. A new hook has been added, allowing businesses to customize barcode behavior specifically for rental transactions. This ensures accurate and consistent barcode scanning for both standard sales and rental operations.
Original PR description
Add a hook method to be used in barcode that can be overriden for `sale_stock_renting`. As there is no common module for these two module, this was put in their common ancestor. opw-5265874 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238753
This update fixes a visual issue where form fields, specifically those using 'Text' type, were displaying a placeholder of 'null' instead of an empty field. This change ensures that all form fields appear correctly, providing a consistent and user-friendly experience when editing website forms. It's a minor cosmetic fix that improves usability.
Original PR description
Steps to see the issue: - Open website and start editing - Drop a form - Add a new field, or click on an optional field, the type of which we can modify - Set the field type to 'Selection' or 'Radio Buttons' (or any other that does not have placeholders) - Set the field type back to 'Text' => Field's placeholder is `'null'`, but it should just be empty. task-5383835 Forward-Port-Of: odoo/odoo#238710
This update corrects a previous issue where employees working less than 6 months were incorrectly denied PFA (Pension Funds Agreement) eligibility. The change adjusts the system to verify an employee's start date is at least 6 months prior, rather than requiring a full 6-month employment period. This ensures accurate PFA calculations for all employees.
Original PR description
If you worked less than 6 months, you could have the right to the PFA. Instead of verifying that the employee worked for 6 full months, we should check that he started at least 6 months ago. task-5405293
This update corrects a display issue where single-value product attributes were appearing twice when the 'accordion' style was selected for product specifications. The fix utilizes a simple SCSS style adjustment, avoiding the need for complex view updates and ensuring consistent product display across the website.
Original PR description
### Issue: In this issue, when specification is set to accordion style, single value attributes is still displayed, making single value attributes duplicated. #### To reproduce: 1- Create a product…
### Issue: In this issue, when specification is set to accordion style, single value attributes is still displayed, making single value attributes duplicated. #### To reproduce: 1- Create a product with a multi-value and a single-value attribute. 2- Using editor on product website page, from style tab, change style of specification to `in accordion`. 3- As you see, single value-attribute is displayed twice. Once in accordion, and one in single-value attributes section. ### Cause: When `specification` is set to other than `None`, IMHO we need to not display `product_accordion` as single values are already displayed: https://github.com/odoo/odoo/blob/ea01165d9486572269c44597a1db49b31bf8aba3/addons/website_sale_comparison/views/website_sale_comparison_template.xml#L196-L209 When `specification` is set to `Bottom of Page`, this is already the case using xpath replace: https://github.com/odoo/odoo/blob/ea01165d9486572269c44597a1db49b31bf8aba3/addons/website_sale_comparison/views/website_sale_comparison_template.xml#L91-L94 However, we cannot do the same in `accordion_specs_item` as it is not inheriting `website_sale.product`. We can instead fix this using scss style, which also won't require updating views. opw-5365375
This update resolves a technical issue that prevented the correct extraction of invoice sequences, specifically when sequences didn't include spaces. The fix uses a regular expression to reliably identify the invoice number, regardless of the separator used (space, slash, or hyphen), ensuring accurate VAT processing.
Original PR description
Before this commit, the method `_get_last_sequence` assumed that the document sequence always contained a space separator (e.g., "INV 12345") It attempted to extract the folio number using `res.split(" ")[-1]`.
If the sequence format did not contain a space, such as the standard Odoo format `INV/2025/01234`, the split would return the entire string. This caused a `ValueError` when trying to cast the non-numeric string to an integer:
ValueError: invalid literal for int() with base 10: 'INV/2025/01234'
This commit fixes the issue by using a regular expression to extract the last group of digits from the sequence string. This ensures the folio number is correctly retrieved regardless of the separator used (slash, space, or hyphen).
opw-5401509
Forward-Port-Of: odoo/enterprise#101665