Wednesday, November 5, 2025
25 changes · 18.0
Enhancements to existing features
POS categories now send their parent category information when syncing with Atlas. This helps preserve the category structure more accurately across systems, improving consistency for menu and product organization.
Original PR description
In this commit: --- - The parent category of a POS category is now included during synchronization with the Atlas platform. - Added `parent_ref_id` in the category payload to maintain hierarchy. Note: The UrbanPiper platform only supports a single level of sub-categories. task-5169337
Resolved issues and error corrections
This fix prevents an error when sending credit or debit notes to DGI if the original document is not a valid electronic invoice. Instead of failing with a technical traceback, Odoo now shows a clear message so users can correct the source document before retrying.
Original PR description
### Description of the issue/feature this PR addresses: When informing a Credit or Debit Note to DGI we always need to inform the related original document, Before this change is the related document…
### Description of the issue/feature this PR addresses:
When informing a Credit or Debit Note to DGI we always need to inform the related original document, Before this change is the related document is not a real CFE then will raise a traceback error
### Steps to reproduce:
1. Create an e-invoice and confirm in Odoo (without sending to DGI)
2. Create an e-credit note from the e-invoice created in (1) and confirm
3. Try to send the credit note to DGI
The result is a traceback:
```
RPC_ERROR
Odoo Server Error
Occured on 18.core.odoo.localhost on model account.move.send.wizard on 2025-10-21 20:47:48 GMT
Traceback (most recent call last):
File "/home/odoo/custom/odoo/odoo/http.py", line 2144, in _transactioning
return service_model.retrying(func, env=self.env)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/odoo/service/model.py", line 156, in retrying
result = func()
^^^^^^
File "/home/odoo/custom/odoo/odoo/http.py", line 2111, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/odoo/http.py", line 2359, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/odoo/addons/base/models/ir_http.py", line 333, in _dispatch
result = endpoint(**request.params)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/odoo/http.py", line 754, in route_wrapper
result = endpoint(self, *args, **params_ok)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/addons/web/controllers/dataset.py", line 42, in call_button
action = call_kw(request.env[model], method, args, kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/odoo/api.py", line 535, in call_kw
result = getattr(recs, name)(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/addons/account/wizard/account_move_send_wizard.py", line 294, in action_send_and_print
attachments = self._generate_and_send_invoices(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/addons/account/models/account_move_send.py", line 719, in _generate_and_send_invoices
self._generate_invoice_documents(moves_data, allow_fallback_pdf=allow_fallback_pdf)
File "/home/odoo/custom/odoo/addons/account/models/account_move_send.py", line 620, in _generate_invoice_documents
self._call_web_service_before_invoice_pdf_render(invoices_data_web_service)
File "/home/odoo/custom/enterprise/l10n_uy_edi/models/account_move_send.py", line 88, in _call_web_service_before_invoice_pdf_render
invoice._l10n_uy_edi_send()
File "/home/odoo/custom/enterprise/l10n_uy_edi/models/account_move.py", line 813, in _l10n_uy_edi_send
request_data = move._l10n_uy_edi_prepare_req_data()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/enterprise/l10n_uy_edi/models/account_move.py", line 787, in _l10n_uy_edi_prepare_req_data
xml_content = self._l10n_uy_edi_get_xml_content()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/enterprise/l10n_uy_edi/models/account_move.py", line 773, in _l10n_uy_edi_get_xml_content
"referencia_lines": self._l10n_uy_edi_cfe_F_reference(),
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/enterprise/l10n_uy_edi/models/account_move.py", line 381, in _l10n_uy_edi_cfe_F_reference
cfe_serie, cfe_number = self.l10n_uy_edi_document_id._get_doc_parts(related_cfe)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/enterprise/l10n_uy_edi/models/l10n_uy_edi_document.py", line 215, in _get_doc_parts
return re.findall(r"([A-Z]{1,2})[-]*([0-9]{1,8})", record.l10n_latam_document_number)[-1]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^
IndexError: list index out of range
The above server error caused the following client error:
RPC_ERROR: Odoo Server Error
RPC_ERROR
at makeErrorFromResponse (http://18.core.odoo.localhost/web/assets/c15481d/web.assets_web.min.js:3162:163)
at XMLHttpRequest.<anonymous> (http://18.core.odoo.localhost/web/assets/c15481d/web.assets_web.min.js:3167:13)
```
### Desired behavior after PR is merged:
Now we ensure to show a proper message to the user to fix the problem: the original document should be a electronic one
<img width="1203" height="664" alt="after" src="https://github.com/user-attachments/assets/bb7b105e-12f0-4935-b6bc-37edb3bc3aca" />
References LATAM 1301 / ADHOC Task 54770This fix prevents the editor toolbar from switching to the wrong set of buttons when users apply formatting on mobile. As a result, the toolbar stays in its normal state and the active formatting button is highlighted correctly, making mobile editing more reliable.
Original PR description
**Current behavior before PR:** In mobile view, when applying the bold format using the toolbar button, the normal toolbar is incorrectly replaced by image toolbar. This occurs because `getFilteredTargetedNodes` returns an empty array, and as a result, the `isApplied` method evaluates to true since Array.every on an empty array returns true. **Desired behavior after PR:** This PR ensures that the toolbar remains in its normal state when a format is applied via the toolbar button. The corresponding format button (e.g., bold) is correctly highlighted. task-5123317 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents the SEO optimization dialog from crashing when the website preview is still loading, especially on slower connections. It now waits until the page frame is ready, so users can open the dialog more reliably without errors.
Original PR description
Steps to reproduce: - Open Website app and enter edit mode on any page. - Reload the page with a slow connection. - Immediately open "Optimize SEO" from the navbar menu. Before this commit, the dialog accessed the preview document while the iframe was reloading, so reading location.origin raised a TypeError. After this commit, the dialog waits for the iframe to finish loading or returns immediately when it is already complete, preventing crashes. task-5104033
This change corrects how stock balances inventory records when a product is delivered with a lot or serial number. It prevents the system from assigning the adjustment to an empty tracking record, so future receipts with the correct lot are matched properly and stock stays accurate.
Original PR description
Uecase to reproduce: - Create a quant with a product and 10 lot A - Create a delivery order - Open barcode - In barcode, deliver the product with lot C Current behavior: You have 2 quants: - 10 lot A - -1 without lot Expected behavior: - 10 lot A - -1 lot C It happens because the code try to balance negative quant for lot/sn in a stack of quants without lot/sn for the product. However in this case the barcode create a quant without quantity and without lot. In this case the system wants to update it due to an incorrect condition. It's an issue since in later receit with the correct lot. The quant will never be balanced and it will result with - -1 without - 1 lot C 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#231853
This update prevents unexpected stock entries from being created when users view location or inventory reports for subcontracted products. It keeps on-hand quantities accurate, so receipt validation and stock tracking work as expected.
Original PR description
Issue: -------- When working with a subcontracted product, confirming the purchase order and opening the physical inventory or location report creates an unwanted quant for the final product. Later,…
Issue: -------- When working with a subcontracted product, confirming the purchase order and opening the physical inventory or location report creates an unwanted quant for the final product. Later, when validating the receipt picking, an extra quant appears in the subcontracting location with on-hand quantity. Steps to Reproduce: -------------------------- 1. Install `mrp_subcontracting`. 2. Create a lot-tracked subcontracted product and its BoM. 3. Create and confirm a purchase order for the main product. 4. Check the location report → a line with reserved qty is created. 5. Validate the receipt picking. 6. Check the location report again → an extra on-hand qty appears in the subcontracting location. Cause: ----------- When opening the location report, the scheduler (`_quant_tasks`) triggers `_clean_reservations`. In this process, the bypass logic for reservations is not applied in the subcontracting case, leading to the creation of a reserved quant. During picking validation, this quant is included in the `quants_cache` inside `_action_done`. Later, `_synchronize_quant` and `_update_available_quantity` use it, resulting in an extra quant being created in the subcontracting location. Fix: ------ Bypass the creation of reserved quants when opening the location report for subcontracting cases. This prevents unwanted quants and ensures correct on-hand quantities in subcontracting locations. After this Commit: ------------------------- No extra quants will be created in subcontracting locations when viewing location reports. Users will see accurate on-hand and lot quantities, ensuring a smooth and reliable workflow. Task ID: 5115466
Table booking notifications are now sent only for bookings that match the appointment type configured in the POS settings. This prevents irrelevant bookings from appearing on the floor plan and avoids bookings disappearing after a refresh when no matching setup exists. The POS configuration also now clears the appointment type automatically when table booking is turned off.
Original PR description
Task: [#5005216](https://www.odoo.com/odoo/my-tasks/5005216) Enterprise v17.0: [#93714](https://github.com/odoo/enterprise/pull/93714) --- **Before:** If no appointment type is specified in the POS config and a table is booked via the website, the floor plan is notified of a new booking because the resource used is one of the POS config resources. However, if the page is refreshed, the booking disappears since no appointment type is defined in the POS config **After:** The floor plan is notified of a new booking only if the appointment type of the booking matches the one specified in the POS config. If no appointment type is set in the POS config, no booking notifications are sent. Additionally, when the "Table Booking" field is unchecked in the POS config, the appointment type is automatically unset.
Users can now edit analytic distributions for batch payments directly in the bank reconciliation screen without running into validation errors. This makes the reconciliation flow work as expected and avoids blocks when handling batch payments.
Original PR description
**Issue** Users were unable to set analytic distributions on batch payments via the bank reconciliation widget. This limitation could lead to validation errors. **Steps to Reproduce** 1. Create two customer payments 2. Group them into a batch and validate it 3. Open the bank reconciliation widget 4. Create a bank statement line 5. Navigate to the batch payment tab and click on the batch payment 6. Attempt to click on the batch payment line **Root Cause** The method handleLineClicked was overridden in a way that prevented the call to the parent implementation when the flag was 'new_batch', disabling interactivity for these lines. **Fix** The restrictive override of handleLineClicked was removed. All fields in the Manual Operations tab are made read-only, except for analytic distributions, as this is the only field users should be allowed to edit in this context. Opw-4757131
When a lead automatically gets linked to a contact after sending an email, Odoo will now keep any manually entered contact and company names instead of replacing them with partner data. This prevents users from losing information they typed into the lead and keeps the record more accurate.
Original PR description
Description of the issue/feature this PR addresses: When a lead with manually entered contact_name and partner_name fields sends an email through a template, the _message_post_after_hook method…
Description of the issue/feature this PR addresses: When a lead with manually entered contact_name and partner_name fields sends an email through a template, the _message_post_after_hook method automatically assigns a partner_id based on the email address. This triggers the computed fields _compute_contact_name and _compute_partner_name, which overwrite the manually entered values with data from the partner record, causing data loss. Current behavior before PR: 1. User creates a lead with contact_name="person1", partner_name="company1", and email_from="person1@company1.com" 2. User sends an email template from the lead 3. System automatically finds/creates a partner and assigns it to partner_id 4. The _compute_contact_name and _compute_partner_name methods are triggered 5. Bug: Manual values are overwritten with partner data (e.g., contact_name changes from "person1" to "company1" if the partner is a company) Desired behavior after PR is merged: 1. User creates a lead with contact_name="person1", partner_name="company1", and email_from="person1@company1.com" 2. User sends an email template from the lead 3. System automatically finds/creates a partner and assigns it to partner_id 4. The _compute_contact_name and _compute_partner_name methods are triggered 5. Fixed: Manual values are preserved when partner data is empty or missing (e.g., contact_name remains "person1") Video with the problem: https://drive.google.com/file/d/1R0z6Rfni5J9b4iWpUxqKzyOvMIYjjMgA/view --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change corrects how shipping amounts and weights are rounded before being sent to DHL. It prevents shipments from failing validation due to tiny floating-point precision errors, helping ensure DHL deliveries can be processed successfully.
Original PR description
Multiple rounding issues could cause DHL validation errors. Example with product price: - Create a storable product - Create a quotation with quantity 7, price 11.43 - Validate the SO - Go to delivery, use DHL carrier, validate - DHL traceback: 11.429999999999998 not multiple of 0.001 Example with product weight: - Create 3 products, each 0.1 kg - Create a SO with these products - Validate the SO - Go to delivery, use DHL carrier, validate - DHL traceback: 0.30000000000000004 not multiple of 0.001 See official DHL API documentation: https://developer.dhl.com/api-reference/dhl-express-mydhl-api and check the POST /shipments data schema opw-5000193 Forward-Port-Of: odoo/enterprise#96012
This fix ensures subscription invoices keep the correct billed quantity when only part of an invoice is refunded. Previously, a partial credit note could make the system think nothing had been invoiced, which could lead to wrong subscription quantities and billing records.
Original PR description
**Issue** When creating a partial credit note (i.e., for a quantity less than originally invoiced) for a subscription invoice, the `qty_invoiced` on the corresponding subscription order line is…
**Issue** When creating a partial credit note (i.e., for a quantity less than originally invoiced) for a subscription invoice, the `qty_invoiced` on the corresponding subscription order line is incorrectly set to zero, instead of reflecting the remaining quantity. **Steps to Reproduce** 1. Create a subscription with a quantity of 50. 2. Confirm the subscription and generate an invoice. 3. Create a credit note (reversal) for the invoice. 4. Change the credited quantity to 30. 5. Post the credit note. 6. The subscription order line shows qty_invoiced = 0 instead of the expected 20. **Root Cause** The method `_get_max_invoiced_date()` is used to determine the latest invoiced period for a subscription. In its original implementation, it removes refunded periods from the list of invoice dates regardless of whether the refund is partial or full. This causes the system to consider the period as not invoiced at all, which leads to incorrect recomputation of `qty_invoiced` **Fix** Adjust `_get_max_invoiced_date()` to track the net invoiced quantity per period. A period is only removed from the list of invoice dates if it has been fully refunded (i.e., net quantity is zero). This ensures that partially refunded periods are still considered invoiced, and the `qty_invoiced` is correctly updated to reflect the remaining quantity Opw-4908760
Fixed an issue in the Barcode app where available stock was not refreshed after changing the product or source location on a transfer. This ensures users see the correct quants immediately, reducing confusion during warehouse operations.
Original PR description
Issue: In this bug, stock quants are not being updated when product_id or location_id is updated. To reproduce: 1- Create a db with demo database and barcode installed 2- Enable storage locations 3- Open barcode -> operations -> Internal transfers -> New 4- Add a product -> e.g. Drawer which there are quants in demo 5- As you see quants are not shown Cause and Fix: This is a partial backport of: #55917 `_compute_product_stock_quant_ids` should depend on `product_id` and `parent_location_id` to be recomputed when product or source location is updated. opw-5065624 Forward-Port-Of: odoo/enterprise#95906
This update fixes an issue in the yearly calendar where some end dates could disappear from view when the screen was zoomed and the user scrolled to the bottom. The calendar now reacts properly to window size changes, so dates remain visible and easier to read.
Original PR description
Before this commit, when zooming on the screen in the yearly calendar and scrolling down to the bottom, some end dates are not visible. By merging this commit, resolved dates will be visible on screen when scrolling down to the bottom by responding to window size changes in the DOM. task-4809668 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 change stops users from canceling a manufacturing order that has already been completed. Instead of canceling related stock movements by mistake, the system now shows a clear error message so the finished order remains protected.
Original PR description
Steps to reproduce:
- Enable multi-step routes.
- Go to Warehouse:
- Manufacturing Operations - Enable 3 steps.
- Create a storable product P1.
- Create a MO to produce one unit of P1.
- Validate the MO.
- Go to the MO list view.
- Select the MO.
- Try to cancel it.
Issue:
The MO is not canceled, but the picking from production to stock is canceled instead.
A done MO should not be cancelable, a UserError should be raised.
opw-5216220This change fixes an issue where partner details used for Peppol verification could briefly become inconsistent when multiple updates were applied separately. As a result, validations are now more reliable and less likely to fail with mismatched endpoint information.
Original PR description
In some cases, when doing two consequent writes instead of one batch, the ORM will trigger the dependencies needlessly, and it can end up to discrepancies like: EAS=0208, endpoint=BE... which lead to a validation error. opw-5228670 opw-5225590 opw-5228716 opw-5229057 opw-5232276 Forward-Port-Of: odoo/odoo#234290
This fix stops users from canceling a manufacturing order that has already been completed. Instead of canceling a related stock transfer by mistake, the system now shows an error and keeps the completed order unchanged.
Original PR description
Steps to reproduce:
- Enable multi-step routes.
- Go to Warehouse:
- Manufacturing Operations - Enable 3 steps.
- Create a storable product P1.
- Create a MO to produce one unit of P1.
- Validate the MO.
- Go to the MO list view.
- Select the MO.
- Try to cancel it.
Issue:
The MO is not canceled, but the picking from production to stock is canceled instead.
A done MO should not be cancelable, a UserError should be raised.
opw-5216220This change prevents Argentine invoice reports from failing when the Spanish (Argentina) language is not available. The report now checks for that language before using it, so invoices continue to render instead of crashing.
Original PR description
**Description of the issue/feature this PR addresses:** Rendering the Argentine invoice report fails with: UserError: Invalid language code: es_AR when the language 'es_AR' is not active in res.lang. **Current behavior before PR:** The report template (l10n_ar.report_invoice_document) always forces lang='es_AR' when calling amount_to_text, causing a crash if that language is not available. **Desired behavior after PR is merged:** The template now checks dynamically if 'es_AR' exists in res.lang before using it. If not, it safely skips rendering to avoid breaking the report. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects the Australian TPAR report so country names are exported properly and no longer cause line length errors. It also fixes PDF generation for the report, allowing downloads to complete without errors.
Original PR description
Behavior before: Exporting the TPAR report using the TPAR option failed with a line length error because the SQL query returned the full JSON object for country names (e.g., {'en_US': 'Australia'})…
Behavior before:
Exporting the TPAR report using the TPAR option failed with a line length error because the SQL query returned the full JSON object for country names (e.g., {'en_US': 'Australia'}) instead of plain text, resulting in incorrect line lengths. Additionally, PDF export failed with a KeyError for the missing 'level' key, as dynamically generated report lines did not include a level field, which the QWeb template requires.
Behavior after:
SQL query uses the JSONB text extraction operator (->>) to retrieve only the country name string (e.g., 'Australia'), ensuring correct line lengths during export. All dynamic report lines are assigned 'level': 1 so that PDF export works correctly without errors.
Root cause:
Country names are stored as translatable JSONB fields, and the previous query did not extract the localized text, returning the full JSON structure. Dynamic report lines for partners did not include a level key by default, causing the PDF template rendering to fail.
Ticket [link](https://www.odoo.com/odoo/project.task/5148697)
opw-5148697
Forward-Port-Of: odoo/enterprise#97990This change fixes a pricing bug in Point of Sale where extra charges for product options could be counted twice. As a result, configurable products now display and charge the correct total price at checkout.
Original PR description
Before this commit, if a product had dynamic attributes with extra prices, those extra prices were computed twice, resulting in incorrect total prices. opw-5187405 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects how downpayment invoices are prepared for ECPay so the payment data is valid. It prevents negative quantities from being sent and helps ensure invoice values are reported accurately.
Original PR description
When an invoice is created from a sale order with a downpayment, the invoice line for the downpayment typically has a negative quantity and a positive unit price. However, ECPay does not accept negative quantities, and this also leads to incorrect price values being sent in the JSON payload. To address this, when an invoice line has a negative quantity, it is inverted to ensure the data sent to ECPay is valid and consistent. **task**-5211264
This update fixes an issue where changing the delivery information on an invoice could be lost when the invoice was confirmed. It helps ensure the delivery date stays correct in anglo-saxon accounting flows, avoiding unexpected changes in customer and accounting records.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Enable anglo-saxon accounting; 2. have a product category with automated AVCO; 3. assign category to a deliverable product; 4. set product to invoice on…
Versions
--------
- 17.0+
Steps
-----
1. Enable anglo-saxon accounting;
2. have a product category with automated AVCO;
3. assign category to a deliverable product;
4. set product to invoice on delivery;
5. add product to a sales order;
6. confirm order & delivery;
7. create invoice;
8. change the delivery on the invoice;
7. confirm the invoice.
Issue
-----
The delivery date gets reset.
Cause
-----
Commit 818cf04f05767 added `delivery_date` as a permanently protected field when modifying moves or move lines, protecting the records on `write`. With anglo-saxon accounting however, new move lines are created when confirming an invoice, which in turn recalculate the delivery date, as `_get_protected_vals` isn't used for their move on `create`.
Solution
--------
Add `self.env['account.move'].protecting(_get_protected_vals({}, moves))` when creating new lines for a move, to avoid recomputing fields that should always be protected.
opw-4965036
Forward-Port-Of: odoo/odoo#231186The VAT summary report for Argentinian accounting now shows the correct total when an invoice includes a price-included VAT tax alongside multiple IIBB taxes. This prevents the VAT amount from being counted more than once, so the report matches the amounts shown in the accounting form.
Original PR description
**Issue** When using a VAT tax marked as price included, together with multiple IIBB taxes on the same invoice, the VAT summary report displays an incorrect total. Specifically, the VAT amount is…
**Issue** When using a VAT tax marked as price included, together with multiple IIBB taxes on the same invoice, the VAT summary report displays an incorrect total. Specifically, the VAT amount is counted multiple times, once for each IIBB tax, leading to an inflated total. **Steps to Reproduce** 1. Install the Accounting app and the Argentinian localization (l10n_ar) 2. Set the 21% VAT Purchase tax as Included in Price 3. Create a vendor bill applying the 21% VAT tax and at least two IIBB taxes 4. Open the VAT summary report for that bill Expected Behaviour: The total in the VAT summary should match the total shown in the accounting form view, with each tax counted only once. **Root Cause** The VAT summary report in the Argentinian localization relies on an SQL query to aggregate tax information for each `account.move`. The query joins `account_move_line` with `account_tax`, `account_tax_group`, and the many-to-many relation table `account_move_line_account_tax_rel`. Each `account_move_line` related to a VAT tax line (via `tax_line_id`) is joined with the `account_move_line_account_tax_rel` table. If that base line is related to multiple IIBB taxes, the join multiplies the VAT line once per IIBB tax since multiple matching rows exist. **Fix** The solution separates the logic for computing tax lines and base lines into two distinct subqueries. Each is aggregated independently to prevent duplication caused by one-to-many and many-to-many joins. The results are then joined using the unique `account_move_line.id`, ensuring each tax amount is counted exactly once in the final totals. opw-4776861 Forward-Port-Of: odoo/enterprise#96315 Forward-Port-Of: odoo/enterprise#85873
The appointment booking flow no longer uses a hard-coded maximum capacity of 12. Administrators can now set a global limit for the highest resource capacity that can be selected on the website, which makes the system work correctly for larger resources.
Original PR description
**Steps to reproduce:** - Install Appointment and Website apps - Create a resource with capacity above 12 - Create an appointment_type on `Resources` - Check `Manage Capacities` - Set its assignment method to `Select Time then auto-assign` - Go to the website and select the new resource - The maximum capacity you can book in the drop-down list is stuck to 12 **Issue:** Arbitrary maximum value (12) seemed to be used in the appointment website and controllers, for the resource capacity which can be booked by someone. **Fix:** Added `resource_max_capacity_allowed` setting to configure the maximum allowed value globally. related: https://github.com/odoo/enterprise/commit/2e855b910173b56e8501d0ebe9ee6f83ac5845bc related: https://github.com/odoo/enterprise/commit/db36b59c80b45c6df1da3ac9dc876e79121e5e5e opw-5059177
Users can now search for messages and jump directly to them inside mailboxes. This removes a previous limitation that prevented message navigation in certain mailbox views, making it easier to find and review conversations.
Original PR description
Before this commit, we could not jump to messages in mailboxes. This happens because the `useMessageHighlight()` hook prevented jumping to messages in thread that were not their origin thread. This commit fixes the issue by removing this limitation specifically for mailboxes. opw-4948798 opw-5087102
The shared project Kanban view no longer allows users to edit stages, which prevents an error from appearing when they try to browse for more projects. This makes the shared project experience more stable and avoids unexpected interruptions for invited users.
Original PR description
Steps to reproduce: - 1. Install the Project module. 2. Create a new project and share it with a user. 3. Log in as that user. 4. Open the shared project Kanban view and try to edit a stage. 5. Try to search for more projects. Issue: - A traceback occurs when clicking on 'Search More'. Fix: - Prevent stage editing in shared project Kanban view. task-5176630