Daily updates from Odoo
Tuesday, September 16, 2025
233 changes
26 changes
Resolved issues and error corrections
Studio exports now work correctly for binary fields that are not stored as attachments. This prevents export failures and helps users retrieve their Studio-managed data reliably.
Original PR description
**Before:** Attempting to export non-attachment binary fields using the `Studio Export` would cause a traceback. **After:** Non-attachment binary fields can now be successfully exported from `Studio` without error. task-4888937 Forward-Port-Of: odoo/enterprise#94230 Forward-Port-Of: odoo/enterprise#93781
DIN5008 report layouts now stop showing the customer's phone number in the address block, and the customer's VAT number is moved out of that section. This keeps printed customer addresses cleaner and aligned with the intended DIN5008 layout.
Original PR description
This commit removes the phone number from the DIN5008 report layout. The customer's VAT is also no longer displayed in the customer's address section. The VAT is moved to another section. Description of the issue/feature this PR addresses: Current behavior before PR: The customer's phone number and VAT are displayed in the customer's address in the DIN5008 report layout. Desired behavior after PR is merged: The customer's phone number is no longer displayed and VAT moved to another section in the DIN5008 report layout. opw-5049074 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226967 Forward-Port-Of: odoo/odoo#226630
This fixes an issue where loyalty points could be counted twice after a sales order was confirmed, preventing some eligible discounts from being applied. Businesses using discount and loyalty programs can now expect customers to receive all qualifying rewards consistently.
Original PR description
## Versions: 16.0+ ## Issue: After confirming a Sales Order (SO), loyalty points are incorrectly calculated when applying additional promotions. This causes only one reward to be applied instead of…
## Versions:
16.0+
## Issue:
After confirming a Sales Order (SO), loyalty points are incorrectly calculated when applying additional promotions. This causes only one reward to be applied instead of all eligible ones.
## Cause:
When the SO is confirmed, the cost in points for each line is retrieved and deducted to compute remaining available points. However, when promotions are re-applied, the system re-evaluates the total cost of the SO and deducts the points again, effectively double-counting the same lines.
## Steps to reproduce:
- Set up a `Discount & Loyalty` promotion program:
- 2 points granted per purchase (minimum $0).
- Rewards:
- 5% discount on "Simple Pen" (costs 1 point).
- 10% discount on "Whiteboard Pen" (costs 1 point).
- Create a Quotation with "Simple Pen" and "Whiteboard Pen".
- Confirm the Quotation into a Sales Order.
- Apply promotions:
- The first reward applies correctly
- The second reward does not apply
opw-4753472
Forward-Port-Of: odoo/odoo#226656
Forward-Port-Of: odoo/odoo#211342Users can now add several new comma-separated tags when creating a forum post without triggering an error. This prevents failed post submissions and makes forum tagging behave as expected.
Original PR description
Currently, an error occurs when a user tries to add multiple comma-separated new tags to a forum post. **Steps to reproduce:** - Install the `website_forum` module. - Go to: `Website > Configuration…
Currently, an error occurs when a user tries to add multiple comma-separated new tags to a forum post. **Steps to reproduce:** - Install the `website_forum` module. - Go to: `Website > Configuration > Forums`, create a new forum, then click `Go to Website`. - Click on `Start by creating a post`, enter content, and set the `Tags` to `_test, retour affectif rapide`. - Click on `Post Your Question`. **Error:** `ValueError: invalid literal for int() with base 10: 'retour affectif rapide'` **Root Cause:** After PR #169472, at [1], the code prepends an underscore (_) only to the entire input string instead of each tag. When multiple tags are entered, the backend receives a mixed list of values (e.g., ['__test', 'retour affectif rapide']), leading to an error during `int()` conversion at [2]. **Fix:** This commit updates the `onCreateOption` logic to prepend an underscore to each tag in the comma-separated input, similar to [3]. Also updated the test case at [4], to click `Create option` to save the tags. [1]: https://github.com/odoo/odoo/blob/afa26af132566a68ad6bf67565062bd73ddd7429/addons/website_forum/static/src/js/website_forum.js#L54-L61 [2]: https://github.com/odoo/odoo/blob/afa26af132566a68ad6bf67565062bd73ddd7429/addons/website_forum/models/forum_forum.py#L304 [3]: https://github.com/odoo/odoo/blob/ac93a25b216e6194895a64fe12c0d01f6833f743/addons/website_forum/static/src/js/website_forum.js#L69-L80 [4]: https://github.com/odoo/odoo/blob/d155edfd729ab9b53f38939fe24b6d1e7b578083/addons/website_forum/static/tests/tours/website_forum_question.js#L34-L37 sentry-6761920887 Forward-Port-Of: odoo/odoo#227185 Forward-Port-Of: odoo/odoo#220058
The accounting KPI summary now counts posted accounting entries that still need an accountant's review, in addition to draft entries. This gives teams a more complete view of outstanding accounting work and categorizes it by journal type for clearer reporting.
Original PR description
The `kpi.provider:get_account_kpi_summary` method should count draft moves by category, but also include posted moves that still are to be checked by the accountant. Task-id: 5062431 Forward-Port-Of: odoo/odoo#227091 Forward-Port-Of: odoo/odoo#226411
PDF documents now display tiny negative amounts that round to zero as "0.00" instead of "-0.00". This avoids confusing or misleading totals on printed reports and customer-facing documents.
Original PR description
Previously, when an amount value that is passed to `value_to_html` is a really small negative number (e.g. -0.000000001), the rounded result will have the negative sign in front of it (e.g. "-0.00").
This commit fixes it so that they will be rendered without the negatives ("0.00").
opw-4685953
Forward-Port-Of: odoo/odoo#224292This fix prevents the Time Off app from showing an error when a user clears the end date while creating a leave request. The system now safely skips date comparison until valid dates are entered, keeping the form usable and relying on existing validation to guide the user.
Original PR description
Currently, an error occurs when user removes value from `request_date_to` field. **Steps to replicate:** - Install Time Off app and open it. - Click new and remove values from the `request_date_to` field (the second date field in the row) and click somewhere else. **Error:** `TypeError: '<=' not supported between instances of 'datetime.date' and 'bool'` **Cause:** - The field `leave.request_date_to` is received as `False` in the line [1] as the user deleted it. **Solution:** - Added a check for date values, if the date values are false, the further code execution is skipped because the validation is already present. [1]: https://github.com/odoo/odoo/blob/b6c4c190331a7dc826df1b2ef399c0f6be32f657/addons/hr_holidays/models/hr_leave.py#L363 sentry-6830356042 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Employees with more than one running contract can now open the Time Off app without an error. This fix helps HR teams manage employees whose contracts change during the year without disrupting leave planning.
Original PR description
**Step to Reproduce** - install hr_contract and hr_holidays module - go to employee -> contracts - Add 2-3 contract to a employee, which can be done by having contracts in different interval (but…
**Step to Reproduce**
- install hr_contract and hr_holidays module
- go to employee -> contracts
- Add 2-3 contract to a employee, which can be done by having contracts in different interval (but same year)
- set their stage to `running`
- open Time off App
**Observation:**
- we receive a traceback
```
File "/data/build/odoo/addons/hr_contract/models/hr_employee.py", line 229, in _get_unusual_days
tmp_date_from = max(date_from_date, selected_contract.date_start)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/orm/fields.py", line 1424, in __get__
record.ensure_one()
File "/data/build/odoo/odoo/orm/models.py", line 5635, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: hr.contract(1, 2)
```
**Cause:**
- `_get_unusual_days` assumes that there is only one running contract
- Hence with multiple contract, it raises traceback
Fix:
- Adjust the method to accept multiple contracts
opw-5045306
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#225521This fix prevents calendar events with non-Odoo video call links from failing during upgrades or mail template checks. It ensures Google Calendar permission validation only applies when relevant calendar-sync fields are being changed, reducing disruption for users upgrading databases with appointments and Google Calendar enabled.
Original PR description
**Steps to Reproduce:** 1. Create DB in 18.0 with calendar module and google_calendar without demo data. 2. create a calendar event with videocall location other then odoo generated and mark that as…
**Steps to Reproduce:**
1. Create DB in 18.0 with calendar module and google_calendar without demo data.
2. create a calendar event with videocall location other then odoo generated and mark that as guest_readonly.
3. after that install appointment module and ``acces_token``.
4. upgrade to 18.3 below mentioned traceback will raise or can update to mail template.
**Issue**
why from 18.3 [from](https://github.com/odoo/odoo/commit/999df6d4a3b5d21648e5e09757661714e99e1154#diff-bd520efea06a5449c8694b54f5f7aa8587c929a5669ea0439bb9d5e38f8d29c8) this commit now template will render on record for checking. During render checking the ``videocall_redirection`` field value as it [compute](https://github.com/odoo/enterprise/blob/f5d99ea7ae7c2748c4a23a793c46ab1a123b3aad/appointment/models/calendar_event.py#L188) and non store field it going for compute over here the access_token is missing so it will go for compute and during that this [validation](https://github.com/odoo/odoo/blob/1ac89eb71aab48fa8d50fbae01d96bec23d88418/addons/google_calendar/models/calendar.py#L106) is triggering and it breaking because env user is odoobot and user_id is different this issue occur during checking on write on mail template.
**Fix:**
For fixing this checking is the fields syncable with calendar or not
```
File "/home/odoo/src/odoo/saas-18.4/odoo/orm/fields.py", line 1751, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/saas-18.4/odoo/orm/fields.py", line 1914, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/saas-18.4/addons/calendar/models/calendar_event.py", line 696, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/saas-18.4/addons/mail/models/mail_thread.py", line 469, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/saas-18.4/odoo/orm/models.py", line 4620, in _compute_field_value
determine(field.compute, self)
File "/home/odoo/src/odoo/saas-18.4/odoo/orm/fields.py", line 81, in determine
return needle(*args)
File "/home/odoo/src/enterprise/saas-18.4/appointment/models/calendar_event.py", line 207, in _compute_videocall_redirection
event.access_token = uuid.uuid4().hex
File "/home/odoo/src/odoo/saas-18.4/odoo/orm/fields.py", line 1847, in __set__
records.write({self.name: write_value})
File "/home/odoo/src/enterprise/saas-18.4/appointment/models/calendar_event.py", line 246, in write
res = super().write(vals)
File "/home/odoo/src/odoo/saas-18.4/addons/google_calendar/models/calendar.py", line 96, in write
self._check_modify_event_permission(values)
File "/home/odoo/src/odoo/saas-18.4/addons/google_calendar/models/calendar.py", line 108, in _check_modify_event_permission
raise ValidationError(_("The following event can only be updated by the organizer "
odoo.exceptions.ValidationError: El organizador es el único que puede actualizar el siguiente evento de acuerdo con los permisos del evento establecidos en Google Calendar.
```
opw-5042454
upg-3113613
TBG - 2082
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#226890Lists marked to appear without indentation now keep their intended spacing in the website editor. This prevents footer and other unstyled lists from looking incorrectly indented while editing pages.
Original PR description
Problem: The default Bootstrap padding is being forced on all lists inside the editor, including those with the `list-unstyled` class. This class is supposed to enforce `0px` padding, but the current rule overrides it. Solution: Remove the style as `2rem` is already the Bootstrap default list padding. Done here: https://github.com/odoo/odoo/commit/1593f25b0160a68d356dd5bba3887ff5a6298c60 Steps to reproduce: 1. Open website. 2. Open the editor. 3. Notice the footer list (with `list-unstyled`) is incorrectly indented. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227204
Creating a repair order with a kit product no longer triggers an error. This restores the expected repair workflow for businesses that service or repair bundled products.
Original PR description
**PROBLEM** There is a traceback when trying to create a repair order with a kit product. **CAUSE** Commit https://github.com/odoo/odoo/commit/facf4eba6cd0504aae949c23454c6ffa9eaa9c3f removed `name` field on `stock.model`, but forget one occurence in `mrp_repair`. opw-5068120
This fixes an internal test setup issue where the self-order payment route was generated before its access token was available. The change helps keep kiosk QR code and IoT payment-related testing reliable, reducing the risk of regressions reaching users.
Original PR description
A call to `_get_self_order_route` in the `test_online_payment_kiosk_qr_code` test was happening too early, resulting on getting the self order url missing the `access_token`. This resulted in making the test fail due to the override of the `iot_http` service in `pos_self_order_iot`, relying on this token to get the IoT WebSocket channel. Enterprise PR: odoo/enterprise#93895
Fixes an issue that could block Ecuadorian delivery guide generation when barcode scanning was turned off in Inventory settings. Businesses can now create delivery guides reliably without needing to enable barcode scanner features.
Original PR description
Currently, an error occurs when generating a Delivery Guide if the Barcode Scanner is disabled in the Inventory settings. **Steps to reproduce:** - Install the `l10n_ec_edi_stock` module and switch…
Currently, an error occurs when generating a Delivery Guide if the Barcode Scanner is disabled in the Inventory settings. **Steps to reproduce:** - Install the `l10n_ec_edi_stock` module and switch to the `EC company`. - Uncheck `Barcode Scanner` in the Inventory `settings`. - Create a new warehouse and set the `Entity` and `Emission Point`. - Navigate to Inventory > Operations > Deliveries and create a new delivery. - Add details > mark as Todo > Validate > Generate Delivery Guide. **Error:** `AttributeError: 'stock.move.line' object has no attribute 'qty_done'` **Root Cause:** At [1], the code references `line.qty_done`, but this field is defined in the `stock_barcode` module at [2]. When the Barcode Scanner is `disabled`, the field is not available, leading to the `error`. **Fix:** This commit updates the delivery guide values to use `line.quantity` instead of `line.qty_done` at [1] and at [4]. Since in the `stock_barcode` module at [3], `qty_done` is derived from `quantity`. [1]: https://github.com/odoo/enterprise/blob/ba5b9790f28e2f7eabda22e5992737eab0e82c6e/l10n_ec_edi_stock/models/stock_picking.py#L354 [2]: https://github.com/odoo/enterprise/blob/8c53e50df1cf9dc6d3ca4cae19c39135ac85d4e4/stock_barcode/models/stock_move_line.py#L23 [3]: https://github.com/odoo/enterprise/blob/8c53e50df1cf9dc6d3ca4cae19c39135ac85d4e4/stock_barcode/models/stock_move_line.py#L48-L50 [4]: https://github.com/odoo/enterprise/blob/8b72fdef63f634ccf436b49adbac5c1f9358c127/l10n_ec_edi_stock/views/report_delivery_guide.xml#L165 sentry-6851008674 Forward-Port-Of: odoo/enterprise#93775
This fixes an issue where changing only stock lot or location details on a manufacturing component could incorrectly mark it as consumed. Manufacturing orders now show component consumption only when the consumed quantity actually changes, reducing user confusion and keeping production records accurate.
Original PR description
Issue Before This Commit: ============================ When only the quants/move line were changed without modifying the quantity, the system automatically marked components as consumed (manual…
Issue Before This Commit: ============================ When only the quants/move line were changed without modifying the quantity, the system automatically marked components as consumed (manual consumption and picked boolean were set). This created confusion for the user since no actual consumption took place. Steps to Reproduce: ============================ - Install the `mrp` module. - Create a tracked product (lot/serial) with quants. - Create and confirm an MO having that product as a component. - Change only the quants (e.g., location of the quant, not quantity); notice that manual consumption and picked boolean are set. Cause of the Issue: =========================== This issue occurs when clicking the 'Details' button (`action_show_details` method) on a stock move. That action passes the context `force_manual_consumption`, based on that which directly sets the `manual_consumption` and `picked` booleans in the `write` and `create` methods. [see](https://github.com/odoo/odoo/blob/master/addons/mrp/models/stock_move.py#L276). With This Commit: ============================ Manual consumption and picked boolean are no longer set when only quants (not quantity) are changed. Component consumption is now triggered only if the quantity differs from the demand, ensuring consistency and avoiding confusion for the user. This fix avoids unintended behaviour by ensuring that the picked and manual consumption booleans change only when the quantity differs from the demand. TaskID:- 5062365 Forward-Port-Of: odoo/odoo#225386
Mobile users now see the template name as the main information when browsing signing templates, instead of seeing the creation date first. This makes it easier to choose the correct template and keeps the mobile view aligned with the desktop experience.
Original PR description
### Issue: - In mobile view, the template list was showing the creation date instead of the template name. - This made it hard to know which template you were selecting. --- ### Fix: - Changed the mobile view to show the template name as the main info. - The creation date is still shown, but as extra information. --- ### Impact: - Easier to find the right template on mobile. - Mobile and desktop views now look consistent. --- Task: 5038933 Forward-Port-Of: odoo/enterprise#93072
Guest shoppers could encounter a Forbidden error when the shop determined taxes or pricing rules from their location. The fix ensures the required fiscal setup can be read safely, keeping the online store accessible to anonymous visitors.
Original PR description
Ensure the fiscal position is always computed using sudo. When computing the fiscal position based on geolocated country, the result may not be return without sudo. Steps to reproduce: - Set a default Fiscal Position on the contact model (property_account_position_id) - Visit the website shop without logging in. - You will get a Forbidden error because Odoo raises an access error when fetching the fiscal position. This fix add a sudo() to the partner used to compute the fiscal position, so that when accessing the partner property, it will be returned with `env.su = True`. opw-5058588 Forward-Port-Of: odoo/odoo#225481
Mexican electronic invoice PDFs now use the same customer fiscal regime as the official XML file. This prevents mismatches between the human-readable invoice and the legally submitted CFDI document, reducing confusion for users and customers.
Original PR description
In l10n_mx: - Create a child contact under a company contact. - Set the fiscal regime of the child contact to one different from the company’s fiscal regime. - Create an invoice with the child contact and send it to the CFDI. In the XML, the fiscal regime used is the company’s, whereas in the PDF it is the child contact’s. This commit applies the same logic from _add_customer_cfdi_values to the PDF generation. After this change, the fiscal regime shown in the PDF will be the company’s, consistent with the XML. opw-4989605 Forward-Port-Of: odoo/enterprise#94259 Forward-Port-Of: odoo/enterprise#92482
Users can now open the duplicate transactions wizard even when no bank journal is linked. This avoids an unexpected error in Accounting and makes the view safer to access directly.
Original PR description
Currently, an error occurs when users try to open the view directly. Steps to reproduce: --- - Install `Accounting` module - Using Open View, Open `account.duplicate.transaction.wizard` view Traceback: --- `ValueError: Expected singleton: account.journal()` This error occurs because no account journal is linked to the wizard at [1], resulting in an empty `account.journal`. [1]- https://github.com/odoo/enterprise/blob/08564f3312c255f2f3ab95cef5a9bfc57727bd1f/account_online_synchronization/wizard/account_journal_duplicate_transactions.py#L32 sentry-6812500330 Forward-Port-Of: odoo/enterprise#94538
The portal signature form now checks whether a pop-up window is present before trying to use it. This prevents errors when the form is embedded directly on a page, making customer signature flows more reliable.
Original PR description
Description of the issue/feature this PR addresses: Be able to use the portal signature form outside of a modal. Current behavior before PR: If the signature form (```<t t-call=“portal.signature_form”>```) is used outside of a modal, an error occurs: ```TypeError: Cannot read properties of null (reading 'addEventListener')``` Desired behavior after PR is merged: The signature form can be used outside of a modal. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224564
When users create a new partner during bank reconciliation, the system now chooses the receivable or payable action based on the transaction amount instead of missing customer or supplier history. This prevents the wrong payment button from appearing for brand-new partners, reducing confusion during reconciliation.
Original PR description
When creating a new partner from the set partner button, the partner doesn't have any rank (supplier or customer), this lead to have the payable button to be displayed since the condition to have it is to have a partner and not (customer_rank > supplier_rank). Since supplier rank and customer rank are 0 it will be False which lead to the button to be displayed. no task id Forward-Port-Of: odoo/enterprise#90435
Website sitemaps now avoid listing the same page more than once when website controllers are customized. This helps search engines receive cleaner sitemap data without changing which pages are available on the site.
Original PR description
When extending controllers (e.g. `WebsiteSale.shop`), sitemap entries were duplicated because deduplication relied on the endpoint function object. Overridden methods result in different function objects but identical sitemap URLs, leading to duplicates. This commit fixes the issue by deduplicating on the generated sitemap location (`loc['loc']`) instead of the function object, ensuring unique URLs in the sitemap even when controllers are extended. Fixes #224193 Forward-Port-Of: odoo/odoo#226810 Forward-Port-Of: odoo/odoo#224406
This fixes an access error that blocked branch or child companies from confirming sales orders when using loyalty programs defined by their parent company. The change lets the necessary loyalty history be recorded correctly, so shared loyalty programs work smoothly across company structures.
Original PR description
If you have a company parent with loyaltly programs and you try to confirm a sale order from a child company, an access error will be raised. Steps to reproduce: ------------------- * Create a…
If you have a company parent with loyaltly programs and you try to confirm a sale order from a child company, an access error will be raised. Steps to reproduce: ------------------- * Create a loyalty cards program * Set company to the current company * Create a branch company for the current one * Switch to branch company * Create a sale order, no need to add products, just a partner * Try to confirm the order > Observation: Access Error: > Sorry, Mitchell Admin (id=2) doesn't have 'create' access to: > -History for Loyalty cards and Ewallets (loyalty.history) Why the fix: ------------ Here's where the access error is being triggered: https://github.com/odoo/odoo/blob/35ea3dcb2eeb379c8b1127f0c7b42191853c0bd2/addons/sale_loyalty/models/sale_order.py#L106 Branches currently have access to the discounts & loyalty programs from the parent company, we extend the access to include loyalty history. Another solution could be to create the loyalty history using sudo() if the coupon's program id is a parent of the current company. opw-5055999 Forward-Port-Of: odoo/odoo#226226
The website SEO dialog now clears old image status changes when it is opened. This prevents image alt descriptions added in the editor from being accidentally erased when users reopen and save the SEO dialog without making changes.
Original PR description
Steps to reproduce: 1. Open Optimize SEO. 2. Mark an image as decorative. 3. Save it. 3. Give a description(ALT) to that image from editor. 4. Open Optimize SEO again and save without doing anything. Issue: The description(ALT) on the image being set is lost. Cause: When reopening the **Optimize SEO** dialog, `seoContext.updatedAlts` still contained entries from previous edits. As a result, saving without making any change triggered an call to `update_alt_images` which reset the `alt` attribute to empty, eventually discarding the description. This PR ensures `seoContext.updatedAlts` is reset when opening the dialog. Forward-Port-Of: odoo/odoo#226913
Odoo Studio now requires users to choose a related record type when creating AI-powered Many2one or Tags fields. This prevents crashes caused by incomplete field setup and gives users a clear visual warning before they confirm.
Original PR description
When adding an AI field of type Many2one or Tags, the Relation field was optional. If left empty, it caused a crash. This commit enforces that a Relation must be selected before confirming the dialog: - Add a red highlight if Relation is missing - Prevent field creation by returning early Task-5055796 Forward-Port-Of: odoo/enterprise#93873
This fix prevents Razorpay OAuth webhook setup from failing when website payments are enabled. It ensures payment connection URLs are built consistently, avoiding authentication errors caused by malformed addresses.
Original PR description
A bad URL could be generated when the `website_payment` module is installed, as it overrides `get_base_url` and may return a URL ending with `/`. Using f-strings to create URLs could result in a double slash `//`, causing errors. Steps to reproduce: - Install `website_payment` and `payment_razorpay_oauth` - Go to Payment Acquirers and connect via OAuth - Click "Generate your webhook" - "Authentication failed" error appears This fix uses `url_join`, like other payment providers, to build URLs correctly and avoid the double slash issue. opw-5079295 Forward-Port-Of: odoo/odoo#226639 Forward-Port-Of: odoo/odoo#226248
FedEx Home Delivery shipments can now generate return labels without triggering a recipient address error. This ensures affected US deliveries proceed smoothly when return labels are enabled.
Original PR description
**PROBLEM** When selecting FedEx Home Delivery service, and enabling the return label generation, we got the error `RECIPIENT.ADDRESS.ERROR`. **STEPS TO REPRODUCE** 1. Install delivery_fedex_rest (use the new fedex credentials). 2. On the FedEx US shipment method (demo data) select FedEx home delivery service, and check the `Generate Return Label` option. 3. Create a SO, add shipping with FedEx US, validate the SO. 4. Validate the delivery order, and notice the FedEx API return an error. **CAUSE** For Home Delivery Service, the recipient address need to have the `residential` flag set to true. In `_return_package()`, the request sent doesn't include this flag, leading to an error. **FIX** Fix `_return_package()` query to include the `residential` flag. opw-4939065 Forward-Port-Of: odoo/enterprise#94463
8 changes
Resolved issues and error corrections
Very small negative amounts that round to zero now appear as "0.00" instead of "-0.00" on printed PDFs. This prevents confusing or misleading totals on business documents while keeping the actual rounding behavior unchanged.
Original PR description
Previously, when an amount value that is passed to `value_to_html` is a really small negative number (e.g. -0.000000001), the rounded result will have the negative sign in front of it (e.g. "-0.00").
This commit fixes it so that they will be rendered without the negatives ("0.00").
opw-4685953
Forward-Port-Of: odoo/odoo#224292The accounting KPI summary now includes posted accounting entries that still need an accountant's review, not only draft entries. This gives teams a more accurate view of pending accounting work by journal category, helping them prioritize follow-up tasks.
Original PR description
The `kpi.provider:get_account_kpi_summary` method should count draft moves by category, but also include posted moves that still are to be checked by the accountant. Task-id: 5062431 Forward-Port-Of: odoo/odoo#227091 Forward-Port-Of: odoo/odoo#226411
This fix prevents Ecuadorian delivery guides from failing when the Barcode Scanner option is turned off in Inventory. Businesses can now generate the required delivery documents reliably regardless of whether barcode scanning is enabled.
Original PR description
Currently, an error occurs when generating a Delivery Guide if the Barcode Scanner is disabled in the Inventory settings. **Steps to reproduce:** - Install the `l10n_ec_edi_stock` module and switch…
Currently, an error occurs when generating a Delivery Guide if the Barcode Scanner is disabled in the Inventory settings. **Steps to reproduce:** - Install the `l10n_ec_edi_stock` module and switch to the `EC company`. - Uncheck `Barcode Scanner` in the Inventory `settings`. - Create a new warehouse and set the `Entity` and `Emission Point`. - Navigate to Inventory > Operations > Deliveries and create a new delivery. - Add details > mark as Todo > Validate > Generate Delivery Guide. **Error:** `AttributeError: 'stock.move.line' object has no attribute 'qty_done'` **Root Cause:** At [1], the code references `line.qty_done`, but this field is defined in the `stock_barcode` module at [2]. When the Barcode Scanner is `disabled`, the field is not available, leading to the `error`. **Fix:** This commit updates the delivery guide values to use `line.quantity` instead of `line.qty_done` at [1] and at [4]. Since in the `stock_barcode` module at [3], `qty_done` is derived from `quantity`. [1]: https://github.com/odoo/enterprise/blob/ba5b9790f28e2f7eabda22e5992737eab0e82c6e/l10n_ec_edi_stock/models/stock_picking.py#L354 [2]: https://github.com/odoo/enterprise/blob/8c53e50df1cf9dc6d3ca4cae19c39135ac85d4e4/stock_barcode/models/stock_move_line.py#L23 [3]: https://github.com/odoo/enterprise/blob/8c53e50df1cf9dc6d3ca4cae19c39135ac85d4e4/stock_barcode/models/stock_move_line.py#L48-L50 [4]: https://github.com/odoo/enterprise/blob/8b72fdef63f634ccf436b49adbac5c1f9358c127/l10n_ec_edi_stock/views/report_delivery_guide.xml#L165 sentry-6851008674 Forward-Port-Of: odoo/enterprise#93775
The Time Off app no longer crashes when an employee has more than one running contract across different periods. This ensures HR users can manage leave normally for employees with multiple active contract records.
Original PR description
**Step to Reproduce** - install hr_contract and hr_holidays module - go to employee -> contracts - Add 2-3 contract to a employee, which can be done by having contracts in different interval (but…
**Step to Reproduce**
- install hr_contract and hr_holidays module
- go to employee -> contracts
- Add 2-3 contract to a employee, which can be done by having contracts in different interval (but same year)
- set their stage to `running`
- open Time off App
**Observation:**
- we receive a traceback
```
File "/data/build/odoo/addons/hr_contract/models/hr_employee.py", line 229, in _get_unusual_days
tmp_date_from = max(date_from_date, selected_contract.date_start)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/orm/fields.py", line 1424, in __get__
record.ensure_one()
File "/data/build/odoo/odoo/orm/models.py", line 5635, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: hr.contract(1, 2)
```
**Cause:**
- `_get_unusual_days` assumes that there is only one running contract
- Hence with multiple contract, it raises traceback
Fix:
- Adjust the method to accept multiple contracts
opw-5045306
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#225521Mexican electronic invoice PDFs now show the same customer fiscal regime as the official CFDI XML when invoicing a child contact under a company. This prevents discrepancies between customer-facing invoice documents and legally reported tax data.
Original PR description
In l10n_mx: - Create a child contact under a company contact. - Set the fiscal regime of the child contact to one different from the company’s fiscal regime. - Create an invoice with the child contact and send it to the CFDI. In the XML, the fiscal regime used is the company’s, whereas in the PDF it is the child contact’s. This commit applies the same logic from _add_customer_cfdi_values to the PDF generation. After this change, the fiscal regime shown in the PDF will be the company’s, consistent with the XML. opw-4989605 Forward-Port-Of: odoo/enterprise#94259 Forward-Port-Of: odoo/enterprise#92482
Public visitors could hit a Forbidden error in the online shop when fiscal settings were calculated from their location. The update ensures those settings can be read correctly, keeping the shopping experience available for anonymous customers.
Original PR description
Ensure the fiscal position is always computed using sudo. When computing the fiscal position based on geolocated country, the result may not be return without sudo. Steps to reproduce: - Set a default Fiscal Position on the contact model (property_account_position_id) - Visit the website shop without logging in. - You will get a Forbidden error because Odoo raises an access error when fetching the fiscal position. This fix add a sudo() to the partner used to compute the fiscal position, so that when accessing the partner property, it will be returned with `env.su = True`. opw-5058588 Forward-Port-Of: odoo/odoo#225481
The portal signature form now works correctly even when it is placed directly on a page instead of inside a pop-up window. This prevents an error that could block users from completing signature steps in some portal flows.
Original PR description
Description of the issue/feature this PR addresses: Be able to use the portal signature form outside of a modal. Current behavior before PR: If the signature form (```<t t-call=“portal.signature_form”>```) is used outside of a modal, an error occurs: ```TypeError: Cannot read properties of null (reading 'addEventListener')``` Desired behavior after PR is merged: The signature form can be used outside of a modal. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224564
Opening the duplicate transactions wizard directly no longer triggers an error when no accounting journal is linked. This improves reliability for users accessing accounting views and prevents an unexpected crash in this edge case.
Original PR description
Currently, an error occurs when users try to open the view directly. Steps to reproduce: --- - Install `Accounting` module - Using Open View, Open `account.duplicate.transaction.wizard` view Traceback: --- `ValueError: Expected singleton: account.journal()` This error occurs because no account journal is linked to the wizard at [1], resulting in an empty `account.journal`. [1]- https://github.com/odoo/enterprise/blob/08564f3312c255f2f3ab95cef5a9bfc57727bd1f/account_online_synchronization/wizard/account_journal_duplicate_transactions.py#L32 sentry-6812500330 Forward-Port-Of: odoo/enterprise#94538
4 changes
Resolved issues and error corrections
The fiscal regime shown on Mexican electronic invoice PDFs now follows the same contact hierarchy rules as the official CFDI XML. This avoids confusing mismatches between the customer-facing PDF and the legally relevant XML when invoicing child contacts of a company.
Original PR description
In l10n_mx: - Create a child contact under a company contact. - Set the fiscal regime of the child contact to one different from the company’s fiscal regime. - Create an invoice with the child contact and send it to the CFDI. In the XML, the fiscal regime used is the company’s, whereas in the PDF it is the child contact’s. This commit applies the same logic from _add_customer_cfdi_values to the PDF generation. After this change, the fiscal regime shown in the PDF will be the company’s, consistent with the XML. opw-4989605 Forward-Port-Of: odoo/enterprise#94259 Forward-Port-Of: odoo/enterprise#92482
Opening the duplicate transactions wizard directly no longer triggers an error when no bank journal is linked. This avoids a confusing crash and makes the Accounting workflow more reliable for users who access the view manually.
Original PR description
Currently, an error occurs when users try to open the view directly. Steps to reproduce: --- - Install `Accounting` module - Using Open View, Open `account.duplicate.transaction.wizard` view Traceback: --- `ValueError: Expected singleton: account.journal()` This error occurs because no account journal is linked to the wizard at [1], resulting in an empty `account.journal`. [1]- https://github.com/odoo/enterprise/blob/08564f3312c255f2f3ab95cef5a9bfc57727bd1f/account_online_synchronization/wizard/account_journal_duplicate_transactions.py#L32 sentry-6812500330 Forward-Port-Of: odoo/enterprise#94538
The booking page now shows the correct maximum number of people based on all available appointment resources, rather than being limited by the first resource found. This prevents customers from seeing an artificially low capacity and helps businesses accept the right number of attendees for each appointment slot.
Original PR description
**How to reproduce:** - Create an appointment with availability assigned to a resource. - Enable 'Manage Capacity' - Set the capacity of the first resource lower than the second one. - Open the appointment's booking page. **Technical Reason:** If appointment is scheduled based on 'resource_time' then resource_default is updated as the first value of resource_possible. Related PR: https://github.com/odoo/enterprise/pull/47059 **After this PR:** 'Number of people' dropdown will display the maximum capacity from all available resources. Task-4664393 Forward-Port-Of: odoo/enterprise#84243
FedEx Home Delivery shipments can now generate return labels without triggering a recipient address error. The fix ensures FedEx receives the required residential address information, reducing failed delivery validations for affected US shipments.
Original PR description
**PROBLEM** When selecting FedEx Home Delivery service, and enabling the return label generation, we got the error `RECIPIENT.ADDRESS.ERROR`. **STEPS TO REPRODUCE** 1. Install delivery_fedex_rest (use the new fedex credentials). 2. On the FedEx US shipment method (demo data) select FedEx home delivery service, and check the `Generate Return Label` option. 3. Create a SO, add shipping with FedEx US, validate the SO. 4. Validate the delivery order, and notice the FedEx API return an error. **CAUSE** For Home Delivery Service, the recipient address need to have the `residential` flag set to true. In `_return_package()`, the request sent doesn't include this flag, leading to an error. **FIX** Fix `_return_package()` query to include the `residential` flag. opw-4939065 Forward-Port-Of: odoo/enterprise#94463
22 changes
Resolved issues and error corrections
Fixed an issue where customers booking paid appointments could be incorrectly told a slot was unavailable when the selected resource still had capacity. This ensures upfront-payment appointment bookings respect the intended simultaneous booking limit and avoids unnecessary checkout failures.
Original PR description
ISSUE ===== Introduced in odoo/enterprise@bce7e94650c337a9046958a7689c81db5b2a4c73 , we now allow configuring a number of max simulatenous appointments per resource / user per slot, when…
ISSUE ===== Introduced in odoo/enterprise@bce7e94650c337a9046958a7689c81db5b2a4c73 , we now allow configuring a number of max simulatenous appointments per resource / user per slot, when manage_capacity is False. However, this broke the booking flow when enabling a payment on the appointment type as well, for resources with capacity > 1. More specifically, as soon as the remaining capacity is lower than the resource's own capacity. STEPS TO REPRODUCE ================== 0. Install payment_demo, in order to be able to test the payment issue. Install website_appointment_sale to ease the testing too. 1. Create an appointment type for 'Resources', enable 'Up-front payment'. 2. Set a new resource with capacity = 2 on the appointment type. 3. Make sure manage_capacity is False, and number of simultaneous appointments (max_bookings) is set to 1. 4. Go to the front end and pick any slot. 5. Fill the form and 'proceed to payment' 6. Try to 'pay now' 7. You get a validation error message telling you that the slot is not available anymore. But it is not the case since it is a new type and new resource. FIX === For resources, created booking lines were setting capacity_used to the resource's capacity, unless shared. (meaning: the resource is completely used, even if the reserved quantity is smaller). It made sense before but not for this new feature. It should only use 1 capacity, as we count the number of different simulatenous appointments, and it is unrelated to the resource's own capacity. When creating the meeting at the end of the regular flow, the computed field on capacity_used on appointment.booking.line will set it to 1 when manage_capacity is False. Hence, no issue will happen there in practice as the meeting is always created in that case and capacity_used updated. However, when enabling a payment, we create a calendar.booking instead, with calendar.booking.lines. And based on those, we evaluate availability when checking the cart before going to payment. Those are simply created from values in the controller, and the model is much simpler. Therefore, we fix the issue by manually setting the capacity_used to 1 when creating the booking lines in the front-end booking flow, in the case of an appointment without capacity management. Task-4963012 Forward-Port-Of: odoo/enterprise#94434 Forward-Port-Of: odoo/enterprise#91700
This fixes an issue where automated check templates did not apply their configured action. Businesses using accounting reports can now rely on automated checks to behave as intended, reducing missed or incorrect follow-up steps.
Original PR description
Currently the check template will not set the action for an automated checks. This is due to a condition that test if there is already the key in the dict which is useless here. Forward-Port-Of: odoo/enterprise#94206
Uruguay electronic invoicing now correctly handles document numbers that start with multiple letters, instead of only recognizing the first letter. This helps ensure credit notes, debit notes, and vendor bill documents are generated with the correct references and reduces validation issues.
Original PR description
If UY EDI document has latam document number with more than one letter at the beggining, it is needed to take in consideration all the letters and not only the first one. Task Latam side: 1352 Task Adhoc side: 53173 Forward-Port-Of: odoo/enterprise#90696
The appointment page loading indicator now uses a more appropriate color instead of incorrectly relying on the secondary theme color. This keeps the visual experience more consistent and polished for visitors while pages are loading.
Original PR description
*: website_helpdesk This commit revises the loading element that misuse the secondary color. task-5079680 Requires: - https://github.com/odoo/odoo/pull/226847 | Before | After | |--------|--------| | <img width="1920" height="1080" alt="Capture d’écran 2025-09-12 à 11 24 24 (3)" src="https://github.com/user-attachments/assets/b0d671e4-5538-4c63-9a3a-20bbe835b459" /> | <img width="1920" height="1080" alt="Capture d’écran 2025-09-12 à 13 22 59 (3)" src="https://github.com/user-attachments/assets/3b2d4452-84f2-446a-bb2b-bb4a8e0e9abc" /> | Forward-Port-Of: odoo/enterprise#94570
Fixed the Knowledge app so opening an activity from the activities menu now shows the related article instead of the full list of articles. This helps users quickly find the specific Knowledge article that needs their attention.
Original PR description
Currently, when the user tries to open any activity of the knowledge article, it opens all articles instead of the one which has an activity assigned to them. **Steps to reproduce this issue:** 1) Install the Knowledge module 2) Set up an activity for yourself on a Knowledge article 3) Open the activities from Activities (top left corner) **Issue:** You will end up in the all articles list, with no filters applied. **Cause:** When the user clicks on the activities, a default search filter is added in the context, which is then applied on the view. But in the knowledge article, we don't have any search filters for the activities. Therefore, it renders all knowledge article records. **Solution:** Add search filters for the knowledge articles. opw-4997201 Forward-Port-Of: odoo/enterprise#93609
The rental search page no longer starts a new search automatically when customers adjust the rental dates. This prevents unexpected page changes and makes the search experience clearer, while also updating the search button to better match the site’s primary styling.
Original PR description
Steps to reproduce: 1. Navigate to the rental search snippet on the website. 2. Modify the date range using the date picker. 3. Observe that the search is triggered automatically, which is not the desired behavior. After this commit: - Updated the search button style to use the primary color. - Made the search trigger only when the button is clicked, preventing automatic activation when the date range is modified. Forward-Port-Of: odoo/enterprise#94296
Calendar export times for planning slots now use the correct timezone when no employee is assigned. This prevents incorrect shift times in downloaded calendar files and keeps tests reliable when demo data is not installed.
Original PR description
The test `test_planning_ics_file_without_assigned_employee` failed when running without demo data because the slot timezone was `Europe/Brussels` while the employee timezone was `UTC`.
The previous code in the method `ics_datetime()` converted to the slot timezone and then relabeled it as the employee timezone with `.replace(tzinfo=...)`, which shifted the actual instant.
This change ensures that ICS datetimes are always converted using astimezone to a single target tz:
- employee tz if the slot is assigned,
- otherwise the current user tz or `UTC` as fallback.
The test was also updated to assert the correct fallback `UTC` values:
`DTSTART:20230602T080000Z`
`DTEND:20230602T170000Z`
[runbot-231213](https://runbot.odoo.com/odoo/error/231213)
Forward-Port-Of: odoo/enterprise#93692This fix restores a missing dependency so the AI website live chat feature can be installed, uninstalled, and reinstalled reliably. It prevents setup errors caused by the module looking for website components that were no longer guaranteed to be present.
Original PR description
odoo/enterprise#93271 changed the dependencies from `ai_website, im_livechat` to `website, ai_livechat`, but this change is incorrect: in `snippets.xml` the module hooks onto `t[@id='ai_livechat_hook']` which is installed by `ai_website`. As a result trying to uninstall `ai_website` when `ai_website_livechat` is installed breaks reinstallation since the snippets view becomes invalid. Forward-Port-Of: odoo/enterprise#94543
This update standardizes how internal test helper tools are accessed in Studio-related tests. It helps keep the test suite easier to maintain and reduces the risk of future test breakages, without changing customer-facing features.
Original PR description
This commit reduces imports to the 'tests/_framework/' subfolder, which is meant to be accessed through the 'web_test_helpers' module as to reduce the amount of imports, as well as centralizing all web helpers to have a quick overview of the available helpers. Community: https://github.com/odoo/odoo/pull/225865 Forward-Port-Of: odoo/enterprise#94496 Forward-Port-Of: odoo/enterprise#94074
This fix ensures POS orders receive cancellation confirmations from Worldline payment terminals even if the cashier refreshes the browser during a transaction. It prevents orders from getting stuck and adds clearer terminal error messages to help staff understand payment issues faster.
Original PR description
This PR fixes a bug where the point of sale didn't receive notifications from the Worldline payment terminal for the cancellations if the browser webpage was refreshed How to reproduce: 1. Open a POS session with Worldline terminal 2. Send a transaction to the terminal 3. Refresh the browser webpage before paying 4. Click on "Cancel" on the POS screen --> your order will be stuck and never receive the confirmation This PR removes the check for the iot longpolling action identifier which changes on refresh of the webpage + adds more error messages for Worldline terminals Related PR in v17 -> saas-18.2: https://github.com/odoo/enterprise/pull/94635 task-5075860 Forward-Port-Of: odoo/enterprise#94629
This update fixes access errors that could prevent non-administrator users from opening employee-related information in Appraisals, Planning, and Manufacturing Shop Floor. Affected users can now continue their normal workflows without needing unnecessary administrator permissions.
Original PR description
Forward-Port-Of: odoo/enterprise#94536
This change fixes an internal test by ensuring it uses vehicle data that is always available, rather than optional demo data. It helps keep validation runs stable across different database setups without changing customer-facing behavior.
Original PR description
In the [PR 91185](https://github.com/odoo/enterprise/pull/91185), the test was changed to comply with the new changes. In that test, a new vehicle was created using a model from the demo data. Since the demo data is not present in all databases, this caused a problem when the ID could not be found. To fix this, we now create a new model using a brand that exists in the data file and will therefore be present in all databases. See: https://runbot.odoo.com/odoo/runbot.build.error/231693?menu_id=405 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#94495
This update makes Philippine report export files generate lines in a consistent order. It helps prevent automated test failures and improves reliability without changing business functionality.
Original PR description
Fixes an issue with tests that would fail when the order of the lines in the file where not consistent. We will be a bit more precise in the order by of the export queries, and for SAWT/QAP we will also sort the lines after grouping per schedules to ensure that the order is consistent there too. See runbot error 232581 Forward-Port-Of: odoo/enterprise#94405
This update corrects internal definition files for the Knowledge app so they match recent product changes. It helps maintain reliability for future development and reduces the risk of technical inconsistencies, with no expected direct change for end users.
Original PR description
Recent changes did not update d.ts accordingly. https://github.com/odoo/odoo/pull/227182
This fix makes the rental checkout test wait for the cart page and pricing updates before checking totals. It helps prevent false build failures caused by timing issues rather than real customer-facing problems.
Original PR description
steps to reprduce: 1. duplicate multi enterprise 18.0 database 2. run the tour `website_sale_change_rental_duration` in the duplicated database inspired from: https://github.com/odoo/enterprise/commit/c7542e897c537650966497065db9c7d033dcb8ee added a delay to wait when choosing the rental duration, after page is loaded when go to cart , check if the next page is loaded before checking untaxed amount build_error-227718 Forward-Port-Of: odoo/enterprise#94519 Forward-Port-Of: odoo/enterprise#89274
This fixes a display issue where start and end date fields in Planning could shift out of alignment after a user clicked away. The Planning screens now remain visually consistent, making scheduling forms easier to read and use.
Original PR description
currently, `start_datetime` and `end_datetime` fields became misaligned when the date field lost focus, due to the datetime formatting changes introduced in PR https://github.com/odoo/odoo/pull/218387. This fix ensures the fields are properly aligned. task-5046364 Forward-Port-Of: odoo/enterprise#93371
This fixes the structure of Swiss ISO20022 payment XML files so bank clearing numbers are placed in the expected nested field. The change helps reduce validation issues when exporting Swiss batch payments, though broader country-specific formatting may still need follow-up work.
Original PR description
### Steps to reproduce: - Install 'account_iso20022', 'l10n_ch' and switch to a Swiss company - Have a bank with a BIC number and an account for that bank with a clearing number - Create a vendor…
### Steps to reproduce: - Install 'account_iso20022', 'l10n_ch' and switch to a Swiss company - Have a bank with a BIC number and an account for that bank with a clearing number - Create a vendor bill for a Swiss partner - Pay with "Swiss ISO20022" - Create a batch payment with that payment and validate - In the XML the field `ClrSysMmbId` contains the clearing number, but it should be in a nested field ([src](https://www.mx-message.com/m/pacs-010-001-05/FIDrctDbt/CdtInstr/Cdtr/FinInstnId/ClrSysMmbId)) ### Cause: The code directly inputs the value of `clearing_number` in `ClrSysMmbId`. ### Solution: Add `MmbId` to contain the clearing number. ### Note: The field `MmbId` when alone is supposed to contain the country's payment system prefix and the clearing number. This commit only input the value of the field `clearing_number` in `MmbId`, so it may be invalid, but at least the architecture is valid. See [this link](https://knowledge.xmldation.com/support/iso20022/general_rules/clearing_codes) for the documentation of `ClrSysMmbId`. This [commit](https://github.com/odoo/enterprise/commit/c277ffa81644b79d95e67a70f7170f5f39c30898#diff-568a46f66108a66d58d845c0e1e00b22db21507ac52576f75b83398112ad10f5) implemented the correct way to set up `ClrSysMmbId` for the Swedish localization. To be always valid, we would need to implement this on all localizations. opw-4872507 Forward-Port-Of: odoo/enterprise#94460
Studio exports no longer fail when they include binary fields that are not stored as attachments. This makes data exports more reliable for users working with custom Studio fields.
Original PR description
**Before:** Attempting to export non-attachment binary fields using the `Studio Export` would cause a traceback. **After:** Non-attachment binary fields can now be successfully exported from `Studio` without error. task-4888937 Forward-Port-Of: odoo/enterprise#94230 Forward-Port-Of: odoo/enterprise#93781
This fixes an error that prevented Ecuadorian delivery guides from being generated when barcode scanning was turned off in Inventory settings. Businesses can now create and print these delivery documents reliably regardless of whether they use barcode scanning.
Original PR description
Currently, an error occurs when generating a Delivery Guide if the Barcode Scanner is disabled in the Inventory settings. **Steps to reproduce:** - Install the `l10n_ec_edi_stock` module and switch…
Currently, an error occurs when generating a Delivery Guide if the Barcode Scanner is disabled in the Inventory settings. **Steps to reproduce:** - Install the `l10n_ec_edi_stock` module and switch to the `EC company`. - Uncheck `Barcode Scanner` in the Inventory `settings`. - Create a new warehouse and set the `Entity` and `Emission Point`. - Navigate to Inventory > Operations > Deliveries and create a new delivery. - Add details > mark as Todo > Validate > Generate Delivery Guide. **Error:** `AttributeError: 'stock.move.line' object has no attribute 'qty_done'` **Root Cause:** At [1], the code references `line.qty_done`, but this field is defined in the `stock_barcode` module at [2]. When the Barcode Scanner is `disabled`, the field is not available, leading to the `error`. **Fix:** This commit updates the delivery guide values to use `line.quantity` instead of `line.qty_done` at [1] and at [4]. Since in the `stock_barcode` module at [3], `qty_done` is derived from `quantity`. [1]: https://github.com/odoo/enterprise/blob/ba5b9790f28e2f7eabda22e5992737eab0e82c6e/l10n_ec_edi_stock/models/stock_picking.py#L354 [2]: https://github.com/odoo/enterprise/blob/8c53e50df1cf9dc6d3ca4cae19c39135ac85d4e4/stock_barcode/models/stock_move_line.py#L23 [3]: https://github.com/odoo/enterprise/blob/8c53e50df1cf9dc6d3ca4cae19c39135ac85d4e4/stock_barcode/models/stock_move_line.py#L48-L50 [4]: https://github.com/odoo/enterprise/blob/8b72fdef63f634ccf436b49adbac5c1f9358c127/l10n_ec_edi_stock/views/report_delivery_guide.xml#L165 sentry-6851008674 Forward-Port-Of: odoo/enterprise#93775
The bank reconciliation screen no longer shows an extra line above action buttons. This restores visual clarity and makes the button area easier to read for accounting users.
Original PR description
During this commit: https://github.com/odoo/enterprise/commit/f9725d7b01cbd1235f022821a6861adb2955e49e we added a line above the buttons, but we lost some clarity, so this commit will remove it task-5082695 Forward-Port-Of: odoo/enterprise#94631
The workcenter planning view now shows totals based on the workcenter's defined working hours instead of always showing a full 24-hour day. This gives manufacturing planners a more accurate view of available capacity and helps avoid scheduling confusion.
Original PR description
## **Issue Before This Commit:** In the workcenter planning view, the total hours displayed were misleading, as they always showed 24 hours of the day instead of the workcenter’s defined working…
## **Issue Before This Commit:** In the workcenter planning view, the total hours displayed were misleading, as they always showed 24 hours of the day instead of the workcenter’s defined working hours. This caused confusion for users since the displayed total hours did not match the actual available working time of the workcenter. ## **Steps to Reproduce:** - Create a Manufacturing Order (MO). - Add "Drawer" as the product. - Add a "SEC-ASSEM: [FURN_8855] Drawer" BOM. - Set the quantity to produce as 10. - Confirm the MO and plan it. - Open the planning view and notice that the total hours count incorrectly shows 24 hours instead of the defined working hours. ## **Cause of the issue:** The bug was introduced by this PR (https://github.com/odoo/odoo/pull/205486), as the related changes were not adapted here. Because of that, pill.record.workcenter_id[0] returns an undefined value. ## **With This Commit:** The calculation of total hours has been corrected to consider only the workcenter’s defined working hours. Users now see accurate hours in the planning view, making it easier to plan and schedule work orders reliably. task - 4900885 Forward-Port-Of: odoo/enterprise#93035
This fixes an issue in the manufacturing master production schedule where planning calculations could incorrectly use horizon days. The change helps keep production planning dates and quantities aligned with the intended schedule, reducing confusion for planners.
Original PR description
19.0 post-freeze bug pad
35 changes
Resolved issues and error corrections
This fixes a visual issue in sales orders where option controls could overflow on combo product lines after shortened text. The change keeps the order line layout tidy and prevents distracting or confusing on-screen display issues for users.
Original PR description
In odoo/odoo@520bb2ff8eb165e4a9389db6300192f9b4a05dfd the styling applied on the `.o_list_section_options` was removed for utility classes. However these utilities were not applied on the combos, rendering an overflow after the ellipsis. task-5089909 Issue: <img width="961" height="583" alt="image" src="https://github.com/user-attachments/assets/fe4f7cd9-da3e-4ca5-98f5-0101d3a95012" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update aligns internal developer reference files with recent changes across messaging, HR, live chat, portal, project, and website features. It helps reduce development errors and keeps future maintenance smoother, without changing day-to-day user behavior.
Original PR description
\* = hr, hr_holidays, im_livechat, portal, project, website_livechat, website_slides Many recent changes did not update d.ts files accordingly. https://github.com/odoo/enterprise/pull/94768
This fixes how sales down payment references are validated so they match the invoice's accounting date rather than the sales order creation date. It helps ensure down payment information stays consistent with invoicing records and avoids false test failures.
Original PR description
Because the test was asserting against the Sale Order creation date, while Odoo actually uses the invoice’s accounting date when updating the down-payment line. build_error-231505 Forward-Port-Of: odoo/odoo#224989
Appointment booking notification emails are now limited to the internal followers who need to know a booking was created, rather than also being sent to attendees. This prevents customers or attendees from receiving an internal-style notification and improves the accuracy of appointment communications.
Original PR description
[1] introduces the new paradigm of always sending emails to "relevant recipients" which fetches emails and partners linked to the relevant record to send a message.
In appointment the "Appointment Booked" template is only meant to be sent to followers of `mt{_calendar,_appointment}_event_booked` to inform users that a new appointment was created even if they are not personally assigned to it.
`test_request_meeting_message_for_manual_confirmation` is also updated to represent the case of some visitor creating booking an appointment instead of using internal users for everything to better represent real use cases. Additionally each mail.mail record is extracted and checked individually to make sure we send the right contents to the right recipients.
[1]: 1dd6070ecaab385446cc2df7cad444f046812061
task-5075513
task-4711415
Forward-Port-Of: odoo/enterprise#94456This fixes an internal mismatch in the Knowledge app after recent changes. It helps keep the app's supporting code aligned, reducing the risk of developer-facing errors without changing user workflows.
Original PR description
Recent changes did not update d.ts accordingly. https://github.com/odoo/odoo/pull/227183
Audit returns now correctly flag accounts for follow-up when posted transactions already exist during the audit period. Posting or resetting transactions also marks the affected accounts for review, helping teams avoid missed audit work.
Original PR description
Before when we created an audit return with no previous audits, and moves already posted, nothing would be done. Now, we set to todo the accounts that were involved inside a move during the audit period. We also did the same logic when changes happen to a move. When we post or reset a move, we set to review to the accounts that was involved inside the move.
Delivery operations now show the correct location label, using "From" because goods leave from the dock. This helps users read delivery details more accurately and reduces confusion during warehouse operations.
Original PR description
Deliveries send goods from the dock location. Therefore, If the operation type is a delivery it will show "From" instead of "To". Description of the issue/feature this PR addresses: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an internal test dependency in the online rental shop area so automated checks can run reliably. It helps prevent false build failures and keeps rental-related website changes moving through validation smoothly.
Original PR description
runbot-error-232620
This fix removes a fragile dependency from automated website tour tests, helping prevent avoidable test failures. It improves reliability for quality checks without changing the customer-facing website experience.
Original PR description
runbot-error-232620 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
Fixes an issue where some payment status messages could be handled incorrectly, causing an error instead of showing the expected status. This helps customers complete payment flows more reliably and reduces support interruptions.
Original PR description
Status message in some cases was evaluated as Qweb Template instead of HTML and is_html_empty() doesn't evaluate Qweb. The solution is to only check is_html_empty() when a custom status message is set. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The website payment support widget now only displays card brands and payment options that are actually active and usable. This prevents customers from seeing unavailable options such as Visa or Mastercard when the main card payment method has been disabled.
Original PR description
On the Support Payment Methods widget, we only wanna display the brands where the associated primary method is active, as those are the ones we can actually pay with. When deactivating the Card (primary) payment method, the related brands (Mastercard, VISA, ...) will be removed from display. <img width="555" height="272" alt="image" src="https://github.com/user-attachments/assets/473f816d-d709-4c71-bdc5-9c31789d31bc" /> opw-5083539
Users without administrator rights can now open return checks without encountering an access error. This prevents unnecessary interruptions for accounting staff and makes the return check workflow more reliable.
Original PR description
Before this fix, trying to open a return with a user not having the administration rights caused an access error. This was because the computation of that field tried to access the name of an ir.model record.
Product option previews now display correctly on mobile shop pages using list-based product layouts. The fix also keeps previews aligned when editors resize the page, reducing visual issues before publishing.
Original PR description
Prior to this commit, the attribute previewer was not properly rendered on mobile in the "List thumbnails" and "List grid" product designs. Also, since the attribute previewer was not updated when…
Prior to this commit, the attribute previewer was not properly rendered on mobile in the "List thumbnails" and "List grid" product designs. Also, since the attribute previewer was not updated when resizing the window in edit mode, it caused layout issues. This commit updates the attribute previewer to ensure it renders correctly in all cases. task-5016573 --- ### Update attribute preview in edit mode | | edit mode | normal mode | |--------|--------|--------| | 19.0 | <img width="1065" height="932" alt="Capture d’écran 2025-09-11 à 11 43 47" src="https://github.com/user-attachments/assets/33c3386e-c07b-4b60-bde5-69152c1b91c5" /> | <img width="1065" height="933" alt="Capture d’écran 2025-09-11 à 11 43 57" src="https://github.com/user-attachments/assets/9e046721-7afe-4109-8a2f-6168f5ada89e" /> | | this branch | <img width="1346" height="975" alt="Capture d’écran 2025-09-11 à 14 48 35" src="https://github.com/user-attachments/assets/8166fbad-41ba-4bf1-9aff-78daf532f112" /> | <img width="1355" height="929" alt="Capture d’écran 2025-09-11 à 14 48 54" src="https://github.com/user-attachments/assets/61b3ad5a-bf15-43cf-8ab2-e04886d8b876" /> | ### Attribute preview in mobile | | 19.0 | this branch | |--------|--------|----------| | List thumbnail | <img width="410" height="211" alt="Capture d’écran 2025-09-11 à 14 53 12" src="https://github.com/user-attachments/assets/c7cadadd-87dd-4e33-9d78-39027fd68602" /> | <img width="409" height="200" alt="Capture d’écran 2025-09-11 à 14 53 26" src="https://github.com/user-attachments/assets/9f938485-6421-453d-89fa-61cd0db26e72" /> | | List thumbnail | <img width="818" height="386" alt="image" src="https://github.com/user-attachments/assets/ce87f4a1-9387-4cad-9098-0bb9ca085162" /> | <img width="406" height="178" alt="Capture d’écran 2025-09-11 à 14 54 29" src="https://github.com/user-attachments/assets/08496b4a-14c8-4090-85a5-db09dcf47bf0" /> | | List grid | <img width="405" height="184" alt="Capture d’écran 2025-09-11 à 14 58 53" src="https://github.com/user-attachments/assets/ff10b4ce-8cb1-49c9-823e-34f354a25b81" /> | <img width="404" height="175" alt="Capture d’écran 2025-09-11 à 14 59 37" src="https://github.com/user-attachments/assets/eb01f787-17bd-4c02-b840-09d74b24a274" /> | |List grid | <img width="409" height="159" alt="Capture d’écran 2025-09-11 à 14 59 57" src="https://github.com/user-attachments/assets/c6e73b57-eb02-4450-b52d-872aed179671" /> | <img width="408" height="144" alt="Capture d’écran 2025-09-11 à 15 00 07" src="https://github.com/user-attachments/assets/cce19acc-3d26-4ae4-8945-55025bc64490" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change makes an existing web framework helper available for reuse by other parts of Odoo, such as Studio. It supports more consistent behavior when checking conditions over time without duplicating logic.
Original PR description
Because waitUntil maybe used in its own sake to periodically check a predicate (in studio) and because macro.js is a standard framework tool, we export its waitUntil function Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an unnecessary warning about listening on all network addresses when Odoo's web server is not enabled. It reduces misleading startup messages for administrators while keeping the warning in place when it is relevant.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The purchase catalog's "Add All" action now correctly adds only products matching the user's current suggestion filters, avoiding unintended purchase order lines. The update also tidies the suggestion interface, keeps suggestions prominent, sets them off by default for first-time users, and limits suggestion percentage values to a safe range.
Original PR description
Use correct domain to compute new orderlines upon clicking "Add All" from purchase catalog suggestion feature. REASON: Typo in rush before freeze on which context to use: BEFORE: `domain =…
Use correct domain to compute new orderlines upon clicking "Add All" from purchase catalog suggestion feature.
REASON: Typo in rush before freeze on which context to use:
BEFORE: `domain = fields.Domain.AND([domain, self.env.context.get('domain')])`
AFTER: `domain = fields.Domain.AND([domain, suggest_ctx.get('domain')])`
Separated in 2 commits for review but they can be squashed on merge.
Fixed typo above in first commit (along some other relevant changes)
The second commit is just some unrelated cleaning up, and the following small changes:
- Moves In the order filter out of Good / Service filter group.
- Clamp suggestion percent factor between 0-999 (previously 0-inf)
- Removes the Activate text from the Suggest Toggle and cleans spacing.
- Put suggestion back on top of sections in SearchPanel (It was on top but then a PR for search panel sections inadvertently moved it below sections)
- Change default suggest state to OFF (first time ever, afterwards state is saved/loaded from localStorage).
Original PR: odoo/odoo#218343
Original task: task [#4783508](https://www.odoo.com/odoo/project/966/tasks/4783508)
Bug ticket: task [#5076240](https://www.odoo.com/odoo/project/966/tasks/5076240)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update removes an unnecessary dependency used by Odoo Studio and switches to an existing shared function. It helps keep Studio lighter and avoids loading code that is only needed for guided tours, with no expected change for users.
Original PR description
HootDom is lazy loaded and necessary only in tours. Studio uses the waitUntil function, but it is also findable in macro.js in @web/core
This fix prevents Point of Sale users from seeing an incorrect warning that another user is closing their session. It helps avoid confusion during session closing by ensuring the system checks the session information correctly.
Original PR description
Issue: When closing session on a pos the warning: "The session is being closed by another user. The page will be reloaded." was shown. Fix: The condition in the closingSessionNotification was strictly comparing an int with a string. 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
Fixed Brazilian Avalara tax handling so taxes marked as not accounting-relevant no longer create extra journal lines or inflate invoice totals. The tax values are still recorded in the document chatter for traceability, including related point-of-sale flows.
Original PR description
### Steps to reproduce: - Install l10n_br_edi, switch to Brazilian company - Set up Avalara - Create an invoice with the tax "ICMS Exemption Incl." which is included in price - Click "Generate taxes"…
### Steps to reproduce:
- Install l10n_br_edi, switch to Brazilian company
- Set up Avalara
- Create an invoice with the tax "ICMS Exemption Incl." which is included in price
- Click "Generate taxes" to compute the taxes with Avalara
- In "Journal Items" we can see a line for "ICMS Exemption Incl.", its value appears as excluded
### Cause:
The result from Avalara included a value for this tax:
```
'tax': 1.44,
'taxImpact': {
'accounting': 'none',
'impactOnFinalPrice': 'Included',
'impactOnNetAmount': 'Included',
},
```
But the untaxed amount is computed without this tax. Odoo keeps the untaxed amount from the response and add a line for the tax. As a result, the tax is added to the amounts like an excluded tax would.
### Solution:
In the response from Avalara, taxes with `['taxImpact']['accounting'] == 'none'` should be part of the accounting: no line should be created for this tax. So we filter them out in `_get_external_taxes`.
We also log these taxes in the chatter to keep a trace of them. As the parameter `'accounting': 'none'` is linked with the tax and not the line, if a tax on one line has `'accounting': 'none'` then the same tax will also have 'accounting': 'none' on all other lines. We use this to fetch all non accounting taxes, then we use the summary to construct the message like it was done before.
The logging in the bridge with pos needed to ba adapted because now the taxes may not be unarchived as they are ignored when they have `'accounting': 'none'`.
opw-4964315US check printing now relies on the correct US accounting package instead of the broader US localization package. This helps ensure the feature has the accounting components it needs, reducing setup or installation issues for customers using printed checks.
Original PR description
It should depend on `l10n_us_account`, not just `l10n_us`.
Product snippets on the website now only show a crossed-out original price when a real discount applies. The fix also respects currency rounding, helping avoid misleading discount displays for shoppers.
Original PR description
Commit 43d5226b500d64c3902eb1528e5d8e461766982c removed the condition on when discount should be shown So it was always shown by default. Additionally, we use the currency compare amounts method to make sure rounding values are respected. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The website shop editor now includes the missing Overlay option for the Showcase Product Design. This fixes an editing gap so business users can apply the intended visual styling to product tiles more easily.
Original PR description
This commit adds the missing Overlay option for the Showcase Product Design. task-5090301 <img width="1919" height="779" alt="Capture d’écran 2025-09-15 à 16 03 52" src="https://github.com/user-attachments/assets/badb1525-c9f8-4298-853a-1d89f6f8897c" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Studio exports now handle binary fields that are stored outside attachments without causing an error. This prevents export failures and helps users retrieve their Studio data more reliably.
Original PR description
**Before:** Attempting to export non-attachment binary fields using the `Studio Export` would cause a traceback. **After:** Non-attachment binary fields can now be successfully exported from `Studio` without error. task-4888937 Forward-Port-Of: odoo/enterprise#94230 Forward-Port-Of: odoo/enterprise#93781
Corrects loyalty point calculations after a sales order is confirmed so previously applied reward costs are not deducted a second time. This ensures customers can receive all eligible promotions on an order, avoiding missed discounts and support issues.
Original PR description
## Versions: 16.0+ ## Issue: After confirming a Sales Order (SO), loyalty points are incorrectly calculated when applying additional promotions. This causes only one reward to be applied instead of…
## Versions:
16.0+
## Issue:
After confirming a Sales Order (SO), loyalty points are incorrectly calculated when applying additional promotions. This causes only one reward to be applied instead of all eligible ones.
## Cause:
When the SO is confirmed, the cost in points for each line is retrieved and deducted to compute remaining available points. However, when promotions are re-applied, the system re-evaluates the total cost of the SO and deducts the points again, effectively double-counting the same lines.
## Steps to reproduce:
- Set up a `Discount & Loyalty` promotion program:
- 2 points granted per purchase (minimum $0).
- Rewards:
- 5% discount on "Simple Pen" (costs 1 point).
- 10% discount on "Whiteboard Pen" (costs 1 point).
- Create a Quotation with "Simple Pen" and "Whiteboard Pen".
- Confirm the Quotation into a Sales Order.
- Apply promotions:
- The first reward applies correctly
- The second reward does not apply
opw-4753472
Forward-Port-Of: odoo/odoo#226656
Forward-Port-Of: odoo/odoo#211342DIN5008 report layouts no longer show the customer phone number in the address block, and the customer VAT number is moved out of that address section. This keeps German-style documents cleaner and places tax details in a more appropriate part of the report.
Original PR description
This commit removes the phone number from the DIN5008 report layout. The customer's VAT is also no longer displayed in the customer's address section. The VAT is moved to another section. Description of the issue/feature this PR addresses: Current behavior before PR: The customer's phone number and VAT are displayed in the customer's address in the DIN5008 report layout. Desired behavior after PR is merged: The customer's phone number is no longer displayed and VAT moved to another section in the DIN5008 report layout. opw-5049074 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226967 Forward-Port-Of: odoo/odoo#226630
This fix makes point of sale test scenarios search for a customer before selecting them, ensuring the customer is available in the list. This reduces false test failures and helps keep POS-related quality checks stable without changing everyday user workflows.
Original PR description
### After this commit: - In test cases, before selecting a customer, perform a search to ensure the customer is loaded into the list if it is not already present. Runbot Err: 230518 task: 5068285
This fix prevents security lead times from being counted more than once when one warehouse is supplied by another. It also ensures manufacturing lead times are applied even when a product has no bill of materials, improving delivery and production date accuracy.
Original PR description
In this bug, when there are multiple warehouse, and a warehouse is supplied by another one, the security lead time is repeated in calculations. To reproduce the bug: 1- Create a db with, stock, mrp,…
In this bug, when there are multiple warehouse, and a warehouse is supplied by another one, the security lead time is repeated in calculations. To reproduce the bug: 1- Create a db with, stock, mrp, sale installed. 2- Unarchive `MTO` route. 3- Set `Security Lead` Time in Setting. 4- Create two warehouses wh1, wh2. 5- In wh1, set `Manufacture to Resupply` to True. 6- In wh2, set `Manufacture to Resupply` to False and make it resupply from wh1. 7- Create a product and track inventory. 8- Create a BOM for the product. 9- Enable `Manufacture`, `MTO`, `wh2: Supply Product from wh1` routes for the product. 10- Create a new Quote for the product and in the Delivery, select `wh2` as the warehouse. Confirm the Quote. 11- Open MO. Security lead time is considered twice in dates calculations which is mistake. To solve this issue, we must call `_get_dates_info` only once. The current condition might be True more than once for multiple moves. We should also check that it is not True for next moves which otherwise means the security lead time is already effected. This issue is reproduced because this condition is not sufficient to ensure it is called once: https://github.com/odoo/odoo/blob/c0a7b51c9e14d29cefa96c29dd716b7aec698818/addons/stock/models/stock_move.py#L1656-L1657 The above condition is written to ensure we are adding the delay only when move location is warehouse stock location. This cause problem in multi-warehouse because we have this case that move location is warehouse stock location once for wh1 and once in wh2. To solve this issue, we make sure the call `_get_dates_info` doesn't affect when the move has rules with src location in warehouse stock location. related: #112325 opw-4889642 Forward-Port-Of: odoo/odoo#226712 Forward-Port-Of: odoo/odoo#224232
The accounting KPI summary now includes posted entries that still need an accountant's review, not only draft entries. This gives teams a more accurate view of pending accounting work by journal category, helping prioritize follow-up more reliably.
Original PR description
The `kpi.provider:get_account_kpi_summary` method should count draft moves by category, but also include posted moves that still are to be checked by the accountant. Task-id: 5062431 Forward-Port-Of: odoo/odoo#227091 Forward-Port-Of: odoo/odoo#226411
This fix ensures a setup-related warning only appears when it is relevant to starting the server/database. Business users and administrators will see fewer confusing messages when running unrelated commands, making system maintenance clearer.
Original PR description
The deprecation warning for `--http-interface` not being present in the config file was also shown for commands that don't start the database, while it's something directly related to it.
PDF documents will no longer show very small negative amounts as values like "-0.00" after rounding. This avoids confusing customers or users by displaying these amounts cleanly as "0.00".
Original PR description
Previously, when an amount value that is passed to `value_to_html` is a really small negative number (e.g. -0.000000001), the rounded result will have the negative sign in front of it (e.g. "-0.00").
This commit fixes it so that they will be rendered without the negatives ("0.00").
opw-4685953
Forward-Port-Of: odoo/odoo#224292Fixes an issue where opening the invoice line form view in Studio could trigger an error before a new invoice was saved. This improves reliability for users customizing invoice screens and prevents an unnecessary interruption during setup.
Original PR description
Currently an error occurs when user opens form view for invoice lines using studio. **Steps to replicate:** * Install `accountant` and `web_studio` * Create new invoice but don't save > Open studio…
Currently an error occurs when user opens form view for invoice lines using studio. **Steps to replicate:** * Install `accountant` and `web_studio` * Create new invoice but don't save > Open studio view * Select Invoice Lines > Edit Form View > Error should occur in terminal `ValueError: Expected singleton: account.move()` **Root cause:** * This error occurs because an empty `account.move()` record is passed as `self` to `_prepare_product_base_line_for_taxes_computation` at [1], which expects only a single record. Since the invoice has not yet been created, the recordset is empty. This issue happens only in version `18.4`, not in `18.3` or earlier. The reason is that in `18.4`, compute method [2] is called when opening the form view, whereas in `18.3` it is not. When [2] is called, it sets the `display_type` to `product`, allowing the code to bypass the condition at [3]. In contrast, in `18.3`,since [2] is not called, `display_type` remains `False` despite the code being the same. **Solution:** * To achieve similar behavior as in version `18.3` and skip that line, modify the condition to include a check for `move_id`. [1]: https://github.com/odoo/odoo/blob/0706aaef3894bbee6eea62679a2d89a3ee316f7b/addons/account/models/account_move_line.py#L880 [2]: https://github.com/odoo/odoo/blob/0706aaef3894bbee6eea62679a2d89a3ee316f7b/addons/account/models/account_move_line.py#L485 [3]: https://github.com/odoo/odoo/blob/0706aaef3894bbee6eea62679a2d89a3ee316f7b/addons/account/models/account_move_line.py#L875 **Sentry-6766906181** Forward-Port-Of: odoo/odoo#224397
This fix prevents Google Calendar permission checks from blocking upgrades or mail template updates when appointment video-call links are recalculated. It helps customers avoid unexpected validation errors for read-only guest events and keeps calendar-related migrations running smoothly.
Original PR description
**Steps to Reproduce:** 1. Create DB in 18.0 with calendar module and google_calendar without demo data. 2. create a calendar event with videocall location other then odoo generated and mark that as…
**Steps to Reproduce:**
1. Create DB in 18.0 with calendar module and google_calendar without demo data.
2. create a calendar event with videocall location other then odoo generated and mark that as guest_readonly.
3. after that install appointment module and ``acces_token``.
4. upgrade to 18.3 below mentioned traceback will raise or can update to mail template.
**Issue**
why from 18.3 [from](https://github.com/odoo/odoo/commit/999df6d4a3b5d21648e5e09757661714e99e1154#diff-bd520efea06a5449c8694b54f5f7aa8587c929a5669ea0439bb9d5e38f8d29c8) this commit now template will render on record for checking. During render checking the ``videocall_redirection`` field value as it [compute](https://github.com/odoo/enterprise/blob/f5d99ea7ae7c2748c4a23a793c46ab1a123b3aad/appointment/models/calendar_event.py#L188) and non store field it going for compute over here the access_token is missing so it will go for compute and during that this [validation](https://github.com/odoo/odoo/blob/1ac89eb71aab48fa8d50fbae01d96bec23d88418/addons/google_calendar/models/calendar.py#L106) is triggering and it breaking because env user is odoobot and user_id is different this issue occur during checking on write on mail template.
**Fix:**
For fixing this checking is the fields syncable with calendar or not
```
File "/home/odoo/src/odoo/saas-18.4/odoo/orm/fields.py", line 1751, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/saas-18.4/odoo/orm/fields.py", line 1914, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/saas-18.4/addons/calendar/models/calendar_event.py", line 696, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/saas-18.4/addons/mail/models/mail_thread.py", line 469, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/saas-18.4/odoo/orm/models.py", line 4620, in _compute_field_value
determine(field.compute, self)
File "/home/odoo/src/odoo/saas-18.4/odoo/orm/fields.py", line 81, in determine
return needle(*args)
File "/home/odoo/src/enterprise/saas-18.4/appointment/models/calendar_event.py", line 207, in _compute_videocall_redirection
event.access_token = uuid.uuid4().hex
File "/home/odoo/src/odoo/saas-18.4/odoo/orm/fields.py", line 1847, in __set__
records.write({self.name: write_value})
File "/home/odoo/src/enterprise/saas-18.4/appointment/models/calendar_event.py", line 246, in write
res = super().write(vals)
File "/home/odoo/src/odoo/saas-18.4/addons/google_calendar/models/calendar.py", line 96, in write
self._check_modify_event_permission(values)
File "/home/odoo/src/odoo/saas-18.4/addons/google_calendar/models/calendar.py", line 108, in _check_modify_event_permission
raise ValidationError(_("The following event can only be updated by the organizer "
odoo.exceptions.ValidationError: El organizador es el único que puede actualizar el siguiente evento de acuerdo con los permisos del evento establecidos en Google Calendar.
```
opw-5042454
upg-3113613
TBG - 2082
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#226890The workcenter planning view now shows totals based on the workcenter's actual configured working hours instead of always showing a full 24-hour day. This gives manufacturing users a more accurate view of available capacity and helps them schedule work orders with less confusion.
Original PR description
## **Issue Before This Commit:** In the workcenter planning view, the total hours displayed were misleading, as they always showed 24 hours of the day instead of the workcenter’s defined working…
## **Issue Before This Commit:** In the workcenter planning view, the total hours displayed were misleading, as they always showed 24 hours of the day instead of the workcenter’s defined working hours. This caused confusion for users since the displayed total hours did not match the actual available working time of the workcenter. ## **Steps to Reproduce:** - Create a Manufacturing Order (MO). - Add "Drawer" as the product. - Add a "SEC-ASSEM: [FURN_8855] Drawer" BOM. - Set the quantity to produce as 10. - Confirm the MO and plan it. - Open the planning view and notice that the total hours count incorrectly shows 24 hours instead of the defined working hours. ## **Cause of the issue:** The bug was introduced by this PR (https://github.com/odoo/odoo/pull/205486), as the related changes were not adapted here. Because of that, pill.record.workcenter_id[0] returns an undefined value. ## **With This Commit:** The calculation of total hours has been corrected to consider only the workcenter’s defined working hours. Users now see accurate hours in the planning view, making it easier to plan and schedule work orders reliably. task - 4900885 Forward-Port-Of: odoo/enterprise#93035
Fixes an issue that prevented Ecuadorian delivery guides from being generated when barcode scanning was disabled in Inventory settings. Businesses can now create required delivery documents regardless of whether they use barcode scanning.
Original PR description
Currently, an error occurs when generating a Delivery Guide if the Barcode Scanner is disabled in the Inventory settings. **Steps to reproduce:** - Install the `l10n_ec_edi_stock` module and switch…
Currently, an error occurs when generating a Delivery Guide if the Barcode Scanner is disabled in the Inventory settings. **Steps to reproduce:** - Install the `l10n_ec_edi_stock` module and switch to the `EC company`. - Uncheck `Barcode Scanner` in the Inventory `settings`. - Create a new warehouse and set the `Entity` and `Emission Point`. - Navigate to Inventory > Operations > Deliveries and create a new delivery. - Add details > mark as Todo > Validate > Generate Delivery Guide. **Error:** `AttributeError: 'stock.move.line' object has no attribute 'qty_done'` **Root Cause:** At [1], the code references `line.qty_done`, but this field is defined in the `stock_barcode` module at [2]. When the Barcode Scanner is `disabled`, the field is not available, leading to the `error`. **Fix:** This commit updates the delivery guide values to use `line.quantity` instead of `line.qty_done` at [1] and at [4]. Since in the `stock_barcode` module at [3], `qty_done` is derived from `quantity`. [1]: https://github.com/odoo/enterprise/blob/ba5b9790f28e2f7eabda22e5992737eab0e82c6e/l10n_ec_edi_stock/models/stock_picking.py#L354 [2]: https://github.com/odoo/enterprise/blob/8c53e50df1cf9dc6d3ca4cae19c39135ac85d4e4/stock_barcode/models/stock_move_line.py#L23 [3]: https://github.com/odoo/enterprise/blob/8c53e50df1cf9dc6d3ca4cae19c39135ac85d4e4/stock_barcode/models/stock_move_line.py#L48-L50 [4]: https://github.com/odoo/enterprise/blob/8b72fdef63f634ccf436b49adbac5c1f9358c127/l10n_ec_edi_stock/views/report_delivery_guide.xml#L165 sentry-6851008674 Forward-Port-Of: odoo/enterprise#93775
Manufacturing orders no longer mark components as consumed when users only change inventory lot or location details without changing quantities. This reduces confusion and keeps consumption status aligned with actual material usage.
Original PR description
Issue Before This Commit: ============================ When only the quants/move line were changed without modifying the quantity, the system automatically marked components as consumed (manual…
Issue Before This Commit: ============================ When only the quants/move line were changed without modifying the quantity, the system automatically marked components as consumed (manual consumption and picked boolean were set). This created confusion for the user since no actual consumption took place. Steps to Reproduce: ============================ - Install the `mrp` module. - Create a tracked product (lot/serial) with quants. - Create and confirm an MO having that product as a component. - Change only the quants (e.g., location of the quant, not quantity); notice that manual consumption and picked boolean are set. Cause of the Issue: =========================== This issue occurs when clicking the 'Details' button (`action_show_details` method) on a stock move. That action passes the context `force_manual_consumption`, based on that which directly sets the `manual_consumption` and `picked` booleans in the `write` and `create` methods. [see](https://github.com/odoo/odoo/blob/master/addons/mrp/models/stock_move.py#L276). With This Commit: ============================ Manual consumption and picked boolean are no longer set when only quants (not quantity) are changed. Component consumption is now triggered only if the quantity differs from the demand, ensuring consistency and avoiding confusion for the user. This fix avoids unintended behaviour by ensuring that the picked and manual consumption booleans change only when the quantity differs from the demand. TaskID:- 5062365 Forward-Port-Of: odoo/odoo#225386
3 changes
Resolved issues and error corrections
Receipts will no longer show a misleading QR code when the Spanish TicketBAI submission fails. This avoids giving customers an invalid code and helps keep point-of-sale receipts accurate after reporting errors.
Original PR description
Currently if the TicketBAI upload fails, a QR code is printed with the value `true`. Steps to reproduce ----- 1. Validate a POS order 2. Have a request exception occur during the TicketBAI post 3. Receipt is printed with an incorrect QR code Issue ----- `get_l10n_es_pos_tbai_qrurl()` returns None if the edi document is not accepted. This is then interpreted as `true` by the client and a QR code is printed. Solution ----- Explicitly return an empty string if the edi document is not accepted.
Duplicate record checks now ignore company differences when a database only uses one company. This lets users find and merge records that were previously missed, reducing cleanup gaps and duplicate data.
Original PR description
**Issue** In single company databases, it wasn't possible to find duplicate records with different `company_id` values to merge them (in multi company databases, it is possible to enable the "Cross-Company" option on the deduplication rule). **Change** Always ignore the company field in single company databases. opw-4794408 Forward-Port-Of: odoo/enterprise#93184
Budget report entries are now limited to the companies a user is allowed to access. This prevents users from seeing budget-related records from other companies and avoids access errors when opening report lines.
Original PR description
**Steps to reproduce:** - Install Accounting - In Accounting settings, activate "Budget Management" - Go to "Accounting / Accounting / Analytic Budget" - Create a budget - Open the budget - Create a bill (or invoice depending on the budget type) using the analytic used in the budget lines - Create a budget from another company and also a bill using the analytic used in the budget lines - Connect with a user with Accounting rights who only has access to the first company - Go to "Accounting / Reporting / Management / Budget Report" - Switch to the list view - Remove the "Open Budget" filter **Issue:** The entries linked to the budget from the other company are visible. When trying to open one of them, an access error is raised. **Solution:** Add a multi-company record rule for budget report. opw-4943360
2 changes
Resolved issues and error corrections
Belgian companies are now registered on Peppol using the Enterprise Number required by Belgian authorities. The change also improves lookup checks by trying the alternative Belgian identifier when the first check does not find a match, helping avoid failed or duplicate Peppol registrations.
Original PR description
Belgium Peppol autorities enforces us to register our Belgian Peppol user with EAS 0208, the Enterprise Number (company_registry). Also allows for Belgium to check for 9925 existence on Peppol when 0208 check failed. And vice-versa. task-4852903
Survey invitation emails now correctly refresh their subject line when a different or updated email template is selected. This ensures survey recipients see the intended subject, reducing confusion and helping teams send accurate invitations.
Original PR description
Description of the issue/feature this PR addresses: Fixed [previous commit] where the subject doesn't update when the template was updated. This was due to a filter in place preventing this from happening. Steps to reproduce on runbot: 1. Go to mail templates and search for Survey 2. Open the Survey: Invite template 3. Update the subject on this template 4. Open the Surveys app and select any survey 5. Click on Share and then enable send by email 6. Change the template being used 6. The subject will stay the same [previous commit]: https://github.com/odoo/odoo/commit/16a2c28c9aec307f7ce9dbed0a660b512db31f3a opw-4654411 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr