Daily updates from Odoo
Wednesday, November 26, 2025
31 changes · 18.0
New functionality added to Odoo
This update introduces basic localization support for Mauritania within the Odoo accounting system. It includes translations for key financial reports and data formats, allowing Odoo to correctly handle transactions and reporting requirements specific to Mauritanian regulations. This expands Odoo's reach to a new market and ensures compliance for businesses operating in Mauritania.
Original PR description
task-4236158 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#211906
This update adds crucial financial reports – Balance Sheet and Profit & Loss – to the Odoo Enterprise system for Mauritanian businesses. This expansion supports compliance with local tax regulations and provides Mauritanian users with the necessary reporting tools.
Original PR description
Add the Balance Sheet and Profit & Loss to the Mauritanian localization. task-4236158 Forward-Port-Of: odoo/enterprise#86530
This pull request updates the Arabic translation files for both the core Odoo application and the Odoo Point of Sale module. These updates ensure accurate and localized Arabic support for users in the Middle East and North Africa region, improving the overall user experience.
Original PR description
ADHOC Task 44224 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update incorporates new translations for the Arabic VAT (e-invoice) functionality within the Odoo Enterprise system. This ensures accurate and compliant reporting for our Arabic-speaking customers, aligning with local regulations and improving the user experience.
Original PR description
Task 44224
Enhancements to existing features
This update clarifies the tooltip for the 'Prices' setting in the configuration. Previously, it stated the setting couldn't be changed after an invoice. Now, it correctly indicates the setting locks once a journal entry is created, providing better guidance for users. This change improves understanding and reduces potential confusion.
Original PR description
This commit improves the tooltip of the Prices setting in configuration. The old tooltip "This setting cannot be changed after an invoice is created." is changed to "This setting locks once a journal entry is created." task-5354382 --- 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 corrects an issue preventing Odoo from properly retrieving invoice documents from the Viettel e-invoice system. The original problem stemmed from incorrect parameter requirements in the API documentation. By removing unnecessary parameters, the system now successfully retrieves the required invoice files, ensuring accurate data exchange.
Original PR description
* Problem: When trying to get document from sinvoice, we get error not found * Reason: in the api document the parameter not include 'strIssueDate' and also the 'transactionUuid' not require at all, but if we include 'transactionUuid' we still get 400 error 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#236628
This update resolves an issue where the Fedex delivery method would fail when shipping to addresses with state codes like 'Hong Kong Island' in Hong Kong. The fix adds a check to ensure the state code splitting process returns at least two elements, preventing a common error. This ensures reliable shipping functionality for customers in Hong Kong.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Use Fedex as a Delivery Method 2. On the Website, select a shippable product. Confirm the cart. 3. Ship to a "Hong Kong" address, with "Hong Kong Island" as State. 4. Traceback is raised. Issue ----- Traceback is raised whenever the Fedex Delivery Method is applied to a HK address (be it shipper or receiver) Cause ----- When splitting a state code, there is no check in the `_parse_state_code` function that the result contains at least two elements. Example ----- For a "Hong Kong" address, with "Hong Kong Island" as State: ``` country_code = "HK" state_code = "HK" ``` The method tries to split `state_code` by its hyphen, which returns a single item list. Solution -------- 1. Check for the size of the post-split list before accessing the second item. opw-5257852 Forward-Port-Of: odoo/enterprise#99635
This update fixes a minor issue where the 'Copy' button in the Payment Link wizard incorrectly displayed. The button label has been updated to accurately reflect its function: 'Generate and Copy Payment Link'. This ensures users see the correct instruction when creating payment links.
Original PR description
Steps to reproduce: 1. Install sale_management 2. Create a sale order and confirm it 3. Open the Generate a Payment Link wizard from the cog menu Issue: The button in the wizard displays “Copy” instead of “Generate a Payment Link”. Cause: The custom paymentWizardCopyClipboardButtonField widget did not forward the field’s string to its component props, causing the default "Copy" label to be used. Solution: Forward the string prop in the widget’s extractProps implementation. opw-5224112 Forward-Port-Of: odoo/odoo#236219
This update resolves an issue preventing the 'Payment Reminder' email template from functioning correctly. The fix corrects a technical error related to how the template processes numerical data, ensuring accurate payment reminders are sent to customers. This improves the reliability of our billing communications.
Original PR description
### Steps to reproduce: - Install account_no_followup - Enable debug mode - Settings > Technical > Email > Email Templates - Search for the "Payment Reminder" template > Preview ### > traceback: Can…
### Steps to reproduce: - Install account_no_followup - Enable debug mode - Settings > Technical > Email > Email Templates - Search for the "Payment Reminder" template > Preview ### > traceback: Can not compile expression: "format_amount(object.total_overdue_followup, ### Cause of the issue: The issue is caused by 7e55a28e73cc99184ed9737e672f451d03a3efb3 These lines: https://github.com/odoo/enterprise/blob/079795fe28f55854f9f785e360580a02e6f89d4e/account_no_followup/__init__.py#L7-L15 simply break every concerned template. the reason being that the template.html_body is a Markup and replacing the string: `t-out="*object.total_overdue` in a `Markup` will simply escape the `"` charracter as a `"` replacing this string by: `"t-out="*object.total_overdue"` for instance in `Payment Reminder` template it will alter this line: https://github.com/odoo/enterprise/blob/079795fe28f55854f9f785e360580a02e6f89d4e/account_followup/data/account_followup_data.xml#L18 and replace `<t t-out="format_amount(object.total_overdue, object.currency_id) or ''"/>` by `<t t-out=""format_amount(object.total_overdue", object.currency_id) or ''"/>` This makes the template crash as `""format_amount(object.total_overdue"` is not a valid attribute value. opw-5138378
This update addresses a security vulnerability where public website visitors could create unwanted UTM tracking records when registering for events. The fix restricts record creation to non-public users, preventing potential misuse and ensuring data integrity. This improves the stability and accuracy of our event registration tracking.
Original PR description
**Steps to reproduce:** - Install Link Tracker app - Go to Link Tracker > UTMs - Check UTM existing records (campaign, source, medium) - None exist with the name "test" - Go as a visitor on the event…
**Steps to reproduce:** - Install Link Tracker app - Go to Link Tracker > UTMs - Check UTM existing records (campaign, source, medium) - None exist with the name "test" - Go as a visitor on the event website - Open a register event link on the website (e.g. `/event/live-music-festival-4/register`) - Add UTM to the URL to simulate a marketing flow (e.g. `?utm_source=test&utm_medium=test&utm_campaign=test`) - Register to the event - Open the event on backend side - Check attendees and find the new one - Check the marketing section in debug mode - New records were created and added for the UTM values **Issue:** No access rights are checked when making the registration and updating the utm values. When not found they are added to existing ones during the `default_get` with `_find_or_create_record`. `return request.env['event.registration'].sudo().create(registrations_to_create)` This means that public users (visitors of the website) can create unwanted utm records when registering via expired/malformed/altered links. **Fix:** Restrict the issue to non public users for now. Might need to apply access rules and avoid the sudo. opw-4948208
This update resolves an issue where deleting a combo product within a sales order caused errors when modifying other items. The fix ensures all nested combo items are properly fetched and processed, preventing data inconsistencies and ensuring accurate order management. This improves the reliability of sales order modifications.
Original PR description
Currently, an error occurs when a combo product is added to a sales order, and one of its combo items is replaced with another combo product, then the original parent combo product is deleted. Steps…
Currently, an error occurs when a combo product is added to a sales order, and one of its combo items is replaced with another combo product, then the original parent combo product is deleted. Steps to reproduce: - Create a sales order and add a combo product to it. - Modify one of the combo items by replacing it with another combo product. - Delete the original parent combo product from the order lines and save. (Note: Make sure to not save the sale order while doing steps 1 & 2) Error: `ValueError: Expected singleton: sale.order.line()` The error occurs because the parent combo item is deleted, which causes `line.virtual_id` to become False. As a result, the filter [1] returns no matching records, and `ensure_one()` fails by raising a singleton error due to receiving zero records. This happens because the function [2] called from onchange in `sales_order` [3] that performs all the changes only checks the first level of combo items and doesn’t handle cases where those items are also combo products with their own linked items. Solution: - This commit fixes the error by properly fetching all nested combo items in the sales order, ensuring no leftover items from nested combos remain that could cause errors. [1] - https://github.com/odoo/odoo/blob/7bb84621b773cdd7e9984222d61d70d622f8ac43/addons/sale/models/sale_order_line.py#L1567-L1569 [2] - https://github.com/odoo/odoo/blob/57b4056798b9a380027fd3da1c4f3965249a4509/addons/sale/models/sale_order_line.py#L1572-L1591 [3] - https://github.com/odoo/odoo/blob/7bb84621b773cdd7e9984222d61d70d622f8ac43/addons/sale/models/sale_order.py#L922 sentry-6979144433,6653847384 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a crash that occurred when users quickly opened the file viewer multiple times, such as by double-clicking attachments. The fix ensures the system properly manages file viewer instances, preventing errors and improving overall stability. This enhances the user experience by eliminating unexpected application interruptions.
Original PR description
Before this commit, quickly triggering the opening of the file viewer multiple times (e.g. double-click on an attachment) caused a crash. This happens because the `createFileViewer` hook generates a `fileViewerId` on initialization. When `open()` is called, it registers the component using this specific ID. If `open()` is triggered a second time while the component is still registered (or being registered), the registry throws an error because duplicate keys are not allowed. This commit fixes the issue by calling `close()` at the beginning of the `open()` function. This ensures that any existing `FileViewer` instance associated with this hook is removed from the registry before a new one is added. task-5262556 Forward-Port-Of: odoo/odoo#237267
This update fixes an issue where vendor bills for Saudi Arabia companies were displaying negative amounts in the currency conversion section. The fix ensures accurate currency calculations and proper bill formatting when dealing with different currency settings. This improves the reliability of financial reporting for SA clients.
Original PR description
**Steps to reproduce:** - Create a vendor bill with currency not matching the currency of an SA company - Print the bill in the SA EDI specific format (is not shown on preview) or export as PDF **Issue:** Amounts displayed in the currency conversion section of the bill incorrectly show negative values for subtotal and total. **Solution:** The view affecting the bill in question referred to `o.amount_untaxed_signed` and `o.amount_total_signed` where either unsigned `o.amount_untaxed` and `o.amount_total` or `abs(o.amount_[...]_signed)` should be used instead, as in other localizations. opw-5253213 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236654
This update ensures the Sign app meets legal requirements for U.S. companies by notifying users when the sender is based in the U.S. and offering the option to request a paper copy of signed documents. This change enhances compliance and provides a safeguard for our business operations.
Original PR description
Previously, the Sign app did not comply with the ESIGN Act. It now notifies users when the sender company is U.S.-based that they can request a paper copy of a signed document, ensuring ESIGN Act compliance. task-5166918 Forward-Port-Of: odoo/enterprise#97163
This update fixes an issue where the report title for DIAN support documents was incorrectly displayed after the document was stamped by the DIAN. The code was adjusted to ensure the correct 'Documento Soporte' title is used, regardless of DIAN acceptance, improving the accuracy of reports submitted to the tax authority.
Original PR description
Steps: - Create and confirm a vendor bill with 'DIAN Support Documents' journal - Print the PDF — it display 'Documento Soporte' as document title - Send the document to the DIAN and print it again -> the returned PDF with the DIAN stamp now shows 'Factura Electrónica de Venta', it should still be 'Documento Soporte' Cause: In `AccountMove._get_name_invoice_report` we return the name of the report depending on specific conditions, but the order of the conditions prevent to get the right report name as soon as the document has been accepted by DIAN. Fix: Modifying the order of the condition, to redirect to the right report, even when the support document has been accepted by DIAN opw-5119858
This update enhances the reliability of POS certification transactions by automatically retrying failed connections to the payment system (TSS). If the connection is unavailable, users will receive a clear message and can continue working, preventing order processing interruptions. The changes also streamline the transaction flow and remove unnecessary code.
Original PR description
In this task: --------------- - Moved the status code handling logic at proper place for all transactions API responses. - Removed the mixed usage of async/await and .then() by async/await totally in all transaction calls to simplify flow and improve readability. - For 5xx errors (e.g., 503), retry once as they occur when the server is unreachable. Print "TSS not reachable" if even after retries followed by exponential backoff logic. - Guarantee tills remain operational and not blocked even if the TSS is unreachable. task:5051693
This update fixes an issue where scanning a lot multiple times during a barcode picking process would incorrectly create a backorder. The fix ensures that quantity updates are applied correctly to the relevant lines, preventing unnecessary backorders and improving order fulfillment accuracy. This ensures accurate stock management when using barcode scanning for picking.
Original PR description
**Steps to reproduce:** - create a product tracked by lot - create a lot with a quantity of 2 - create a new sale order - add two sale order lines, both for a quantity of 1 of the product - confirm -…
**Steps to reproduce:** - create a product tracked by lot - create a lot with a quantity of 2 - create a new sale order - add two sale order lines, both for a quantity of 1 of the product - confirm - open the picking in barcode - scan the stock location - scan the lot - scan the lot another time - validate **Current behavior:** a backorder is created **Expected behavior:** No back order should be created **Cause of the issue:** After scanning the lot for the first time we have the following situation: two lines : - one with a quantity of 1, qty_done of 1 and reserved_uom_qty of 1 - one with a quantity of 1, qty_done of 0 and reserved_uom_qty of 1 both lined grouped in a parent line with quantity of 1 qty_done of 1 and reserved_uom_qty of 2 All of this is correct. when scanning the lot for the second time: _findLine iterates through the lines to select the right line to use. _findLine calls _lineIsNotComplete on the first line to check if it's complete (this first line is complete). https://github.com/odoo/enterprise/blob/58d55868750b827a9d5ebd8b4ab2cc23c4445eca/stock_barcode/static/src/models/barcode_model.js#L1684 But _lineIsNotComplete will actually do the check on the parent line (which is not complete), so the return value will be true. https://github.com/odoo/enterprise/blob/58d55868750b827a9d5ebd8b4ab2cc23c4445eca/stock_barcode/static/src/models/barcode_picking_model.js#L1338 As a consequence, the quantity will be added in the first line and we will have a qty_done of 2 in the first line and a qty_done of 0 in the second line. Which will lead to the creation of a back order opw
This update ensures invoices exported with foreign VAT numbers correctly reflect the customer's VAT in the PDF invoice (factur-x file). Previously, the VAT number was incorrectly defaulting to the company's VAT. This fix addresses a data accuracy issue, particularly for EU distance sales, ensuring compliance and accurate reporting.
Original PR description
When exporting invoices, the VAT number of the company could be wrong if the fiscal position of the invoice defines a foreign VAT number. In that case we need to use it. Steps to reproduce: 1. Install a European localization (ex: l10n_at) 2. Enable EU Intra-community Distance Selling. You should now have new OSS fiscal positions. Update the one you want to use with a foreign VAT. 3. Create a valid foreign customer. (within the EU) 4. Create and send an invoice for this customer. 5. In the PDF, there is an embedded factur-x file. Notice how the VAT number under the SellerTradeParty corresponds to the company's VAT, not the foreign VAT number defined on the fiscal position. This is more apparent because we use the correct VAT number in the PDF file but not in the corresponding XML. This commit fixes this issue by first checking if we have a foreign VAT number defined on the fiscal position of the invoice. If so, we use it. opw-5182837
This update resolves an issue where a backorder was incorrectly created after a quality control check failed during a picking process. The change ensures that only failed quality checks are accounted for when validating the picking, preventing unnecessary backorders and streamlining inventory management. This improves order fulfillment accuracy.
Original PR description
Scenario: - have 3 steps incoming shipments - create a quality control check for one product - create and confirm a PO for that product and another one - fail the quality check, then validate the picking Result: a backorder will be created for product that was not failed Expected: no backorder is created Why: when we fail a quantity, we set the move as "picked", then when validating the picking, because of this move all move will be set as picked. Fix: add a new condition so a move that is picked and has a failed quality check is not taken into account when deciding if we set all moves as picked when the picking is validated. Note: without the fix, the added test fails because we are showing a confirmation wizard when confirming in backend, or validating in barcode tour. opw-4363773
This update corrects a bug in the demo kiosk's payment process. Previously, the kiosk incorrectly used a 'meal' payment mode, causing the payment screen to be skipped. This change ensures the kiosk always uses the 'each' payment mode when in kiosk mode, resolving this issue and improving the demo experience.
Original PR description
The field `self_ordering_pay_after` should always be `each` when the `self_ordering_mode` is set to `kiosk`. This is enforced in the `write` method. However, the demo kiosk is created with a `self_ordering_pay_after` value of `meal`, until the `write` method is run. This results in behaviour such as the payment screen being skipped when it is not expected to. This commit sets the correct `self_ordering_pay_after` value of `each` when creating the demo kiosk. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures that archived companies are correctly excluded from standard user searches within the Documents app. Previously, administrators could still access documents from these archived companies, creating a potential security and data management issue. The fix explicitly checks for archived status, ensuring normal users don't see archived content while administrators retain access for necessary oversight.
Original PR description
**Steps to reproduce:** - Install Documents app - Create a bunch of companies with their own folders - Archive the companies - Try to open Documents app with admin - Access Error is raised **Issue:** Archived companies not properly taken into account in the search permission. **Fix:** Explicitly check of archived status for the folders company. The behavior is that normal users won't see documents from archived companies but admins still can. From related PR: > Also need to ensure archived companies are not removed from the admin search > domain even if the user has `active_test=False` related: https://github.com/odoo/enterprise/commit/b7e6acba60e50c86627b177a86b357d2bb956cbc opw-5127040
This update fixes a technical error that occurred when users attempted to make partial payments using SEPA QR payments in the Point of Sale system. The issue was caused by a missing JavaScript function, which resulted in a traceback error. The fix restricts the 'Adjust Amount' button to compatible payment methods and adds the necessary JavaScript code to handle the payment adjustment, ensuring a smoother payment experience.
Original PR description
Steps to reproduce: ==================== - Create a SEPA QR payment method (for a BE company). - Create an order and select this payment method. - Manually change the payment amount (partial amount). - Confirm the partial payment. - Click on the "Adjust Amount" button a traceback occurs. Issue: ======= In the XML template, the JS method `sendPaymentAdjust()` was being called, but this method was not defined on the JS side, leading to a traceback when the button was clicked. Fix: ===== - Restricted visibility of the "Adjust Amount" button to payment terminal methods that support adjustment. - Added the missing JS method to handle the call and prevent traceback. Task-5241346
This update resolves an issue where changes to SO quantities within multi-step delivery workflows weren't consistently reflected in the procurement process. Specifically, the system incorrectly only considered the initial quantity when calculating returns, leading to incorrect stock levels. This fix ensures that all quantity changes are properly accounted for, improving inventory accuracy.
Original PR description
Steps to reproduce: - Enable Multi-step routes & set warehouse to 3 steps delivery - Make a SO for 5 qty of a stored product - Validate the PICK - Set the SO line qty to 3 & save - Set the SO line qty to 5 & save Issue: While the first update to 3 creates a return PICK from Packing Zone -> Stock for 2 qty, the second updates does nothing. When checking the outgoing/incoming moves to see which quantity should be set in the procurement, it only considered the outgoing quantity from the first step of the delivery. Which means that the return wasn't taken into account, so since we only compare the new SO line qty to the already moved PICK, there was no difference thus no procurement made. Now, we also consider less strict critera for incoming moves when checking in `strict == False` mode, as this is only used to compute the procurement quantity. opw-5028794 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects an issue where rental order quantities were incorrectly calculated after a return PICK was processed. The fix ensures accurate tracking of product quantities within rental orders, preventing discrepancies in inventory levels. This improves the reliability of rental order management.
Original PR description
Steps to reproduce: - Enable multi-step & Rental transfers - Set warehouse to 2 steps reception/delivery - Create a rental order for a product with a qty of 5 - Process the PICK - Change the quantity in the rental order to 3 and save - Change the quantity back to 5 and save again Issue: The Rental IN picking has now a `product_uom_qty` of 1. This is due to a wrong computation of incoming/outgoing moves when there are returns (e.g. here a return PICK) in the linked pickings. opw-5028794
This fix resolves an issue where the website page URL input field would intermittently freeze or reset during slow network conditions. The update introduces a debouncing mechanism to prevent unnecessary updates and corrects a related display problem when reverting to the original URL, ensuring a smoother user experience.
Original PR description
Scenario: - edit a website page (eg: /test that you create) - go to Site > Properties - have a slow connection and write in field "Page URL" for some seconds Result: the input jitter, if going too…
Scenario: - edit a website page (eg: /test that you create) - go to Site > Properties - have a slow connection and write in field "Page URL" for some seconds Result: the input jitter, if going too fast the text can be removed to get previous version. Secondary issue: if we cancel our change and set back the original URL, the "Redirect Old Url" part is not hidden. Reason: we trigger onchange at each input event, so if we write 20 letters we will possibly still have 20 onchange that are ongoing and will set back older version of the field value. The secondary issue is because we are using a field using useInputField and FieldUrl but we are hacking it to remove the "/" prefix inside the input. So when the invisible modifier is checked, we check eg. "old_url=/test" against "url=test" that are always different. With this fix: Since the triggered onchange were only to update quicker the condition `invisible="old_url == url"`, we trigger them only if that condition will change, and debounce it to prevent the now single onchange of happening in the middle of text input. And for the secondary issue, we add and remove the / when triggering the onchange. opw-4517181
This update corrects a reporting issue where employee leave days were incorrectly included in planned hour calculations within the Timesheets > Planning Analysis report. The fix ensures that leave and holidays are properly excluded, providing more accurate project time tracking. This improves reporting reliability and data accuracy.
Original PR description
**Description** The Timesheet/Planning Analysis report (Timesheets > Planning Analysis) incorrectly calculates planned hours by not excluding employee time-off and public holidays. This results in…
**Description** The Timesheet/Planning Analysis report (Timesheets > Planning Analysis) incorrectly calculates planned hours by not excluding employee time-off and public holidays. This results in leave days being assigned the average daily hours from planning slots and incorrectly attributed to projects. **Steps to Reproduce** 1. Create a planning slot for an employee spanning a full month 2. Add employee time-off (resource.calendar.leaves) during that period 4. Navigate to Timesheets > Timesheets / Planning Analysis report 5. Filter by the employee and date range 6. Observe: Planned hours include leave days, incorrectly attributed to the planning slot's project **Root Cause** The SQL query filters by day of week (weekends) but never queries `resource_calendar_leaves`. While `working_days_count` correctly excludes leaves, the report still generates rows for those leave days and assigns them average hours per day, causing the discrepancy. **Solution** Filter out dates that have employee time-off or public holidays by joining to `resource_calendar_leaves` and excluding matching dates. opw-5027070 Forward-Port-Of: odoo/enterprise#97657
This update fixes an issue where a backorder was incorrectly created after a quality check failed during a picking process. The change prevents moves with failed quality checks from being incorrectly marked as 'picked' when the picking is validated, ensuring accurate inventory management. This improves order fulfillment accuracy.
Original PR description
Scenario: - have 3 steps incoming shipments - create a quality control check for one product - create and confirm a PO for that product and another one - fail the quality check, then validate the picking Result: a backorder will be created for product that was not failed Expected: no backorder is created Why: when we fail a quantity, we set the move as "picked", then when validating the picking, because of this move all move will be set as picked. Fix: add a new condition so a move that is picked and has a failed quality check is not taken into account when deciding if we set all moves as picked when the picking is validated. Note: this commit only extract code from _traverse_path in another method so it can be overrideable. opw-4363773
This update corrects a bug that prevented users from sending E-Factura (SPV) invoices when linking a bank account to an invoice in the Romanian localization (l10n_ro_edi) module. The fix ensures the correct field ('state' for banks) is used, resolving an error related to mismatched data structures. This ensures invoices with E-Factura functionality can be processed correctly.
Original PR description
Same issue already fixed for 18.4+ here: https://github.com/odoo/odoo/pull/231399 Issue: When setting up a payment reference and linking a bank to an invoice, sending an E-Factura (SPV) triggers an exception: state_id not defined for res.bank. Repro Steps: 1- Create invoice for romanian localization. 2- Link payment account to invoice. 3- Add bank to payment account. 4- Confirm and send invoice with "Send E-Factura SPV" checked. Cause: The state field is defined differently for res.bank and res.partner. res.partner uses state_id, while res.bank uses state. The code that retrieves addresses assumes the same field for both, leading to an exception when accessing state for res.bank. Fix: The fix checks the type of the input and selects the appropriate field (state or state_id) accordingly. opw-5362000 (cherry picked from commit a2af8d434bfc7f77008959c8179e8f158bcf9e93) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a display issue where the 'Due Date' column disappeared in the phone view of invoices. The problem stemmed from conflicting CSS styles, which caused incorrect column titles. This ensures the 'Due Date' is consistently visible and correctly labeled across all device views.
Original PR description
****Behavior:****
When switching to phone view, the 'Due Date' column name dissapears but the values stay, which causes every further column of the table to have the wrong title.
The removal of the Due Date column is intended, the issue happens beacause the 't-att-class' specifying the condition to make values red was overriding the initial 'class' specifying the behavior in phone view.
**Steps to reproduce:**
- Create an Invoice for the current user
- Go to Website -> User -> My Account -> Your Invoices
- switch to phone view (reduce to less than 768px if not initially the case)
- You'll see the 'Due Date' column name dissapear and the value shift to the next column name ('Amount Due')
opw-5239794This update fixes an issue where search results on the website were not displaying correctly when the search returned more results than a single page. The system now automatically redirects users to the last page of results, ensuring all relevant information is shown. This improves the user experience and prevents missed opportunities.
Original PR description
Scenario: - enable website_studio - go to contact -> open studio -> website - add a listing and open it on website - go to page 2 and search a specific terms with less than 20 results Result: we see "5 results" in the search bar, but no result are shown and the pager is hidden. Cause: the pager is hidden since there is only one page, and we are currently displaying the records of page 2 that do not exist. Fix: if we detect that we are on a page over the last page, redirect to the last page. Eg. if there is 2 pages and we are in page 500, redirect to page 2. opw-5008556 Forward-Port-Of: odoo/odoo#223447
This update fixes a problem that occurred during Odoo upgrades where new companies were created without a designated subcontracting location. This caused subsequent upgrade steps to fail, leading to instability. The fix ensures locations are correctly created during the upgrade process, improving overall upgrade reliability.
Original PR description
During an upgrade, it could happen that some companies are created before this module is loaded. That means the override of `_create_per_company_locations` is not called and the company is created with an empty `subcontracting_location_id`. That can lead later to issues as that value was not expected to be empty. To reproduce: - On 16, install `onboarding`[^1], `l10n_de`, `mrp_subcontracting` with demo data. - Upgrade to 17. Module `l10n_de` will have created a company with empty subcontracting location. - Upgrade to 18. The upgrade will break during a call to `_create_or_update_sequences_and_picking_types` in `stock` because of the empty value. [^1]: onboarding is necessary to ensure l10n_de is loaded before mrp_subcontracting because of the dependencies. Forward-Port-Of: odoo/odoo#236149