Daily updates from Odoo
Friday, January 2, 2026
31 changes · 19.0
New functionality added to Odoo
This update adds the functionality to generate e-invoices in Croatia, specifically for the MojEracun system. It utilizes a new proxy client to interact with the eRacun network, ensuring compliance with Croatian e-invoice standards. XSD validation is included to guarantee the accuracy of the generated invoices.
Original PR description
Adding e-invoice generation base functionality for Croatia. Implemented as an extension of account_edi_ubl_cii, similar to other localisations using such documents. Adding proxy client for MojEracun sevice provider to send invoiced on the eRacun network. Proxy user is entirely separate from the standard Odoo IAP EDI proxy implementation. Adding UBL 2.1 compliant node `cac:SellerContact` to existing node `cac:AccountingSupplierParty` to be used in Croatian e-invoice XLM generation with the new method chain. XSD validation included in the tests on the client side as there is no corresponding Odoo IAP proxy. task-4925745 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241794 Forward-Port-Of: odoo/odoo#230757
Resolved issues and error corrections
A minor bug was resolved where the 'Consumidor Final' product type was incorrectly selected during refund processing for orders using the Deco Addict partner in the EC module. This fix corrects a typo in the code, ensuring accurate partner selection and proper refund functionality. This ensures correct reporting and transaction processing.
Original PR description
Step to reproduce: - install l10n_ec_edi_pos - start pos and settle order with specific partner(ex. Deco Addict) - process the refund for this order Observation: - on product screen, "Consumidor Final" is selected instead of Deco addict. Cause and Fix: - Fixed a typo: it used `final_consumer_id` instead of `_final_consumer_id` opw-5412346 Forward-Port-Of: odoo/enterprise#103082 Forward-Port-Of: odoo/enterprise#102202
This update fixes an issue where contacts without names and emails appeared as 'Unnamed' in chatter and recipient lists. Now, when a contact lacks this information, the system will automatically display their display name as a fallback, ensuring a more user-friendly experience. This improves usability and prevents confusion when adding contacts.
Original PR description
Steps to reproduce =============== 1. Create a contact of type invoice address without name and email. 2. Go to any app with chatter. 3. Add this user to the recipient ----> Only the blue tick will be visible (recipient name will be empty) After this commit, we will use the display_name as a fallback to show in the chatter. Forward-Port-Of: odoo/odoo#231561 Forward-Port-Of: odoo/odoo#213545
This update fixes a potential error that could occur during Odoo installation, specifically when accessing data within the system. The fix prevents a 'KeyError' by ensuring the necessary data is available before attempting to access it, improving installation stability.
Original PR description
An error occurs when the code attempts to access `leaf_id` in `self.__leaves`, but `leaf_id` does not exist in the dictionary . Error: `KeyError: 35` This might happen during installation when the `leaf_id` is not available in `self.__leaves`. This commit fixes the issue by accessing `leaf_id` from `self.__leaves` only when it is present. sentry-6925358461
This update resolves an issue where test cases for Point of Sale could fail due to a limited local customer database. A new setting allows tests to fetch customers from the server, particularly useful in offline test environments. This ensures more reliable test results and improved stability of the Point of Sale functionality.
Original PR description
before this commit: - By default, clicking on a customer only searched local records. - Since the local cache is limited to 100 customers, with demo data it was possible that the required customer was not found. after this commit: - Added 'pressEnter' boolean parameter to search more to also fetch customers from the server. - The boolean parameter was introduced because some test cases require offline mode where fetching from the server would cause issues. runbot-232714, 232715
This update fixes an issue where changing the work schedule in the salary calculator didn't correctly update employer costs. The fix ensures that the calculator now accurately reflects the selected resource calendar (e.g., 40h/week vs. 20h/week) when calculating employer costs. This improves the accuracy of payroll calculations.
Original PR description
Bug: Changing the work schedule on the salary configurator does not update the employer yearly cost Steps to reproduce: 1- Go to Payroll > Employees > Salary calculator 2- Put a yearly cost of 10000 3- Select the "40h/week calendar" 4- Check the yearly cost 5- Change to "20h/week calendar" Cause of the bug: _get_version inside ContractSalaryOffer would take the default calendar from the version if it exists (in our case it will always be the full time for the simulation employee) Fix done: Keep the condition as it is for normal offers, and for simulation offers change the default to the selected resource calendar task-5431216
This update ensures invoices exported with foreign VAT numbers (used for distance selling) accurately reflect the correct VAT information in the PDF invoice and the underlying XML file. Previously, the company's VAT was used instead, leading to discrepancies. This fix improves invoice accuracy and compliance for EU distance sales.
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.…
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 Forward-Port-Of: odoo/odoo#241436 Forward-Port-Of: odoo/odoo#236692
This update addresses a requirement from the Mexican tax authority (SAT) regarding the format of ‘CuentaPredial’ accounts. The regex pattern has been updated to comply with the SAT’s latest specifications, ensuring accurate tax reporting. This change ensures Odoo continues to meet compliance standards for Mexican businesses.
Original PR description
SAT has declared the restriction [0-9a-zA-Z]{1,150} for CuentaPredial node
Specification: https://www.sat.gob.mx/sitio_internet/cfd/4/cfdv40.xsd
Forward-Port-Of: odoo/enterprise#102981This update fixes an issue where users could inadvertently change product taxes when items were already in their shopping cart. Now, users can still modify product details but tax updates are restricted, ensuring accurate order calculations and preventing inconsistencies between product and order taxes. This improves the reliability of the Point of Sale system.
Original PR description
- When a product is already in the cart, prevent updating its taxes from the frontend product edit popup. This avoids inconsistencies between the product taxes and the taxes applied to the order line. - Now we can still edit other fields of the product. task-id: 4943650 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239867
This update resolves an error that prevented users from opening employee forms within the Point of Sale (POS) frontend. The fix disables the employee selection field on the frontend only, allowing the backend to function correctly where all necessary data is available. This ensures a smoother user experience for POS operations.
Original PR description
Opening employee form in the frontend was throwing an error, since not all thre required assets were available on the PoS frontend. So in this commit 57aba149b6e6927f9055124e58bed03f842329d5, we disabled openening the employee form by making the employee_id field unclikcable, both in forntend and backend!! It was enough however to only macking it unclikcable on the frontend, since it was working fine on the backend where all the required assets were loaded anyway. This commit restores the functionality on the backend, but overriding the `Many2OneField` used by the `employee_id`, and making it unclickable only on the frontned. opw-5252486 Forward-Port-Of: odoo/odoo#241100
This update resolves an issue where the invite dialog remained open after creating a group chat from a direct message. Now, the dialog automatically closes, providing a smoother and less confusing user experience. This improves usability and prevents unnecessary open dialogs.
Original PR description
**Description of the issue this PR addresses:** ------------------------------------------------ When creating a group chat from a Direct Message via the invite dialog, the invite dialog remained open after the group chat was created. This resulted in a confusing user experience. **Current behavior before PR:** --------------------------------- - The invite dialog stays open after creating a group chat **Desired behavior after PR is merged:** ----------------------------------------- - The invite dialog closes after creating the group chat - No extra dialogs remain open **Task:** 5440535 --- I confirm I have signed the CLA and read the PR guidelines at https://www.odoo.com/submit-pr
This update fixes a formatting issue in notifications where a period was incorrectly separating the title and message, leading to an awkward display. The fix removes the unnecessary exclamation mark, improving the notification's readability. Additionally, the translation of 'Done' has been added for internationalization.
Original PR description
Issue: a notification used the title field with "Done!" and a message. The issue is that a title and message are separated by a period, resulting in "Done!. rest of the message." Solution: remove the exclamation mark Note: Added translation of "Done" Task-5420416
This update resolves an issue where copying and pasting content from the Knowledge editor resulted in a loss of plain text formatting. The fix restores the ability to paste text directly into other applications, ensuring users can accurately copy and paste content without formatting changes. This improves the usability of the Knowledge feature.
Original PR description
Since [1] when `vnd.odoo.odoo-editor` was added to the `HtmlViewer` clipboard, the `text/plain` mimetype was lost. This commit restores the plain text version of the clipboard. Steps to reproduce: - In knowledge, lock a page - Select some content - Copy - Paste into a plain text editor => No content was pasted [1]: https://github.com/odoo/odoo/commit/62a7c50b434e3f47ad58e20e96970cbd90b979b6 task-5449435 Forward-Port-Of: odoo/odoo#241676 Forward-Port-Of: odoo/odoo#241642
This update corrects an issue where product names were duplicated on delivery slips when a kit's component lacked a description. The fix ensures that product names appear only once on delivery slips, improving the accuracy and clarity of shipping documents. This resolves a problem that could lead to confusion for customers and warehouse staff.
Original PR description
When creating a delivery slip, if the product sold is a kit and it's component doesn't have a description, the name will be repeated. Steps to reproduce: ------------------- * Create a product A with…
When creating a delivery slip, if the product sold is a kit and it's component doesn't have a description, the name will be repeated. Steps to reproduce: ------------------- * Create a product A with a bom of type kit * Add a product "comp" in the bom (don't give it a description) * Create a sales order with the product A and confirm it * Go on the delivery and create a delivery slip -> Issue, the name of the product "comp" appears twice. Observation: ------------- The name is added in description_picking field, since it is considered that the fallback for the description for outgoing deliveries should be display_name: https://github.com/odoo/odoo/blob/584f94e3246b6b59641bf83d4e707f2e872bc1e8/addons/stock/models/product.py#L293-L301 In _compute_description_picking, information about the bom will be added : https://github.com/odoo/odoo/blob/08c5fbbb5bc44c4810cd07188b29090c3060e14f/addons/mrp/models/stock_move.py#L235-L236 This causes the issue because the filter to prevent repeating the name on the delivery slip is implemented directly in the XML: https://github.com/odoo/odoo/blob/08c5fbbb5bc44c4810cd07188b29090c3060e14f/addons/stock/report/report_deliveryslip.xml#L83-L85 However, since we have added elements to the description (the bom information), this filter will not be applied, leading to the repeated name. opw-5265906 Forward-Port-Of: odoo/odoo#236948
This update fixes an issue where customers weren't correctly returned to the splitting order screen after making a payment when automatic receipt printing and skipping the preview screen were enabled. Now, the system seamlessly redirects to the splitting workflow, ensuring a smoother and more intuitive customer experience for multi-item orders. This enhancement improves order management and reduces potential customer frustration.
Original PR description
Ensure FeedbackScreen uses a unified `goNext()` flow and restore the splitting workflow when `Automatic receipt printing` + `Skip preview screen` are enabled. Paying part of a splitted orders now correctly return to the splitting screen instead of the floor plan by delegating the logic to `pos.continueSplitting()` / `pos.isContinueSplitting()` (shared with ReceiptScreen). task-id: 5405595 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures that Point of Sale line merges are only successful when the discount and unit price are identical. Previously, merging was inconsistent, leading to potential errors. This change provides a more reliable and predictable process for updating order lines.
Original PR description
Only allow merging lines if they have the same discount and unit price. Before this commit, you were able to merge lines with different discounts or unit prices only if the source order contained the line with the discount/price change. It was not working the other way which was inconsistent. task-id: 5189949 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a bug that prevented users from successfully paying invoices when an invoice line lacked a due date. The fix ensures that the system handles invoices with missing due dates correctly, preventing a 'TypeError' and allowing payments to proceed smoothly. This improves the reliability of the invoicing process.
Original PR description
Currently, an error occurs when a user attempts to pay an invoice. **Steps to Reproduce ([Video](https://drive.google.com/file/d/1onmo1mxeZgH6fkQOoueGCgC67HPjYHX6/view)):** - Install the `Accounting`…
Currently, an error occurs when a user attempts to pay an invoice. **Steps to Reproduce ([Video](https://drive.google.com/file/d/1onmo1mxeZgH6fkQOoueGCgC67HPjYHX6/view)):** - Install the `Accounting` module. - Go to `Payment Terms` and create `a new Payment Term` with at `least two Due Term lines`. - Go to `Invoices` and `create a new Invoice`. - Add one invoice line and set the `Payment Term` to the `newly created payment term`. - In the `Journal Items` tab > `Enable the Due Date` column (optional hidden). - From the two `Receivable journal items`, remove the `Due Date` from one of the `receivable lines`. - Now `Confirm the invoice` and `Click on Pay`. **Error:** `TypeError: '<' not supported between instances of 'datetime.date' and 'bool'` **Cause:** This error occurs when the user clicks Pay, than it going to calculate the total amount to pay from here [1]. If the payment term has more than one term line, it creates more than one receivable invoice line, and the receivable invoice lines are sorted from here [2]. When two or more invoice lines have the same move_id, they are sorted based on the due date. However, if one of the receivable lines does not have a due date, the error is raised. Similarly, as shown in [3], when the system retrieves the installment data, it sorts the lines based on the due date and raises the same error. **Fix:** This commit ensures that when there is no due date on any receivable invoice line and two lines belong to the same invoice, the comparison uses the maximum date as like here [4] and places that line at the end for that invoice, thereby maintaining the correct flow. The same fix is applied while retrieving the installment data, as described above. [1]: https://github.com/odoo/odoo/blob/92a9f6b19670685dfe9fb1714bf01449768e5f62/addons/account/wizard/account_payment_register.py#L703 [2]- https://github.com/odoo/odoo/blob/92a9f6b19670685dfe9fb1714bf01449768e5f62/addons/account/wizard/account_payment_register.py#L635 [3]: https://github.com/odoo/odoo/blob/92a9f6b19670685dfe9fb1714bf01449768e5f62/addons/account/models/account_move_line.py#L3305 [4]: https://github.com/odoo/odoo/blob/92a9f6b19670685dfe9fb1714bf01449768e5f62/addons/account/models/account_move_line.py#L522 sentry-713241246 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241744 Forward-Port-Of: odoo/odoo#241060
This update resolves an issue where unnecessary dialogs appeared during One-click Payment with preset options in the Point of Sale system. The fix prevents the creation of new orders during validation, ensuring a smoother payment process for customers. It also corrects a behavior where the Delivery preset was incorrectly removed.
Original PR description
steps: - Configure a default preset as Delivery or Takeout and enable One-click Payment - Open the POS restaurant. - Open any table and add a product. - Click the One-click payment method. issue: - Unnecessary dialogs appear on the ReceiptScreen (e.g., customer selection or time-slot selection), followed by traceback. reason: - The order is validated on the ProductScreen during One-click Payment and ProductScreen creates new draft order. fix: - After this commit, new order will not be created on the ProductScreen with One-click Payment.. - If validation fails (e.g., an RPC error), it will redirected back to the previous screen. - In case of Delivery preset, on discard do not remove Delivery preset. task-5391389
This update fixes a bug that caused calls to unexpectedly end when a user joined from another browser tab. The change ensures stability and prevents crashes during multi-tab call scenarios, improving the overall meeting experience for users. This resolves an issue identified during testing.
Original PR description
**Steps to reproduce:** - Start a meeting with user A - Share the invitation link with user B - Login with user B and join the call - Open another browser tab/window with the same user B - Join the same call in that tab using the invitation link - The call ends for that user as the RTC session is terminated - **_TAB1_**: join the call again - **_TAB2_**: error **Current behavior before PR:** When the same user joined the same call from another tab or during RTC renegotiation, selfSession could temporarily be undefined. **Desired behavior after PR is merged:** This PR ensures that no crash happens when dealing with the RTC Session in a `multi-tab` scenario. task-[5263097](https://www.odoo.com/odoo/project/1519/tasks/5263097) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241578 Forward-Port-Of: odoo/odoo#240881
This update fixes a security vulnerability where portal users with existing invoices or sales orders could modify their country information. Previously, this was restricted via another route, but not the standard profile edit page. Now, portal users with active orders will be prevented from changing their country details, ensuring data integrity.
Original PR description
Steps to reproduce: 1. Install website_forum, website_sale. 2. Confirm a Sale Order for a portal user. 3. Log in as the portal user, go to My Account -> Edit Information. 4. Country is in readonly. 5. Go to Forum -> Profile -> Edit 6. Edit the country 7. Nothing stops the user from doing so. --- Description of the issue this commit addresses: If there is already an invoice or a sale order for a partner, we restrict the edition of some of its values to system administrators. This is already enforced on the edition of the profile via /my/home route but not via the /profile/user. --- Desired behavior after the commit is merged: When an invoice or a sale order is set for a partner with portal access, he can't edit his country via the /profile/user route anymore. --- task-5331916 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239789 Forward-Port-Of: odoo/odoo#237781
This update ensures the live chat info panel remembers your preference (open or closed) across different chat sessions. Previously, users had to manually adjust the panel each time they switched chats. This change improves user convenience and a smoother experience.
Original PR description
**Purpose of this PR:** Previously, the livechat info panel would always open by default when switching between chats, regardless of the user's preference. This required users to manually close the panel repeatedly. This commit persists the panel's toggle state, so the panel remains open or closed based on the user's last choice across all livechat sessions. Task-5291258 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures that changes to product descriptions within Odoo are correctly reflected in the UrbanPiper menu synchronization process. Previously, updates to product descriptions weren't consistently propagated to UrbanPiper, leading to outdated information. This fix resolves that issue, maintaining accurate product details for UrbanPiper.
Original PR description
Before this commit: --- When we sync the menu with the product description and later update the product description, re-syncing the menu does not update the product description in UrbanPiper. After this commit: --- This fix ensures that any change in the product description is properly sent to UrbanPiper during menu synchronization. task-5439271 Forward-Port-Of: odoo/enterprise#102946 Forward-Port-Of: odoo/enterprise#102846
This update resolves a bug that caused the Odoo mobile app to crash when users joined meetings via invitation links. The fix ensures the app handles access to meeting messages safely, preventing UI errors and improving the mobile meeting experience. This enhances stability for users joining meetings from their mobile devices.
Original PR description
**Steps to Reproduce:** - Log in with User A. - Start a meeting. - Send the invitation link to User B. - Log in as User B/Guest and join the call from a mobile device. Before this PR, joining the call from the public invitation page on mobile could crash due to accessing undefined inbox messages. This PR fixes the issue by safely handling the messages access, ensuring the UI no longer crashes in this scenario. task-[5428778](https://www.odoo.com/odoo/project/1519/tasks/5428778) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where joining a call from an invitation didn't automatically open the related chat thread. Now, clicking 'Join Call' opens the correct thread in both the Discuss app and chat window, and clicking the invitation avatar focuses the composer within the chat window. This improves the user experience for call participation.
Original PR description
**Description of the issue this PR addresses:** Clicking on join call does not open the corresponding thread, neither in the discuss app nor in the chat window. **Steps to Reproduce:** - Log in with…
**Description of the issue this PR addresses:** Clicking on join call does not open the corresponding thread, neither in the discuss app nor in the chat window. **Steps to Reproduce:** - Log in with Admin and Demo user - From the Demo side, open the chat window/discuss app and call Mitchell Admin - On the Admin Side, click Join the call from the call invitation preview - Chatwindow/Discuss app does not open the corresponding thread automatically Additionally, clicking on the `invitation avatar` does not focuses the composer as expected in the chat window. **Desired behavior after PR is merged:** - Clicking join call now opens the corresponding thread in both discuss and chat window, with the composer focused in the `chat window`. - Clicking the avatar on a call invitation now focuses the composer when opened inside a chat window. task-[5367781](https://www.odoo.com/odoo/project/1519/tasks/5367781) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update enhances the user experience within Odoo's discuss calls by adding a subtle hover effect to the 'Picture-in-picture' and 'Fullscreen' buttons. Previously, these buttons lacked visual feedback, making them difficult to click accurately. This small change improves usability and reduces user frustration.
Original PR description
Before this commit, when in a discuss call, the buttons "Picture-in-picture" and "Fullscreen" in the bottom right had no mouse hover effect. As these buttons are visually just icons, the lack of hover effect makes it hard to tell which button is hovered thus making the click harder than it should. This commit reduces slightly the opacity of items, so that on mouse hover the opacity is removed. This acts as a small hover effect that makes it easier to click on these buttons reliably. 
This update resolves an issue where submitting a forum post with an empty description would trigger a validation error. The fix resets a key property to ensure the textarea is correctly populated before submission, preventing the error and allowing users to successfully post questions.
Original PR description
Steps to reproduce =================== 1. Go to Forum. 2. Select any forum and Click on New Post. 3. Add a title and keep description empty. 4. Post Your Question. => The title is marked as invalid.…
Steps to reproduce =================== 1. Go to Forum. 2. Select any forum and Click on New Post. 3. Add a title and keep description empty. 4. Post Your Question. => The title is marked as invalid. 5. Now add a description. 6. Post Your Question. => Error page: Bad Request 7. Go back or open any forum page => Will receive error on each page until you clear sessionStorage Technical ============ The commit [1] updates the website forum interaction to use the html_editor `Wysiwyg` instead of `loadWysiwygFromTextarea`. The textarea is hidden and populated through `WebsiteForumWysiwyg`. When the description is left empty and the form is submitted, `WebsiteForumWysiwyg.onSubmitButtonClick` populates empty content into the textarea, sets the `readyToSubmit` property to true, and resubmits the form to trigger the interaction logic. The editor container is then validated as empty, marked invalid, and the submission is prevented. After the description is refilled and the form is submitted again, the `readyToSubmit` is already true, causing an early return from `onSubmitButtonClick`. This skips populating the textarea from the editor container. Since validation is performed against the editor container, the form is submitted successfully. As we use form action that relies on named inputs, including the hidden textarea, the submitted payload contains an empty textarea value. As a result, the request fails with a bad request error due to empty content. [1] https://github.com/odoo/odoo/commit/6bd3d1b557f82475f0a78ef8ff0529528e5f2b29 After this commit ====================== This commit fix the issue by resetting `readyToSubmit` property to false. Task-5400394
This update fixes a technical issue in the Point of Sale module that was causing errors when displaying product prices. The fix involves adding a default value to the computed field, ensuring the system correctly calculates and displays prices. This ensures consistent and accurate pricing information for Point of Sale transactions.
Original PR description
**Step to reproduce:** 1. Install pos_pricer module: 2. Open the Point of Sale app and create a product. 3. Go to the Product Variants menu. 4. Open that product. 5. Activate developer mode. 6. Click…
**Step to reproduce:** 1. Install pos_pricer module: 2. Open the Point of Sale app and create a product. 3. Go to the Product Variants menu. 4. Open that product. 5. Activate developer mode. 6. Click on the Bug icon (top-right corner). 7. Click on Data. **Issue:** A traceback is raised with the error: `Compute method failed to assign product.product(191,).pricer_display_price` The method `_compute_pricer_display_price` was removed in this commit https://github.com/odoo/enterprise/commit/87b1672ac7c1d27cd9eab05138b78f6a9439fea7 , and was reintroduced in a later commit https://github.com/odoo/enterprise/commit/4575d3dfdbd0ccd9bf57bddbd35a89bd47c48798 to avoid the AttributeError. **Cause:** The computed field `pricer_display_price` is a type Char and and is non-stored was not being assigned a value inside the compute method. So ORM requires that records to be assigned a value in a compute method. **Solution:** To fix this, assign a default value to `pricer_display_price` inside the compute method to prevent the error. opw-4887318 Forward-Port-Of: odoo/enterprise#90676 Forward-Port-Of: odoo/enterprise#88517
This update fixes an issue where navigation arrows in product snippets displayed incorrectly when the website was configured for Right-to-Left languages like Arabic. The fix ensures that these arrows align correctly, providing a consistent and user-friendly experience for all website visitors regardless of their language settings. This improves usability for a global customer base.
Original PR description
Steps to reproduce: =================== - Install an RTL language (e.g., Arabic) on the website. - Go to website & Edit mode - Drop product snippet `s_dynamic_snippet_products`. ->When the website is…
Steps to reproduce: =================== - Install an RTL language (e.g., Arabic) on the website. - Go to website & Edit mode - Drop product snippet `s_dynamic_snippet_products`. ->When the website is viewed in an RTL language, the navigation arrows in the snippet are displayed in the wrong direction. Cause: ====== A previous commit [1] applied a specific `transform` to arrows to adjust their visual style, By defining a new transformation for the snippet, the default generic transform for RTL language was overwritten. https://github.com/odoo/odoo/blob/e0a5e68e861363378ecd184711bc9356fe0376ff/addons/web/static/lib/odoo_ui_icons/style.css#L105 Consequently, the arrows lost their RTL-specific orientation. Solution: ========= The CSS has been updated to explicitly handle the RTL context. [1]: https://github.com/odoo/odoo/commit/d9ea6d1ebabf64dac434e0d2a7c2535bbfff5c71 opw-5440273 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update optimizes how the Point of Sale system calculates product prices for paid orders. Previously, the system unnecessarily recomputed prices, leading to wasted processing time. This change improves the efficiency of the POS system and reduces unnecessary server load.
Original PR description
Before this commit, the POS system would recompute product prices even for orders that were already paid. This led to unnecessary calculations. opw-5263663 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a typo in the spreadsheet dashboard name and updates the labels for key scorecards to use more accurate terminology ('Avg revenue per guest' and 'Avg revenue per order'). These changes improve the dashboard's readability and provide more precise data insights for restaurant managers.
Original PR description
Desired behavior after PR is merged:
- Fix typo in first sheet name: 'Dahsboard' -> 'Dashboard'.
- Rename scorecards to reflect average values:
- 'Total revenue per guest' -> 'Avg revenue per guest'.
- 'Total revenue per order' -> 'Avg revenue per order'.
Task: [5447108](https://www.odoo.com/odoo/project/2328/tasks/5447108)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#241838
Forward-Port-Of: odoo/odoo#241598This update resolves a technical issue where a key module, l10n_br_edi_sale_fiscal_reform, wasn't explicitly linked to another important module, l10n_br_avatax_sale. This change ensures proper functionality and stability of the Brazilian e-commerce reporting features. The fix was automatically triggered by our testing system.
Original PR description
l10n_br_edi_sale_fiscal_reform depends on l10n_br_edi_sale, which depends on both l10n_br_edi and sale, but not explicitly on l10n_br_avatax_sale. runbot-exception-762 [runbot-error-237690](https://runbot.odoo.com/odoo/runbot.build.error/237690) Forward-Port-Of: odoo/enterprise#103117