Daily updates from Odoo
Friday, May 22, 2026
263 changes
16 changes
New functionality added to Odoo
This update includes basic tests for recently added 'all' category and billable type options within the Odoo sale project modules. These tests ensure the system correctly handles these new features, improving the reliability and stability of the sales process. This is a standard improvement to maintain code quality.
Original PR description
This commit's purpose is to add a few basic test case for the all category and billable type that were added recently. task-6147696 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
Resolved issues and error corrections
This update fixes a warning error that appeared during payrun creation when multiple payruns were generated or the payroll schedule was adjusted. The issue stemmed from an error in how the system processed domain settings, which was corrected to prevent the warning. This ensures consistent and reliable payrun processing.
Original PR description
[FIX] hr_payroll: fix payrun warning bug Bug reproduction: When we select Employee Type and all employees and create a payrun. Do this twice at least. Then set your schedule in the dashboard of payroll app. Error will appear. Bug cause: There was ast.literal_eval(action['domain']) part where action refers to action_hr_payslip_run but action['domain'] is False and ast.literal_eval(action['domain']) throws and error Bug solution: I said ast.literal_eval(action['domain'] or '[]'), in case action['domain'] is False, we should return [] domain to prevent throwback. task - 6227118
This update fixes a potential issue where spreadsheet formulas referencing list headers could break due to translation changes. The update ensures list headers remain stable, preventing formula errors and improving the overall reliability of spreadsheet calculations. This change simplifies the spreadsheet behavior and enhances user confidence.
Original PR description
Description: With odoo/odoo#261686, list headers became translatable by default and we only stored explicit labels again when a pivot was created from a list range. This kept pivots stable, but formulas using list headers could still break when labels changed with translations. It also made the behavior harder to understand, as some headers were translated while others became fixed later on. In this commit: - store `string` again for newly inserted and user-edited lists so their headers stay stable - keep `string` optional for existing spreadsheets so they preserve their current behavior - remove the pivot-specific list header conversion logic - validate source dashboards in tests so their list columns keep omitting `string` and fall back to translated field labels Task: 6204484 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where spreadsheet formulas could break due to translation changes in list headers. By ensuring list headers remain stable, the update enhances spreadsheet reliability and simplifies the user experience. It removes complex conversion logic, making the system more predictable and easier to maintain.
Original PR description
With odoo/odoo#261686, list headers became translatable by default and we only stored explicit labels again when a pivot was created from a list range. This kept pivots stable, but formulas using list headers could still break when labels changed with translations. It also made the behavior harder to understand, as some headers were translated while others became fixed later on. In this commit: - store `string` again for newly inserted and user-edited lists so their headers stay stable - keep `string` optional for existing spreadsheets so they preserve their current behavior - remove the pivot-specific list header conversion logic - validate source dashboards in tests so their list columns keep omitting `string` and fall back to translated field labels Task: 6204484
This update resolves an issue where clicking on archived users in the member list caused errors. By preventing clicks on archived users, we've improved the user experience and eliminated these technical problems. This change aligns with how archived users are handled in other parts of the system.
Original PR description
Previously, clicking on an archived user from the channel or group member list triggered a traceback. This PR prevents archived users from being clickable, aligning the behavior with the message model where the popover is not opened for archived users, thus avoiding the traceback. enterprise: https://github.com/odoo/enterprise/pull/117480 task-6179486 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#265544 Forward-Port-Of: odoo/odoo#262247
This update resolves a test failure in the Odoo WhatsApp app's discuss sidebar. The change ensures the test accurately reflects the new system behavior of only considering active users when determining available commands. This improves the reliability of the test and ensures the app functions correctly for users.
Original PR description
This PR updates the discuss sidebar testcase to match the new behavior where only active users are considered when computing main_user_id, reducing the number of available commands and fixing the failing assertion. community: https://github.com/odoo/odoo/pull/262247 task-6179486 Forward-Port-Of: odoo/enterprise#117902 Forward-Port-Of: odoo/enterprise#117480
Internal users could previously not access certain agent tools due to an access error. This update corrects a previous change that removed necessary permissions, ensuring internal users can now properly utilize menu-related agent functionalities. This resolves a critical issue impacting agent performance.
Original PR description
Purpose: -------- Currently an internal user can't use an agent that requires the list of available menus or get the details of any menu: an access error is raised stating that the user can't access ir.actions.client records. The issue for the get_available_menus was introduced by commit 15df7f50f67 in which the sudo was dropped when calling the tool. The sudo has been moved inside it when fetching the actions of the available menus. Task-6240831
This update fixes an issue where receipt QR codes weren't correctly using invoice data. Now, the QR code generated on the receipt will automatically reflect the information from the invoice, ensuring accurate record-keeping and compliance with Saudi regulations. This resolves a previous error during receipt preview in POS.
Original PR description
Description of the issue/feature this PR addresses: in this PR we are computing the qr code on the receipt to be taken from the invoice qr field when the document is sent Current behavior before PR: pr receipt qr codes are always created with the logic used by phase 1 qr codes regardless if the invoice was sent. there was a traceback that also occurs during receipt preview in POS. Desired behavior after PR is merged: after this pr the qr code will reflect the value computed on the invoice if it was set (i.e. sent). task-6217641 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where the receipt preset section incorrectly displayed 'false' when certain information was missing. Now, the preset section is hidden when no identification is provided (Dine In) and missing values in Delivery are handled correctly. Additionally, customer names are now included on the receipt header for retail and Dine In orders.
Original PR description
Before this commit: ==== - When a preset ( Dine In or Delivery) was selected and no time slot was set, the receipt displayed false in the preset section. After this commit: ==== - Hide the preset section when no identification is defined ( Dine In ). - Properly handle missing values in Delivery to avoid displaying false. - Added customer name on receipt header in retail and Dine In. task-6141964
This update corrects an issue where the 'Send to Kitchen' toast message in the restaurant ordering system was displaying incorrect formatting for items in languages other than English. The fix utilizes a language-aware method to properly combine item descriptions, ensuring accurate messaging for all users regardless of their selected language. This improves the clarity and professionalism of the order preparation process.
Original PR description
Steps to reproduce: ------------------- 1. Set the user language to French. 2. Configure a preparation display. 3. In PoS, add 2 products of different categories (e.g. 2 starter and 1 main) 4. Send to kitchen -> Toast shows "2 starter et 1 €, envoyé à la cuisine" instead of "2 starter et 1 main, envoyé à la cuisine". What's happening: ----------------- The summary is built with a regex that uses `$1` to replace the ", <last_item>" with an "and <last_item>", however, this `$1` in languages other than english is being translated, in our case to `1€`, and the regex replacement logic does not work properly anymore. The fix: -------- Use `formatList` to join the items, it uses the user language to apply locale-specific joining rules. opw-6149616 Forward-Port-Of: odoo/odoo#265712
This update corrects a translation issue in the Odoo Gantt view. The button used to toggle display modes was not correctly translated, preventing users from seeing the view in their preferred language. This commit ensures the button title is dynamically translated based on the current display mode setting.
Original PR description
The title of the button allowing to toggle the display mode in the Gantt view was not translated. This commit adds a getter to compute the title based on the current display mode, and uses it in the template. Issue reported by translator. Forward-Port-Of: odoo/enterprise#117807 Forward-Port-Of: odoo/enterprise#117739
This update resolves two issues related to Odoo's eTransport functionality. Previously, errors during transport setup resulted in technical tracebacks. Now, the system will display a clear validation message on the delivery document itself, providing better guidance to users. This improves the user experience and simplifies troubleshooting.
Original PR description
This commit fixes two corner case bugs:
1. Transport on National Territory with a warehouse in another country
- Setup eTransport data in settings
- Create a delivery to a Romanian customer
- in eTransport tab -> choose operation type: Transport on National
Territory
- Go to configuration -> warehouses -> change the address of the
warehouse to an address not in Romania
- send the eTransport
2. Sending to eTransport with invalid tokens
- Setup eTransport data in settings
- Remove a character from one of the tokens
- send a valid Delivery to eTransport
we get a traceback for both cases but we want a validation message on the
created document instead.
task-6217207
Forward-Port-Of: odoo/odoo#264747This update ensures that users are prevented from booking rental services when resources are unavailable during the selected time period. Previously, the system didn't check availability for rentals with the ‘website_sale_renting_stock’ module. This change improves the user experience by preventing incorrect bookings and ensuring accurate resource management.
Original PR description
Before this commit, when the user goes to the webshop to take a rental service with rental service unavailable at a certain period, the system does not block the user when the resource is not available during 2 hours in the period chosen by the user. The reason is because the hours are not checked when website_sale_renting_stock is not installed. This commit moves the code checking the time of the rental period made in website_sale_renting_stock in website_sale_renting to be able to have that verification for rental service used with planning to make sure the system will prevent the user to add the product in his cart when the resource is unavailable. task-5123239 Forward-Port-Of: odoo/enterprise#114285
This update resolves an issue where barcode settings for Manufacturing Orders weren't consistently applied, allowing users to bypass mandatory scan requirements. The fix ensures that barcode configurations, including lot/serial tracking, are correctly utilized when creating Manufacturing Orders through the Barcode app. This improves data accuracy and control over production processes.
Original PR description
Before this commit, the "Allow full order validation" were partially ignored in the Barcode app when used for Manufacturing Orders, and the "Mandatory scan" settings didn't work very well. For…
Before this commit, the "Allow full order validation" were partially ignored in the Barcode app when used for Manufacturing Orders, and the "Mandatory scan" settings didn't work very well. For example, setting the scan of lot/serial as mandatory didn't prevent the user to set automatically a SN on consummed component by generating a lot/serial on the produced product or by clicking on "Produce All" button. This commit adds some conditions to avoid to update barcode lines in case they should depending of the config. This commit also fixes a related issue where the MRP operation type's config wasn't used at all when a MO is created directly from the Barcode app. As the config is get from the MO's picking type and no MO exists when a new one is created from the Barcode app, there is no MO's config returned in the data send by the server. To fix that, the config is now updated clientside when the data are fetched after a save. [Task-5420762](https://www.odoo.com/odoo/project/966/tasks/4655907/project.task/5420762) [opw-5223507](https://www.odoo.com/odoo/project/49/tasks/5223507) Forward-Port-Of: odoo/enterprise#117816 Forward-Port-Of: odoo/enterprise#113318
This update fixes a problem where Point of Sale orders weren't correctly calculating payments and invoices, leading to errors. The fix ensures that order details are properly updated during validation and payment processing, resolving the 'entry not balanced' error when generating invoices. This improves the reliability of the POS system.
Original PR description
### Steps to reproduce: - Download 'Point of Sale' and 'Contacts' app - Create a customer with a pricelist that includes a percentage discount - Create a shop with the following properties: - Default…
### Steps to reproduce:
- Download 'Point of Sale' and 'Contacts' app
- Create a customer with a pricelist that includes a percentage discount
- Create a shop with the following properties:
- Default preset = 'Takeout' with a standard 40hr/week schedule
- Payments = 'Card' and 'Customer Account'
- Pricelists = a 'Default' and the discounted pricelist
- Create a POS order (without choosing a customer)
- Add products to the order, and select 'Customer Account' payment method
- Select the created customer
* Pricelist applies → Order total decreases.
* Payment now exceeds total → Negative change shown.
- Disable 'Invoice' checkbox.
- Click 'Validate' → Show popup 'No cash statement found for this session.'
- Again click 'Customer Account' → Add another payment line (negative).
- Process the order payment
- Close Session
- Try to create an invoice for the order
> Error: Entry not balanced
### Cause of Issue:
When 'Validate' is clicked for the first time and `syncAllOrders()` is called, `serializeForORM()`
clears the `_dirty` state tracking after the serialization. https://github.com/odoo/odoo/blob/418b103dab782d81a33d2a7afd8ec3767d7a82df/addons/point_of_sale/static/src/app/services/pos_store.js#L1501-L1534
When the 'No cash statement found' error occurs, the backend rolls back the changes made to the
order lines.
Then, since the `order.lines` weren't marked as dirty (no changes occured to them) and `payment.ids`
were marked as dirty, when 'Validate' is clicked for the second time, the js side doesn't send the
`order.lines` again, so the backend uses the existing, undiscounted lines.
The mismatch happens because while the product lines are undiscounted, the `payment.ids` are
correct (because a new 'Customer Account' line was added, so `payment.ids` were sent again).
Hence, `amount_total` and `amount_paid` were calculated with discounts applied, while individual
`line.price_unit` values remained at list price, resulting in invoice line amounts not matching
the amount paid and causing "entry not balanced" errors during invoice generation.
### Fix:
Preserved the `_ dirty` state commands, ensuring that when the order is reserialized on retry,
the line data are included in the second `sync_from_ui` payload.
opw-6080597
Forward-Port-Of: odoo/odoo#259636This update resolves an issue where UBL invoices sent via Peppol were failing due to incorrect VAT number formatting for Norwegian suppliers. The fix ensures the VAT number is correctly pre-formatted with 'NO' and 'MVA' when creating the UBL document, allowing invoices to be successfully transmitted.
Original PR description
**Steps to reproduce:** * Install a Norwegian localization (e.g. **l10n_no**). * Set up a company with a valid Norwegian VAT number (e.g. **NO179728982MVA** or just **179728982**). * Create a…
**Steps to reproduce:**
* Install a Norwegian localization (e.g. **l10n_no**).
* Set up a company with a valid Norwegian VAT number (e.g. **NO179728982MVA** or just **179728982**).
* Create a customer invoice and send it via **Peppol** (format: **UBL BIS Billing 3.0.12**).
**Observed behavior:**
* The EDI document creation fails with: "The VAT number of the supplier does not seem to be valid. It should be of the form: NO179728982MVA."
* The error occurs even when the VAT number is correctly formatted.
**Cause:**
* Commit 186ad1db refactored the party node building by removing `_get_party_node()` and replacing it with granular `_ubl_add_party_*_nodes()` methods. The Norwegian VAT normalization block (introduced in task-5448941) that set `supplierCompanyID` on the party node lived inside `_get_party_node()` and was not ported to the new architecture, leaving `supplierCompanyID` never set.
* The NO-R-001 constraint in `_invoice_constraints_peppol_en16931_ubl()` reads the VAT from `party_node.get('supplierCompanyID')`, which now always returns `None`, causing `mva.is_valid(None)` to return `False` and the constraint to always fail.
**Fix:**
* Port the missing normalization logic into `_ubl_add_accounting_supplier_party_tax_scheme_nodes()`: prepend `NO` and append `MVA` to the VAT if not already present, then assign the normalized value to `party_node['supplierCompanyID']` and update `PartyTaxScheme[0]/CompanyID` when a VAT node exists.
* Handle the `NO` case in `_ubl_add_party_legal_entity_nodes()` to write the normalized VAT into `PartyLegalEntity/CompanyID`.
opw-6215400
Forward-Port-Of: odoo/odoo#2646799 changes
New functionality added to Odoo
This update adds a new test to ensure the structure of payment data sent to our payment processor (Odoofin) remains consistent. This helps prevent unexpected changes on their side and ensures that any necessary updates are made in our system as well, strengthening our payment processing reliability.
Original PR description
Add a test asserting the payment payload structure sent to Odoofin. The goal is to safeguard against unintended payload changes that are not handled on Odoofin's side by making such changes explicit during testing, and reminding developers that corresponding updates may also be required there. No task ID Forward-Port-Of: odoo/enterprise#117836 Forward-Port-Of: odoo/enterprise#117260
Resolved issues and error corrections
This update removes a confusing and outdated warning message related to background workers in the Odoo system. The new tab functionality addresses the original concern, making the warning redundant and simplifying the user experience. This change improves clarity and reduces potential user confusion.
Original PR description
Those warning are considered as cumbersome and new tabs will work anyway.
This update resolves an issue where timesheet data wasn't consistently synchronized between Odoo tabs. The fix ensures that changes made in one tab's timesheet are accurately reflected in all other tabs, improving data accuracy and user experience. This was a bug related to how the system saved and retrieved timesheet data across different windows.
Original PR description
This PR reworks the implementation of https://github.com/odoo/enterprise/pull/116007 Task-6180394
This update fixes a technical issue in the Gantt view that prevented users from correctly filtering work orders when using multiple grouping options. The fix ensures consistent data display and prevents errors related to incorrect data interpretation, improving the overall usability of the planning tool.
Original PR description
Before this commit: ------------------------- - When planning work orders in the Gantt view, applying a Group By on Work Center and then adding another grouping (e.g., Manufacturing Order or Status)…
Before this commit: ------------------------- - When planning work orders in the Gantt view, applying a Group By on Work Center and then adding another grouping (e.g., Manufacturing Order or Status) caused a traceback when clicking grouped rows in the panel. Steps to reproduce: ------------------------- 1. Install the `mrp_workorder` module. 2. Create and plan a Manufacturing Order. 3. Open the Planning Gantt view 4. Apply Group By → Work Center. 5. Add another group by (e.g., Manufacturing Order or Status) 6. Click on one of the groups (MO or Status) in the side panel. Cause of the issue: ------------------------- - Rows grouped by Work Center -> Manufacturing Order attempted to access a Work Center record that does not exist, leading to the error: `TypeError: Cannot read properties of undefined (reading 'display_name')` - Rows grouped by Work Center -> Status incorrectly treated the status value as a Work Center ID, leading to the error: `psycopg2.errors.InvalidTextRepresentation: invalid input syntax for type integer` After this commit: ----------------------- - Rows created directly from the Work Center grouping are now correctly linked using their corresponding `workcenterIds` and remain clickable. - Rows created by additional groupings after Work Center (e.g., Manufacturing Order or Status) are no longer clickable. - This ensures a consistent interaction flow in the Gantt view and prevents the previous errors during filtering. Task ID: 6132396
This update fixes an error in how overtime hours are calculated for employees with flexible schedules. Previously, the system incorrectly generated excessive overtime hours. The fix ensures that overtime is accurately calculated based on the employee's actual working hours, addressing a discrepancy in the overtime rule logic.
Original PR description
__ ## Short functional explanation of the error When setting attendances on several consecutive days for a flexible employee, with an overtime ruleset containing a single rule. This rule being based…
__ ## Short functional explanation of the error When setting attendances on several consecutive days for a flexible employee, with an overtime ruleset containing a single rule. This rule being based on week and quantity. When regenerating overtimes for this ruleset, the overtime hours generated isn't correct. ## Reproduction Steps 1. Create an employee. In the Payroll tab, set a start date for their contract. Set Work Entry Source as Attendances. Set their Working Hours as a flexible schedule. Set their weekly hours at 40. 2. Create an Overtime Ruleset. Add a single rule, based on Quantity, if the worked hours on a `Week` differs `from the amount defined on the contract`. Check Pay Extra Hours and leave the Work Entry Type to use as Overtime Hours. 3. Go back to the employee. In Settings, set the Overtime Ruleset field as the new Overtime Ruleset you just created. 4. Create 5 attendances, each from 8 am to 6 pm, from Monday to Friday. 5. Go to the Overtime Ruleset you just created and click on Regenerate Overtimes. 6. Go back to Attendances. Search for your employee, and click on the list view. ### Expected behavior The employee's schedule is 40 hours per week. They worked 50 hours. 10 hours should be considered as Worked Extra Hours. ### Unexpected behavior 18 hours are considered as extra hours. ## Origin of the issue To compute the expected duration of the day, we run: https://github.com/odoo/odoo/blob/7fc5edc29f854d619dbcb5fcc3503fb18ca05335/addons/hr_attendance/models/hr_attendance_overtime_rule.py#L303-L304 where `schedule['work']` will contain intervals on 5 consecutive days, from 8 am to 4 pm. However, the last day of the employee's attendances isn't contained in these intervals. As a result, `period_schedule` will contain 4 days (the common days between the employee's Attendance days and `schedule['work']` ) and thus, `expected_duration` will be set at 36 hours instead of 40. In the case where overtimes are computed based on hours from the contract, for flexible employees, the expected hours are the ones indicated on their schedule. __ opw-6131543 Forward-Port-Of: odoo/odoo#263335
This update corrects an issue where the toast message displayed for restaurant order preparations was incorrectly formatted in French. The original system used a translation-dependent regex that failed when translating currency symbols. The fix now uses a language-aware function to correctly format the list of items in the toast message, ensuring accurate order details are communicated to the kitchen.
Original PR description
Steps to reproduce: ------------------- 1. Set the user language to French. 2. Configure a preparation display. 3. In PoS, add 2 products of different categories (e.g. 2 starter and 1 main) 4. Send to kitchen -> Toast shows "2 starter et 1 €, envoyé à la cuisine" instead of "2 starter et 1 main, envoyé à la cuisine". What's happening: ----------------- The summary is built with a regex that uses `$1` to replace the ", <last_item>" with an "and <last_item>", however, this `$1` in languages other than english is being translated, in our case to `1€`, and the regex replacement logic does not work properly anymore. The fix: -------- Use `formatList` to join the items, it uses the user language to apply locale-specific joining rules. opw-6149616 Forward-Port-Of: odoo/odoo#265712
This update resolves two issues related to sending deliveries via eTransport in Romania. Specifically, it corrects errors caused by incorrect warehouse addresses and invalid eTransport tokens. Now, instead of a technical traceback, users will receive a clear validation message when these problems occur, improving delivery reliability.
Original PR description
This commit fixes two corner case bugs:
1. Transport on National Territory with a warehouse in another country
- Setup eTransport data in settings
- Create a delivery to a Romanian customer
- in eTransport tab -> choose operation type: Transport on National
Territory
- Go to configuration -> warehouses -> change the address of the
warehouse to an address not in Romania
- send the eTransport
2. Sending to eTransport with invalid tokens
- Setup eTransport data in settings
- Remove a character from one of the tokens
- send a valid Delivery to eTransport
we get a traceback for both cases but we want a validation message on the
created document instead.
task-6217207
Forward-Port-Of: odoo/odoo#264747This update fixes an issue where barcode settings for Manufacturing Orders weren't consistently applied, allowing users to bypass mandatory scan requirements. The change ensures that barcode configurations, including lot/serial tracking, are correctly utilized when creating Manufacturing Orders through the Barcode app. This improves data accuracy and traceability in the production process.
Original PR description
Before this commit, the "Allow full order validation" were partially ignored in the Barcode app when used for Manufacturing Orders, and the "Mandatory scan" settings didn't work very well. For…
Before this commit, the "Allow full order validation" were partially ignored in the Barcode app when used for Manufacturing Orders, and the "Mandatory scan" settings didn't work very well. For example, setting the scan of lot/serial as mandatory didn't prevent the user to set automatically a SN on consummed component by generating a lot/serial on the produced product or by clicking on "Produce All" button. This commit adds some conditions to avoid to update barcode lines in case they should depending of the config. This commit also fixes a related issue where the MRP operation type's config wasn't used at all when a MO is created directly from the Barcode app. As the config is get from the MO's picking type and no MO exists when a new one is created from the Barcode app, there is no MO's config returned in the data send by the server. To fix that, the config is now updated clientside when the data are fetched after a save. [Task-5420762](https://www.odoo.com/odoo/project/966/tasks/4655907/project.task/5420762) [opw-5223507](https://www.odoo.com/odoo/project/49/tasks/5223507) Forward-Port-Of: odoo/enterprise#117816 Forward-Port-Of: odoo/enterprise#113318
This update fixes a problem where POS orders weren't correctly calculating payments and invoices, leading to errors. The fix ensures that order details are properly updated during validation and payment processing, resolving the 'entry not balanced' error when generating invoices. This improves the reliability of the Point of Sale system.
Original PR description
### Steps to reproduce: - Download 'Point of Sale' and 'Contacts' app - Create a customer with a pricelist that includes a percentage discount - Create a shop with the following properties: - Default…
### Steps to reproduce:
- Download 'Point of Sale' and 'Contacts' app
- Create a customer with a pricelist that includes a percentage discount
- Create a shop with the following properties:
- Default preset = 'Takeout' with a standard 40hr/week schedule
- Payments = 'Card' and 'Customer Account'
- Pricelists = a 'Default' and the discounted pricelist
- Create a POS order (without choosing a customer)
- Add products to the order, and select 'Customer Account' payment method
- Select the created customer
* Pricelist applies → Order total decreases.
* Payment now exceeds total → Negative change shown.
- Disable 'Invoice' checkbox.
- Click 'Validate' → Show popup 'No cash statement found for this session.'
- Again click 'Customer Account' → Add another payment line (negative).
- Process the order payment
- Close Session
- Try to create an invoice for the order
> Error: Entry not balanced
### Cause of Issue:
When 'Validate' is clicked for the first time and `syncAllOrders()` is called, `serializeForORM()`
clears the `_dirty` state tracking after the serialization. https://github.com/odoo/odoo/blob/418b103dab782d81a33d2a7afd8ec3767d7a82df/addons/point_of_sale/static/src/app/services/pos_store.js#L1501-L1534
When the 'No cash statement found' error occurs, the backend rolls back the changes made to the
order lines.
Then, since the `order.lines` weren't marked as dirty (no changes occured to them) and `payment.ids`
were marked as dirty, when 'Validate' is clicked for the second time, the js side doesn't send the
`order.lines` again, so the backend uses the existing, undiscounted lines.
The mismatch happens because while the product lines are undiscounted, the `payment.ids` are
correct (because a new 'Customer Account' line was added, so `payment.ids` were sent again).
Hence, `amount_total` and `amount_paid` were calculated with discounts applied, while individual
`line.price_unit` values remained at list price, resulting in invoice line amounts not matching
the amount paid and causing "entry not balanced" errors during invoice generation.
### Fix:
Preserved the `_ dirty` state commands, ensuring that when the order is reserialized on retry,
the line data are included in the second `sync_from_ui` payload.
opw-6080597
Forward-Port-Of: odoo/odoo#2596365 changes
Resolved issues and error corrections
This update resolves a problem where custom product attributes weren't correctly displayed in the POS kiosk mode. Specifically, when a product had a single custom attribute, options weren't shown, and the 'Add to Cart' button was disabled. The fix ensures that custom attributes are displayed and functional within the kiosk experience, improving usability.
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.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#265238
Forward-Port-Of: odoo/odoo#257880This update fixes an issue where the 'import emissions' action wasn't appearing in the ESG module's menu. The fix allows the import action to be displayed, even with a restricted 'create' setting in the list view, ensuring users can easily access and utilize the ESG carbon emission reporting feature.
Original PR description
Before this commit, the "import" action of emissions in the ESG module was not visible in the COG menu. It is because the "create" attribute of the list view is disabled, which prevents the menu item from being displayed. With this commit, we override the standard behavior in this particular action, by allowing the import action to show up in the COG menu, even if the "create" attribute is disabled. version-19.1
This update resolves two issues related to the eTransport integration, specifically concerning national territory shipments and invalid delivery tokens. Instead of generating tracebacks, the system now displays a clear validation message on the affected delivery document, improving user experience and troubleshooting.
Original PR description
This commit fixes two corner case bugs:
1. Transport on National Territory with a warehouse in another country
- Setup eTransport data in settings
- Create a delivery to a Romanian customer
- in eTransport tab -> choose operation type: Transport on National
Territory
- Go to configuration -> warehouses -> change the address of the
warehouse to an address not in Romania
- send the eTransport
2. Sending to eTransport with invalid tokens
- Setup eTransport data in settings
- Remove a character from one of the tokens
- send a valid Delivery to eTransport
we get a traceback for both cases but we want a validation message on the
created document instead.
task-6217207
Forward-Port-Of: odoo/odoo#264747A recent update to Odoo's PDF processing caused errors when downloading signed documents. This fix corrects a problem with how PDF compression was handled, specifically related to newer versions of the pypdf library. The change ensures documents are downloaded correctly from the Sign app.
Original PR description
This [related PR] introduced a compression pass after calls to mergePage(). However in newer versions of pypdf (>=3.5.2), compress_content_streams() can only be called on pages of PdfWriter. An error would be raised when called on pages of a PdfReader. Steps to reproduce ----- 1. Run Odoo with pypdf>=3.5.2 2. Sign and download a document in the Sign app 3. Traceback occurs Fix ---- This commit moves the compression to the writer object, after the merged page has been added. Related pr: https://github.com/odoo/odoo/pull/261879 runbot-937761 Forward-Port-Of: odoo/odoo#265945 Forward-Port-Of: odoo/odoo#265304
A recent update to Odoo's document signing process caused errors when downloading signed documents. This fix addresses a compatibility issue with a newer version of the pypdf library, ensuring documents are correctly processed and downloaded. The change ensures smooth operation with the Sign app and related modules.
Original PR description
This [related PR] introduced a compression pass after calls to mergePage(). However in newer versions of pypdf (>=3.5.2), compress_content_streams() can only be called on pages of PdfWriter. An error would be raised when called on pages of a PdfReader. Steps to reproduce ----- 1. Run Odoo with pypdf>=3.5.2 2. Sign and download a document in the Sign app 3. Traceback occurs Fix ---- This commit moves the compression to the writer object, after the merged page has been added. Related pr: https://github.com/odoo/odoo/pull/261879 runbot-937761 Forward-Port-Of: odoo/enterprise#118117 Forward-Port-Of: odoo/enterprise#117756
1 change
Resolved issues and error corrections
This update resolves an issue where constant fields within signing documents would become empty during the signing process, leading to signing failures. The fix ensures that default field values are retained when auto-fields return empty strings, preventing the 'Some required items are not filled' error and improving the reliability of the signing workflow.
Original PR description
Version: - saas-18.4 Steps to reproduce: - Create sign template. - Add a sign item with read only true and linked model and auto_value field set. - Send document for signing. - Try to sign the document. Issue: - Signing fails with "Some required items are not filled". - Constant readonly fields become empty during signing flow. Cause: - In `_populate_constant_items()`, the default field value was always replaced by `_get_auto_field_value()`. - When no reference document was set, `_get_auto_field_value() `returned an empty string. - This caused an empty value to be stored in `sign.request.item.value`. Solution: - Keep the default field value when auto-field resolution returns an empty string. - Only replace the value when a valid auto-field value is found. task-6229776
4 changes
Resolved issues and error corrections
This update resolves two issues related to sending deliveries via eTransport in Romania. Specifically, it corrects errors when transporting goods across national borders and when invalid eTransport tokens are used. Instead of displaying tracebacks, the system now provides clear validation messages within the delivery document.
Original PR description
This commit fixes two corner case bugs:
1. Transport on National Territory with a warehouse in another country
- Setup eTransport data in settings
- Create a delivery to a Romanian customer
- in eTransport tab -> choose operation type: Transport on National
Territory
- Go to configuration -> warehouses -> change the address of the
warehouse to an address not in Romania
- send the eTransport
2. Sending to eTransport with invalid tokens
- Setup eTransport data in settings
- Remove a character from one of the tokens
- send a valid Delivery to eTransport
we get a traceback for both cases but we want a validation message on the
created document instead.
task-6217207
Forward-Port-Of: odoo/odoo#264747This update fixes a visual issue where the background color of selected table cells wasn't accurately displayed in the toolbar. The changes include a new system to calculate and show cell background colors, ensuring consistent and correct color representation when selecting table cells, even when empty cells are involved.
Original PR description
Before this commit: the background color of selected table cells isn't shown in the toolbar. After this commit: we have a background color processor in the table plugin to calculate the background color of selected cells. The color and background color are also properly reset to update the selected color when selecting an empty table cell. table_selectionchange_handlers is created to make sure the selected color is updated after it. task-5976046 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263088 Forward-Port-Of: odoo/odoo#252011
This update fixes a translation issue within the HTML editor's move tooltip functionality. The fix ensures that tooltips are correctly translated for all users, resolving a previous display problem. It also includes a security enhancement to prevent potential cross-site scripting vulnerabilities.
Original PR description
Currently the move tooltip in the HTML editor is not translated because the exporter can't see `_t()` calls in tagged template literal. This commit fixes the issue by moving the call outside of the template literal. Forward-Port-Of: odoo/odoo#265991
This update resolves a bug that prevented users from uploading attachments when accessing certain Odoo web pages. The issue stemmed from how session timeouts were handled, leading to incorrect status codes. Applying this fix ensures consistent attachment upload functionality.
Original PR description
1. Apply the below diff. 2. Login using the same account in two independent tabs (e.g. one regular tab, and a private one). 3. In the first tab, change the account password. 4. In the second tab, go…
1. Apply the below diff.
2. Login using the same account in two independent tabs (e.g. one regular tab, and a private one).
3. In the first tab, change the account password.
4. In the second tab, go to `/web/binary/upload_attachment` (any `type='http', auth='user'` controller would do) => 500 error.
> AttributeError: 'HttpDispatcher' object has no attribute 'env'
```
diff --git a/odoo/http.py b/odoo/http.py
index b0fd6197aea8..1ea817ec85cd 100644
--- a/odoo/http.py
+++ b/odoo/http.py
@@ -2309,7 +2309,7 @@ class HttpDispatcher(Dispatcher):
"""
if isinstance(exc, SessionExpiredException):
session = self.request.session
- was_connected = session.uid is not None
+ was_connected = True
session.logout(keep_db=True)
response = self.request.redirect_query('/web/login', {'redirect': self.request.httprequest.full_path})
if was_connected:
```
It is necessary to apply the diff because most places that raise `SessionExpiredException` also pro-actively `logout()`, i.e. they reset `session.uid` and when the exception reaches handle-error `was_connected` is always `False`. For the bug to occur, we need a way to be in the `was_connected == True` case but we found no way in standard Odoo (this also explains how this bug is still present, 2 years later). The diff is the easiest way we found to reproduce it.
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#2659522 changes
Enhancements to existing features
This pull request updates the labels used in the VoIP activity scheduling form within the Enterprise module. The change clarifies the terminology used for scheduling VoIP calls, enhancing usability and reducing potential confusion for users. This is an internal improvement to the user interface.
Original PR description
Task-[6240796](https://www.odoo.com/odoo/project.task/6240796)
Resolved issues and error corrections
This update simplifies how text is clipped in website content, primarily within the website_appointment and related modules. The change replaces older, browser-specific code with a more flexible and maintainable approach using a standard CSS class and variable. This ensures consistent text clipping across different browsers and allows for easier customization of the number of lines displayed.
Original PR description
*: website_helpdesk, website_helpdesk_forum, website_helpdesk_slides - requires https://github.com/odoo/odoo/pull/248061 --------------- This commit clears up the `-webkit-line-clamp` handled in CSS and replace them with the `.o_line_clamp` CSS class. To clamp a certain amount of line, you can now apply the `.o_line_clamp` class to your element, and assign a value to the `--lines-clamp` CSS variable, which will be used to clamp that number of line. If you don't define this variable on your element, the default value will be used, which is `2`. Example with the new method using the class: OLD WAY: ```CSS overflow: hidden; text-overflow: ellipsis; display: -webkit-box; -webkit-line-clamp: 3; -webkit-box-orient: vertical; ``` NOW: ```XML <!-- If you don't define `--lines-clamp` it'll clamp `2` lines by default !--> <myElement class="o_line_clamp" style="--lines-clamp: 3;"/> ``` task-5905780
15 changes
Enhancements to existing features
This update improves the accuracy of Indian Profit & Loss reports by incorporating 'Other Expenses' into the calculations. This ensures the net profit figure reflects all overhead costs, aligning with standard accounting rules and providing a more complete financial picture.
Original PR description
Update the Indian P&L report structure to capture accounts categorised under 'Other Expenses'. This ensures that the net profit calculation accounts for all overheads, aligning with standard accounting practices. task-6166626
Resolved issues and error corrections
This update resolves an issue where the VIES validation process incorrectly flagged invoices without VAT as problematic during tax return creation. The fix ensures VIES validation only applies to tax returns where a fiscal position with VAT requirements is present, improving accuracy and preventing unnecessary errors. This ensures proper compliance with VAT regulations.
Original PR description
Vies validation should only occurs with moves having fiscal position with vat required Steps: - With base_vat, and european l10n like BE installed - Make a bill for a partner with no vat or invalid vat - Create a tax return - Open the return -> the 'check_partner_vies' fails opw-6200246
This update resolves an issue where generating a lot in a manufacturing order would reset the intended production quantity back to zero. The fix ensures the quantity is saved before lot generation, preventing this unexpected reset and maintaining accurate production tracking. This improves the reliability of the manufacturing process.
Original PR description
Step to reproduce: - Create a MO with a lot tracked product (enable it in settings) and a work center - Put the quantity to produce to more than 1 - Confirm the MO - Use the smart button to go to the Shop floor - Click on the three dots and click on "Register production / serial" - Put the quantity to produce to 1 and click on "Generate lot" - The quantity to produce is updated to 0, which is not correct, it should stay to 1 Cause: The quantity to produce was not saved before generating the lot, so after the reload triggered by the generation of the lot, the quantity to produce was reset to the last saved value, which is 0. Task-6158833
This update fixes an issue where the Point of Sale system incorrectly applied AvaTax fiscal positions to customers even when AvaTax wasn't activated in the POS. The change ensures that if a customer doesn't have a configured fiscal position, the system correctly defaults to AvaTax, preventing incorrect tax calculations. This improves the accuracy and reliability of POS transactions.
Original PR description
**Steps to reproduce:** - Install Accounting and Point of Sale - In Accounting settings, activate "AvaTax" - Configure the AvaTax fiscal position and activate "Detect Automatically" option - Make…
**Steps to reproduce:** - Install Accounting and Point of Sale - In Accounting settings, activate "AvaTax" - Configure the AvaTax fiscal position and activate "Detect Automatically" option - Make sure that the other fiscal positions don't have that option set or that they are ordered after the AvaTax one - Go to the settings of a point of Sale - Activate "Flexible Taxes" and configure "Default" and "Allowed" - Make sure that AvaTax fiscal position is not allowed - Do not activate "AvaTax PoS Integration" - Open a POS session - Select a customer with an address in the US and without fiscal position - Check the fiscal position **Issue:** The selected fiscal position is the AvaTax one even though AvaTax is not activated in the POS. **Cause:** We force the use of a fiscal position if it is configured on a customer. In this case, as no fiscal position is configured on the customer, we try to retrieve one that matches the condition and the AvaTax one is selected. **Solution:** When searching for the fiscal position of a customer, if AvaTax is not configured in the POS and if its fiscal positions are not allowed in POS, we ignore the fiscal positions using AvaTax. opw-6154089 Forward-Port-Of: odoo/enterprise#116626
This update fixes an issue where users couldn't undo the insertion of a prompt banner. The fix ensures that undo functionality correctly removes prompt banners, improving user experience and data consistency. It addresses a bug preventing proper history management within the AI editor.
Original PR description
Problem: After inserting a prompt banner, undo does not remove it. Cause: History commands were ignored when the selection was inside the prompt banner, preventing undo from handling banner insertion. Solution: Handle history commands even when the selection is inside the prompt banner. Steps to reproduce: - Insert a prompt banner using `/prompt` + Enter. - Press Ctrl + Z. - Observe that the banner is not removed. task-6230530
This update addresses an issue causing incorrect balances in the French Balance Sheet reports, specifically related to accounts 119 and 129. The change reverts a previous update that introduced this problem, ensuring accurate financial reporting for French businesses using Odoo Enterprise.
Original PR description
This reverts commit 4ce40ed3be6981b32292d98621f1071d4a431e21, after problems have been reported in the display of accounts 119/129, which leaded to an unbalanced Balance Sheet. See opw-6229773
This update fixes a previous issue where weekly subscription revenue wasn't accurately reflected on the project dashboard. The change ensures that revenue from weekly subscriptions is now correctly calculated and displayed, improving the accuracy of financial reporting for projects using this subscription type.
Original PR description
…plan Before this commit, the #113918 corrects the project dashboard revenue when a yearly subscription is linked to that project. The problem is the fix does not take into account the weekly subscription. This commit handles the subscriptions with plan unit set to week and linked to the project to correclty set the right revenue in to invoice column. opw-5916688
The original query was inefficiently re-querying account statements for partner name matching, leading to significant performance overhead. This change eliminates redundant statement lookups, drastically reducing query execution time and improving partner search responsiveness. The fix focuses on efficient data retrieval based on the initial statement match.
Original PR description
Various improvements related to performance for `<account.bank.statement.line>._retrieve_partner`
This update resolves an issue where downloading signed documents through the Sign app was failing due to a compatibility problem with the pypdf library. The fix moves the document compression step to the correct object, ensuring compatibility with newer versions of pypdf and preventing errors. This ensures reliable document downloads for users.
Original PR description
This [related PR] introduced a compression pass after calls to mergePage(). However in newer versions of pypdf (>=3.5.2), compress_content_streams() can only be called on pages of PdfWriter. An error would be raised when called on pages of a PdfReader. Steps to reproduce ----- 1. Run Odoo with pypdf>=3.5.2 2. Sign and download a document in the Sign app 3. Traceback occurs Fix ---- This commit moves the compression to the writer object, after the merged page has been added. Related pr: https://github.com/odoo/odoo/pull/261879 runbot-937761 Forward-Port-Of: odoo/enterprise#118111 Forward-Port-Of: odoo/enterprise#117756
This update corrects a visual issue in comparison reports (Balance Sheet, P&L) where total values were incorrectly duplicated in both the line and header sections when 'Add total below sections' was enabled. The change ensures that totals are only displayed when a section is expanded, improving report clarity and accuracy.
Original PR description
Right now when you expland a section in comparison mode like in the Balance Sheet and P&L, if "Add total below sections" is enabled in the report then it shows in both the header and totals sections. This commit clears up that by only showing the value in the line when it's unexpanded, but once it is expanded it is hidden. task-6190986
This update fixes a potential error in the generic tax report that prevented error messages from appearing when dealing with negative net values. The change ensures that the report accurately checks for tax discrepancies, regardless of whether the net amount is positive or negative, improving report reliability.
Original PR description
**Issue:** In the generic tax report, a check is performed on the report lines to ensure that the declared tax amount is consistent with the expected amount. If the difference between the declared tax amount and the expected one is higher than 0.1% of the declared net amount, then a error message is displayed. If the net amount is negative, the error message is never displayed because the computed percentage of the tax difference is negative and therefore lower than 0.1% (i.e. 0.001). opw-6014350 Forward-Port-Of: odoo/enterprise#117990
This update resolves an issue where removing a general note from a restaurant orderline caused the preparation display to incorrectly mark the line as cancelled and create a new one. The fix ensures that note history is recorded regardless of whether the note is confirmed, allowing the system to update existing orderlines instead of creating duplicates.
Original PR description
Steps to reproduce: --------- 1. Create an order with an orderline general note. 2. Send the order to the preparation display. 3. Remove the note from orderline. 4. Resend the order Issue: --------------- Removing the note changes the preparation line key, so the preparation display marks the old line as cancelled and creates a new one instead of updating the existing line. Cause: ----------- The note history was only recorded when the note was confirmed. If the user simply removes/clears the note, no note history entry is generated, so the backend cannot match the previous key with the updated key. Fix: ---------- Record note history even when the note is discarded (not only when confirmed. This allows the backend to match the old and new keys and update the line instead of cancelling it. Task-6101501 Related PR - https://github.com/odoo/odoo/pull/258632 Forward-Port-Of: odoo/enterprise#117943 Forward-Port-Of: odoo/enterprise#113514
This update removes a redundant step in creating embedded actions within Odoo. Previously, a separate translation was required, but now that embedded actions automatically inherit their display names, this manual process is no longer necessary. This streamlines the action creation workflow and ensures consistent translations.
Original PR description
Now that `ir.embedded.actions` delegates its display name to the linked action, the manual translation copy on embedded action creation is no longer needed. Related: https://github.com/odoo/odoo/pull/262981 Forward-Port-Of: odoo/enterprise#116793 Forward-Port-Of: odoo/enterprise#116369
This update corrects a translation error in the Odoo Enterprise Gantt view. The button used to toggle display modes was not properly translated, preventing users from seeing the view in their preferred language. This fix ensures all users can consistently access and understand the Gantt view's options.
Original PR description
The title of the button allowing to toggle the display mode in the Gantt view was not translated. This commit adds a getter to compute the title based on the current display mode, and uses it in the template. Issue reported by translator. Forward-Port-Of: odoo/enterprise#117807 Forward-Port-Of: odoo/enterprise#117739
This update resolves an issue where product variant prices didn't automatically update when the cost price was modified. The fix ensures that changes to the cost price immediately trigger an update to the 'On Sale Price,' eliminating the need for manual price list adjustments. This improves accuracy and efficiency in managing product pricing.
Original PR description
When we create a product variant and have a pricelist which is based on the cost price, and change the cost price, the on_sale_price doesn't update. You have the change the price list to other and back to the one you want for it to trigger change because the _onchange_compute_pricing only gets triggered if there's change on pricelist (pricer_sale_pricelist_id), and sales price (lst_price). Steps to Reproduce: 1.Create a pricelist and add a line with "formula" price type, and based on "cost", 2.Create a product variant, and add the pricelist just created. 3.Change the "Cost". The "On Sale Price" doesn't update. 4.You have to change the price list to some other and back to the one you want for the "On Sale Price" to update. To fix the issue, we add the field Cost (standard_price) on api.onchange, so when we change the cost it'll update the "On Sale Price" right away. opw-5947995 Forward-Port-Of: odoo/enterprise#111892
4 changes
Resolved issues and error corrections
A recent test failed because the system wasn't correctly assigning user permissions for production lot tracking. This update ensures that the necessary user group (`stock.group_production_lot`) is automatically applied during test execution, resolving the issue and allowing tests to run reliably. This improves the accuracy of our testing process.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Run `test_reservation_method_for_outgoing` without demo data. Issue ----- > AssertionError: 'lot_id' was not found in the view Cause ----- The `lot_id` field is only rendered if the current user has the `stock.group_production_lot` group. This is only default when demo data is installed. Solution -------- Add the group to the current user in `setUpClass`. runbot-243588
This update resolves two issues related to sending deliveries to eTransport. Previously, the system generated error traces; now, it displays clear validation messages directly on the delivery document. This ensures better visibility and easier troubleshooting for users.
Original PR description
This commit fixes two corner case bugs:
1. Transport on National Territory with a warehouse in another country
- Setup eTransport data in settings
- Create a delivery to a Romanian customer
- in eTransport tab -> choose operation type: Transport on National
Territory
- Go to configuration -> warehouses -> change the address of the
warehouse to an address not in Romania
- send the eTransport
2. Sending to eTransport with invalid tokens
- Setup eTransport data in settings
- Remove a character from one of the tokens
- send a valid Delivery to eTransport
we get a traceback for both cases but we want a validation message on the
created document instead.
task-6217207
Forward-Port-Of: odoo/odoo#264747This update upgrades the PostgreSQL version used in the Odoo Windows installer from 12 to 16. This change addresses end-of-life support for the older version and ensures continued compatibility and security. Additionally, the installer now uses a dedicated Odoo user for the database connection, 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#265134
This update addresses a potential issue where the system could incorrectly retrieve IAP VIES identifiers, leading to inaccurate VAT calculations. The changes include improved testing, clearer state tracking for Intra-Community value updates, and adjustments to ensure the system remains synchronized during data updates. This ensures data integrity and accurate VAT processing.
Original PR description
- Avoid race condition while getting the IAP VIES identifiers - Clarify to which state the Intra-Community value has been updated - Increment validity of the webhook_token while waiting for a push update - Add more tests, especially for the controller and the cron - Remove no-longer-relevant tests task-none Forward-Port-Of: odoo/odoo#260440
7 changes
Resolved issues and error corrections
This update resolves an issue where invoices with excessively long item descriptions were being rejected by the eTIMS system. The fix truncates descriptions to meet the 200-character limit specified by eTIMS, ensuring successful invoice submission and avoiding delays in customs processing. This improves compliance with eTIMS regulations.
Original PR description
The eTIMs specification limit the `itemNm` to 200 characters, so truncate the invoice line description to that limit to ensure that the invoice can be correctly submitted eTIMS server. Otherwise it will be rejected with: ``` Error sending to the KRA: - Request parameter error[<ItemList><itemNm>: length must be between 0 and 200] ``` Task-Id: 5220129
This update resolves an issue preventing orders from being confirmed on branch company websites after payment. The fix addresses a conflict between company affiliations within the payment system, ensuring orders are properly processed and reflected in the backend, even after manual confirmation.
Original PR description
Version: --- 17.0+ Issue: --- Due to this issue, the orders are never confirmed on branch company website once payment is done. ### Steps to reproduce: 1- Create a branch company. 2- Add a website to…
Version: --- 17.0+ Issue: --- Due to this issue, the orders are never confirmed on branch company website once payment is done. ### Steps to reproduce: 1- Create a branch company. 2- Add a website to the branch company. 3- Enable a payment provider in the parent company. (The reason why the payment provider is set on the parent company is because due to limitation caused by account journal which requires branches to use the payment provider from the parent: b093786714e9e8567cf75abf78ac3d954a3d89b2 In another PR #257622, we are going to restrict users from being able to create a payment provider for the branch company) 4- Navigate to the branch website using incognito mode, and add a product to the cart. 5- Checkout and pay. On version 17.0: You will get a blocking error: ``` Incompatible companies on records: - False belongs to company 'YourCompany' and 'Customer/Vendor' (partner_id: 'Public user for Branch') belongs to another company. ``` On 18.0+: You can only see the error if debug mode is on. However, after payment, in the backend you can find the SO is never confirmed. Even if you confirm the order manually in the backend, then a cron will be initiated to register the payment in the journal and fail at every try. Cause: --- The _check_company() method enforces a strict constraint preventing relational fields from another company. Here in this case we have a `account.payment` record with a `partner_id` from parent company, which violates the constraint. As mentioned, in branch companies we are required to use the payment provider from parent company. So we would need to create a `account.payment` record inside parent company's journal with current partner which has `compnay_id` set to branch company. Fix: --- We could avoid the issue by not setting the website.company_id on the created partner on the website. related: #257622 opw-6013978
This update addresses a technical issue related to how Odoo retrieves VIES identifiers, preventing potential errors and ensuring accurate VAT calculations. The changes include improved testing and synchronization to enhance the reliability of the base_vat module.
Original PR description
- Avoid race condition while getting the IAP VIES identifiers - Clarify to which state the Intra-Community value has been updated - Increment validity of the webhook_token while waiting for a push update - Add more tests, especially for the controller and the cron - Remove no-longer-relevant tests task-none
This update replaces the older PostgreSQL 12 installer with version 16, addressing end-of-life support for the previous version. Additionally, the installer now uses a dedicated Odoo user for database connections, enhancing security and stability.
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.
This update resolves an issue where closing a popup using the ESC key was not functioning correctly. The fix ensures that the popup closes reliably, regardless of whether the popup contains interactive elements. This improves the user experience and prevents unexpected popup persistence.
Original PR description
Steps to reproduce: =================== - Add a Popup snippet to a page - Remove all links/buttons inside the popup - Save and wait for the popup to appear - Press ESC -> Nothing happens. Cause:…
Steps to reproduce:
===================
- Add a Popup snippet to a page
- Remove all links/buttons inside the popup
- Save and wait for the popup to appear
- Press ESC
-> Nothing happens.
Cause:
======
https://github.com/odoo/odoo/blob/a922c31fa7ccd1107b31287ab1f75697fae874f8/addons/website/static/src/snippets/s_popup/000.js#L219-L226 when the popup contains no tabbable elements, `this.el.focus()` was called. `this.el` refers to the `.s_popup` div, not the `.modal` element that Bootstrap monitors for keyboard events. As a result, the ESC keydown event never reached Bootstrap's handler and the modal stayed open.
When focusable elements (links, buttons) were present, `tabableEls[0].focus()` correctly focused an element inside `.modal`, so ESC worked fine in that case.
Solution:
=========
Replace `this.el.focus()` with `this.el.querySelector(".modal").focus()` so focus lands on the `.modal` element allowing Bootstrap's built-in ESC handler to fire correctly in all cases
opw-5891054
task-5182964
task-5182964This update fixes a visual glitch in the website builder's carousel feature. Previously, changing image sizes through border overlays caused inconsistent heights and a distracting 'jitter' effect. This change ensures a smooth and stable carousel display across different image sizes.
Original PR description
In a carousel snippet all carousel items keep a consistent height to prevent layout jitter when sliding. The height synchronization was broken in the `s_carousel` snippet when item dimensions were modified via border overlays (padding changes). The issue was caused by the resize event being triggered from a different jQuery instance than the one used to register the height synchronization listener, preventing the handler from being executed. Steps to reproduce (Border Overlay): 1. In the website builder, add the `s_carousel` snippet. 2. Drag the lower border overlay so that the height of an image increases. 3. Navigate through the carousel and observe height changes causing a jitter effect. Task: [5135520](https://www.odoo.com/odoo/project/974/tasks/5135520)
This update corrects a recent change that was preventing users from properly reconciling multi-step bank transfers (like payouts to internal accounts and then to destination banks). The fix focuses the matching filter to receivable and payable accounts, restoring the expected behavior for liquidity transfer reconciliation flows. This ensures accurate bank statement matching and avoids incorrect flagging of transactions.
Original PR description
Commit e2a9f3bfbb8a excludes from the bank statement matching domain any AML whose source statement line is already reconciled, to prevent false-positive label matches on past manual counterparts. However, the filter is applied to every account type, which breaks legitimate multi-step reconciliation flows on liquidity / transfer accounts (e.g. payout -> internal transfer account -> destination bank). After the first statement line is reconciled, the transfer-account AML is no longer offered as a candidate for the destination bank line; the line falls back to the suspense account and the AML is also invisible in "Match Existing Entries". Scope the new filter to receivable / payable accounts only, which is the case the original commit was actually guarding against. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr