Thursday, May 28, 2026
22 changes · saas-19.3
Enhancements to existing features
This update introduces a new EC Sales list report specifically for Hungary, providing more detailed sales data. Instead of grouping solely by partner, it now analyzes transactions based on transaction type (B, C, etc.) and transaction state (new or corrected), offering a more granular view of sales activity. This improves reporting accuracy for Hungarian businesses.
Original PR description
This commit implement the EC Sales list for Hungary This report is a bit different from the main EC Sales list, instead of just grouping the lines on partner_id, we need to group on specifics fields on account.move: - l10n_hu_transaction_type: B, C, K, R or V This field represente the type of Intra Community Transaction, it's a selection field with all the legal possible values. We leave the field blank for normal transactions. - l10n_hu_transaction_state: U or T Represent if the transaction is a new one (U) or a correction (T) The grouping of the report works like this: groupby partner_id, l10n_hu_transaction_type, l10n_hu_transaction_state This mean for a single partner, we can have up to 12 different lines. [task-4950959](https://www.odoo.com/odoo/project/967/tasks/4950959) Linked:https://github.com/odoo/enterprise/pull/110448 Forward-Port-Of: odoo/odoo#253556
This update introduces a new report for Hungary, specifically designed to generate the EC Sales list. Unlike the standard report, this version groups data by specific tax codes (B, C, K, R & V) instead of partner ID, ensuring accurate Hungarian tax reporting. It also includes the necessary tax return data for this report.
Original PR description
This report is a bit different from the main EC Sales list, instead of just grouping the lines on partner_id, we need to group on specifics tax.tags [B, C, K, R & V]. It also adds the tax returns for this same report. [task-4950959](https://www.odoo.com/odoo/project/967/tasks/4950959) Linked:https://github.com/odoo/odoo/pull/253556 Forward-Port-Of: odoo/enterprise#110448
Resolved issues and error corrections
This fix resolves an issue where confirming a sales order would only create one lead, even when multiple event registrations were involved. The update now correctly creates multiple leads based on each event registration, ensuring accurate lead tracking for multi-event purchases. This improves the reliability of lead generation within the CRM.
Original PR description
# How to reproduce - Install the Events, Porject & CRM apps - Create two event A & B with tickets that can be purchased - Go to Events > Configuration > Lead Generation - Create a Lead Generation…
# How to reproduce - Install the Events, Porject & CRM apps - Create two event A & B with tickets that can be purchased - Go to Events > Configuration > Lead Generation - Create a Lead Generation Rule with : - Create : Per Order - When : Attendees are created - Event : None - Create a new quotation with two lines : - Product : Even Registration for event A 1st, then B - Confirm the SO # The problem A traceback will appear # Cause of the issue When confirming the SO, we create `event.registrations`s that will check for lead generation rules and create or update `crm.lead`s accordingly : https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/event_crm/models/event_registration.py#L35 We will then group the registrations by leads & grouping model : https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/event_crm/models/event_lead_rule.py#L166 For all groups, if the lead does not exist, we create one : https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/event_crm/models/event_lead_rule.py#L184-L187 `_get_lead_values()` works fine with multiple `event.registrations`s, but crashes when those registrations does not have all the same event, which is our case : https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/event_crm/models/event_registration.py#L170 # Proposed solution Since we have multiple events and leads are associated to a single event : https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/event_crm/models/crm_lead.py#L11 We group the registrations by event and create multiple leads accordingly opw-6167518 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#265017
This update corrects a rounding issue that previously caused the withholding base amount on invoices to exceed the total invoice amount. The fix ensures that withholding calculations are accurate, preventing potential discrepancies in invoice totals. This improves financial reporting and reduces the risk of errors.
Original PR description
**PROBLEM** In some case, because of rounding issues, the withholding base amount can be bigger than the total amount of the invoice, which should not be the case. **STEP TO REPRODUCE** 1. Install…
**PROBLEM** In some case, because of rounding issues, the withholding base amount can be bigger than the total amount of the invoice, which should not be the case. **STEP TO REPRODUCE** 1. Install l10n_pe_edi 2. Create an invoice with those 2 lines: qty: 300, unit_price: 0.481936, tax: VAT 18% + 3% IGV Withholding qty: 300, unit_price: 0.747376, tax: VAT 18% + 3% IGV Withholding 3. Confirm the invoice, and send the xml (if this fail, you may have to change the name of the invoice, using odoo inspector or other means). 4. Open the xml, and notice the base amount for the allowance on the document level is 435.18 which is bigger than the invoice payable amount. **CAUSE** We exclude the withholding taxes to compute the invoice taxInclusiveAmount. When computing this amount, we round the line base and the tax total of the VAT 18% tax leading to the result of 435.17. When creating the allowance node for the Withholding taxes, the base used for the withholding taxes is the sum of the line base, and the tax total of previous tax NOT rounded. There is no easy way to change the withholding tax computation, so we just limit the base to not be bigger than the invoice total when there is rounding issues. opw-6010388 Forward-Port-Of: odoo/enterprise#113689
This update fixes a problem where the IT tax closing process incorrectly rejected valid quarterly VAT reports due to issues with year-end comparisons and incorrect data assumptions. The changes ensure accurate validation by correctly handling period gaps and using debit/credit columns for VAT reporting, preventing errors and improving the reliability of tax closing.
Original PR description
Description of the issue this commit addresses: The IT tax closing validation compared month numbers only, which broke across year boundaries and could reject valid quarterly progressions. It also assumed a balance column existed in monthly VAT report lines, but this report uses debit/credit columns, which could trigger a traceback. --- Desired behavior after this commit is merged: This commit computes the period gap with year-aware month deltas and aligns the allowed gap with periodicity (monthly or quarterly). It also checks VP lines using balance when present, or debit/credit as fallback, preventing crashes and ensuring consistent tax closing validation. --- opw-6131080 Forward-Port-Of: odoo/enterprise#118450 Forward-Port-Of: odoo/enterprise#117428
This update fixes an issue where payments weren't automatically linked to invoices when created after the payment was processed. Previously, invoices created while a payment was being processed would not be correctly associated with the payment, leading to reconciliation problems. This ensures payments are accurately linked to their corresponding invoices.
Original PR description
Steps to reproduce: - Ensure Automatic Invoice setting is on - Create sales order for product with ordered quantites invoicing policy - Generate a Payment Link - Pay with the ACH Direct Debit method via a provider (e.g. Stripe) - While the payment is processing, confirm the sales order, create an invoice, confirm the invoice Current Behavior: When the payment is finished processing, the payment is not automatically linked to the corresponding invoice Expected Behavior: When the payment is finished processing, the payment should be linked to the invoice despite it being created by a user Explanation: The payment transaction's link to invoice_id is severed in PaymentTransaction._invoice_sale_orders if an invoice is created before the payment is cleared. This will eventually lead to the account.payment created automatically later on not being reconciled with the invoice. opw-6087656 Forward-Port-Of: odoo/odoo#264800
This update resolves several issues related to how product attributes are displayed and handled in the Point of Sale (POS) kiosk mode. Specifically, it corrects how custom attributes are presented and ensures the 'Add to Cart' button functions correctly when a product uses a single, custom attribute. This improves the kiosk experience for users.
Original PR description
this pr fixes 3 bug, as all are closely related. Step to reproduce (hide is_custom attr in kiosk mode): - have two attributes A and B - A has only 1 attribute value with is_custom = True - B can have…
this pr fixes 3 bug, as all are closely related. Step to reproduce (hide is_custom attr in kiosk mode): - have two attributes A and B - A has only 1 attribute value with is_custom = True - B can have any two value ( ex. gender: male/female) - use it on a product and make it available in POS for kiosk - start kiosk and open that product Observation: - we do not get option to select option from A but the heading is visible - when we select from B, Add to cart is disabled. Cause: - we do not allow attribute values with is_custom = True in kiosk - but we display the attribute regardless - the Add to cart btn depends on `selectedValues`, which requires value from each attribute, in this case, we are not seletion anything from A - so it is disabled Fix: - we introduced `attributesToDisplay` which will hide heading in case of single custom value for any attribute - for Add to cart, wenow do not expect value from `is_custom` attribute values. Allow product with 1 attr which is `is_custom` to be configurable in configs other than kiosk) correct fix for commit Step to reproduce - have attributes A - A has only 1 attribute value with is_custom = True - use it on a product and make it available in POS - start pos and open that product Observation: - we do not get option to select add text for A Cause: - in pos, we consider product to be configurable only it has more than 1 attributes, which misses is_custom attr Fix: - we backport commit[1] and also considers its side effect by introducing `isProductConfigurable` for pos_self_order, which will still avoid `is_custom` attrs for kiosk [1] https://github.com/odoo/odoo/commit/5155c77a03ed2ff6c914eac41cc81ccb34b1f3c7 Empty page is displayed if product has only `is_custom` attribute value and other attribute with type other then 'no_variant' for combo item Step to reproduce - have attributes A and B - A has only 1 attribute value with is_custom = True - B has two values with type "always" - use it on a product and add that product in combo item and make it available in Kisok - start kiosk and open that combo and select that product Observation: - we do not get option to select Cause: - `availableAttributeValue` only show `no_variant` and non `is_custom` attribute values in attributeSelection component. Fix: - before mounting Attributeselection component, we check if product has required attribute or not. opw-6100965 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266138 Forward-Port-Of: odoo/odoo#257880
This update corrects a technical issue where the FAIA report was incorrectly referencing suppliers without matching entries in the system. This ensures accurate reporting of financial data, specifically for the LU company, and resolves a validation error within the report generation process. The fix ensures data integrity for financial reporting.
Original PR description
## Steps to reproduce: 1. Install `l10n_lu_reports`, swap to the LU company 2. Look at the partner Azure Interior. 1. They have no open balances on `asset_receivable` or `liability_payable` accounts.…
## Steps to reproduce:
1. Install `l10n_lu_reports`, swap to the LU company
2. Look at the partner Azure Interior.
1. They have no open balances on `asset_receivable` or `liability_payable` accounts.
2. Their `supplier_count` is higher than their `customer_count`.
3. Navigate to Accounting > Reporting > General Ledger.
4. Select the 2026 fiscal year.
5. Select gear > FAIA report.
6. Open the downloaded file. Notice:
1. Azure Interior is listed under /MasterFiles/Customers/Customer.
2. There are no /MasterFiles/Suppliers.
3. Azure Interior's ID (14 in this case) is referenced in a /SupplierID section.
7. Take a gander at the official XSD for LU [1]. The SupplierID must match an element in /MasterFiles/Suppliers.
Video: [2]
## Explanation
This is one of several errors found with the FAIA export. See PR #113316 for more.
It's possible to have a /SupplierID listed on a /Transaction/Line element but not have a /Suppliers/Supplier element that it refers to. This is not valid according to the FAIA report's schema [1].
This happens because /Transaction/Line and /MasterFiles use different criteria to determine if a partner is a Customer or a Supplier.
The element /Transaction/Line [3] determines this from the `partner_vals['type']` value [4]. This value is 'customer' or 'supplier' and is determined by comparing the ResPartner fields `customer_rank` and `supplier_rank`. In case of a tie, the partner is assigned as a 'supplier'.
The element /MasterFiles allows a partner to be both a Customer and a Supplier via `partner_vals['types']` [5]. Partners with an open `asset_receivable` balance at the start or end of the reporting period are listed as Customers [6]. Likewise, partners with an open `liability_payable` balance are listed as Suppliers [7]. If there are no open balances, partners are put in the Customer list by default.
The XSD validation error will not show up in a standard Runbot database because the namespace for the XSD is incorrect. If you manually fix the XSD namespace (`xmlns:doc` instead of `xmlns`) and use xmllint to check a generated XML against the XSD, it will raise the following error.
> No match found for key-sequence ['14'] of keyref 'RefGLTransactionLineSupplier'. Downloads/general_ledger (5).xml fails to validate
[1] https://pfi.public.lu/dam-assets/backup/FAIA/FAIA/XSD_Files.zip. I will note that there are three XSDs. Version A has a different namespace and appears to be more restrictive. The "full" XSD document does not raise these errors.
[2] https://drive.google.com/file/d/1xeULpCcGgZk-kYcCjBTKxcfv4ICYRzaB/view?usp=sharing
[3] https://github.com/odoo/enterprise/blob/434d88960abb5e424fdc1106fc93935d328bff78/account_saft/data/saft_report.xml#L244-L248
[4] https://github.com/odoo/enterprise/blob/434d88960abb5e424fdc1106fc93935d328bff78/account_saft/models/account_general_ledger.py#L299
[5] https://github.com/odoo/enterprise/blob/434d88960abb5e424fdc1106fc93935d328bff78/account_saft/models/account_general_ledger.py#L303-L309
[6] https://github.com/odoo/enterprise/blob/434d88960abb5e424fdc1106fc93935d328bff78/account_saft/data/saft_report.xml#L153
[7] https://github.com/odoo/enterprise/blob/434d88960abb5e424fdc1106fc93935d328bff78/account_saft/data/saft_report.xml#L173
opw-6107107
Forward-Port-Of: odoo/enterprise#117799This update ensures that vendor price selections from product.supplierinfo are accurate, regardless of the user's timezone. Previously, the system incorrectly interpreted UTC dates, leading to missed price matches. This fix converts dates to the user's local timezone for precise calculations.
Original PR description
opw-6211908 ## Summary When selecting a vendor price from `product.supplierinfo`, the purchase module converts `purchase.order.date_order` (a `fields.Datetime` stored in UTC) to a `date` using…
opw-6211908 ## Summary When selecting a vendor price from `product.supplierinfo`, the purchase module converts `purchase.order.date_order` (a `fields.Datetime` stored in UTC) to a `date` using Python's `.date()` method. This extracts the **UTC calendar date** rather than the user's local date. For users in positive-offset timezones (e.g. `Pacific/Auckland` UTC+12, `Africa/Johannesburg` UTC+2), this produces the wrong day, causing `product.supplierinfo` records with `date_start`/`date_end` to be incorrectly included or excluded during vendor price selection. ### Affected methods | File | Method | |------|--------| | `addons/purchase/models/purchase_order_line.py` | `_compute_selected_seller_id` | | `addons/purchase/models/purchase_order_line.py` | `_prepare_purchase_order_line` | | `addons/purchase/models/purchase_order.py` | `_get_product_catalog_lines_data` | ### Fix Replace `.date()` calls with `fields.Date.context_today(record, timestamp=...)` which correctly converts the UTC datetime to the user's timezone before extracting the date. Also fixes `fields.Date.today()` → `fields.Date.context_today(self)` in `_prepare_purchase_order_line` for consistency (same issue — `fields.Date.today()` returns UTC date, not the user's local date). ## Steps to reproduce 1. Set user timezone to **Pacific/Auckland** (UTC+12). 2. Create a product with a vendor pricelist (`product.supplierinfo`) entry: - **Vendor**: any partner - **Price**: 50.00 - **Start Date**: 2026-05-13 - **End Date**: 2026-05-31 3. Create a **Purchase Order** for that vendor. 4. Set the **Order Deadline** to **2026-05-13 08:00** NZST (stored as `2026-05-12 20:00 UTC`). 5. Add the product as a line on the PO. **Expected**: The supplier price of 50.00 is selected — the user's local date (May 13) is within the validity window. **Actual**: No supplier price is matched. `.date()` on the UTC datetime returns `2026-05-12`, which is before `date_start` of `2026-05-13`, so the supplierinfo record is skipped. Forward-Port-Of: odoo/odoo#266468 Forward-Port-Of: odoo/odoo#263992
This update optimizes the process of exporting large datasets in Odoo reports. Previously, the system would consume significant memory when exporting many records at once. By batching the export calls and invalidating recordsets, we've reduced memory usage and slightly improved export times, especially for larger datasets.
Original PR description
When exporting a number N of records as XLSX or CSV file, we call the export_data() method for the N records at the same time. This method prefetches the selected fields for all the records which can lead to memory limit errors when N is too large. We propose to batch this call and invalidate the recordsets between batches. Benchmarks ----------- Execution time: | No records | Before PR | After PR | |------------|-----------|----------| | 70 260 | 3.82 s | 3.94 s | | 228 116 | 18.71 s | 19.36 s | | 394 381 | 31.02 s | 32.67 s | Memory usage: | No records | Before PR | After PR | |------------|-----------|----------| | 70 260 | 316.0 MB | 273.5 MB | | 228 116 | 796.9 MB | 620.8 MB | | 394 381 | 1.3 GB | 947.7 MB | opw-5881026 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266078 Forward-Port-Of: odoo/odoo#257333
This update resolves an issue where production orders created with batch sizes on materials didn't correctly update delivery quantities. The fix ensures that all related production orders are linked to the delivery, regardless of the batch size setting, improving the accuracy of inventory tracking during sales order fulfillment. This prevents discrepancies in stock levels.
Original PR description
### Steps to reproduce: - In the settings enable: Multi-steps routes - Inventory > Configuration > Warehouse Management > Routes - Unarchive MTO - Create a storable product P with a bom using the MTO…
### Steps to reproduce: - In the settings enable: Multi-steps routes - Inventory > Configuration > Warehouse Management > Routes - Unarchive MTO - Create a storable product P with a bom using the MTO Route - In the Miscellaneous tab of the bom tick Batch Size and set it to 2 - Create and confirm a sale order for 6 units of P #### > Three MO's are created but only the last one will update the quantities of the delivery at validation of the production. ### Cause of the issue: The `move_dest_ids` of the `move_finished_ids` is only set on the last of the three productions. That is only the last MO is properly chained to the delivery via an MTO chain. This happens because the `move_dest_ids` field of the `mrp.production` model is a `One2Many` field: https://github.com/odoo/odoo/blob/a2f072fe99a03aaf521bba1965e7f29a1c99e325/addons/mrp/models/mrp_production.py#L223-L224 Which implies that each move can be linked to at most one mrp.production via the `created_production_id` field. However, if you have set a batch size on your bom, it is expected for a single move to create multiple mo's. While the `move_dest_ids` of each of these MO is appropriately set in the create vals to be the mto `stock.move` of the delivery, due to the nature of the `created_production_id` field only the *last* mo will created with a set `move_dest_ids` as this is the only record that will be set as `created_production_id`. However, after the creation of these MO's, the related `move_finished_ids` will be recomputed: https://github.com/odoo/odoo/blob/a2f072fe99a03aaf521bba1965e7f29a1c99e325/addons/mrp/models/mrp_production.py#L1089-L1093 However, the `move_dest_ids` of the created moves will be set to be either the `move_dest_ids` of their production (which is unset for all but the last one) or these of the first production of the same `production_group` that is these generated by a common production split: https://github.com/odoo/odoo/blob/a2f072fe99a03aaf521bba1965e7f29a1c99e325/addons/mrp/models/mrp_production.py#L1263-L1267 Now, since neither are set in our use case, the `move_dest_ids` will not be set on the `move_finished_ids` which implies in particular that the mto link between our productions (but the last one) and the delivery is lost. Fix: Since we can not change the nature of the `move_dest_ids` and `created_production_id` in stable to become Many2Many fields, we need to find a way to propagate the `move_dest_ids` on moves without relying on the probably inaccurate value provided by the production. And, since the compute of the `move_finished_ids` could be launched at many other points than during a create process (because of the many dependencies), we can not solely rely on the creation context but rather new to provide a way to recreate the link from relations at any given point. We therefore rely on the `stock.reference`'s similar to what was done prior to 19.0 via the `procurement_group_ids`: https://github.com/odoo/odoo/blob/132f042ca14012877f608783b57a0ca9c4e565f3/addons/mrp/models/mrp_production.py#L1198-L1202 opw-6188069 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266184 Forward-Port-Of: odoo/odoo#264951
This update resolves an issue where UBL imports with taxes set to 'price include' were failing to correctly calculate tax amounts, particularly for invoices with multiple items. The fix ensures accurate tax retrieval and adjustment based on quantity, improving the reliability of UBL import processes. This impacts companies using UBL invoices with price-inclusive taxes.
Original PR description
**PROBLEMS** 1. On a company with taxes with price_include = True, we fail to retrieve a tax when importing a ubl. 2. The price_unit adjustement for when importing price-included taxes doesn't account for quantity. **STEP TO REPRODUCE** 1. Have a setup where the tax are only price_include. 2. Import a ubl, the taxes will not be retrieved. 3. Run odoo only with the fix for problem 1, and import the same ubl with some invoice quantity != 1 4. Notice the price unit are messed up for lines with quantity != 1 (odoo tries to correct the untaxed amount with a line, but this doesn't fixes the tax). opw-6159394 Forward-Port-Of: odoo/odoo#266107 Forward-Port-Of: odoo/odoo#262686
This update addresses a printing problem reported by a client who was unable to print without LNA. The fix involved correcting a missing check within the system, ensuring proper handling of printing requests and preventing errors. This resolves a critical issue impacting order fulfillment.
Original PR description
Based on the ticket below the client is experiencing an issue when printing without LNA. This PR fixes the missing key check opw-https://www.odoo.com/odoo/project/49/tasks/6232008 Forward-Port-Of: odoo/enterprise#118101 Forward-Port-Of: odoo/enterprise#118005
This update enhances the accessibility of carousels on our website, making them easier to navigate using a keyboard. Specifically, it adds visual focus indicators and allows users to control the carousel with 'home' and 'end' keys, improving usability for all visitors.
Original PR description
[FIX] website: improve carousel accessibility To improve keyboard accessibility on carousels, the indicators container is not focusable anymore, and the indicators themselves now only have one…
[FIX] website: improve carousel accessibility
To improve keyboard accessibility on carousels, the indicators container
is not focusable anymore, and the indicators themselves now only have
one focusable button at a time.
The tab order is thus: previous button > active indicator > next button.
(The previous and next button may both appear before.)
You can still navigate among indicators with the left and right arrows,
which also moves the focus to the newly targetted indicator.
Note that other accessibility improvements remain to be done on the
carousels (add a pause/play button on auto-sliding carousels, place the
buttons before the carousel slide in the tab order, add some aria
attributes (roledescription, live), adaptative labels...).
[FIX] website: make focus visible on carousel arrows
When focusing manually (with tab / shift+tab) the previous/next arrows
in carousels, it is hard to follow where the focus is, because there is
no outline and the contrast is too small.
This commit adds a specific outline if the button is `:focus-visible`
(with both black and white to work on any background).
[IMP] website: pause carousel on focus within
Carousels are paused on hover (or touchstart), but if the focus is
inside one, it won't pause. That can make it hard to navigate within
interactive carousels during the sliding interval (e.g. the dynamic
products, which by default has 4 different products with 3 different
focusable links/buttons).
This commit applies the same behavior on focusin as Bootstrap's default
on mouseover, and on focusout as on mouseout.
[IMP] website: support home/end keys on carousels
When the focus is in a carousel, pressing the "home" key displays the
first slide and pressing the "end" key displays the last slide.
task-5470023
Forward-Port-Of: odoo/odoo#266428
Forward-Port-Of: odoo/odoo#244939This update corrects a bug preventing employees administrators from seeing the attendance smart button for other employees. The issue stemmed from how the system determined button visibility based on user group permissions, specifically related to attendance management. The fix ensures the correct groups are recognized to display the button, improving usability for managers.
Original PR description
## Issue When logged in with a user who has the *Employee: Administrator* (`hr.group_hr_manager`) and the *User: Read his own attendances* (`hr_attendance.group_hr_attendance_own_reader`) groups, but…
## Issue
When logged in with a user who has the *Employee: Administrator* (`hr.group_hr_manager`) and the *User: Read his own attendances* (`hr_attendance.group_hr_attendance_own_reader`) groups, but not the *Officer: Manage attendances* (`hr_attendance.group_hr_attendance_officer`) group, the user won't be able to see their own attendance on their own employee's form view.
Additionally, a user without no Employee group but with the *Officer: Manage attendances* group could not see the attendance smart button on other employees form view.
## Steps to reproduce
1. Install *Attendances* (`hr_attendance`)
2. Set Marc Demo's groups:
- *Employees: Administrator*
- *Officer: Manage attendances*: unchecked
- *User: Read his own attendances*: checked (implied by Role / User)
3. Log in as Marc Demo and open his own form in Employees
4. **The attendance smart button is missing, even though Marc Demo has the group to see his own attendance.**
For the second issue:
1. Set Marc Demo's groups:
- *Employees: No*
- *Officer: Manage attendances*: checked
- *User: Read his own attendances*: checked (implied by Role / User)
2. Log in as Marc Demo and open another employee's form
3. **The attendance smart button is missing, even though Marc Demo has
the group to manage other employee's attendance.**
## Cause
There are two employee views defined in `hr_attendance`: `hr_employee_public_view_form` and `view_employee_form_inherit_hr_attendance`. The two views have different conditions under which the attendance smart button is displayed:
- In the public view, which is seen by users who do not have the *Employee: Administrator* group, the button is only displayed if the employee form is the one of the current user.
https://github.com/odoo/odoo/blob/b13d831e4c3c27ec7756302270f78c15f576a296/addons/hr_attendance/views/hr_employee_public_views.xml#L9-L15
https://github.com/odoo/odoo/blob/b13d831e4c3c27ec7756302270f78c15f576a296/addons/hr/models/hr_employee_public.py#L119-L123
**This means that a user without the _Employee: Administrator_ group cannot see the attendance button of other employees, even with the _Officer: Manage attendances_ group.** This view should take into account the *Attendance Manager* group.
- In the other view, which is displayed for users with the *Employee: Administrator* group, the button is only displayed for attendance officers.
https://github.com/odoo/odoo/blob/b13d831e4c3c27ec7756302270f78c15f576a296/addons/hr_attendance/views/hr_employee_view.xml#L24-L29
**This means that if a user is an Employee Administrator, but is not an Attendance Officer, they cannot see their own attendance, even with the "own attendance" group.** This second view should take into account the _User: Read his own attendances_ group.
opw-6167399
Forward-Port-Of: odoo/odoo#263826This update resolves an issue where the 'Info & Tags' button was hidden on the Documents mobile Kanban view. The fix adjusts CSS styling to ensure the chatter section is always visible and accessible, improving the user experience for mobile document management. This prevents users from missing important information.
Original PR description
**Steps to reproduce:** - Go to Documents app in mobile - Go to the kanban view - Add some files and select one - Click on `Info & Tags` button in the control panel - Reload the page - Chatter is not…
**Steps to reproduce:** - Go to Documents app in mobile - Go to the kanban view - Add some files and select one - Click on `Info & Tags` button in the control panel - Reload the page - Chatter is not displayed but the button is still enabled - Switching to the list view properly shows it **Issue:** We have two conflicting css styling on mobile: - `overflow-hidden` was added for mobile to avoid multiple scroll bars - `min-height: 100%` which is due to the default `o_kanban_ungrouped` in the controller css This means that the element is present at the bottom of the page, but we can't get to it manually. When re-enabling the action we are properly moved to the existing chatter (but we can't go back to the top). Also the documents panel should have a single scrollbar to display all the records, but we still need a way to scroll the messages of the chatter. **Fix:** Set `min-height: 0;` for documents kanban to ensure the chatter is still visible and accessible on mobile by default. This makes the chatter take the full available height when displayed. original overflow fix: https://github.com/odoo/enterprise/commit/945b9e2b1c6752bd905695aa40b0babcf38c50cd opw-6061993 Forward-Port-Of: odoo/enterprise#118134 Forward-Port-Of: odoo/enterprise#113168
This update optimizes how the Point of Sale system calculates prices, particularly when dealing with complex product pricing lists. By streamlining the process, the system now responds faster, enhancing the overall user experience. This change improves the efficiency of price calculations within the POS module.
Original PR description
The getPrice function in product_template_accounting.js was a performance bottleneck when using large pricelists. This commit introduces the following optimizations: 1. Pre-index pricelist rules by product_id and product_tmpl_id at load time in ProductPricelist. 2. Replace the sort() operation with a single-pass scan to find the best matching rule (highest min_quantity that satisfies the current quantity). 3. Apply sequential rule precedence (Variant → Template → General), stopping as soon as a valid rule is found. 4. Move rule mappings from uiState to direct properties in ProductPricelist to avoid useless reactivity. 5. Centralize rule selection logic in ProductPricelist for better responsibility separation. task-id: 5965826 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244268
This update fixes an issue where COGS calculations were inaccurate, particularly with multi-stage customer returns. It ensures that quantity conversions are applied correctly and that the 'value' field on stock moves is only set when a move is fully completed, preventing incorrect monetary values from being applied to intermediate return steps. This improves the accuracy of COGS reporting.
Original PR description
[FIX] sale_stock: convert quantity using correct UoM The quantity unit conversion was applied to an already summed value, ignoring the fact that individual COGS lines may have different UoMs. --- [FIX] stock_account: Do not copy field 'value' of StockMove When a customer return is split into multiple steps (e.g., Customer -> Input -> Stock), the `value` field of the stock move was being copied from the first step to the second. This caused the second step (which should not be valued) to inherit the monetary value, leading to incorrect COGS entries when the invoice was posted. The value should only be set when the move is Done, not during a copy. --- OPW-6076350 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260495 Forward-Port-Of: odoo/odoo#257543
This update replaces the older PostgreSQL 12 installer with a newer version (16). This is necessary because PostgreSQL 12 is no longer supported, ensuring continued stability and security for our Odoo SaaS platform. Additionally, the installer now uses a dedicated Odoo user for database connections, improving security.
Original PR description
The Windows installer installs PostgreSQL 12. That version was chosen for its small size, but now in 2026 the size doesn't matter as much anymore. Also, version 12 is no longer supported, so it's time to bump to version 16. While at it, this commit adds an Odoo user for the PostgreSQL connection instead of using the superuser. Forward-Port-Of: odoo/odoo#266059 Forward-Port-Of: odoo/odoo#265134
This update resolves issues preventing IoT drivers from receiving websocket messages due to startup problems. Specifically, it handles scenarios where the device initially lacks an IP or database connection, and ensures the websocket client starts correctly after a successful data transmission attempt. This enhances the stability and reliability of data transfer from IoT devices.
Original PR description
This commit fixes several issues which can cause websocket messages to not be received: 1. If the IoT box does not have an IP when it first starts, the Websocket class will not be started (due to…
This commit fixes several issues which can cause websocket messages to not be received: 1. If the IoT box does not have an IP when it first starts, the Websocket class will not be started (due to `@require_db`). It will remain closed even if the IoT box connects to the network shortly after. 2. If the IoT box does have an IP but can't reach the database when it starts, the Websocket client will crash due to a missing try/except around the request to get a session from the DB. 3. If the IoT box fails the first `send_all_devices` call, the websocket channel will not be set when the Websocket client starts. This causes no messages to be received, since it does not subscribe to the channel. The changes are as follows: 1. The `@require_db` helper is removed from the Websocket client, and instead the server URL is provided explicitly. 2. Any exception raised by the session request is caught and logged, and the websocket can still continue connect attempts. 3. Instead of starting the websocket client after the first call to `send_all_devices`, it is started after the first *successful* call to `send_all_devices` so the channel is guaranteed to be set. 4. The closing status code is now logged as a warning instead of debug. This is to make it easier to troubleshoot websocket disconnections at a glance. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266710
This update corrects a bug that prevented accurate invoice generation for Point of Sale (POS) orders. Previously, the system couldn't properly process lot numbers from POS orders, leading to errors. This fix ensures that POS order lot information is correctly linked to invoices, improving order accuracy and financial reporting.
Original PR description
POS order lines store lot/serial numbers as `pos.pack.operation.lot` records, while the shared invoice lot hooks expect `stock.lot` records. When `sale_stock_product_expiry` extends the invoice lot values, it reads `expiration_date` from the received lot. For invoiced POS orders, this crashes because POS passes a `pos.pack.operation.lot`, which has no such field. Resolve the matching `stock.lot` from the POS lot name, product, and company before extracting extra invoice lot values. opw-6193332 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263495
This update fixes an issue where users weren't notified when expense authorizations were updated or cancelled. Previously, the system ignored events related to authorization changes, preventing users from knowing their expenses were affected. This change ensures users receive timely updates regarding their expense authorizations.
Original PR description
## [FIX] hr_expense_stripe: Fix error messages coherence Fix the incoherent punctuation ## [FIX] hr_expense_stripe: Fix reversed and expired authorizations Before this, when receiving an `issuing_authorization.updated` event, the event would be ignored and the user would never know that the expense had been cancelled opw-6210055 Forward-Port-Of: odoo/enterprise#118574 Forward-Port-Of: odoo/enterprise#117257