Thursday, June 19, 2025
46 changes · saas-18.3
Enhancements to existing features
The tax list views now include the 'Replaces' field so users can more easily see which taxes are being replaced. It is shown by default from Fiscal Positions and available as an optional column in the main tax list, improving tax configuration review without changing behavior.
Original PR description
Before this pr: The 'Replaces' field was not visible in the list view of the tax model, including when accessed via the Fiscal Position form view. After this pr: The 'Replaces' field is now available in both list views: - In the list view accessed from the Fiscal Position form view, it is visible by default. - In the main tax list view, it is available but hidden by default. Task: 4879111
The self-ordering flow now shows a clearer, more professional message when a point-of-sale session is inactive. This helps customers and staff better understand why ordering is unavailable, reducing confusion at the point of service.
Original PR description
Before this commit:
----------------
-The inactive session message was unclear.
After this commit:
-------------------------
-The message is now clearer and more professional.
Task-4797948The VoIP transfer screen now uses a solid transfer button instead of an outlined one. This small visual update makes the primary transfer action clearer and easier for users to recognize during calls.
Original PR description
This commit changes the style of the transfer button in the transfer view to be solid instead of outlined. ## Before  ## After 
Resolved issues and error corrections
This fixes a permission issue in an automated test for Italian electronic invoicing. It helps ensure invoice export checks run reliably when related Italian stock delivery features are installed without demo data.
Original PR description
Steps to reproduce: 1. install `l10n_it_stock_ddt` without demo data 2. run `test_export_invoice_with_two_downpayments` missing sudo in test case to create sale order in the test Error [link](https://runbot.odoo.com/odoo/error/163631) build_error-163631
Miscellaneous changes
**Note: issue discovered in saas-18.3** **Step to reproduce:** - In mobile view, create a quotation (version saas-18.3) - Trying to change the quantity or view the product a traceback will be received **Traceback** ``` Uncaught Promise > Cannot read properties of undefined (reading 'activeFields') Occured on localhost:9000 on 2019-03-11 09:30:00 GMT TypeError: Cannot read properties of undefined (reading 'activeFields') at http://localhost:9000/web/assets/debug/web.assets_unit_t
Original PR description
**Note: issue discovered in saas-18.3** **Step to reproduce:** - In mobile view, create a quotation (version saas-18.3) - Trying to change the quantity or view the product a traceback will be…
**Note: issue discovered in saas-18.3**
**Step to reproduce:**
- In mobile view, create a quotation (version saas-18.3)
- Trying to change the quantity or view the product a traceback will be received
**Traceback**
```
Uncaught Promise > Cannot read properties of undefined (reading 'activeFields')
Occured on localhost:9000 on 2019-03-11 09:30:00 GMT
TypeError: Cannot read properties of undefined (reading 'activeFields')
at http://localhost:9000/web/assets/debug/web.assets_unit_tests_setup.js:82391:75
at async openRecord (http://localhost:9000/web/assets/debug/web.assets_unit_tests_setup.js:106172:18)
```
**Issue:**
fieldDependencies of widget are evaluated by `addFieldDependencies` function.
now if a field of type "x2many" is added as fieldDependencies, and field is not present in the form,
examples : [sol_product_many2one](https://github.com/odoo/odoo/blob/saas-18.3/addons/sale/static/src/js/sale_product_field.js#L409) and [qty_at_date_widget](https://github.com/odoo/odoo/blob/saas-18.3/addons/sale_stock/static/src/widgets/qty_at_date_widget.js#L119)
the `related` key is not added for such fields by `addFieldDependencies` function
https://github.com/odoo/odoo/blob/b092750d2a595ac6d4bb6402c0b78db5db6d4dce/addons/web/static/src/model/relational_model/utils.js#L52-L76
which is required, when opening the subview here
https://github.com/odoo/odoo/blob/b092750d2a595ac6d4bb6402c0b78db5db6d4dce/addons/web/static/src/model/relational_model/static_list.js#L227-L233
**opw-4858035**
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#214496Fixed an issue where sales order line descriptions could show the product name twice or format translated product names incorrectly. This ensures customers and sales teams see cleaner, accurate product descriptions on sales documents.
Original PR description
After [1], the translated product name was missing from the view, resulting in the SOL description displaying the product name twice since it couldn't be pruned in the displayed description. This commit simply adds the missing field dependency, ensuring the ORM fetches the field to the client. This commit also fixes an issue from [2] when the SOL description did not include a newline after the translated product name, which caused it to show unexpectedly. opw-4760300 --- 1. https://github.com/odoo/odoo/pull/214099 2. https://github.com/odoo/odoo/pull/209141 Related: - https://github.com/odoo/odoo/pull/214569 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix improves how QR codes are generated for the self-ordering point of sale flow. It helps ensure customers can reliably scan the codes to access self-order menus, reducing friction during ordering.
Original PR description
This commit improves the generation of the self svg qr codes Task-4881395 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
Kiosk self-order checkout now shows combo meals as a single item instead of listing each included product separately. This makes the order summary clearer for customers and reduces confusion before payment.
Original PR description
Steps to reproduce: ----------------------------------------- - Install the point_of_sale module. - Select Kiosk mode - 1. Open Kiosk. - 2. Order Now & add combo product - 3. Checkout Issue: --------------------------------- - When a combo product is added to the cart in kiosk self-order mode, the order summary displays both the combo parent line and all its child lines. Cause: ----------------------- - After Checkout all cart product orderline shown. Fix: ------------------------------ - Now we are sending the orderline properly after filtering , if combo product then their child product not show as diffrent order line. - The condition is updated correctly. ----------------------------------- Task:4758958
This fixes an issue where attachments added to reconciled bank statement lines were not visibly indicated with the paper clip icon. Users can now see when supporting documents are attached, reducing the chance of missed documentation during bank reconciliation.
Original PR description
In this commit: https://github.com/odoo/enterprise/commit/13d527b2f940d2215a3bba578e47f180a0b7126e We wrongly removed the move_attachment_ids from the model params. Meaning that when putting an attachment on the reconciled line, the paper clip for the attachments was not visible on the statement line no task id
This fix updates performance test expectations after changes that automatically remove obsolete activities when records are deleted. It helps keep business data cleaner by preventing leftover activity records that no longer refer to anything useful.
Original PR description
Mail now override unlink of all models to remove hanging activities. Indeed notably with server actions activities may be added on models not inheriting from mail.thread or mail.activity.mixin e.g. users. They should be removed when removing records otherwise they lead to void records, and do not mean anything business wise anyway. See community PR for more details.
This fixes bank reconciliation matching so very short shared text between two transaction labels is no longer treated as a meaningful match. It helps reduce incorrect automatic matching suggestions and makes reconciliation behavior more reliable.
Original PR description
The [_get_common_substring](https://github.com/odoo/enterprise/blob/e8f7975659f3bfea42acdc7495efeccbffe183bc/account_accountant/models/account_bank_statement.py#L708-L782) method ought to return None if the substring is shorter than 10. The check is only done while looping through the normalised labels, but the loop is [skipped](https://github.com/odoo/enterprise/blob/e8f7975659f3bfea42acdc7495efeccbffe183bc/account_accountant/models/account_bank_statement.py#L777) if we have exactly 2 labels, thus returning the substring irrespective of its length. Instead, we should do the actual length check (and substitute with None as needed) right before returning. The phrasing of the method's docstring is also updated to clarify that in the case of identical normalised labels, the _normalised_ label is returned rather than its original form.
This fix ensures the receivable and payable buttons in bank reconciliation update properly after account changes. It restores expected screen feedback so accounting users can continue reconciliation with accurate button states.
Original PR description
During this commit:https://github.com/odoo/enterprise/commit/8419a92ae4697656da5b18325a5cc653a87e3ab5 we moved the reload of the statement line from the _setAccountOnReconcileLine function but by doing so the receivable and payable button are not reloaded anymore no task id
This update removes an unintended file that was accidentally introduced during a previous code update. It is a housekeeping fix with no expected impact on users or business workflows.
Original PR description
Forward-port odoo/enterprise#87064 wrongly introduced a tash file, this commit removes it
Payroll administrators can now change the status of Hong Kong rental records used in payroll. This fixes a permissions mismatch where the right people could view the records but were blocked from completing the related payroll workflow.
Original PR description
Since the access rights to see the hk rental is given to the payroll officer and the rights to modify the status is given to the employee administrator, you have payroll adminsitrator that cannot change the status and employee administrator that cannot access the model. As the model seems to be dedicated to Payroll and you need to be payroll officer to techniaclly change the status, we modify the view to allow this operation to payroll Adminsitrator.
When grouping by week/days in a pivot, some issues can be seen for dates which week is between two years (for instance 12/30/2024 is both part of the last week of 2024 and the first week of 2025). Currently, such a date is assigned to week 1 of 2024 in a spreadsheet pivot, which is false and also messes up the group by of the first week of 2024. Technically, it's an issue with the date formatting "WW/YYYY" because the two parts are decorellated. Following the ISO calendar rules, the year of
Original PR description
When grouping by week/days in a pivot, some issues can be seen for dates which week is between two years (for instance 12/30/2024 is both part of the last week of 2024 and the first week of 2025).…
When grouping by week/days in a pivot, some issues can be seen for dates which week is between two years (for instance 12/30/2024 is both part of the last week of 2024 and the first week of 2025). Currently, such a date is assigned to week 1 of 2024 in a spreadsheet pivot, which is false and also messes up the group by of the first week of 2024. Technically, it's an issue with the date formatting "WW/YYYY" because the two parts are decorellated. Following the ISO calendar rules, the year of the date is obviously 2024 but the week of 12/30/2024 is 1 only because we consider it part of 2025. Since both parts of the information are gathered independently, we end up with this misleading formatted value. Task-4853825 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#213757 Forward-Port-Of: odoo/odoo#213302
There are some rare cases there's a chat bubble but no thread, e.g. when the thread is deleted and/or data hasn't be fetched (yet). These cases should assume no thread for a short time instead of following crash: ``` TypeError: Cannot read properties of undefined (reading 'importantCounter') ``` Forward-Port-Of: odoo/odoo#214524
Original PR description
There are some rare cases there's a chat bubble but no thread, e.g. when the thread is deleted and/or data hasn't be fetched (yet). These cases should assume no thread for a short time instead of following crash: ``` TypeError: Cannot read properties of undefined (reading 'importantCounter') ``` Forward-Port-Of: odoo/odoo#214524
**Current behavior before PR:** Clicking "Cancel" or "Save" in the composer would unintentionally cause the page to scroll. **Desired behavior after PR is merged:** This default behavior is now prevented in `onClickCancelOrSaveEditText`. **task**-[4826935](https://www.odoo.com/odoo/my-tasks/4826935) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214532
Original PR description
**Current behavior before PR:** Clicking "Cancel" or "Save" in the composer would unintentionally cause the page to scroll. **Desired behavior after PR is merged:** This default behavior is now prevented in `onClickCancelOrSaveEditText`. **task**-[4826935](https://www.odoo.com/odoo/my-tasks/4826935) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214532
This commit fixes a race condition in one of Hoot's internal tests. The fix simplifies the failing test since the previous manipulations were redundant and fragile. runbot [223471](https://runbot.odoo.com/odoo/runbot.build.error/223471) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214869
Original PR description
This commit fixes a race condition in one of Hoot's internal tests. The fix simplifies the failing test since the previous manipulations were redundant and fragile. runbot [223471](https://runbot.odoo.com/odoo/runbot.build.error/223471) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214869
runbot-112917 runbot-112998 Follow up of https://github.com/odoo/odoo/pull/214559 The issue is still happening after the previous fix, because the issue does not only happen with the `last_interest_dt` of the member, but also with the `last_interest_dt` of the channel. Forward-Port-Of: odoo/odoo#215015
Original PR description
runbot-112917 runbot-112998 Follow up of https://github.com/odoo/odoo/pull/214559 The issue is still happening after the previous fix, because the issue does not only happen with the `last_interest_dt` of the member, but also with the `last_interest_dt` of the channel. Forward-Port-Of: odoo/odoo#215015
Creating a post using default values in context was bypassing the karma check when adding link or image. This no-so-sexy solution just ensure that whatever the way the post is created (using or not default values in context), the check is properly executed. Task-4114387 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197325
Original PR description
Creating a post using default values in context was bypassing the karma check when adding link or image. This no-so-sexy solution just ensure that whatever the way the post is created (using or not default values in context), the check is properly executed. Task-4114387 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197325
- The "Clear" button is only accessible by "group_stock_manager" but without a group attached, "stock_user" can still see it and operate it, resulting in an unnecessary permission error, confusing the user. Current behavior before PR:  
Original PR description
- The "Clear" button is only accessible by "group_stock_manager" but without a group attached, "stock_user" can still see it and operate it, resulting in an unnecessary permission error, confusing the user. Current behavior before PR:   --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214142 Forward-Port-Of: odoo/odoo#213508
The goal of this commit is to fix the `website_form_editor_tour` tour that is failing undeterministically. The tour fails because this flow happens; - The user types something ("A") as input and clicks somewhere else to commit its change. - The DOM is updated with the new value. - The user types something else ("B") on the same input. - The options are rebuild with the DOM value. -> "A" is displayed in the option input and "B" is lost. This is a know issue and it has been decided to no
Original PR description
The goal of this commit is to fix the `website_form_editor_tour` tour that is failing undeterministically. The tour fails because this flow happens;
- The user types something ("A") as input and clicks somewhere else to commit its change.
- The DOM is updated with the new value.
- The user types something else ("B") on the same input.
- The options are rebuild with the DOM value.
-> "A" is displayed in the option input and "B" is lost.
This is a know issue and it has been decided to not fix it in stable as the behavior seems really unlikely to happen with human behavior and the issue is not critical.
Although it is not optimal, the tour is fixed by adding delays before doing further steps.
runbot-64572
Forward-Port-Of: odoo/odoo#213417
Forward-Port-Of: odoo/odoo#213197Before this commit, when using discuss call, using some usb camera would lead to wrong camera settings: ``` aspectRatio: 1.7777777777777777 frameRate: 20, height: 360, resizeMode: "crop-and-scale", width: 640, ``` This happens because of the camera config constraints that are not well understood by some usb cameras, such as `max` for width and height. Another problem is that `frameRate` was set to 30 but a camera can stream 30.0003 frames per seconds which is slightly higher. Becaus
Original PR description
Before this commit, when using discuss call, using some usb camera would lead to wrong camera settings: ``` aspectRatio: 1.7777777777777777 frameRate: 20, height: 360, resizeMode: "crop-and-scale",…
Before this commit, when using discuss call, using some usb camera would lead to wrong camera settings: ``` aspectRatio: 1.7777777777777777 frameRate: 20, height: 360, resizeMode: "crop-and-scale", width: 640, ``` This happens because of the camera config constraints that are not well understood by some usb cameras, such as `max` for width and height. Another problem is that `frameRate` was set to 30 but a camera can stream 30.0003 frames per seconds which is slightly higher. Because of the 30 value, it forces camera to stream a much lower framerate. Also somehow the camera panics and crop the content when this is not wanted. This commit fixes the issue by simplifying constraints to only asking for explicit width. This is well understood by many cameras and it just works. Framerate is managed by camera and bandwidth constraints, aspect-ratio has no reason to be limited by constraints and instead the source decides and call view managed the layout like it does now. With the same usb camera that give the results before, with the new contraints this become: ``` aspectRatio: 1.7777777777777777 frameRate: 30.000030517578125 height: 720 resizeMode: "none" width: 1280 ``` Forward-Port-Of: odoo/odoo#214886
Logs were rotating after 2 days, but not above a certain filesize, which could lead to saturation of `/var`, which size is limited to 192MB. We now rotate above 100M. Forward-Port-Of: odoo/odoo#214629
Original PR description
Logs were rotating after 2 days, but not above a certain filesize, which could lead to saturation of `/var`, which size is limited to 192MB. We now rotate above 100M. Forward-Port-Of: odoo/odoo#214629
runbot-112917 runbot-112998 `unpin_dt` was using `now()` inside the function and `last_interest_dt` was using `now()` (-1 sec) from its default value. When there was more than one sec between the two calls due to slow CPU or slow query, the channel would be considered pinned even though it was supposted to not be. This commit ensures the same `now()` is used in both cases. The opportunity is taken to clean the method a bit: - ensure the provided ids are existing partners - inter
Original PR description
runbot-112917 runbot-112998 `unpin_dt` was using `now()` inside the function and `last_interest_dt` was using `now()` (-1 sec) from its default value. When there was more than one sec between the two calls due to slow CPU or slow query, the channel would be considered pinned even though it was supposted to not be. This commit ensures the same `now()` is used in both cases. The opportunity is taken to clean the method a bit: - ensure the provided ids are existing partners - internally, use recordset of partners rather than ids - use `self_member_id` rather than extra manual search Forward-Port-Of: odoo/odoo#214559
In this PR, we fixed the creation of a new None stage each time when we move an application to the existing None stage (stage_id = false). ## Description of the issue/feature this PR addresses: In the Kanban view of the application dashboard, when a user moves an application to the "None" stage (which corresponds to stage_id = False) and refreshes the page, a new stage labeled "None" is incorrectly created. The issue arose from the way we were updating the many2one field for stage_id. Speci
Original PR description
In this PR, we fixed the creation of a new None stage each time when we move an application to the existing None stage (stage_id = false). ## Description of the issue/feature this PR addresses: In…
In this PR, we fixed the creation of a new None stage each time when we move an application to the existing None stage (stage_id = false).
## Description of the issue/feature this PR addresses:
In the Kanban view of the application dashboard, when a user moves an application to the "None" stage (which corresponds to stage_id = False) and refreshes the page, a new stage labeled "None" is incorrectly created.
The issue arose from the way we were updating the many2one field for stage_id. Specifically, we were setting the value as:
`{ id: false, display_name: "None" }`
This object was interpreted by the model layer as an instruction to create a new related record (i.e., a new stage) with the name "None", which is unintended.
## Fix:
We adjusted the logic so that if the targetGroup.value is falsy (i.e., null, undefined, or false), we now explicitly pass false instead of constructing an object. This correctly unsets the many2one field without triggering record creation.
This ensures:
- If a valid stage is selected, we pass the appropriate { id, display_name } object.
- If "None" is selected, we pass false to unset the stage_id, avoiding the creation of a phantom stage.
Current behavior before PR:
Desired behavior after PR is merged:
Task: 4873853
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#214605In migration scripts, while loading the chart of accounts, we should always initiate with parent companies to avoid creating duplicate chart records. When a new account is added and the chart is loaded from the child company before the parent (due to sequence, name ordering), the account will be created for both companies. Sometimes resulting into singleton error from [here](https://github.com/odoo/enterprise/blob/saas-18.3/account_reports/models/chart_template.py#L31). With this commit, t
Original PR description
In migration scripts, while loading the chart of accounts, we should always initiate with parent companies to avoid creating duplicate chart records. When a new account is added and the chart is…
In migration scripts, while loading the chart of accounts, we should always initiate with parent companies to avoid creating duplicate chart records.
When a new account is added and the chart is loaded from the child company before the parent (due to sequence, name ordering), the account will be created for both companies. Sometimes resulting into singleton error from [here](https://github.com/odoo/enterprise/blob/saas-18.3/account_reports/models/chart_template.py#L31).
With this commit, the COA for Colombian-based companies will now be loaded hierarchically — i.e. parent company first — ensuring proper inheritance and avoiding redundant account or journal creation.
Community PR - #182706
UPG - [2982418](https://upgrade.odoo.com/odoo/upgrade.request/2982418)
Traceback faced:
```python
Traceback (most recent call last):
File "/home/odoo/src/odoo/saas-18.3/odoo/service/server.py", line 1396, in preload_registries
registry = Registry.new(dbname, update_module=update_module, install_modules=config['init'], upgrade_modules=config['update'])
File "<decorator-gen-6>", line 2, in new
File "/home/odoo/src/odoo/saas-18.3/odoo/tools/func.py", line 83, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/src/odoo/saas-18.3/odoo/orm/registry.py", line 167, in new
load_modules(
File "/home/odoo/src/odoo/saas-18.3/odoo/modules/loading.py", line 487, in load_modules
migrations.migrate_module(package, 'end')
File "/home/odoo/src/odoo/saas-18.3/odoo/modules/migration.py", line 220, in migrate_module
exec_script(self.cr, installed_version, pyfile, pkg.name, stage, stageformat[stage] % version)
File "/home/odoo/src/odoo/saas-18.3/odoo/modules/migration.py", line 257, in exec_script
mod.migrate(cr, installed_version)
File "/home/odoo/src/odoo/saas-18.3/addons/l10n_co/migrations/1.0/end-migrate_update_taxes.py", line 8, in migrate
env['account.chart.template'].try_loading('co', company)
File "/home/odoo/src/odoo/saas-18.3/addons/account/models/chart_template.py", line 160, in try_loading
return self._load(template_code, company, install_demo, force_create)
File "/home/odoo/src/odoo/saas-18.3/addons/account/models/chart_template.py", line 244, in _load
self._load(template_code, subsidiary, install_demo, force_create)
File "/home/odoo/src/odoo/saas-18.3/addons/account/models/chart_template.py", line 227, in _load
self._post_load_data(template_code, company, template_data)
File "/home/odoo/src/enterprise/saas-18.3/account_reports/models/chart_template.py", line 29, in _post_load_data
'account_tax_return_journal_id': closing_journal.id,
File "/home/odoo/src/odoo/saas-18.3/odoo/orm/fields_misc.py", line 117, in __get__
raise ValueError("Expected singleton: %s" % record)
ValueError: Expected singleton: account.journal(28, 29)
```
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#214488Before this commit: we have basic test for the url autocomplete in the linkpopover, but we miss the case for the page anchors After this commit: we added the page anchor test, also updated the icon path to the one inside website module Related PR: https://github.com/odoo/odoo/pull/187091 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214707
Original PR description
Before this commit: we have basic test for the url autocomplete in the linkpopover, but we miss the case for the page anchors After this commit: we added the page anchor test, also updated the icon path to the one inside website module Related PR: https://github.com/odoo/odoo/pull/187091 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214707
At the moment, the tax aggregators always give a base line with no tax the `None` grouping key. Sometimes, we want base lines with no tax to be grouped as if they had a particular tax, such as an exempt one. This commit extends the aggregator behaviour so that for base lines with no tax, the grouping function is called with an empty tax_data dict, and the returned grouping key is used to group the base line. Enterprise PR: https://github.com/odoo/enterprise/pull/87223 task-4242065 F
Original PR description
At the moment, the tax aggregators always give a base line with no tax the `None` grouping key. Sometimes, we want base lines with no tax to be grouped as if they had a particular tax, such as an exempt one. This commit extends the aggregator behaviour so that for base lines with no tax, the grouping function is called with an empty tax_data dict, and the returned grouping key is used to group the base line. Enterprise PR: https://github.com/odoo/enterprise/pull/87223 task-4242065 Forward-Port-Of: odoo/odoo#213405
The `_set_duration` inverse method of `mrp.workorder` is ignoring microsecond variations when computing the `date_start `of a workorder productivity record. This method uses the current time as the end date but does not remove microseconds from it. This causes a intermittent error when running the `test_labor_cost_balancing_with_cost_share`, because the computed duration (around 0.03 hours or 1.8 seconds) can vary slightly depending on the microseconds captured by `datetime.now()`. This fluc
Original PR description
The `_set_duration` inverse method of `mrp.workorder` is ignoring microsecond variations when computing the `date_start `of a workorder productivity record. This method uses the current time as the end date but does not remove microseconds from it. This causes a intermittent error when running the `test_labor_cost_balancing_with_cost_share`, because the computed duration (around 0.03 hours or 1.8 seconds) can vary slightly depending on the microseconds captured by `datetime.now()`. This fluctuation results in a 1- or 2-second difference, which breaks the test. To fix it, we simply set the microsseconds of the end date to zero. This bug was introduced in: https://github.com/odoo/odoo/pull/211853 Runbot failure example: https://runbot.odoo.com/odoo/runbot.build.error/226657 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214381
Prior to this commit, when validating a Scrap Order for a product with insuficient quantity, a wizard was shown to confirm the order as you would end up with a negative quantity in your warehouse. However, the view did not properly displayed quant_ids which allows seeing the current quantity for this product on the current warehouse as this compute field was not triggered during the first onchange call. When confirming the popup, the quant_ids could barely be seen before closing. The ide
Original PR description
Prior to this commit, when validating a Scrap Order for a product with insuficient quantity, a wizard was shown to confirm the order as you would end up with a negative quantity in your warehouse. However, the view did not properly displayed quant_ids which allows seeing the current quantity for this product on the current warehouse as this compute field was not triggered during the first onchange call. When confirming the popup, the quant_ids could barely be seen before closing. The idea is to make so that quand_ids can be seen as expected before any confirmation/cancelation. Forward-Port-Of: odoo/odoo#211152
Description ----------- Following d5a6e97abab04282c7a69093cd790b539a958241, the currently selected filter of the progress bar in the kanban view is injected into the domain of the kanban view during `read_progress_bar`. This behaves well in general, but it's a performance regression when the filtering field is a non-stored search field that potentially does elaborate subqueries (e.g.: `activity_state`). This commit reverts this modification to the previous behavior, to avoid this patholo
Original PR description
Description ----------- Following d5a6e97abab04282c7a69093cd790b539a958241, the currently selected filter of the progress bar in the kanban view is injected into the domain of the kanban view during `read_progress_bar`. This behaves well in general, but it's a performance regression when the filtering field is a non-stored search field that potentially does elaborate subqueries (e.g.: `activity_state`). This commit reverts this modification to the previous behavior, to avoid this pathological case. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214778
This commit fixes the `test_postcommit` that fails in a non deterministic fashion. This test ensures bus notifications created in the post commit hook result in only one batch. To do so, the test listens on the connection with a selector. However, the loop condition is incorrect and exits after the first select timeout. As a result, if the test takes more than 5 seconds, it fails. This commit fixes the loop condition to continue until the stop event is set. runbot-116746,161035,223589,7747
Original PR description
This commit fixes the `test_postcommit` that fails in a non deterministic fashion. This test ensures bus notifications created in the post commit hook result in only one batch. To do so, the test listens on the connection with a selector. However, the loop condition is incorrect and exits after the first select timeout. As a result, if the test takes more than 5 seconds, it fails. This commit fixes the loop condition to continue until the stop event is set. runbot-116746,161035,223589,77470 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#214737
## Version 18.0+ ## Issue Carousel images are not zoomable on product's website view ## Steps to reproduce - Select any product and move to `Sales` tab: - Add 1 image under `ECOMMERCE MEDIA` section. - Click `Go to website` and open edit mode: - Select the main image in the view; - In the editor, change the `Image Zoom` value for `Pop-up on Click`; - Save and close the editor. - Click on the main image to display the carousel: - Hover the current image and t
Original PR description
## Version
18.0+
## Issue
Carousel images are not zoomable on product's website view
## Steps to reproduce
- Select any product and move to `Sales` tab:
- Add 1 image under `ECOMMERCE MEDIA` section.
- Click `Go to website` and open edit mode:
- Select the main image in the view;
- In the editor, change the `Image Zoom` value for `Pop-up on Click`;
- Save and close the editor.
- Click on the main image to display the carousel:
- Hover the current image and try to zoom in or out *(using the mouse wheel or equivalent action on trackpad)*
opw-4831912
Forward-Port-Of: odoo/odoo#213933Starting from version 18.0, `check_access_rule()` is deprecated. This **PR** updates the code to use `check_access()` instead. Forward-Port-Of: odoo/odoo#214490
Original PR description
Starting from version 18.0, `check_access_rule()` is deprecated. This **PR** updates the code to use `check_access()` instead. Forward-Port-Of: odoo/odoo#214490
When the user saves the vendor pricelist after removing both the UoM and the product template, a traceback appears. Steps to reproduce the error: - Install ``purchase`` module - Enable ``Units of Measure & Packagings`` from settings - Go to Purchase > Configuration > Vendor Pricelists > New > Add Vendor > Save - Now add any Product > remove the uom and product > Save Traceback: ``` RecursionError: maximum recursion depth exceeded ``` https://github.com/odoo/odoo/blob/06733a16cff
Original PR description
When the user saves the vendor pricelist after removing both the UoM and the product template, a traceback appears. Steps to reproduce the error: - Install ``purchase`` module - Enable ``Units of…
When the user saves the vendor pricelist after removing both the UoM and the product template, a traceback appears. Steps to reproduce the error: - Install ``purchase`` module - Enable ``Units of Measure & Packagings`` from settings - Go to Purchase > Configuration > Vendor Pricelists > New > Add Vendor > Save - Now add any Product > remove the uom and product > Save Traceback: ``` RecursionError: maximum recursion depth exceeded ``` https://github.com/odoo/odoo/blob/06733a16cff904887c8a5ec9e2d2ba591f252636/addons/product/models/product_supplierinfo.py#L117-L118 When the user removes both the product and UoM from a vendor pricelist, the condition becomes true, and attempts to reassign the product UoM from ``supplier.product_tmpl_id.uom_id``. However, since ``product_tmpl_id`` is also cleared, this causes repeated assignments and eventually triggers a RecursionError during write operations. sentry-6666831551 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213497
When computing the payment state fetching the payment data from the database is only necessary for posted invoices. Previously it was fetched all the time which causes unnecessary requests to the database and can cause performance issues when a lot of non invoice entries are being processed concurrently. With inventory valuation for instance. opw-4724142 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: ---
Original PR description
When computing the payment state fetching the payment data from the database is only necessary for posted invoices. Previously it was fetched all the time which causes unnecessary requests to the database and can cause performance issues when a lot of non invoice entries are being processed concurrently. With inventory valuation for instance. opw-4724142 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#212617 Forward-Port-Of: odoo/odoo#208850
The call was done with `bank` parameter instead of `branch`. This made the tests (and the feature) fail. ref: odoo/enterprise#74967 runbot-114997 Forward-Port-Of: odoo/enterprise#87617
Original PR description
The call was done with `bank` parameter instead of `branch`. This made the tests (and the feature) fail. ref: odoo/enterprise#74967 runbot-114997 Forward-Port-Of: odoo/enterprise#87617
**Steps to reproduce:** 1. Install hr_payroll. 2. Create a salary rule (with a structure where country_id is null) and set `View on Payroll Reporting?` is checked for a custom field (x_l10n_xx_%). 3. Add the custom field to the payroll report's pivot view using Studio. **Issue:** - The pivot view fails to open, resulting in a traceback. ``` UncaughtPromiseError > OwlError Uncaught Promise > The following error occurred in onWillStart: "Cannot read properties of undefined (reading
Original PR description
**Steps to reproduce:** 1. Install hr_payroll. 2. Create a salary rule (with a structure where country_id is null) and set `View on Payroll Reporting?` is checked for a custom field (x_l10n_xx_%). 3.…
**Steps to reproduce:** 1. Install hr_payroll. 2. Create a salary rule (with a structure where country_id is null) and set `View on Payroll Reporting?` is checked for a custom field (x_l10n_xx_%). 3. Add the custom field to the payroll report's pivot view using Studio. **Issue:** - The pivot view fails to open, resulting in a traceback. ``` UncaughtPromiseError > OwlError Uncaught Promise > The following error occurred in onWillStart: "Cannot read properties of undefined (reading 'string')" ``` **Cause:** - Custom field that not start with `l10n_<country_code>` or `x_l10n_<country_code>` are removed, causing undefined fields in the pivot view. https://github.com/odoo/enterprise/blob/ccb5ed4779db4bdf6944f43eb2e4a7aa978b9272/hr_payroll/static/src/js/hr_payroll_report_pivot_model.js#L13-L15 **Solution:** - Allow to add custom fields created from salary rules without a country code to be used as custom measures in the pivot view. opw-4688376 Forward-Port-Of: odoo/enterprise#84881
before this PR: split horizontally is ticked by default on Balance Sheet. after this PR: split horizontally is unticked by default. Task Id: 4836667 Forward-Port-Of: odoo/enterprise#86779
Original PR description
before this PR: split horizontally is ticked by default on Balance Sheet. after this PR: split horizontally is unticked by default. Task Id: 4836667 Forward-Port-Of: odoo/enterprise#86779
Current Behavior: When validating a SEPA Direct Debit batch payment, Odoo automatically attempts to send a pre-notification email using the email template account_sepa_direct_debit.email_template_sdd_pre_notification. If this template is missing (e.g. deleted or unlinked), the process fails with a ValueError: External ID not found, and the batch cannot be validated. Expected Behavior: If the template is missing, no pre-notification email should be sent, but the batch validation shoul
Original PR description
Current Behavior: When validating a SEPA Direct Debit batch payment, Odoo automatically attempts to send a pre-notification email using the email template account_sepa_direct_debit.email_template_sdd_pre_notification. If this template is missing (e.g. deleted or unlinked), the process fails with a ValueError: External ID not found, and the batch cannot be validated. Expected Behavior: If the template is missing, no pre-notification email should be sent, but the batch validation should still proceed without error. The process must not raise a traceback or prevent validation. task-4815699 Forward-Port-Of: odoo/enterprise#86278
We cannot add dependency on stable. Commit: cfeb0bacf5d66148c483d7177417cda582858ec7 Forward-Port-Of: odoo/enterprise#87900
Original PR description
We cannot add dependency on stable. Commit: cfeb0bacf5d66148c483d7177417cda582858ec7 Forward-Port-Of: odoo/enterprise#87900
At the moment, the tax aggregators always give a base line with no tax the `None` grouping key. Sometimes, we want base lines with no tax to be grouped as if they had a particular tax, such as an exempt one. This commit extends the aggregator behaviour so that for base lines with no tax, the grouping function is called with an empty tax_data dict, and the returned grouping key is used to group the base line. Community PR: https://github.com/odoo/odoo/pull/213405 task-4242065 Forward
Original PR description
At the moment, the tax aggregators always give a base line with no tax the `None` grouping key. Sometimes, we want base lines with no tax to be grouped as if they had a particular tax, such as an exempt one. This commit extends the aggregator behaviour so that for base lines with no tax, the grouping function is called with an empty tax_data dict, and the returned grouping key is used to group the base line. Community PR: https://github.com/odoo/odoo/pull/213405 task-4242065 Forward-Port-Of: odoo/enterprise#87223
- Before this commit, when a POS order was created with an urban piper delivery method, the blackbox data was not saved to the database. - Now we explicitly save the bbox data to ensure this info is displayed on the receipt. task-id: 4781945 Forward-Port-Of: odoo/enterprise#87841
Original PR description
- Before this commit, when a POS order was created with an urban piper delivery method, the blackbox data was not saved to the database. - Now we explicitly save the bbox data to ensure this info is displayed on the receipt. task-id: 4781945 Forward-Port-Of: odoo/enterprise#87841
Before this PR: - IRN number was also copied when a record was duplicated or while creating a debit/credit note for purchase document. - This caused the same IRN to appear on multiple records. After this PR: - Now, when a record is duplicated or a debit/credit note is created, the IRN number will be empty to prevent duplication. Task Id: 4854568 Forward-Port-Of: odoo/enterprise#87860 Forward-Port-Of: odoo/enterprise#87468
Original PR description
Before this PR: - IRN number was also copied when a record was duplicated or while creating a debit/credit note for purchase document. - This caused the same IRN to appear on multiple records. After this PR: - Now, when a record is duplicated or a debit/credit note is created, the IRN number will be empty to prevent duplication. Task Id: 4854568 Forward-Port-Of: odoo/enterprise#87860 Forward-Port-Of: odoo/enterprise#87468
Before this commit, in Chrome, when the first item was placed on second page or later, clicking on "Click to start" to automatically scroll to the first sign item would stop earlier. As a result, the user would have to click again on the navigator to focus it and to fill the automatic value. task-id-4854650 Forward-Port-Of: odoo/enterprise#87748
Original PR description
Before this commit, in Chrome, when the first item was placed on second page or later, clicking on "Click to start" to automatically scroll to the first sign item would stop earlier. As a result, the user would have to click again on the navigator to focus it and to fill the automatic value. task-id-4854650 Forward-Port-Of: odoo/enterprise#87748