Daily updates from Odoo
Thursday, July 31, 2025
17 changes · master
Resolved issues and error corrections
Products with GST rates other than 5% now include the required packaged-good label when synced to Swiggy and Zomato. This helps ensure product information is classified correctly on delivery platforms and reduces potential listing or compliance issues.
Original PR description
*: pos_urban_piper_swiggy, pos_urban_piper_zomato Before this commit: --- - Products with GST != 5% were not receiving the `packaged-good` tag in the sync payload for Swiggy and Zomato. After this commit: --- - Now, products with GST != 5% correctly include the `packaged-good` tag in their respective provider tag list (`swiggy` or `zomato`). task-4954571 Forward-Port-Of: odoo/enterprise#91278 Forward-Port-Of: odoo/enterprise#90595
The Italian Libro Giornale PDF report now keeps long entries in the Name column visible by wrapping the text instead of cutting it off. Column spacing has also been stabilized, making the report easier to read and more reliable for accounting review.
Original PR description
Issue: In the Libro Giornale report (PDF), long descriptions in the 'Name' column were getting cut off, and column spacing appeared inconsistent in the generated PDF. These issues reappeared due to recent layout changes from commit https://github.com/odoo/enterprise/commit/233e82cf4e6908502a580be4bcd77fadd2aada53, which unintentionally removed previous fixes made to handle such cases. Fixes Applied: - Reintroduced the `o_overflow_name` class on the 'Name' column to ensure long descriptions wrap correctly and are not truncated in the PDF export. - Applied the `o_fixed_column_width` class to the 3rd column (currently 'Account Code') to resolve inconsistent spacing between columns caused by `wkhtmltopdf`. Forward-Port-Of: odoo/enterprise#91231
The Australian payroll termination process now uses the correct calculation flow instead of an outdated contract method. This helps ensure termination payslips are generated correctly and adds test coverage for the full process to reduce future regressions.
Original PR description
Termination flow used an old method from contracts. This fixes the issue and adds a test for the full termination flow. Forward-Port-Of: odoo/enterprise#91200
Users can now clear and reselect a start date in work order time tracking without triggering an error. This prevents interruptions when updating manufacturing work order time entries and keeps the workflow reliable.
Original PR description
When the user removes the value of the start date and selects the value again in the start date, a traceback will appear Steps to reproduce the error: - Create one mo > Work orders > Add a line >…
When the user removes the value of the start date and
selects the value again in the start date,
a traceback will appear
Steps to reproduce the error:
- Create one mo > Work orders > Add a line > Click on Open work order button
- In Time Tracking > Add a line > Remove the start date >
Select the start date again > Apply
Traceback:
```
TypeError: '<' not supported between instances of 'bool' and 'datetime.datetime'
File "odoo/http.py", line 2373, in __call__
response = request._serve_db()
File "odoo/http.py", line 1903, in _serve_db
return self._transactioning(
File "odoo/http.py", line 1966, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1933, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2177, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 223, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 754, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 35, in call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 459, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "addons/web/models/models.py", line 1007, in onchange
record._apply_onchange_methods(field_name, result)
File "odoo/models.py", line 7028, in _apply_onchange_methods
res = method(self)
File "addons/mrp/models/mrp_workcenter.py", line 448, in _date_start_changed
self._loss_type_change()
File "addons/mrp/models/mrp_workcenter.py", line 473, in _loss_type_change
if self.workorder_id.duration > self.workorder_id.duration_expected:
File "odoo/fields.py", line 1208, in __get__
self.recompute(record)
File "odoo/fields.py", line 1423, in recompute
apply_except_missing(self.compute_value, recs)
File "odoo/fields.py", line 1396, in apply_except_missing
func(records)
File "odoo/fields.py", line 1445, in compute_value
records._compute_field_value(self)
File "odoo/models.py", line 5037, in _compute_field_value
fields.determine(field.compute, self)
File "odoo/fields.py", line 101, in determine
return needle(*args)
File "home/odoo/src/enterprise/saas-17.4/mrp_workorder_hr_account/models/mrp_workorder.py", line 62, in _compute_duration
super()._compute_duration()
File "home/odoo/src/enterprise/saas-17.4/mrp_workorder/models/mrp_workorder.py", line 762, in _compute_duration
wo.duration = wo.get_duration()
File "home/odoo/src/enterprise/saas-17.4/mrp_workorder/models/mrp_workorder.py", line 838, in get_duration
duration += self._intervals_duration([(t.date_start, t.date_end or now, t) for t in times])
File "home/odoo/src/enterprise/saas-17.4/mrp_workorder/models/mrp_workorder.py", line 826, in _intervals_duration
for date_start, date_stop, timer in Intervals(intervals):
File "addons/resource/models/utils.py", line 124, in __init__
for value, flag, recs in sorted(_boundaries(intervals, 'start', 'stop')):
File "addons/resource/models/utils.py", line 51, in _boundaries
if start < stop:
```
https://github.com/odoo/enterprise/blob/1f626176d28762683dc32ddbb351d994be894a71/mrp_workorder/models/mrp_workorder.py#L787 Here when "date_start" is empty,
It leads to the above traceback.
sentry-5679416830
Forward-Port-Of: odoo/enterprise#91259
Forward-Port-Of: odoo/enterprise#68014Users can now open signature requests even if the employee or user who created them has since been deleted. This prevents an error from blocking access to existing signing documents and keeps signature workflows available.
Original PR description
## Issue: ## Before this commit, opening a sign request created by a deleted user would raise an Owl Error ## Cause: ## The `action.params` are used as a fallback in the signRequest setup But sometimes sometimes the `action.params`are undefined, causing access to `action.params.create_uid` to fail ## Fix: ## The document can be open with `create_uid` set to False So we just added a check for `action.params` to be set before accessing his properties If the create_uid isn't in the context or in the params, it will be set to False ## Steps to reproduce: - Create a user (to be deleted later) - Create a sign request with this user - Delete the user - Try to open the sign request - The error should be displayed opw-4786368 Forward-Port-Of: odoo/enterprise#91271 Forward-Port-Of: odoo/enterprise#88758
The delivery settings no longer show installation checkboxes that pointed users to older shipping connectors. Users are now guided to install their preferred USPS, FedEx, UPS, or DHL connector from the Apps menu, where the newer REST API options are described more clearly and legacy options are hidden by default.
Original PR description
We have recently introduced several new versions of the delivery connectors, based on the newer REST APIs introduced by the shipping companies (USPS, FedEx, UPS, DHL). However, in the settings we still link with installation checkboxes to the old modules. To avoid confusion for the user, we remove these checkboxes and refer the user to the Apps menu instead for manual installation of the preferred shipping connector. In the apps menu, we clarify that these new modules are only compatible with the new REST APIs, and we also hide the legacy modules by default by making them application: False. Forward-Port-Of: odoo/enterprise#90074 Forward-Port-Of: odoo/enterprise#81354
Mobile self-service orders are now sent to the preparation display as soon as customers proceed to payment. This helps kitchen or preparation teams see incoming mobile orders promptly instead of waiting until cashier payment is completed.
Original PR description
When doing a self order from a mobile device, the order was not sent to the preparation display until it was paid at the cashier. Steps to reproduce: ------------------- * Setup a PoS with self-ordering mode set to 'mobile'. * Setup a preparation display to show orders from this PoS. * Place an order from a mobile device. * Click on "Pay" > Observation: The order does not appear on the preparation display. Why the fix: ------------ Instead of just sending the order from the kiosk, we also need to send it from the mobile device. opw-4819732 Forward-Port-Of: odoo/enterprise#91148 Forward-Port-Of: odoo/enterprise#90169
Website generation now handles HTML replacements more efficiently by reusing a prepared replacement pattern instead of rebuilding larger ones repeatedly. This reduces unnecessary processing and helps generated website content load or update faster, especially when many replacements are involved.
Original PR description
Fixed issue where regex where larger than required due to growing dictionnary of replacements. Improved global replacements by creating the patern early and sharing it accross all replacement. Forward-Port-Of: odoo/enterprise#91218
Fixes an issue where users could not download signed documents from the download menu after a recent interface change. The download options now use the proper download action, so users can retrieve their documents as expected.
Original PR description
As click event on DropdownItem rendered as `<a href="">` are prevented, the recent refactoring (PR [1]) of the SignRequestDocumentsDropdown component to use OWL components instead of Bootstrap JS introduce a regression, preventing the user from downloading the documents. This commit fixes it by properly using the dedicated download action (i.e. `act_url` action with a `target="download"` attribute) when selecting one of the dropdown's items. Steps to reproduce: - Open Sign - In template, choose one and click Send - Choose your user as Customer and click Send - Go to Documents menu > My Documents > open the sent document - Open Download dropdown and click on one of the item => download should happen but doesn't [1]: https://github.com/odoo/enterprise/pull/89727
Mexican POS global invoices now use the postal code from the journal’s configured issued address when one is set, instead of defaulting to the company address. This helps ensure the generated CFDI XML reflects the correct place of issue for cash sales and reduces compliance errors.
Original PR description
Steps to reproduce: [l10n_edi_extended] - setup up a mexican company - create a journal in which you define an issued address (different from your company) - setup your pos with newly created journal - Open a pos session - add a product - pay in cash with no customer - in the backend go into the orders - select the newly created order in the list view and click on the action "create global invoice" - in the order > cfdi: download the created xml Issue: The "Lugar de expedicion" will have the zip code of the company and not from the issued address one Cause: We only check for issue adress in account_move but not from orders. Global invoice is not only for invoices but also to account for sale (orders) made with petty cash Solution: We don't want to create a bridge module only for that. We check if the field is defined on `account.journal` opw-4802389 Forward-Port-Of: odoo/enterprise#86545
This fix prevents an error when users post Italian tax closing journal entries from the Accounting Dashboard. It ensures the system uses the correct accounting entry context, allowing the posting workflow to complete normally.
Original PR description
Currently a traceback is occurring when the user tries to post a journal entry from journal dashborad. **Steps to reproduce:** 1) Install `l10n_it_xml_export` and switch to IT company 2) Create a…
Currently a traceback is occurring when the user tries to post a journal entry from journal dashborad. **Steps to reproduce:** 1) Install `l10n_it_xml_export` and switch to IT company 2) Create a closing entry for the tax report 3) Open the miscellaneous Operations from Accounting Dashboard 4) Open the above-created entry by removing the default filter 5) Post the closing entry, a wizard opens. 6) Validate the values. 7) A traceback appears **Error:** ``` account.journal' object has no attribute '_get_report_options_from_tax_closing_entry' ``` **Cause:** When the user tries to post the closing entry from the accounting dashboard, its active_model is `account.journal`, and the active_id should be the current id of the miscellaneous journal. This leads to the above traceback, as the method `_get_report_options_from_tax_closing_entry` is not available in account.journal. **Solution:** To resolve this issue, we can browse the current move from the `ctx['l10n_it_moves_to_post']`, since the value of the `l10n_it_moves_to_post` is also self.ids. Which is the current active id for that closing entry. https://github.com/odoo/enterprise/blob/3d89d9fe6be8e789278dee9bc706e091ee5a0ec5/l10n_it_xml_export/models/account_move.py#L19 opw-4783958 Forward-Port-Of: odoo/enterprise#88743 Forward-Port-Of: odoo/enterprise#86791
The referral rewards configuration now opens in the correct full form view instead of the mobile-specific layout. This makes it easier for HR teams to manage reward settings reliably from the standard configuration screen.
Original PR description
since https://github.com/odoo/enterprise/commit/6a9f8a8d69fecde388f0030a10944a6fa9da9e58, the main reward form view has been replaced by the mobile alternate view. This commit ensure that the main form view is used when accessing the reward configuration form view. Task-4953625
This fix ensures tax prediction in Accounting uses the right document context when suggesting taxes. It prevents failed or missing tax predictions, helping users get more reliable accounting automation.
Original PR description
Previously, when _predicted_field was invoked from _predict_specific_taxes, self did not have an associated move_id. As a result, _build_predictive_query was unable to construct the correct query, causing the prediction logic to fail and return False. With this fix, a new argument has been added to _predicted_field to pass the move. This ensures that the prediction logic uses the correct move_id and behaves as expected. **task**-4943015 Community PR - https://github.com/odoo/odoo/pull/219911 Forward-Port-Of: odoo/enterprise#91224
The app creator dialog now displays its selection buttons with the correct spacing again. This fixes a visual issue introduced during a recent component update, helping keep the app creation experience clear and polished.
Original PR description
This commit brings back the 'p-0' class to the SelectMenu's being used in the app creator. They were removed during the refactor of the component, but were still required to display properly those buttons in the app creator dialog.
Users can now edit bank-related fields in Odoo Studio without encountering an error. This prevents a crash when configuring certain contact and accounting screens, making customization smoother and more reliable.
Original PR description
Example of steps: - Install contacts, web_studio and accounting - Go to contacts, accounting tabs - Open web_studio and click on Banks field - Traceback The error stems from the fact that we are using a widget in an o2m field that uses a placeholder that is not defined for o2m. One solution is to add the placeholder attribute for o2m in addition to m2m and m2o. opw-4937447 Forward-Port-Of: odoo/enterprise#91346
The Belgian point of sale module now checks that a value is present before using it during processing. This prevents an avoidable error and helps keep POS operations running smoothly.
Original PR description
We increased the code robustness by ensuring the variable isn't undefined before using `.startsWith` Forward-Port-Of: odoo/enterprise#91357
The payslip PDF now respects the salary structure option to hide the basic wage. This prevents basic wage details from appearing when payroll administrators have chosen to keep them off printed payslips.
Original PR description
After this commit: odoo/enterprise@9dceed0896ce5089bccbc9cc2ce1e8c4b13f0048…
After this commit: odoo/enterprise@9dceed0896ce5089bccbc9cc2ce1e8c4b13f0048 [diff](https://github.com/odoo/enterprise/commit/9dceed0896ce5089bccbc9cc2ce1e8c4b13f0048#diff-de4a628e7837c273b67d71f93efab85b6a9ee957ea702f502066ebcc632a76cbL64) The condition that handles hiding the basic wage on the payslip was not added —possibly it was missed. That’s why the "Hide basic on PDF" feature doesn’t work, regardless of whether it’s enabled, as the necessary condition is missing in the template. Steps to reproduce (on runbot): - In a v18 runbot, open any payslip and go to the salary structure. Enable the "Hide basic on PDF" option. - Return to the payslip and print it. - You’ll see that the basic wage is still printed on the payslip. **Before Fix:** <img width="669" height="238" alt="payslipbefore" src="https://github.com/user-attachments/assets/2fce67a2-19d8-45d8-88fa-4fc6a1767e68" /> **After Fix:** <img width="683" height="289" alt="payslipafter" src="https://github.com/user-attachments/assets/adcb0104-9c4e-4a35-ba78-b3f278f6bfda" /> opw-4953831 Forward-Port-Of: odoo/enterprise#91389 Forward-Port-Of: odoo/enterprise#90798