Wednesday, July 29, 2026
30 changes · saas-19.1
Enhancements to existing features
When an expense card cannot be created because Stripe is not connected, users are now directed to the relevant settings page to complete the connection. This reduces confusion and helps teams resolve setup issues faster without needing technical support.
Original PR description
When a user tries to create a card but the configuration is not connected, redirect the user towards the settings to do the connection. task-6272805 Forward-Port-Of: odoo/enterprise#125113
Give clearer, more accurately attributed error messages, and add validation to catch classification code / General Public TIN mismatches before they reach MyInvois. task-4651934 Forward-Port-Of: odoo/odoo#278208
Original PR description
Give clearer, more accurately attributed error messages, and add validation to catch classification code / General Public TIN mismatches before they reach MyInvois. task-4651934 Forward-Port-Of: odoo/odoo#278208
Previously, questions in the event template could not be reordered via drag-and-drop on the Questions page. Instead of adding the handle to the inline list embedded in the event.type form view, we add it to the dedicated event.question list view (event_question_view_list). This will allow the users to reorder from the event questions and the sequence will be synced everywhere those questions appear. Steps to reproduce: 1.Go to event, configurations, and event questions. 2.We can't drag an
Original PR description
Previously, questions in the event template could not be reordered via drag-and-drop on the Questions page. Instead of adding the handle to the inline list embedded in the event.type form view, we add it to the dedicated event.question list view (event_question_view_list). This will allow the users to reorder from the event questions and the sequence will be synced everywhere those questions appear. Steps to reproduce: 1.Go to event, configurations, and event questions. 2.We can't drag and drop questions Original PR (18.0): odoo/odoo#270576 opw-6260478
Resolved issues and error corrections
Expense card authorization updates now better recognize the merchant currency instead of falling back to the company currency. This helps keep expense amounts accurate when Stripe sends updated authorization information.
Original PR description
During updates of the authorization amounts the currency may revert to the company one Specifically, if the merchant currency cannot be found, it defaults to the company currency. We now broaden the search search on currency with the `ilike` operator Task [link](https://www.odoo.com/odoo/project.task/6345203) opw-6345203 Forward-Port-Of: odoo/enterprise#123772
Miscellaneous changes
Deleting `loyalty.card` records causes severe performance bottlenecks due to a sequential scan during the foreign key constraint check on `pos_order_line.coupon_id` --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#278555
Original PR description
Deleting `loyalty.card` records causes severe performance bottlenecks due to a sequential scan during the foreign key constraint check on `pos_order_line.coupon_id` --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#278555
Chilean invoice PDF copies now always show the legally required CEDIBLE disclaimer in Spanish. This prevents the footer from appearing in English when the customer language is not Spanish, helping businesses keep Chilean electronic invoices compliant.
Original PR description
Steps to reproduce: - Set the database language to Spanish (Latin America). - Create a customer invoice, confirm it and send it to the SII. - Print it using Print > Invoice PDF copy (Chile). - Scroll…
Steps to reproduce:
- Set the database language to Spanish (Latin America).
- Create a customer invoice, confirm it and send it to the SII.
- Print it using Print > Invoice PDF copy (Chile).
- Scroll to the CEDIBLE section at the bottom of the PDF.
Cause of the issue:
The CEDIBLE footer is merged into l10n_cl.report_invoice_document, which account.report_invoice (odoo/addons/l10n_cl/views/report_invoice.xml) renders with t-lang set to the invoice partner's lang, not the database/user language. The disclaimer text was hardcoded in English and relied on the regular translation to be shown in Spanish, so as
soon as the partner's lang field isn't Spanish, the translation lookup falls back to the untranslated English source, regardless of the database language.
Solution:
This disclaimer is boilerplate mandated by Chilean law: it must always be printed in Spanish, independently of the invoice partner's or current user's language. The same template already follows that rule a few lines above for the SII stamp block ("Timbre Electrónico SII..."), which is hardcoded in Spanish instead of relying on translation.
opw-6390207
Forward-Port-Of: odoo/enterprise#124916The French FEC export checks were updated to match a recent change in how accounting entry labels are chosen when fallback text is needed. This keeps automated validation accurate and helps ensure French accounting reports continue to be tested reliably.
Original PR description
Adjust the FEC export test expectations to match the updated `EcritureLib` fallback logic introduced in the related community change. Related: https://github.com/odoo/odoo/pull/257242 task-5346068 Forward-Port-Of: odoo/enterprise#112822
This fix adds a missing tax conversion factor to the invoice data sent to Avalara for Brazil fiscal reform requirements. It helps ensure sales quantities are interpreted correctly for compliance calculations, reducing the risk of invoice processing errors.
Original PR description
This commit adds the comexTaxUnitFactor to the json sent to Avalara when sending an invoice. comexTaxUnitFactor is a factor that convert sales quantity to comexTaxUnit, its value should be the same as cbsIbsUnitFactor. opw-6396462
Swiss employee payslip reports now show the actual contract withdrawal date instead of a related version end date. This prevents incorrect departure information from appearing on payroll documents when those dates differ.
Original PR description
The Withdrawal Date in the payslip of CH employees was printing the date_end relative to the version related to the payslip. Instead, it should print the end of the contract of that version, since they can be different. The end date of the contract is in l10n_ch_withdrawal. Task: 6398291 Forward-Port-Of: odoo/enterprise#124848
When a product uses automated inventory valuation, scrapping it from an already validated (done) picking generated no inventory valuation journal entry, even though the stock move value and the on-hand quantity were correctly updated. The same scrap done from the Scrap menu, or from a picking that is not done yet, worked as expected. A stock move whose picking is already done is created directly in the 'done' state (stock.move.create). Such a move is filtered out of the recordset returned by
Original PR description
When a product uses automated inventory valuation, scrapping it from an already validated (done) picking generated no inventory valuation journal entry, even though the stock move value and the on-hand quantity were correctly updated. The same scrap done from the Scrap menu, or from a picking that is not done yet, worked as expected. A stock move whose picking is already done is created directly in the 'done' state (stock.move.create). Such a move is filtered out of the recordset returned by _action_done(), on which _create_account_move() is called, so the scrap move never received its journal entry. Steps to reproduce: - Use a storable product with automated inventory valuation - Create and validate a receipt for it - Open the completed picking, click Scrap, set a quantity and validate it - The stock is reduced but no journal entry is created. opw-6368258 Forward-Port-Of: odoo/odoo#275847
Issue: If a product has a pricelist that updates on quantity and in quotation preview the customer changes the quantity the unit price doesn't update. Steps to reproduce: Create a product with price list that change depending on quantity. In a new quotation create a section and set it to optional. Add your product under this new section, and enter preview. Notice that if you change the quantity so that a different pricelist would apply the unit price still does not change. Cause: The va
Original PR description
Issue: If a product has a pricelist that updates on quantity and in quotation preview the customer changes the quantity the unit price doesn't update. Steps to reproduce: Create a product with price list that change depending on quantity. In a new quotation create a section and set it to optional. Add your product under this new section, and enter preview. Notice that if you change the quantity so that a different pricelist would apply the unit price still does not change. Cause: The value for unit price was not getting updated. Fix: After changing quantities update the price unit if there are active pricelists. As not all customers might want this change, it also checks for `sale.disable_sale_update`, so that the user can choose whether to update or not. opw-6377679 Forward-Port-Of: odoo/odoo#275868
Issue ----- International deliveries for fractions of items (eg 500g of a product sold by kg) are rejected by Sendcloud. Steps to reproduce ----- - Setup Sendcloud - Fedex international - Create a product - weight: 1kg - valid hs code - Create a contact (outside EU if the company is in EU) - Deliver 0.5 of the product to the contact > Error "... parcel not returned from Sendcloud" Cause ----- Sendcloud returns he folloing error: > "The total weight for declared items e
Original PR description
Issue ----- International deliveries for fractions of items (eg 500g of a product sold by kg) are rejected by Sendcloud. Steps to reproduce ----- - Setup Sendcloud - Fedex international - Create a…
Issue ----- International deliveries for fractions of items (eg 500g of a product sold by kg) are rejected by Sendcloud. Steps to reproduce ----- - Setup Sendcloud - Fedex international - Create a product - weight: 1kg - valid hs code - Create a contact (outside EU if the company is in EU) - Deliver 0.5 of the product to the contact > Error "... parcel not returned from Sendcloud" Cause ----- Sendcloud returns he folloing error: > "The total weight for declared items exceeds the total weight set for the shipment." This is because the `weight` set on the shipment https://github.com/odoo/enterprise/blob/99a13453cac8a7a4677cef3df8896329c90c9e99/delivery_sendcloud/models/sendcloud_service.py#L449-L464 corresponds to the weight of the package, whereas the weight set on the description of the product in `parcel_items` corresponds to the weight of one "full" unit of the product. https://github.com/odoo/enterprise/blob/99a13453cac8a7a4677cef3df8896329c90c9e99/delivery_sendcloud/models/sendcloud_service.py#L327-L335 We cannot change the quantity in `parcel_items` to match the actual delivered one because the field should be an integer. https://sendcloud.dev/api/v2/parcels/create-a-parcel-or-parcels#body-one-of-0-parcel-parcel-items-items-quantity The price is also off, because it gets taken from the `move_line`, so it reflects the price of the actual quantity and not a "full" item. https://github.com/odoo/odoo/blob/208a8a6a5adb8ec1f2710453c2ee3b54c55a9f1e/addons/stock_delivery/models/delivery_carrier.py#L235 Note that this issue is common to **all UoM types**. Solution ----- Since we cannot change the quantity, we can instead adapt the description and weight sent in `parcel_items`. For example, sending 300g of sugar, we would send - description: "Sugar (0.3 kg)" - weight: "0.300" ----- Ticket: opw-6346330 Forward-Port-Of: odoo/odoo#277440
### Issue: The fix in commit `f0d164d3ab` introduced one cash rounding record per Indian company for new installations, but existing databases were not updated Indian companies created before that fix still share the old `l10n_in.cash_rounding_in_half_up` record, and moves may be linked to a cash rounding belonging to another company ### Cause: No migration script was included with the original fix The script creates a dedicated cash rounding record for each Indian company that does n
Original PR description
### Issue: The fix in commit `f0d164d3ab` introduced one cash rounding record per Indian company for new installations, but existing databases were not updated Indian companies created before that…
### Issue: The fix in commit `f0d164d3ab` introduced one cash rounding record per Indian company for new installations, but existing databases were not updated Indian companies created before that fix still share the old `l10n_in.cash_rounding_in_half_up` record, and moves may be linked to a cash rounding belonging to another company ### Cause: No migration script was included with the original fix The script creates a dedicated cash rounding record for each Indian company that does not already have one, reassigns existing moves to the correct record, and migrates the XML ID of the original shared record to the new per-company format ### Steps to reproduce: - Create a database with `l10n_in` installed before commit `f0d164d3ab` - Create an invoice and set its Cash Rounding to `Half Up` - Create a new Indian company (the `Half Up` record is now reassigned to the new company) - Repeat the previous two steps as many times as desired - Apply the fix (without the migration script) and upgrade `l10n_in` Before the fix, invoices from other companies still reference the shared cash rounding record belonging to the last created company - Apply the migration script and upgrade again After the fix, each company has its own cash rounding record and existing invoices are reassigned correctly opw-6318857
Currently, an error occurs when installing the hr_holidays_attendance module. **Steps to Reproduce:** - Install the `hr_attendance` module without demo data. - Go to `Attendance` > `Configuration` > `Overtime Rulesets` and open the `Default Ruleset` record. - Delete its `linked overtime rules`. - Install the `hr_holidays_attendance` module. **Error:** ```py Exception: Cannot update missing record 'hr_attendance.hr_attendance_overtime_employee_schedule_rule' odoo.tools.conver
Original PR description
Currently, an error occurs when installing the hr_holidays_attendance module. **Steps to Reproduce:** - Install the `hr_attendance` module without demo data. - Go to `Attendance` > `Configuration` >…
Currently, an error occurs when installing the hr_holidays_attendance module.
**Steps to Reproduce:**
- Install the `hr_attendance` module without demo data.
- Go to `Attendance` > `Configuration` > `Overtime Rulesets` and open the `Default Ruleset` record.
- Delete its `linked overtime rules`.
- Install the `hr_holidays_attendance` module.
**Error:**
```py
Exception: Cannot update missing record 'hr_attendance.hr_attendance_overtime_employee_schedule_rule'
odoo.tools.convert.ParseError: while parsing /home/odoo/odoo18/community/addons/hr_holidays_attendance/data/hr_holidays_attendance_data.xml:7, somewhere inside <record id="hr_attendance.hr_attendance_overtime_employee_schedule_rule" model="hr.attendance.overtime.rule">
<field name="compensable_as_leave" eval="True"/>
</record>
```
This error occurs when the user deletes all overtime rules and then installs the hr_holidays_attendance
module. During installation, the module attempts to update the deleted overtime rule records,
which raises an error [1].
This commit uses forcecreate="0" to skip updating records if the corresponding overtime
rules do not exist.
[1]- https://github.com/odoo/odoo/blob/da0a83761f38ee4a2940015b6c8f7190c310a4a0/addons/hr_holidays_attendance/data/hr_holidays_attendance_data.xml#L7-L12
sentry-7372074675
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr- Fix: The edit() calls now pass { confirm: false } to avoid calling the extra step that involved clicking manually on the input to trigger the search and the dropdown display. This should remove the race condition. - Small cleanup: clickFieldDropdownItem replaces the hardcoded ".dropdown-item:nth-child(1)" click, allowing selecting by product name instead of position. runbot-error: 941390 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-P
Original PR description
- Fix: The edit() calls now pass { confirm: false } to avoid calling the extra step that involved clicking manually on the input to trigger the search and the dropdown display. This should remove the race condition.
- Small cleanup: clickFieldDropdownItem replaces the hardcoded ".dropdown-item:nth-child(1)" click, allowing selecting by product name instead of position.
runbot-error: 941390
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#278813When `cash_rounding` is enabled on a POS config but `rounding_method` is not set,`get_tax_totals_summary` is called with undefined (instead of null). Fix: ensure the `rounding_method` is set when `cash_rounding` is enabled, otherwise pass null to `get_tax_totals_summary`. task-id: 6388234 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#276914
Original PR description
When `cash_rounding` is enabled on a POS config but `rounding_method` is not set,`get_tax_totals_summary` is called with undefined (instead of null). Fix: ensure the `rounding_method` is set when `cash_rounding` is enabled, otherwise pass null to `get_tax_totals_summary`. task-id: 6388234 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#276914
**Description of the issue/feature this PR addresses:** When rendering floating-point numbers with high decimal accuracy (e.g., UoM quantities set to 10 decimals), the UI can occasionally display a trailing parasitic digit (such as 53000.0000000002 instead of 53000.0000000000). This commit resolves the issue by backporting the formatting logic from master. The `maxDecDigits` calculation is moved outside the conditionals so it unconditionally caps precision for all numbers. Furthermore, the
Original PR description
**Description of the issue/feature this PR addresses:** When rendering floating-point numbers with high decimal accuracy (e.g., UoM quantities set to 10 decimals), the UI can occasionally display a…
**Description of the issue/feature this PR addresses:** When rendering floating-point numbers with high decimal accuracy (e.g., UoM quantities set to 10 decimals), the UI can occasionally display a trailing parasitic digit (such as 53000.0000000002 instead of 53000.0000000000). This commit resolves the issue by backporting the formatting logic from master. The `maxDecDigits` calculation is moved outside the conditionals so it unconditionally caps precision for all numbers. Furthermore, the global significant digit ceiling is reduced from 15 to 14. This 14-digit ceiling reserves a 1-digit buffer, allowing the newly introduced `formatFixedDecimals` utility to safely run `roundDecimals` on the float. This mathematically sanitizes the trailing corrupted digit before it is ever converted to a string. opw-6313540 **Current behavior before PR:** - With Product UoM set to 10 Decimal Accuracy, floats such as 53000 are displayed with a corrupted digit (e.g. 53000.0000000002) **Desired behavior after PR is merged:** - With Product UoM set to 10 Decimal Accuracy, floats such as 53000 are displayed without corrupted digits (e.g. 53000.000000000) This PR is essentially a backport of https://github.com/odoo/odoo/commit/07da917f6e3319b4acde1029e77f69f1aba314b8 and https://github.com/odoo/odoo/commit/c4e7ba8d8fdfd7b0c442cf834f562ef8cedf019b for numbers.js Forward-Port-Of: odoo/odoo#276406 Forward-Port-Of: odoo/odoo#272940
**Steps to reproduce:** - Install website_forum - Create a new post on the forum with the admin - Subscribe to the post notifications using the bell button - Create a new portal user and give him 5 karma (to give him enough rights to answer and comment) - Connect with the portal user and go to the post - Create an answer - Try to comment on your own answer - AccessError is raised **Issue:** Since [1] we check comodel access (in this case `res.partner`) when adding records. Here
Original PR description
**Steps to reproduce:** - Install website_forum - Create a new post on the forum with the admin - Subscribe to the post notifications using the bell button - Create a new portal user and give him 5…
**Steps to reproduce:**
- Install website_forum
- Create a new post on the forum with the admin
- Subscribe to the post notifications using the bell button
- Create a new portal user and give him 5 karma
(to give him enough rights to answer and comment)
- Connect with the portal user and go to the post
- Create an answer
- Try to comment on your own answer
- AccessError is raised
**Issue:**
Since [1] we check comodel access (in this case `res.partner`) when adding records. Here during the `message_post` the `question_followers` are added manually as `partner_ids` before sending (the logic only relies on the original post subscribers, not on the added comment/reply).
```py
question_followers = self.env['mail.followers'].sudo().search([
('res_model', '=', self._name),
('res_id', '=', self.parent_id.id),
('partner_id', '!=', False),
]).filtered(lambda fol: comment_subtype in fol.subtype_ids).mapped('partner_id')
partner_ids += question_followers.ids
```
As the portal user has no `read` access to the subscribers the message creation fails with a traceback.
**Fix:**
Add `sudo` to the `message_post` call of `post_comment`.
(Also fix a minor display issue in the 'Karma Error' notification)
[1] https://github.com/odoo/odoo/commit/aae732957c3c3b3590f5686cfccc0ab264d0b5c9
opw-5318757
Forward-Port-Of: odoo/odoo#274751The test that verifies the behavior of cancelling the link popover during an attachment upload relies on a hard-coded delay. Occasionally, when the test runs on an overloaded runbot infrastructure, the upload manages to complete before the discard happens. This commit fixes this by making sure the upload never completes within the test. runbot-940190 runbot-944098 Forward-Port-Of: odoo/odoo#278820
Original PR description
The test that verifies the behavior of cancelling the link popover during an attachment upload relies on a hard-coded delay. Occasionally, when the test runs on an overloaded runbot infrastructure, the upload manages to complete before the discard happens. This commit fixes this by making sure the upload never completes within the test. runbot-940190 runbot-944098 Forward-Port-Of: odoo/odoo#278820
This commit [1] added a top margin to headings for the html_editor. However, this margin was also applied in the website, breaking the WYSIWYG behavior. Exclude the website from this rule so the margin is only applied in the html_editor. [1]: https://github.com/odoo/odoo/commit/13a452106733c950a7e25cfeb5107eb03367b756 Forward-Port-Of: odoo/odoo#278730
Original PR description
This commit [1] added a top margin to headings for the html_editor. However, this margin was also applied in the website, breaking the WYSIWYG behavior. Exclude the website from this rule so the margin is only applied in the html_editor. [1]: https://github.com/odoo/odoo/commit/13a452106733c950a7e25cfeb5107eb03367b756 Forward-Port-Of: odoo/odoo#278730
To improve compliance with French requirements for FEC exports. Now we avoid exporting empty or placeholder labels ('/') by improving the fallback logic for EcritureLib. So now we, - Use existing line label when valid - For receivable/payable lines, fallback to 'partner - reference' - Otherwise fallback to move reference or name - Replace '/' with 'Balance initiale' for opening entries Related: https://github.com/odoo/enterprise/pull/112822 task-5346068 Forward-Port-Of: odoo/odoo#2572
Original PR description
To improve compliance with French requirements for FEC exports. Now we avoid exporting empty or placeholder labels ('/') by improving the fallback logic for EcritureLib. So now we,
- Use existing line label when valid
- For receivable/payable lines, fallback to 'partner - reference'
- Otherwise fallback to move reference or name
- Replace '/' with 'Balance initiale' for opening entries
Related: https://github.com/odoo/enterprise/pull/112822
task-5346068
Forward-Port-Of: odoo/odoo#257242Description of the issue this commit addresses: When a member of the Invoicing group tries to create a payment trough the L10nPlAccountPaymentRegister wizard, upon clicking "Create Payment", an AccessError is thrown. Invoicing group members should be able to handle payments so this is an issue. --- Steps to reproduce: 1. Make sure sale_management and l10n_pl_bank_verification are installed. 2. Create a new user with "Invoicing" Accounting group. 3. Create a new sales order with sai
Original PR description
Description of the issue this commit addresses: When a member of the Invoicing group tries to create a payment trough the L10nPlAccountPaymentRegister wizard, upon clicking "Create Payment", an…
Description of the issue this commit addresses: When a member of the Invoicing group tries to create a payment trough the L10nPlAccountPaymentRegister wizard, upon clicking "Create Payment", an AccessError is thrown. Invoicing group members should be able to handle payments so this is an issue. --- Steps to reproduce: 1. Make sure sale_management and l10n_pl_bank_verification are installed. 2. Create a new user with "Invoicing" Accounting group. 3. Create a new sales order with said user (any customer, any product) 4. Confirm the quotations and, from its form view, "Create Invoice". 5. Confirm the invoice and, from its form view, "Pay". 6. Upon clicking "Create Payment", an Access Error is thrown. --- Desired behavior after this commit is merged: This commit makes sure an Invoicing group member is able to create the payment withtout AccessErrors being thrown. --- task-none feedback from: https://github.com/odoo/odoo/pull/267992 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#278688 Forward-Port-Of: odoo/odoo#270008
**Issue** A traceback is raised when creating a batch if the batch sequence prefix does not contain the expected '/' separator. **Steps to reproduce** - Go to settings > technical > sequences & identifiers > sequence: - batch transfer: - prefix: BATCH- - Create a new batch: - operation type: delivery orders - Try to save -> a traceback is triggered: ```ValueError: not enough values to unpack (expected 2, got 1)``` **Cause** `_prepare_name()` assumes that the sequence
Original PR description
**Issue**
A traceback is raised when creating a batch if the batch sequence prefix does not contain the expected '/' separator.
**Steps to reproduce**
- Go to settings > technical > sequences & identifiers > sequence:
- batch transfer: - prefix: BATCH-
- Create a new batch:
- operation type: delivery orders
- Try to save -> a traceback is triggered:
```ValueError: not enough values to unpack (expected 2, got 1)```
**Cause**
`_prepare_name()` assumes that the sequence returned by
`next_by_code()` contains a '/' separator and directly unpacks the
result of `rsplit('/', 1)`.
When no '/' is present, `rsplit()` returns a list containing a single
element, causing the unpacking to fail.
https://github.com/odoo/odoo/blob/18407651d2912b7d30463ec72cd379177530ef4f/addons/stock_picking_batch/models/stock_picking_batch.py#L418-L419
opw-6304270
Forward-Port-Of: odoo/odoo#272212# How to reproduce - Have two language in the db - Create an e-Commerce category - Have a different translation for each language for that category's name - Copy the link to that category's name in one language (Should be something like /shop/category/name-x) - Have two websites, each with a different default language - Create a link to the shop category in each website. > ! The link must be the exact same > You can put it in the header menu for simplicity - Open the website editor - D
Original PR description
# How to reproduce - Have two language in the db - Create an e-Commerce category - Have a different translation for each language for that category's name - Copy the link to that category's name in…
# How to reproduce
- Have two language in the db
- Create an e-Commerce category
- Have a different translation for each language for that category's name
- Copy the link to that category's name in one language (Should be something like /shop/category/name-x)
- Have two websites, each with a different default language
- Create a link to the shop category in each website.
> ! The link must be the exact same
> You can put it in the header menu for simplicity
- Open the website editor
- Do 2 or 3 times :
- click on the category link and switch website
# The issue
A traceback is displayed
# Cause
This manipulation will make us enter an infinite redirect scenario described here :
https://github.com/odoo/odoo/blob/f8741728294a5147c7d2427d9997738096386262/addons/website/static/src/client_actions/website_preview/website_builder_action.js#L371-L384
The problem is that this commit introduced an assignation to `iframe.contentDocument.body` before the patch :
https://github.com/odoo/odoo/commit/89994eb7a54ca606bab26b6d579d03e86c11ba60
But in our case, iframe.contentDocument is null, so it throws an error before the patch can be applied
opw-6322115
Forward-Port-Of: odoo/odoo#276634When the shop sidebar categories are enabled with collapsed categories, subcategory names could wrap unexpectedly at 100% zoom or lower, even when there was enough available space. Steps to reproduce: - Open the Shop page and click Edit - Go to the Style tab - Set Content Width to Full - Enable the Categories sidebar - Enable Collapse Category This issue caused sidebar subcategory labels to wrap only at lower zoom levels, while higher zoom levels displayed them correctly. Add CSS
Original PR description
When the shop sidebar categories are enabled with collapsed categories, subcategory names could wrap unexpectedly at 100% zoom or lower, even when there was enough available space. Steps to reproduce: - Open the Shop page and click Edit - Go to the Style tab - Set Content Width to Full - Enable the Categories sidebar - Enable Collapse Category This issue caused sidebar subcategory labels to wrap only at lower zoom levels, while higher zoom levels displayed them correctly. Add CSS rules to prevent category names in the sidebar from wrapping. opw-6296804 Forward-Port-Of: odoo/odoo#275279
`_get_belgian_cocontractant_note()` resolves the co-contractant fiscal position through chart_template.ref(), which uses env.company. The "Send invoices automatically" cron runs as the inactive OdooBot user, so env.company is OdooBot's default company, not the invoice's. That company can differ from the invoice's and even be archived, in which case ref() raises "IndexError: tuple index out of range" (parent_ids is empty for an archived company) Steps to reproduce: - Set the main company to a
Original PR description
`_get_belgian_cocontractant_note()` resolves the co-contractant fiscal position through chart_template.ref(), which uses env.company. The "Send invoices automatically" cron runs as the inactive OdooBot user, so env.company is OdooBot's default company, not the invoice's. That company can differ from the invoice's and even be archived, in which case ref() raises "IndexError: tuple index out of range" (parent_ids is empty for an archived company) Steps to reproduce: - Set the main company to a non-Belgian company, and invoice from another active Belgian company. - Move every active user off the main company and archive it - Send a Belgian 0% invoice through the cron. => IndexError: tuple index out of range in chart_template.ref opw-6398778 Forward-Port-Of: odoo/odoo#278666 Forward-Port-Of: odoo/odoo#278326
When an order/invoice is fully discounted by a global discount, its base and tax amounts are sums of values each already rounded to the currency precision, so their sum is only a sub-unit floating point residue (~1e-6) instead of a clean zero. `_get_tax_totals_summary` fed that raw sum straight to the cash rounding. With a 'UP' (or 'DOWN') rounding method the residue was inflated into a full rounding step, e.g. a 0.01 total to pay on an otherwise empty document. opw-6402143 --- I confi
Original PR description
When an order/invoice is fully discounted by a global discount, its base and tax amounts are sums of values each already rounded to the currency precision, so their sum is only a sub-unit floating point residue (~1e-6) instead of a clean zero. `_get_tax_totals_summary` fed that raw sum straight to the cash rounding. With a 'UP' (or 'DOWN') rounding method the residue was inflated into a full rounding step, e.g. a 0.01 total to pay on an otherwise empty document. opw-6402143 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#278291
Issue caused because of https://github.com/odoo/odoo/commit/619d8ce9f31349ed06b11ead4988a4a1d9ca6bdd Steps to reproduce- Create db with demo and install l10n_in Create a new company for India (other than IN Company) Go to Settings -> Accounting/Invoice Tab -> Enable Ewaybill traceback ```py Traceback (most recent call last): File "/home/odoo/odoo18/community/odoo/orm/models.py", line 5385, in ensure_one _id, = self._ids ^^^^ ValueError: not enough values to unpack (expected
Original PR description
Issue caused because of https://github.com/odoo/odoo/commit/619d8ce9f31349ed06b11ead4988a4a1d9ca6bdd Steps to reproduce- Create db with demo and install l10n_in Create a new company for India (other…
Issue caused because of https://github.com/odoo/odoo/commit/619d8ce9f31349ed06b11ead4988a4a1d9ca6bdd Steps to reproduce-
Create db with demo and install l10n_in
Create a new company for India (other than IN Company) Go to Settings -> Accounting/Invoice Tab -> Enable Ewaybill
traceback
```py
Traceback (most recent call last):
File "/home/odoo/odoo18/community/odoo/orm/models.py", line 5385, in ensure_one
_id, = self._ids
^^^^
ValueError: not enough values to unpack (expected 1, got 0)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/odoo/odoo18/community/odoo/http/router.py", line 273, in __call__
response = serve_db(request)
^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo18/community/odoo/http/router.py", line 380, in serve_db
registry = Registry(request.db)
^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo18/community/odoo/orm/registry.py", line 105, in __new__
return cls.new(db_name)
^^^^^^^^^^^^^^^^
File "/home/odoo/odoo18/community/odoo/tools/func.py", line 67, in locked
return func(inst, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo18/community/odoo/orm/registry.py", line 217, in new
cr.rollback()
File "/home/odoo/odoo18/community/odoo/sql_db.py", line 568, in rollback
with rollbacking:
File "/home/odoo/.pyenv/versions/3.12.0/lib/python3.12/contextlib.py", line 144, in __exit__
next(self.gen)
File "/home/odoo/odoo18/community/odoo/orm/environments.py", line 1004, in rollbacking
self.restore_state()
File "/home/odoo/odoo18/community/odoo/orm/environments.py", line 1067, in restore_state
self.reset()
File "/home/odoo/odoo18/community/odoo/orm/environments.py", line 912, in reset
self._reset_registry_change()
File "/home/odoo/odoo18/community/odoo/orm/environments.py", line 832, in _reset_registry_change
registry._setup_models__(cr)
File "/home/odoo/odoo18/community/odoo/tools/func.py", line 67, in locked
return func(inst, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo18/community/odoo/orm/registry.py", line 422, in _setup_models__
env.invalidate_all()
File "/home/odoo/odoo18/community/odoo/orm/environments.py", line 395, in invalidate_all
self.flush_all()
File "/home/odoo/odoo18/community/odoo/orm/environments.py", line 413, in flush_all
self._recompute_all()
File "/home/odoo/odoo18/community/odoo/orm/environments.py", line 406, in _recompute_all
self[field.model_name]._recompute_field(field)
File "/home/odoo/odoo18/community/odoo/orm/models.py", line 6462, in _recompute_field
field.recompute(records)
File "/home/odoo/odoo18/community/odoo/orm/fields.py", line 2042, in recompute
apply_except_missing(self.compute_value, recs)
File "/home/odoo/odoo18/community/odoo/orm/fields.py", line 2012, in apply_except_missing
func(records)
File "/home/odoo/odoo18/community/odoo/orm/fields.py", line 2066, in compute_value
records._compute_field_value(self)
File "/home/odoo/odoo18/community/addons/mail/models/mail_thread.py", line 498, in _compute_field_value
return super()._compute_field_value(field)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo18/community/odoo/orm/models.py", line 4387, in _compute_field_value
determine(field.compute, self)
File "/home/odoo/odoo18/community/odoo/orm/fields.py", line 82, in determine
return needle(*args)
^^^^^^^^^^^^^
File "/home/odoo/odoo18/community/addons/l10n_in_ewaybill/models/l10n_in_ewaybill.py", line 228, in _compute_document_partners_details
seller_buyer_details = ewaybill._get_seller_buyer_details()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo18/community/addons/l10n_in_ewaybill/models/l10n_in_ewaybill.py", line 185, in _get_seller_buyer_details
return move._get_l10n_in_seller_buyer_party()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo18/community/addons/l10n_in/models/account_invoice.py", line 629, in _get_l10n_in_seller_buyer_party
self.ensure_one()
File "/home/odoo/odoo18/community/odoo/orm/models.py", line 5388, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: account.move()
```
In this commit, we resolve the above traceback
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prWhen a bus process restarts, every client on every database it serves loses its websocket at the same instant and immediately schedules a reconnection. Each database that comes back triggers a registry recompute server-side, so a tight reconnection window makes all of those recomputes land together and pile up on the freshly started process. The jitter added to each reconnection delay was only one second, far too narrow to break up that wave. Widen it to thirty seconds so the retries of the m
Original PR description
When a bus process restarts, every client on every database it serves loses its websocket at the same instant and immediately schedules a reconnection. Each database that comes back triggers a…
When a bus process restarts, every client on every database it serves loses its websocket at the same instant and immediately schedules a reconnection. Each database that comes back triggers a registry recompute server-side, so a tight reconnection window makes all of those recomputes land together and pile up on the freshly started process. The jitter added to each reconnection delay was only one second, far too narrow to break up that wave. Widen it to thirty seconds so the retries of the many clients fan out over a much wider window and the registry recomputes spread over time instead of colliding. Raise the ceiling on the retry delay to two minutes to match that wider spread, and drop the exponential growth factor: with a thirty-second jitter accumulating on every attempt, the delay already climbs on its own, so scaling it further only pushed clients toward the ceiling sooner without spreading them any better. 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#278599 Forward-Port-Of: odoo/odoo#276869
Both the `bus.bus` long-polling logic and the garbage collector vacuum cron rely on filtering by `create_date` to fetch new messages and purge expired notifications. Under heavy real-time notification usage or high client concurrency, this table grows significantly. Without an index on `create_date`, these frequent operations are forced to run full sequential scans. This commit adds a dedicated index on `create_date` to enable efficient index scans. --- I confirm I have signed the CLA
Original PR description
Both the `bus.bus` long-polling logic and the garbage collector vacuum cron rely on filtering by `create_date` to fetch new messages and purge expired notifications. Under heavy real-time notification usage or high client concurrency, this table grows significantly. Without an index on `create_date`, these frequent operations are forced to run full sequential scans. This commit adds a dedicated index on `create_date` to enable efficient index scans. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#278542