Daily updates from Odoo
Monday, September 15, 2025
35 changes · saas-18.3
Enhancements to existing features
Point of Sale users can now reopen configurable and combo products from an order line to adjust choices without starting over. Matching edited lines are merged automatically, prices are handled more reliably, and custom text selections are preserved after refreshes.
Original PR description
Task: [#4890396](https://www.odoo.com/odoo/my-tasks/4890396) Community PR: [#221924](https://github.com/odoo/odoo/pull/221924) --- Improves the POS experience by allowing users to reopen and edit…
Task: [#4890396](https://www.odoo.com/odoo/my-tasks/4890396) Community PR: [#221924](https://github.com/odoo/odoo/pull/221924) --- Improves the POS experience by allowing users to reopen and edit configurable and combo products directly from their orderlines. When a product is edited to match another existing line, the lines are automatically merged to avoid duplicates. - Introduced `useTimedPress` to support both click and long press interactions. - Reopening a configurator now pre-fills default attributes, custom values, and combo selections. - Removed click delay when selecting an orderline, improving responsiveness. - Extracted logic for configurator, combo choice, unit price computation, and orderline merging from `addProductToOrder` into dedicated functions (`tryMergeOrderline`, etc.) for reuse across the codebase. --- The Combo/Product Configurator popups no longer receive default values directly. Instead, they now work with the orderline passed as a prop. ** Combo Configurator Popup ** - Use `props.line.selectedComboIds` as the source for default values. - Save the initial `state.combo` so it can be restored on discard. - Add a **Discard** button in the popup footer. ** Product Configurator Popup ** - Use `props.line.selectedAttributes` for the default values. - If there is no orderline like new combo item, fall back to `props.comboItem?.saveStateAttributes`. - Save the initial `state.selectedAttributes` so it can be restored on discard. - Expose `selectedAttributes` on `pos.orderline` as a function so it can be recomputed at any time. ** Bug Fix: Price ** - Fixed a bug where updating a combo item directly from the Order Summary used the wrong price (ignoring the combo). - We now open the **Combo Configurator** instead of the **Product Configurator** when editing a combo item from the Order Summary. --- When refreshing the page, we also lose the `free text` of the `custom_attribute_value`. By adding the model `product.attribute.custom.value` to the `get databaseTable()` from `DataServiceOptions`, we ensure that the records are saved in IndexedDB Forward-Port-Of: odoo/odoo#221924
The Argentina electronic invoicing module now includes renewed demo and test certificates for ARCA's testing services. This prevents test failures caused by expired certificates and keeps the certification environment available for validation work.
Original PR description
Homologation certificates are required to connect Odoo with ARCA's test web services. When they expire, electronic invoicing tests fail, displaying a “Digital certificate expired” warning. In this PR, I'm updating the certificates so we can continue using the testing environment for our tests. Odoo Task 1359 Adhoc Task 57144 Forward-Port-Of: odoo/enterprise#94128
Point of Sale now cleans up internal record links more efficiently during bulk updates. This helps prevent slowdowns when sales sessions involve many related records, improving reliability for busy retail operations.
Original PR description
When the “set” command is used, we will manually clean up the indexes to avoid performance issues when there are too many associated records. Forward-Port-Of: odoo/odoo#226958 Forward-Port-Of: odoo/odoo#225854
Documents and trash views now use the creation date as the default order instead of the last modified date. This keeps document lists more stable because minor updates, such as tag or name changes, will no longer unexpectedly move items around.
Original PR description
As the write_date can be reset by very small changes like adding a tag, updating its name and also during some upgrade, we set the default ordering to create_date. We do similarly for the trash. Task-5025453 Forward-Port-Of: odoo/enterprise#93952 Forward-Port-Of: odoo/enterprise#92840
This update adds automated test coverage for the self-ordering point-of-sale experience, helping catch issues earlier before they affect customers or staff. It also separates printer-related logic to make testing safer and reduce conflicts with the main point-of-sale system.
Original PR description
- Isolated `printer` service into a standalone file to avoid naming conflicts with `point_of_sale` during tests. - Introduced `setupSelfPosEnv` to mock and bootstrap the self-order testing environment. - Add Hoot test coverage for core components, models, and service logic Task-4945633
Improves how draft, cancelled, and posted vendor bills are matched during Indian GST return reconciliation. This reduces missed or incorrect matches, helping businesses reconcile GST-2B data more accurately for the return period.
Original PR description
Before this PR: - `line_ids.tax_ids` filter was applied too early, excluding some valid draft/cancelled bills. - Bill reference and IRN checks were not consistently combined, leading to missed matches in reconciliation. - Posted bills could be incorrectly excluded when the reconciliation status was not considered properly. After this PR: - Refined domain grouping so `line_ids.tax_ids` and GST treatment checks only apply for posted bills. - Draft/cancelled bills are matched if they have a valid IRN or bill reference. - Posted bills require bill reference, tax, reconciliation status, and GST treatment checks for accurate matching. This ensures more reliable matching of draft bills with GST-2 B during the GST return period reconciliation.
Resolved issues and error corrections
This fix prevents appointment-related upgrades or mail template updates from failing when calendar events use custom video call links from Google Calendar. It ensures existing events can be processed safely, reducing upgrade disruption for customers using appointments and calendar integrations.
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 no need to assign standard ``videocall_redirection`` as ``video_location`` is custom
```
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 - 2082Opening and saving the Optimize SEO dialog no longer accidentally clears image descriptions added in the website editor. This protects accessibility and search-related content from being lost when users revisit SEO settings.
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.
This fix updates the sales test to match Odoo’s actual behavior: down-payment lines are based on the invoice accounting date, not the sales order creation date. It helps ensure automated checks correctly reflect how invoice-related dates are handled, reducing false build 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
This fixes a crash when Indonesian invoices with more than one non-luxury tax are used to download an e-Faktur document. Users can now complete the e-Faktur download flow without hitting an unexpected system error in this tax setup.
Original PR description
The system crashes with an error when a user tries to `download the e-Faktur` document. **Steps to produce:-** - Install `Accounting` and switch to `ID Company`(with demo data). - Create a `new…
The system crashes with an error when a user tries to `download the e-Faktur` document.
**Steps to produce:-**
- Install `Accounting` and switch to `ID Company`(with demo data).
- Create a `new invoice` and select customer as `ID Company`.
- Add the product and in `taxes add 11% and 0% (2 non-luxury taxes)` and confirm the invoice.
- Click on gear icon and click on `Download e-Faktur` button.
**Error:-**
`ValueError: ValueError('Expected singleton: account.tax(5, 15)') while
evaluating 'action = records.download_efaktur()'`
**Root cause:-**
- When more than one non-luxury tax is applied and the e-Faktur document is downloading, the code at [1] expects a single tax record, but multiple non-luxury taxes are found.
**Solution:-**
- Since luxury tax is already excluded from the regular tax computation at [2], I think we can directly sum all non-luxury taxes.
[1]: https://github.com/odoo/odoo/blob/52aa6231130ea165fdb44e6370ec3e396b7603cc/addons/l10n_id_efaktur_coretax/models/account_move_line.py#L52
[2]: https://github.com/odoo/odoo/blob/52aa6231130ea165fdb44e6370ec3e396b7603cc/addons/l10n_id_efaktur_coretax/models/account_move_line.py#L24-L25
**sentry-6837559933**
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#224419Refreshing a page in Odoo will now keep users in the correct app menu when several apps share the same underlying customer or partner screen. This prevents confusion where, for example, a Sales customer page could reload under the Invoicing menu instead of Sales.
Original PR description
* STEP TO REPRODUCE: install sale management module, go to sale app -> customer menu -> Then reloading the page using F5 -> the menu is change to invoice which is not correct * Also Multiple modules (Sale, Account, Purchase) share same actions (e.g. partner action) * SOLUTION: Modified webclient.js action-to-menu mapping to handle multiple menus sharing same action Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226391 Forward-Port-Of: odoo/odoo#225984
Reloading shared customer screens now keeps users in the correct app menu instead of switching to another app such as Invoicing. This prevents confusion when Sales, Accounting, and Purchase share the same underlying customer action.
Original PR description
* STEP TO REPRODUCE: install sale management module, go to sale app -> customer menu -> Then reloading the page using F5 -> the menu is change to invoice which is not correct * Also Multiple modules (Sale, Account, Purchase) share same actions (e.g. partner action) * SOLUTION: - Modified webclient.js action-to-menu mapping to handle multiple menus sharing same action Forward-Port-Of: odoo/enterprise#94485
This fix ensures Uruguayan electronic invoices correctly recognize document numbers that start with multiple letters. It helps prevent incorrect processing or validation of affected EDI documents, improving reliability for companies using Uruguay localization.
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
Event invitation emails now use embedded images instead of external icon styling that many email clients do not support. This prevents missing or duplicate location icons in the email editor and helps recipients see the intended event location details clearly.
Original PR description
Font awesome classes must no be inserted into email as external servers do not use them so icons are not displayed and also because some issues occur with the email editor. This commit replaces i tags with font awesome classes in mail by images. Task-5082165 Forward-Port-Of: odoo/odoo#226332
Purchase orders created from the product catalog now keep the same unit of measure shown and selected in the catalog. This prevents accidental ordering of vendor packs when the buyer intended individual units, improving order accuracy and reducing correction work.
Original PR description
Steps to reproduce the bug:
- Create a storable product “P1”:
- UoM: unit
- Purchase tab:
- Vendor: Azure interior
- UoM: Pack of 6
- Create a purchase order:
- Vendor: Azure interior
- Click the Catalog button:
- Select 1 unit of P1 (note: UoM cannot be changed in the catalog)
Problem:
The purchase order line is created, but with 1 pack of 6 instead of 1 unit
Fix:
Ensure the selected product quantity and UoM from the catalog are correctly applied to the PO line.
Opw-4794362
Forward-Port-Of: odoo/odoo#224231Event searches now show consistent results whether users select from the search dropdown or press Enter. Events that match the search term in their description are now included on the results page, reducing confusion and helping visitors find relevant events more reliably.
Original PR description
Purpose ======= Making sure that, when typing a search term, all the results displayed in the search bar dropdown are visible on the page when clicking Enter. Specification ============= Previously, the search bar dropdown was displaying all the events where the name or description matched the search term. However, when clicking Enter, only the events where the name matched were displayed on the page (the ones where only the description matched were ignored). Fixing the issue by considering the description in the event search options. Task-5039221 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224414
The spreadsheet interface is now kept in light mode because dark mode is not supported there. This prevents mixed dark and light styling, making spreadsheets look more consistent and easier to use.
Original PR description
Spreadsheet doesn't support dark theme. This fixes some style where dark and light themes are mixed. Task: 5082593 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226798
This fixes an issue where tapping Send in Odoo's messaging composer on iOS when used as a Progressive Web App could sometimes miss the button. The send area no longer shifts unexpectedly when the keyboard focus changes, making message sending more dependable in Discuss and chatter.
Original PR description
Before this commit, when using IOS PWA, pressing 'Send' button of in composer in discuss or chatter would sometimes not register the send. This happens because in IOS PWA, the composer has a bottom margin as this is close to iOS persistent swipe bar. However, the margin should not be present when there's the soft-keyboard. Because of this dynamic margin based on input focus, when composing textual message and pressing "Send" button, the textarea looses focus and a fraction of second the margin-bottom is increased and moves the "Send" button. This leads to mis-clicking the "Send" button. This commit removes the margin-bottom rule on non-focusin of textarea with iOS PWA. The composer is close to swipe bar so that's not as elegant as before, but at least this doesn't add the problem of non- working "Send" button. opw-5028809 Forward-Port-Of: odoo/odoo#226881 Forward-Port-Of: odoo/odoo#226546
Users can now open assigned activities from "View all activities" even when they do not have permission to access the related record. This prevents an error and still lets them complete the activity using the appropriate activity form.
Original PR description
**Steps to reproduce** 1. Create an activity on a record and assign it to a user who doesn't have access to this record. (e.g. create an activity on a `hr.employee` record and assign to a user without HR rights). 2. With this user lacking access rights, click on "View all activities" in the systray. 3. Click on the activity: error **Cause** The user may not have access rights to the record related to an activity. **Change** Open the activity's form view, we use `mail_activity_view_form_without_record_access` to display the "Mark as done" button. opw-4925744 Forward-Port-Of: odoo/odoo#222649
This fix prevents certain Google Calendar events from blocking upgrades or mail template updates when appointment video call links are checked in the background. It ensures permission validation only applies to fields that actually need Google Calendar synchronization, reducing unexpected errors for users with read-only guest events.
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-prPlanning calendar exports now keep the correct start and end times when a shift has no employee assigned. This prevents users from seeing shifted times in calendar files, especially in databases without demo data or when time zones differ.
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#93692Emails sent after signing multiple documents now include attachments with the correct individual document names. This prevents confusing duplicate filenames and avoids extra “.pdf” extensions such as “abc.pdf.pdf”.
Original PR description
Steps to reproduce: 1. Install Sign. 2. Configure an outgoing email server. 3. Send a sign request for 2 or more documents to the admin (use your own email) 4. Open the email, sign and validate the documents. 5. You will receive an email. **Issue:** - You observe there are attachments in the email with same name and an extra `.pdf` as file extensions (e.g. `abc.pdf.pdf`). **Cause**: https://github.com/odoo/enterprise/blob/a1cd174c65fa181701cc3c5883fb5ab43b2803d8/sign/models/sign_request.py#L588-L594 - The code used `record` instead of the current `document` to determine the attachment name, causing the wrong generated name. **Solution:** - Use the `document` name when generating the attachment filename. opw-4965405
Users editing product properties without a category will now see the intended warning message instead of an empty notification. This improves clarity and avoids confusion when product setup is incomplete.
Original PR description
Versions -------- - saas-18.3+ Steps ----- 1. Create a new product without a category; 2. try to edit properties. Issue ----- An empty notification appears. Cause ----- The `_getPropertyEditWarning` override in `account_asset` introduced by PR odoo/enterprise#87807 doesn't return the value of the `super` call. This was introduced in a forward port as the logic to display the warning was changed in `web` in saas-18.3, and not requiring a return value in previous versions. Solution -------- Return the `super` call. opw-4980006
Changing component lot or location details in a manufacturing order no longer marks the component as consumed unless the quantity actually changes. This prevents misleading consumption status updates and helps users trust manufacturing order information.
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
The Discuss app no longer shows the compact chat hub button when there are no chat hub conversations to display. This removes a redundant control and keeps the messaging interface cleaner and less confusing for users.
Original PR description
Before this commit, chat hub compact was visible in disucss app. This happens because while chat windows and bubbles are conditioned to not be shown in discuss app (with exceptions), the compact mode of chat hub was solely relying on compact mode on/off, ignoring the overall condition for whether some conversations are shown in chat hub (note: conversations in compact are still considered as "shown"). This commit adds extra condition on showing compact button to take into account chat hub showing some conversations. If no conversations are shown, then the compact mode should not be shown at all. Discuss app prevents showing of conversations in chat hub (with exceptions), as this is redundant with discuss app itself. Backport of https://github.com/odoo/odoo/pull/227162
Studio now requires users to choose a related record type when creating AI-powered relationship fields. This prevents crashes caused by saving Many2one or Tags AI fields without the required relation information.
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
Mobile users now see the template name as the main information when choosing a Sign template, instead of the creation date. This makes it easier to identify the right template and keeps the mobile experience aligned with desktop.
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
When users create a new partner during bank reconciliation, the system now chooses the correct receivable or payable action based on the statement amount instead of missing partner history. This prevents the wrong button from appearing and helps accounting teams reconcile transactions more accurately.
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
This fixes an issue where lists meant to have no indentation were still being pushed inward in the website editor. Footer and other unstyled lists will now appear with the intended alignment, improving visual consistency 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
External values used in tax reports can no longer be changed once the relevant tax return lock date is set, helping preserve submitted tax data. The tax closing process now creates default values before locking the period so normal closing still works while preventing later edits.
Original PR description
[FIX] account_reports: external value check lock date This commit add the check that protects external values from being edited out of the lock date. For example when the tax report is submitted, the…
[FIX] account_reports: external value check lock date This commit add the check that protects external values from being edited out of the lock date. For example when the tax report is submitted, the user is not supposed to modify any external values anymore. To do this, we had to modify the tax closing flow a little bit: when closing the tax period, we now generate the default external values before setting the tax lock date. This is because the generation of the default external values was done for the period we were closing, but now that we forbid the creation of an external value after the lock date we had to change the order of the flow. Due to one specific corner case (l10n_fr), we had to keep a hack to bypass the Tax Return Lock Date check. This was done with a context key and will have to be removed in master. The case is the following : when the user generates the tax closing entry, the external values for the period are generated and the Tax Return Lock Date is set with the last day of the month. Then if the user tries to submit the EDI VAT report, it tries to create 2 external values for the carryover but as the lock date was set, it raises an error. task-5012442 Forward-Port-Of: odoo/enterprise#92949
The product image carousel now makes the currently selected thumbnail much easier to identify. This improves the shopping experience by reducing confusion when customers browse products with multiple images.
Original PR description
Steps ----- 1. Have a published product with multiple images; 2. go to its website page; 3. open website editor; 4. set Images Ratio to Wide; 5. enable pop-up on click; 6. save; 7. browse through the images. Issue ----- - While there is a border around the active thumbnail in the bottom row, it is barely visible, making it difficult to see which image is currently being shown. Cause ----- - The border is only 1 pixel wide. Solution -------- - Increase the width of the border to 4 pixels, change the color to `$primary`, and hide the border for inactive images. - Set opacity of thumbnails that aren't selected or hovered over to 0.5. opw-4908881
Fixed an issue where loyalty points could be counted twice after a sales order was confirmed, preventing eligible additional rewards from being applied. Businesses using discount and loyalty programs can now expect all qualifying promotions to work correctly on confirmed orders.
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 reports no longer show the customer phone number in the address block. The customer VAT number is moved out of the address section to keep the report layout cleaner and aligned with the expected format.
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
Odoo Studio exports no longer fail when they include binary file fields that are not stored as attachments. This prevents export errors and helps users retrieve their Studio 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
Users can now add several new tags to a forum post at once without triggering an error. This makes forum posting smoother and prevents failed submissions when tags are entered as a comma-separated list.
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