Daily updates from Odoo
Wednesday, March 11, 2026
221 changes
27 changes
New functionality added to Odoo
This update introduces support for accepting payments via MPESA, a popular mobile money service in Kenya, through two payment methods: Express and Lipa Na Mpesa. This allows businesses to offer a convenient payment option to customers, streamlining transactions and expanding market reach.
Original PR description
This pr introduces MPesa payment methods using Safaricom APIs for Kenya. There are two types of payment methods : - Mpesa Express: This is implemented with the M-Pesa Express API. It's the Merchant…
This pr introduces MPesa payment methods using Safaricom APIs for Kenya. There are two types of payment methods : - Mpesa Express: This is implemented with the M-Pesa Express API. It's the Merchant Initiated payment method. The merchant create a payment method M-Pesa Express with Safaricom payment provider. The merchant is allowed to ask for payment through the API with an USSD prompt on the customer phone number. Customer enters the PIN and the API call the callback of the POS to reconcile transaction with order. (https://daraja.safaricom.co.ke/dashboard/apis?api=MpesaExpressSimulate) - Lipa Na Mpesa: This is implemented with the Customer To Business (C2B) API. This payment method is different from the first one. It is a Merchant-Initiated payment method. The POS registers callback URLs through the register URL. The POS listen on its callbacks. Customer sends a payment through his Safaricom or MPesa application with some informations of the business. When a transaction is catch in the callback, POS displays it. The cashier needs, manually, to reconcile it with the current order. To reconcile, cashier see a popup with every transaction done on this business account number. (https://daraja.safaricom.co.ke/dashboard/apis?api=CustomerToBusiness) Dynamic QR Code API is also implemented to allow customers to scan the QR Code in the official Safaricom application and send the payment easily without errors of amount or till number. (https://daraja.safaricom.co.ke/dashboard/apis?api=DynamicQRCode) Note : The problem with this payment method is that there is two steps. The first step is a "Verification" step, which is optional. Businesses needs to manually sends an email to Safaricom to allows them to add this step. This step is useful because it is used to accept or reject a transaction before charging the customer. But, in reality, not all of the businesses ask Safaricom to add this step. So, we don't configure it for the moment. The second step is the "Confirmation" step, before this step, the customer is already charged. The API sends transaction data to the POS, we display it in the POS to allow cashier to reconcile the current order with a transaction. Requirements : If you want to test this API, https is needed and a valid kenyan (+254) phone number is also needed. But, you can simulate requests in the Daraja Portal. (https://daraja.safaricom.co.ke/dashboard/apis) task: 5886047 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247615
Resolved issues and error corrections
This update clarifies Odoo's logging system by removing the use of error and warning colors for process IDs (PIDs). This change improves readability and prevents users from misinterpreting log messages, leading to a more straightforward understanding of system activity.
Original PR description
At first glance people think there is a problem when the PID is colored using the same color logging.ERROR and logging.WARNING. For clarity we drop those two colors. There now are 11 (still prime) available colors.
This update fixes a visual issue where 'looking for help' conversations with the user as a member had a distracting purple overlay, obscuring key information like the country flag and conversation name. By increasing the 'z-index', the overlay is now correctly positioned, ensuring all conversation details are clearly visible to users.
Original PR description
Before this commit, looking for help conversations with self user as member had poor readability on country flag, conversation name and description, and the language code. This happens because when a looking for help conversation has self member, there's a hatched purple background. This background is done with an overlay over the whole item, and some items were below it like country flag and conversation name, reducing clarity of these items. This commit fixes the issue with increased `z-index` just to be on top of this overlay. Before / After (see text and country flag with hatched pattern / purple tint that comes from overlay) <img width="878" height="503" alt="Screenshot 2026-03-10 at 15 36 20" src="https://github.com/user-attachments/assets/fa5764e9-436b-48bc-b920-20064b176e68" /> <img width="888" height="493" alt="Screenshot 2026-03-10 at 15 36 39" src="https://github.com/user-attachments/assets/1aadd167-9449-433c-bc5f-1505abe02a77" />
This update corrects an issue where the Partner Ledger incorrectly displayed residual amounts in the company's currency. The fix ensures that currency values are accurately shown based on the partner's currency, improving reporting accuracy. Additionally, a bug preventing the debug popover from functioning has been resolved.
Original PR description
# [FIX] account_reports: Partner Ledger residual amount currency wrong In the partner ledger, the residual amount currency had all it's results set to the currency from the company. Here, we do the same as from amount currency and set it to it's currency and aggregate it if all the currency from the partner / all the partners is the same currency. # [FIX] account_reports: Partner ledger debug popover not working To reproduce: - Open the partner ledger - Active the developper mode - click on the debug button on the line Open Items
This pull request reverts a recent change to the web_studio test suite. The previous modification incorrectly checked for a specific element count (exactly 3 times) instead of verifying it appears at least 3 times. This reversion ensures the test accurately reflects the expected behavior of the web_studio UI, preventing potential issues during development.
Original PR description
Revert modifications made in https://github.com/odoo/odoo/pull/245680 With that modification, we checked that element is exactly 3 times, But this is not the same to check that the element is at least preset 3 times.. Backport of odoo/enterprise#108294
This update resolves an error that occurred when opening the shop page, specifically when products had no variants configured. The fix ensures that the 'Add to Cart' button is correctly displayed or hidden based on product availability, preventing a technical error. This improves the overall stability and usability of the shop page.
Original PR description
Currently, an error occurs when the user opens the shop page. **Steps to Reproduce:** - Install `website_sale_stock` module. - Go to `Settings` and enable `Product Variants`. - Create a `product…
Currently, an error occurs when the user opens the shop page. **Steps to Reproduce:** - Install `website_sale_stock` module. - Go to `Settings` and enable `Product Variants`. - Create a `product template` of type `Goods`. - Enable `Track Inventory`. - In the `Sales tab`, disable `Sell when Out-of-Stock`. - In the `Attributes & Variants` tab, add one attribute with two values and save. - Delete all variants using the `Variants smart button` or from Inventory > Products > Product Variants. - Go to `Website` > `Shop`. **Error:** `ValueError: Expected singleton: product.product()` After [this commit], when opening the shop page, it calculates the quick add availability [1] for every product. It checks whether the product is sold out [2] to determine whether the quick add to cart button should be displayed or not. Since the product has no variants, it raises the error here [3]. Before 19.0, the quick add availability was calculated if the product had variants [4]. This commit ensures that if a product has no variants, it is treated as sold out. As a result, the quick add to cart button is not shown, as in the previous version. [this commit]: https://github.com/odoo/odoo/commit/43d5226b500d64c3902eb1528e5d8e461766982c [1]: https://github.com/odoo/odoo/blob/aeaace7c70b7ac3db68f188c9c517f1ff849e55d/addons/website_sale_stock/models/product_template.py#L35-L39 [2]: https://github.com/odoo/odoo/blob/aeaace7c70b7ac3db68f188c9c517f1ff849e55d/addons/website_sale_stock/models/product_template.py#L33 [3]: https://github.com/odoo/odoo/blob/aeaace7c70b7ac3db68f188c9c517f1ff849e55d/addons/website_sale_stock/models/product_product.py#L41 [4]: https://github.com/odoo/odoo/blob/18d9baa690d6b103fbf8dbe875b3e00b056dd873/addons/website_sale/views/templates.xml#L400-L403 sentry-7287364112 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250373
This update fixes a bug that caused errors in logs when using computed fields in domain definitions for automation rules. The change ensures that domain validations are properly executed, preventing unexpected behavior and improving data integrity. This primarily impacts the CRM and Email Marketing modules.
Original PR description
An error is generated in the logs when a user opens a record after saving a computed field used in the domain, as demonstrated in the steps below. Step1: - install `crm` and `base_automation` -…
An error is generated in the logs when a user opens a record after saving a computed field used in the domain, as demonstrated in the steps below.
Step1:
- install `crm` and `base_automation`
- Create a new automation rule for the `Activity` module and set the `Apply On` domain as below: `[("res_model", "=", "crm.lead"), ("state","=","done")]`
- An error will occur in the log when you open this record.
Step 2:
- Install `mass_mailing`
- Go to Email Marketing and create a record as below data
- Recipients: `Contact`
- Set domain as `[("vat_label", "=", 'test')]`
- An error will occur in the log when user open this record.
This issue occurred because the recently refactored commit [1] used `validate` of Domain for the domain instead of `search_count`. The `validate` method only checks the structure of the domain and does not verify whether the domain is actually executed or not.
This commit fixes the issue by reverting commit [1], restoring the previous behavior where the domain is evaluated using `search_count`.
[1]: https://github.com/odoo/odoo/commit/a1434c32e9f4dd226d512677fd96e3051b908d8b
sentry-7004977102
Forward-Port-Of: odoo/odoo#252379This update fixes a bug related to member removal confirmation messages and ensures that archived users cannot perform member removal actions. It improves the user experience by providing clearer notifications and enhances security by restricting access for inactive users. This change was part of a larger effort to improve stability and security.
Original PR description
*=im_livechat, test_discuss_full Purpose the commit: - To update the string the member removal confirmation dialog. - Restrict the actions usage for archived users. task-5944930 part of-5867464 Forward-Port-Of: odoo/odoo#248998
This update fixes a visual issue on the mobile POS tablet where the pill selection popup was positioned incorrectly, leading to a confusing user experience. The change adjusts the popup's starting position to the bottom of the screen, resulting in a cleaner and more intuitive interface for tablet users. This ensures a consistent and user-friendly experience.
Original PR description
Small modification of the pills selection popup in order to make it starting at the bottom of the screen and not with a fixed size, which caused in certain cases, weird UI. task: 5952769 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a restriction preventing users without the necessary HR group from accessing bank account information. Previously, accessing a bank account triggered an error, impacting data visibility. This fix ensures all users can manage bank accounts correctly.
Original PR description
The field `employee_salary_amount_is_percentage` is computed, but the computation[^1] relies on `hr_employee.salary_distribution`, a field restricted[^2] to members of `hr.group_hr_user`. If you try…
The field `employee_salary_amount_is_percentage` is computed, but the computation[^1] relies on `hr_employee.salary_distribution`, a field restricted[^2] to members of `hr.group_hr_user`. If you try to check a bank account without an hr group, you will get an access error: ``` odoo.exceptions.AccessError: You do not have enough rights to access the field "salary_distribution" on Employee (hr.employee). Please contact your system administrator. Operation: read User: 21 Groups: allowed for groups 'Employees / Officer: Manage all employees' ``` This also happens during the mock crawl test of upgrades if the admin lacks the group. To reproduce in standard: - Install contacts and hr. - Use a user without hr permissions. - Try to create a new bank account. [^1]:https://github.com/odoo/odoo/blob/57573994313988837d89329d77ab1def63a8cfdd/addons/hr/models/res_partner_bank.py#L26 [^2]:https://github.com/odoo/odoo/blob/57573994313988837d89329d77ab1def63a8cfdd/addons/hr/models/hr_employee.py#L147 --- I've also added another commit to make the percentage symbol stick to the salary amount. Before: <img width="366" height="38" alt="image" src="https://github.com/user-attachments/assets/ef890852-50ca-40b1-8c09-07c4aa2d330d" /> After: <img width="219" height="35" alt="image" src="https://github.com/user-attachments/assets/88e4a6c4-bc3f-483e-97f9-3080c6aa85c9" /> I know the number is not formated correctly but I don't think I can do more just from the view. Forward-Port-Of: odoo/odoo#239298
This update resolves a recurring issue causing nightly builds to fail due to timeouts. The changes include improvements to emoji loading, debugging tools, and asset caching to enhance stability and test efficiency. These updates ensure smoother and more reliable nightly builds.
Original PR description
Community: https://github.com/odoo/enterprise/pull/107499 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update addresses a recurring issue causing nightly timeouts within the Odoo Enterprise system. The team reorganized code to improve asset caching, allowing for more reliable testing and ultimately a more stable system. This change enhances the overall performance and stability of the Enterprise edition.
Original PR description
Enterprise: https://github.com/odoo/odoo/pull/248815
This update resolves an issue where Dutch tax returns appeared to be submitted but weren't actually sending data to the tax authorities. The fix ensures that the XBRL export is triggered when a Dutch tax return is submitted, accurately reflecting the status in the system and ensuring compliance.
Original PR description
Commit 647699eeb4b8a1cc37ca074fa57844871c5086c1 introduced account returns to the Dutch localization. However, the "Submit" action only updated the internal record state without triggering the actual XBRL export to the Dutch tax authorities. This led to a mismatch where the UI displayed "Submitted" despite no data being transmitted. This commit fixes the flow by: - Overriding `action_submit` on the account return to launch the XBRL wizard when the return type is a Dutch tax return. - Ensuring the SBR tax report wizard calls `_proceed_with_submission` on the associated account return to correctly finalize the process (including locking the period and generating the closing entry). opw-5974711 Forward-Port-Of: odoo/enterprise#110015 Forward-Port-Of: odoo/enterprise#109691
This update resolves a technical issue preventing the Quote Builder from generating PDF quotes correctly. The change ensures compatibility with a newer version of the PDF library, specifically addressing a requirement for 'Fields' within AcroForm structures. This ensures Quote Builder continues to function as expected.
Original PR description
Issue: --- Due to this issue, generating PDF Quote using Quote Builder leads to traceback. Steps to reproduce: --- 1- Using a python 3.13 env, install requirements.txt. (You could instead uninstall…
Issue: --- Due to this issue, generating PDF Quote using Quote Builder leads to traceback. Steps to reproduce: --- 1- Using a python 3.13 env, install requirements.txt. (You could instead uninstall pypdf2 and install pypdf==5.4.0) 2- Enable Quote Builder. 3- Create a SO and in quite builder tab, select a document. 4- Print -> PDF Quote. This will lead to traceback. Cause: --- There is a requirement change on https://github.com/odoo/odoo/pull/233600, as pypdf2 will not be supported in future. Instead we use pypdf==5.4.0. In pypdf 5.4.0 it is required to have `Fields` present in `Acro Form` (introduced in [1] v3.13.0): https://github.com/py-pdf/pypdf/blame/f20954f2241640feb484800e191373f8fbdfa44b/pypdf/_writer.py#L1060-L1061 FIX: --- We could add an empty `fields` dictionary when it's not present. The entry should be `/Fields`: https://github.com/py-pdf/pypdf/blob/f20954f2241640feb484800e191373f8fbdfa44b/pypdf/constants.py#L362-L370 Note: --- In this fix, we replace `is_upper_version_pypdf2` with specific version comparison. To be precise `getNumPages` is depreciated in version 1.28.0 [2]. References: --- [1]- https://github.com/py-pdf/pypdf/commit/dcf997a028e993b215457c5629cb4e78186e11c0 [2]- https://github.com/py-pdf/pypdf/blob/3ab1581a51f446f86dd445662005f8747941c2b6/pypdf/_writer.py#L507-L514 opw-5784464 Forward-Port-Of: odoo/odoo#250329
This update resolves an issue where large file uploads to forms would fail, resulting in error messages. The fix adjusts how the system handles request body sizes, ensuring compatibility with our web server's limits. This prevents form saving failures and improves the user experience when uploading files.
Original PR description
# How to reproduce - A reverse proxy needs to be set up between the client and the backend (for localhost, you can use nginx) - This reverse proxy needs to have a request max body size set below…
# How to reproduce - A reverse proxy needs to be set up between the client and the backend (for localhost, you can use nginx) - This reverse proxy needs to have a request max body size set below 128mb (for nginx : client_max_body_size) - If the system parameter web.max_file_upload_size is set, delete it and refresh your page - Pick any form view and add a file field with studio - Upload a file larger than the limit set in the proxy, but smaller than 128mb - Save the form # The problem The form is not saved and depending on the version, a Traceback will be shown (18.X) or a Connection Lost notification will be shown for a short period of time (19.0+) # Why When the system parameter web.max_file_upload_size is not set, the check for file size uses the default 128mb. A binary field added to a form via studio will upload its file in the json of the post request. This is done by encoding the file in base64. Our nginx servers set a limit for the request body size (usually 64mb). So if you add a file between 64mb and 128mb, it will bypass the default front-end size check but be stopped by the nginx reverse proxy. The proxy will send back an HTTP response with error code 413 to the client. Theses http responses are not correctly handled by the framework and are interpreted as a Connection Lost error because the response content cannot be parsed to json. Additionally, since we use base64 for the encoding and then use gzip to compress the json request, it's not really feasible to synchronize the front-end limit with the nginx one. opw-5891662 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252527 Forward-Port-Of: odoo/odoo#249025
This update resolves an issue where autocomplete fields weren't consistently saving manual changes made by the user. The fix ensures that the field's value is correctly updated after a user manually edits the input, preventing data discrepancies when saving the form. This improves data accuracy and reliability.
Original PR description
*google_address_autocomplete,partner_autocomplete This commit aims at fixing the behavior of 2 field widgets using the Autocomplete component. Those widgets rely on the `useInputField` hook, because…
*google_address_autocomplete,partner_autocomplete This commit aims at fixing the behavior of 2 field widgets using the Autocomplete component. Those widgets rely on the `useInputField` hook, because they basically render an input (spiced with the autocomplete feature), so they must handle "manual" updates (listen to `input`, `change`, `keydown` events), like regular input fields. However, the input also acts as a "search bar" for the autocomplete. As a consequence, it might happend that the `useInputField` hook internals weren't correctly reflecting the actual state of the field. Here's a faulty scenario to highlight the issue, involving any of the two widgets: - open a form view with the field set to value "XYZ" - type in the input "ABC" and select a suggestion from the autocomplete dropdown => say the value is now "Value ABC" - manually erase the content of the input and type "XYZ" as before - save => the value sent to the server was actually "Value ABC" The reason is that the hook still believes that the field is dirty after the value has been picked from the dropdown, and set (in the model) to "Value ABC", so `lastSetValue` isn't correctly updated to "Value ABC" (it's still "XYZ"). Later on, after the manual update to go back to the value "XYZ", we compare this value with `lastSetValue`, and as they are the same, we do nothing, so the value in the model remains "Value ABC". Those widgets need to use the hook, because the logic encapsulated inside it is really tricky and we don't want to duplicate it. But the hooks internals aren't exposed, and we don't want to expose them to keep it under control. So we did the fix inside the hook itself: in `useEffect`, so after a patch, if the value in the model is the same than the value in the input, it means that the field isn't dirty anymore, so we force-reset the flag to `false`. This scenario only makes sense for inputs that are handled both internally by the hook and externally (e.g. by the autocomplete). Task~6018655 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#252829
This update enhances the clarity of Odoo's server logs during data imports. Previously, it was difficult to quickly determine if an import was a dry run or a real import, or which specific model the data was being loaded into. This change makes it easier for support teams to investigate issues and resolve import problems efficiently.
Original PR description
When investigating support tickets (and the server logs), it is not always clear if: 1) The `info`` log from base_import refers to a dry run or a "real" import 2) The "done" log does not explicitly specify which model the data was imported to While an experienced user can still extrapolate what happened by the immediate context of the preceding/following log lines, it makes it unnecessary difficult to see at first glance where the data was imported to. This PR aims at rectifying it to improve the quality of life of people investigating the server logs. OPW-5999195 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252783 Forward-Port-Of: odoo/odoo#252734
This update fixes a test failure related to live chat operator access. The system now correctly handles operator assignments, ensuring the test accurately validates description edit permissions. This change improves the reliability of our live chat functionality.
Original PR description
this PR is resolving [runbot error](https://runbot.odoo.com/odoo/runbot.build.error/241727) due to **/get_session** now creates the assigned operator as a channel member, so the previous non-member assertion became invalid and could fail depending on operator assignment. The test now uses a distinct livechat operator added after session creation to keep validating description edit access without relying on outdated membership assumptions. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252736
This update resolves a technical problem where screenshots of spreadsheets were sometimes failing due to the spreadsheet being unexpectedly closed. The fix ensures that thumbnails are consistently saved, improving the reliability of spreadsheet sharing and reducing potential data loss. This was a priority fix to maintain a stable user experience.
Original PR description
When we leave a spreadsheet, we take a screenshot of the canvas to save as thumbail. But it's sometime possible for the spreadsheet to be unmounted whe trying to screenshot it, leading to a traceback. Task: [5914708](https://www.odoo.com/web#id=5914708&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#109531
This update fixes an issue where POS receipts displayed duplicate company names and incorrectly showed the company name instead of the POS configuration name. The change ensures receipts now accurately display the POS configuration name once, improving the clarity and professionalism of customer receipts.
Original PR description
Before this commit: =================== The POS receipt displayed the company name twice, resulting in duplicated company information. Additionally, the company name was shown instead of the PoS config name. After this commit: ================== The receipt now correctly displays the POS config name only once. Duplicate company information has been removed to ensure a clean and accurate receipt layout. Task-5951599
This update resolves a technical issue preventing users from generating ird reports when employees have multiple versions recorded within the same reporting period. The fix temporarily prioritizes the most recent version for report generation, ensuring report functionality is restored. This ensures accurate reporting for employees with complex payroll histories.
Original PR description
Fixes an issue that blocks users from generating ird reports if the employee has multiple versions in the period. For now, we will only keep the latest version at the time of reporting. task - 6023310
This update fixes a technical issue preventing module overrides (like those in HR) from correctly updating VoIP contact status information. The change ensures VoIP data aligns with Odoo's extensibility standards, maintaining consistency between the real system and test environments. This improves the reliability of VoIP integrations.
Original PR description
`_store_voip_fields` was directly adding `"im_status"` to the stored partner fields. This bypassed `_store_im_status_fields`, so module overrides (notably HR-related ones) could not extend/adjust the IM status payload. Use `_store_im_status_fields(res)` from `_store_voip_fields` instead of hardcoding `"im_status"`. Also align the VoIP mock server `res.partner` contact payload with the real store payload by including the same contact fields and IM status data (`partner_share`, `im_status`, `im_status_access_token`, etc.). This keeps VoIP aligned with the extensibility contract and keeps tests on the same data shape as runtime. [H>A]
This update resolves an issue where the point-of-sale search feature wasn't consistently working due to a timing problem with updating the search input. A small delay has been added to ensure the search input is properly updated before triggering the search, guaranteeing accurate database lookups. This improves the reliability of the search function.
Original PR description
In some test, we try to search the database for a partner through the partner_list. To do this, we edit the partner_list input and trigger an "Enter" event. In some case, the value is not set to the state of the partner_list before we dispatch the event and result in no search in the database being done. This is partly due to the debounce of the input before setting the state of the partner list and due to some method running asynchronously every method triggered by the insertion of text. To fix this, we add a little sleep in the tour (200ms) to ensure that the state of the component is well updated before triggering the event. runbot-error: 238511 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A recent issue prevented the automated update of POS price tags. This fix removes an outdated argument from the scheduled process, resolving a technical error that was disrupting the tag synchronization. This ensures the POS Pricer module functions correctly without interruption.
Original PR description
Currently, an error occurs when the scheduled action "POS Pricer: Tags Update Synchronization" runs. **Steps to Reproduce:** - Install the `pos_pricer` module. - Go to `Scheduled Actions` and run…
Currently, an error occurs when the scheduled action "POS Pricer: Tags Update Synchronization" runs.
**Steps to Reproduce:**
- Install the `pos_pricer` module.
- Go to `Scheduled Actions` and run `"POS Pricer: Tags Update Synchronization"`.
**Error:**
`
ValueError: TypeError("PricerStore._update_pricer_tags() got an unexpected keyword argument 'update_all'") while evaluating 'model.search(([("pricer_tag_ids", "!=", False)]))._update_pricer_tags(update_all=False)'`
This error occurs because, after this [recent commit], `_update_pricer_tags` was changed to
no longer accept the `update_all` argument and now relies on the `needs_pricer_update` instead.
However, the scheduled action still passes the `update_all` argument [1], which causes the
error when the cron job runs.
This commit removes the unexpected `update_all` argument from the tag update synchronization cron.
[recent commit]: https://github.com/odoo/enterprise/commit/166a8a240d0588f4e908ce09c4639da1216ba3b7
[1]- https://github.com/odoo/enterprise/blob/0ef7643bba5b3fa3d22ab122ef3b65f0d67c8fb7/pos_pricer/data/pricer_ir_cron.xml#L9
sentry-7324339777This update fixes a temporary issue that prevented a helpful training tour for restaurant staff within the Odoo POS system. The tour has been re-enabled with added checks to ensure order synchronization, particularly after printer errors, improving the user experience and training process.
Original PR description
In this commit: --- - Re-enable `test_course_restaurant_preparation_tour`, which was previously disabled to allow merging during freeze. - Add steps to ensure the order is properly synchronized. task-5958387 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A recent update caused crashes when creating YouTube posts in Odoo Enterprise. This fix removes an outdated dependency within the social_youtube module, resolving the crash. The change ensures stable saving of YouTube posts without impacting core functionality.
Original PR description
Bug: Following recent changes introduced in saas-19.2, creating and saving a YouTube post causes the flow to crash. Cause: A refactoring in the social module removed the `utm.source.mixin` dependency from the `social_post` model. This consequently removed the `name` attribute from the model. However, `social_youtube` still expected this attribute to exist, triggering the crash. Solution: Remove all references to the `name` attribute within the `social_youtube` module. We opted not to reintroduce the attribute on the model because it did not add significant functionality and has been superseded by other attributes.
This update fixes a minor issue where a warning about leaving a chatbot conversation was displayed even when the conversation was already closed. Now, the warning only appears when a chatbot conversation is actively in progress, providing a smoother and less disruptive user experience. This change ensures users aren't unnecessarily alerted about finished chats.
Original PR description
Before this commit: When a user finishes a chatbot script and the conversation is already ended, clicking on close / continue still triggers the leave conversation warning. After this commit: The leave conversation warning is no longer shown when the chatbot conversation is already closed or ended. The warning is only shown for active conversations. [Task-5882084](https://www.odoo.com/odoo/project/1519/tasks/5882084) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252750 Forward-Port-Of: odoo/odoo#247918
9 changes
New functionality added to Odoo
This update incorporates support for Mexican asset accounting within the Odoo system. Specifically, new asset models and corresponding account codes have been added to the Mexican tax template, aligning with local regulations. This enhancement allows businesses operating in Mexico to accurately track and report on their fixed assets.
Original PR description
This commit do two things: - Add the asset models into the Mx template - Update CoA with new accounts and descriptions task-4920083 target: 19.0 -> master --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249939
Enhancements to existing features
This update adjusts the trial balance reports for Mexican accounting (MX) to align with the latest accounting standards (CoA). This ensures accurate reporting and compliance for businesses operating in Mexico within the Odoo Enterprise system.
Original PR description
Adapted trial balance tests to consider update on MX CoA task-4920083 target: 19.0 -> master Forward-Port-Of: odoo/enterprise#108200
Resolved issues and error corrections
This update resolves an issue where empty options were being saved and displayed in dropdown selectors within website forms. The fix ensures that empty 'Selection' fields are now automatically removed before saving, improving the user experience and data consistency. This was caused by a previous change affecting how form custom field values were handled.
Original PR description
**Description of the problem** Before this commit, the user could entry empty many2one options in a form, and these would be saved and displayed in the website as empty entries in a dropdown…
**Description of the problem** Before this commit, the user could entry empty many2one options in a form, and these would be saved and displayed in the website as empty entries in a dropdown selector. **How to reproduce the problem** 1. Drop a form 2. Add a "Selection" field (many2one) 3. Clear the text in one of the options in "Option List" 4. Save 5. The empty option is not removed, and shows up in the dropdown selector **Why the problem happens** Commit [1] introduced some changes to the action `SetFormCustomFieldValueListAction`, as a result, empty many2one options are not dropped anymore on apply. **Solution** The solution is applied on `BuilderList` (not only forms), as required by the task. `BuilderList.handleValueChange` now drops empty text fields before commiting changes, unless this violates `props.forbidLastItemRemoval`. The form action `setFormCustomFieldValueList` is changed such that the last entry is never removed even if its text is empty (unless `props.forbidLastItemRemoval` is false). task-5925171 [1]: https://github.com/odoo/odoo/commit/cb8469e9fe73f5c10b4e49d3462e0b23df2a047d
This update fixes a warning appearing in the Belgian VAT report due to an incorrect sign for tax code 61. The change ensures the report aligns with updated standards, preventing potential rejection by tax authorities. It corrects a formula discrepancy within the accounting data to ensure accurate VAT reporting.
Original PR description
Currently, in the Belgian VAT report, `61 – Various VAT regularizations in favor of the State` is displayed with a negative amount under `Taxes > IV Due`, which triggers a warning in the report.…
Currently, in the Belgian VAT report, `61 – Various VAT regularizations in favor of the State` is displayed with a negative amount under `Taxes > IV Due`, which triggers a warning in the report. **Steps to reproduce:** - Install the `l10n_be` module and switch to the `BE company CoA`. - Navigate to `Invoicing > Configuration > Taxes` and open any tax (e.g., 6%). - Replace the `Tax Grid` with `61` on the second line under `Distribution for Invoices`, then `save`. - Navigate to `Customers > Invoices` and create and confirm an invoice using this `tax`. - Navigate to `Reporting > Tax Report` and select the current month. **Observation:** - The report shows a warning: `The report contains negative amounts. This is normally not allowed and could cause the tax authorities to reject it.` - Case `61` under `Taxes > IV Due` displays a `negative` value. **Root Cause:** At [1], all formulas under `IV Due` use a negative sign (-XX) except for case `61`, which uses `61` instead of `-61`. Since the concept of `inverted tax tags` was removed in v19 in PR [2], case `61` must follow the same sign convention as the other `IV Due` cases to ensure correct reporting behavior. **Fix:** This commit updates the formula of case `61` to `-61`, aligning it with the other `IV Due` lines. As a result, the VAT report no longer displays an incorrect negative amount for case `61` and prevents the related `warning` from appearing. [1]: https://github.com/odoo/odoo/blob/f229f23d7bf3d837ff5577c36145bf2ba410ea22/addons/l10n_be/data/account_tax_report_data.xml#L497-L596 [2]: https://github.com/odoo/odoo/pull/225252 opw-5866225 Forward-Port-Of: odoo/odoo#248961
This update fixes an issue where sign requests generated from HR wizards didn't automatically use the expiration dates defined on the sign templates. Now, all sign requests will adhere to the template's configured validity period, ensuring accurate tracking and preventing outdated requests.
Original PR description
Before, when sending sign requests from the HR custom wizards, the validity date defined on the sign template was not applied to the generated signature requests. As a result, requests were created without respecting the template’s configured expiration. task-5928110 Forward-Port-Of: odoo/enterprise#107076
This update resolves an issue where autocomplete fields weren't consistently saving manual changes made by the user. The fix ensures that the field's value is correctly updated after a user manually edits the input, preventing data discrepancies when saving the form. This improves data accuracy and reliability.
Original PR description
*google_address_autocomplete,partner_autocomplete This commit aims at fixing the behavior of 2 field widgets using the Autocomplete component. Those widgets rely on the `useInputField` hook, because…
*google_address_autocomplete,partner_autocomplete This commit aims at fixing the behavior of 2 field widgets using the Autocomplete component. Those widgets rely on the `useInputField` hook, because they basically render an input (spiced with the autocomplete feature), so they must handle "manual" updates (listen to `input`, `change`, `keydown` events), like regular input fields. However, the input also acts as a "search bar" for the autocomplete. As a consequence, it might happend that the `useInputField` hook internals weren't correctly reflecting the actual state of the field. Here's a faulty scenario to highlight the issue, involving any of the two widgets: - open a form view with the field set to value "XYZ" - type in the input "ABC" and select a suggestion from the autocomplete dropdown => say the value is now "Value ABC" - manually erase the content of the input and type "XYZ" as before - save => the value sent to the server was actually "Value ABC" The reason is that the hook still believes that the field is dirty after the value has been picked from the dropdown, and set (in the model) to "Value ABC", so `lastSetValue` isn't correctly updated to "Value ABC" (it's still "XYZ"). Later on, after the manual update to go back to the value "XYZ", we compare this value with `lastSetValue`, and as they are the same, we do nothing, so the value in the model remains "Value ABC". Those widgets need to use the hook, because the logic encapsulated inside it is really tricky and we don't want to duplicate it. But the hooks internals aren't exposed, and we don't want to expose them to keep it under control. So we did the fix inside the hook itself: in `useEffect`, so after a patch, if the value in the model is the same than the value in the input, it means that the field isn't dirty anymore, so we force-reset the flag to `false`. This scenario only makes sense for inputs that are handled both internally by the hook and externally (e.g. by the autocomplete). Task~6018655 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#252829
This update enhances the clarity of Odoo server logs related to data imports. Previously, it was difficult to quickly determine if an import was a dry run or a real import, or to see which specific model the data was imported into. This change makes it easier for support teams to investigate issues and improve the overall efficiency of data import troubleshooting.
Original PR description
When investigating support tickets (and the server logs), it is not always clear if: 1) The `info`` log from base_import refers to a dry run or a "real" import 2) The "done" log does not explicitly specify which model the data was imported to While an experienced user can still extrapolate what happened by the immediate context of the preceding/following log lines, it makes it unnecessary difficult to see at first glance where the data was imported to. This PR aims at rectifying it to improve the quality of life of people investigating the server logs. OPW-5999195 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252783 Forward-Port-Of: odoo/odoo#252734
This update resolves a technical error that occurred when processing refunds in the Spanish Point of Sale (POS) module. Specifically, a 'singleton error' was triggered due to incorrect data being passed during refund operations. The fix ensures the correct order ID is used, preventing the error and ensuring refunds are processed smoothly.
Original PR description
Step to reproduce: - install l10n_es_pos - create a pos, open its setting and set its `Simplified Invoice` with a journal - start pos, create a order and refund it Observation: - we receive a singleton error for account.move Cause: - when calling `get_invoice_name` method, we pass `order_server_ids` which contains order and refund order id, hence two ids are passed Fix: - instead of using `order_server_ids` we use 'order.id' i.e. current order opw-5870707 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251519 Forward-Port-Of: odoo/odoo#247986
This update resolves an issue where the system incorrectly interpreted date columns in import files. Specifically, it fixed a bug where date formats like '2500/1222' were wrongly identified as '%Y.%m.%d'. This ensures that import files with various date formats are now processed accurately, preventing import errors and improving data reliability.
Original PR description
## Description of the issue/feature this PR addresses: If you try to import an excel sheet for example with these column on sale order, but the issue is at every model: (this is an example)…
## Description of the issue/feature this PR addresses: If you try to import an excel sheet for example with these column on sale order, but the issue is at every model: (this is an example)  First column: Client ref Second column: committment date Third column: Customer ## Current behavior before PR: When you upload the file to import, the extract_header_types calls _try_match_date_time that try to guess the date column. The first column makes the _try_match_date_time to guess that the format is %Y.%m.%d format . This is an error because that column does not contain a date . The reason is that check_patterns when convert the pattern to reg ex using `def to_re(pattern):` on base_import/base_import.py, does not escape the "." so it works as "every char" wildcard character on regex . ## Desired behavior after PR is merged: No error should appear and the correct date format from the right date column should be guessed --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252488 Forward-Port-Of: odoo/odoo#196477
8 changes
Resolved issues and error corrections
This update resolves an issue where documents couldn't be opened after their names were changed. The fix corrects a technical error in the document management system related to how attachments were handled. This ensures documents can now be reliably opened and used after a name change.
Original PR description
Steps to reproduce: 1. Install `documents` 2. Open a document in full screen and click on info icon on top right 3. Edit the name and close full screen document and chatter 4. Try to open the same document Issue: - Traceback occures `TypeError: Cannot read properties of undefined (reading 'insert')` Cause: - In file document_service `this.store.Attachment` was used instead of `this.store["ir.attachment"]` After this commit https://github.com/odoo/odoo/commit/70153559c34ffd18c67b83c39ee397ecb0a90b4a we renamed the Attachment model opw-5483625 Forward-Port-Of: odoo/enterprise#109567 Forward-Port-Of: odoo/enterprise#105602
A previous shortcut conflict in the asset management module caused users to incorrectly navigate to the Posted Entries view instead of the previous asset. This update resolves this issue by changing the shortcut to ALT + SHIFT + P, aligning with existing shortcuts and improving usability.
Original PR description
# How to reproduce - Have atleast two assets - Go to the last asset - Type ALT + P on your keyboard # The problem We enter the Posted Entries view instead of going to the previous asset # Why This PR (https://github.com/odoo/enterprise/pull/67840) added shortcuts to the asset form view, but used ALT + P for the Posted Entries. This shortcut is already used on all form views for the "previous page" button. After consulting with the developer of the original PR, we decided to move the Posted Entries shortcut to ALT + SHIFT + P opw-5948523 Forward-Port-Of: odoo/enterprise#109022
This update corrects a technical issue preventing electronic invoices in the RIMPE Emprendedor regime from being properly processed. The change ensures the correct string value is used for the invoice structure, resolving a validation error that was causing invoice processing failures. This ensures compliance with Ecuadorian tax regulations.
Original PR description
Corrected the hardcoded string for the RIMPE Emprendedor regime to match the SRI structure According to SRI technical specifications, the <contribuyenteRimpe> tag only accepts two specific values:…
Corrected the hardcoded string for the RIMPE Emprendedor regime to match the SRI structure According to SRI technical specifications, the <contribuyenteRimpe> tag only accepts two specific values: CONTRIBUYENTE RÉGIMEN RIMPE (Fixed value) CONTRIBUYENTE NEGOCIO POPULAR - RÉGIMEN RIMPE Steps to reproduce: Install l10n_ec_edi module Go to Settings > Invoicing > Ecuadorian Localization In Electronic Invoicing > Regime, select rimpe_emprendedor In Electronic Invoicing > Regime, configure a SRI Connection Post an customer invoice **Validation error occurring during the electronic signing process (using .p12 certificates):** `35 - Se encontró el siguiente error en la estructura del comprobante: cvc-pattern-valid: Value 'CONTRIBUYENTE EMPRENDEDOR - RÉGIMEN RIMPE' is not facet-valid with respect to pattern 'CONTRIBUYENTE RÉGIMEN RIMPE|CONTRIBUYENTE NEGOCIO POPULAR - RÉGIMEN RIMPE' for type 'contribuyenteRimpe'.. - ARCHIVO NO CUMPLE ESTRUCTURA XML - ERROR ` Forward-Port-Of: odoo/enterprise#109147
This update corrects a bug where users without HR document centralization enabled were seeing all documents, not just their own employee documents, when using the 'documents' smart button. The fix restores the intended behavior for companies without this HR setting, ensuring employees only access their own files.
Original PR description
Steps: - uncheck the "Human Resources" file centralization option - go to an employee, click the documents smart button -> You see every documents, not only the ones from the employee PR https://github.com/odoo/enterprise/pull/93782 aimed at restoring the previous behaviour of the employee documents button and accesses for companies without the hr documents settings enabled, but forgot the domain on the employee smartbutton action. opw-5857914 Forward-Port-Of: odoo/enterprise#107224
This update fixes an issue where currency exchange difference values were missing from DATEV exports. The fix correctly uses the line balance instead of the currency amount, ensuring accurate reporting of exchange rates for DE company transactions. This improves the reliability of financial data sent to DATEV.
Original PR description
**Steps to reproduce: 1. Create DE company (EUR currency) 2. Add USD -> EUR exchange rates for XX/01/26 and XX/15/26 (XX is target month) 3. Install l10n_de_reports 4. Make sure bank journal has…
**Steps to reproduce: 1. Create DE company (EUR currency) 2. Add USD -> EUR exchange rates for XX/01/26 and XX/15/26 (XX is target month) 3. Install l10n_de_reports 4. Make sure bank journal has 'outstanding receipts' set for incoming manual payment [Accounting -> Config -> Journals -> Bank] 5. Create USD invoice for XX/02/26 and confirm it 6. Register a Payment for XX/16/26 and confirm it (you should see the exchange difference entry matched alongside the payment) 7. Go to [Accounting -> Reporting -> General Ledger] and export DATEV data **Description of issue: The currency exchange rate difference entries in the exported file are shown as 0 **Expected behavior: The actual currency exchange difference values should be displayed **Why this happens? The DATEV export currently sets the amount based on 'amount_currency'. For currency exchange difference entries, this value is 0.0 in the General Ledger, resulting in 0 values in the export. **The fix: Updated the logic to use the line balance when the entry is identified as a currency exchange difference. opw-5358954 Forward-Port-Of: odoo/enterprise#109655 Forward-Port-Of: odoo/enterprise#107268
This update resolves an issue where users were unable to set both a start and end date simultaneously within the web_studio feature. The fix prevents the creation of invalid date range fields, ensuring data consistency and a smoother user experience when configuring forms and workflows. This improves the reliability of the studio interface.
Original PR description
Steps to reproduce ================== - Install project,web_studio - Click on the three dots in the top right of a project - Click on settings - Open studio - Add a new date field - Set the start date field to Start date - Set the end date field to Expiration Date - Exit studio => The date range field is marked as invalid (red outline) Cause of the issue ================== https://github.com/odoo/odoo/blob/ee15163fe516817da277760752892ea76a699e22/addons/web/static/src/views/fields/datetime/datetime_field.js#L371-L373 We cannot set both the start and end field at the same time. opw-5403670 Forward-Port-Of: odoo/enterprise#108562
This update fixes a display issue in the SEPA payment wizard, ensuring the warning message accurately reflects the number of payments being processed (originally showing 4 when only the first installment was being paid). Additionally, a bug preventing the 'group payment' button from appearing when multiple bills were selected has been resolved. This ensures accurate payment tracking and a smoother user experience.
Original PR description
[FIX] account_iso20022: right number of payments skipped in send wizard adding tests to the community commit Steps to reproduce: - install modules account_sepa_direct_debit, account_iso20022 - create 2 vendor bills with payment terms so that there are 2 installments per bill, and post them - from the list view, select both bills and click pay - select SEPA as a payment method, a warning message is displayed mentionning 4 payments We want the warning to display a number of 2 payments because we're paying only the first installment of each bill This commit also fixes the visibility of the "group payment" button: when two bills from different suppliers were selected with one having installments, the button was visible task-5917803 Forward-Port-Of: odoo/enterprise#106894
This update fixes a previous issue where certain salary deductions (specifically 'ATTACH_SALARY') weren't correctly reflected in employee net pay calculations for the Kenyan payroll module. The changes add four new rules to the deduction line, adjusting their sequence and sign to accurately account for these attachments, ensuring accurate net pay reporting.
Original PR description
**Behavior before this commit** Some salary rules (e.g. `ATTACH_SALARY`) were ignored in the NET calculation. **Behavior after this commit** - Four rules are now added to the "Total deductions" line: their sequence and category has been changed. - The sign of these lines has also been switched: an attachment of salary of a positive amount should be added to the amount of total deductions, which is then deducted from the net.  opw-5894647 Forward-Port-Of: odoo/enterprise#107033
15 changes
Resolved issues and error corrections
This update resolves an issue where Odoo invoices for Danish customers were incorrectly formatted according to Peppol standards. The change skips adding redundant information to ensure compliance with regulations, preventing invoice submission errors. This ensures seamless integration with Peppol networks for Danish businesses.
Original PR description
Currently, if a Danish partner has a reference set, Odoo adds it under PartyIdentification. This violates Peppol `DK-R-013`, which mandates using schemeID when PartyIdentification is used. Adding the Danish schemeID would also trigger another error, `PEPPOL-COMMON-R042`, as the organization number (CVR) must be included in the `_text`. Including schemeID seem therefore unnecessary since it will appear in CompanyID. Steps to reproduce: - Create a Danish company and enable Peppol - Create a Danish customer with a reference - Create an invoice and submit to Peppol, `DK-R-013` error occurs opw-5921602 Forward-Port-Of: odoo/odoo#251737
This update removes an unnecessary check for local network connectivity when opening cashboxes via IoT. Because Stable IoT Boxes are now reachable through a websocket, this redundant step has been removed, streamlining the process. This change improves the reliability of cashbox operations.
Original PR description
Stable IoT Boxes can be reached using websocket, so it doesn't make sense to check the connectivity on local network before sending the "open cashbox" action. We then removed this check. Forward-Port-Of: odoo/enterprise#107397
This update fixes an issue where sandwich leave durations were incorrectly calculated when public holidays were involved. The fix ensures that all date calculations are properly localized to the company's timezone, guaranteeing accurate leave duration calculations for employees. This improves the reliability of leave management.
Original PR description
Steps to Reproduce: 1. Install the `l10n_in_hr_holidays` module. 2. Enable the "sandwich leave" option for the time off type. 3. Create public holidays that last the entire day, for example from 00:00 to 23:59. 4. Create a leave around the public holiday 5. Duration should be 3 days instead of 1 Cause: When creating a dictionary for company-specific public holidays, the dates from and to are not converted to the company's timezone when calculating the days between public holidays. Fix: To resolve this, the first step is to localize the `date_from` and `date_to` to the company's timezone before counting the days between the public holidays. Task-6012992 Forward-Port-Of: odoo/odoo#252466
This change corrects a typo in the XML format used when sending debit notes to the Italian SDI (electronic reporting system). The original error caused debit notes to be rejected, preventing accurate tax reporting. The fix updates a field name to ensure compliance with the required XML structure.
Original PR description
# Problem:
When sending debit notes to the SDI, they are rejected with the following error:
`File non conforme al formato : Invalid content was found starting with element 'Datifatturecollegate'. One of '{DatiOrdineAcquisto, DatiContratto, DatiConvenzione, DatiRicezione, DatiFattureCollegate, DatiSAL, DatiDDT, DatiTrasporto, FatturaPrincipale}' is expected.`
# Cause:
In the `account_invoice_it_FatturaPA_export_debit_note` there's a typo in 'Datifatturecollegate' as it should be 'DatiFattureCollegate'
https://github.com/odoo/odoo/blob/bc1c264b6232c78c33a96169110b37d9d4430243/addons/l10n_it_edi_ndd_account_dn/data/invoice_it_template.xml#L5-L8
opw-5930596
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#252272
Forward-Port-Of: odoo/odoo#249284A recent issue causing Distro builds to fail during the quality control tour has been resolved. The fix increases a delay in the tour process to ensure backend operations complete before the user interface updates, preventing UI elements from disappearing during the test. This improves the reliability of our automated testing environment.
Original PR description
Distro builds was failing with:
```js
FAILED: [8/14] Tour test_quality_check_packages_lots_tour →
Step .o_line_button.o_toggle_sublines
{
'trigger': '.o_line_button.o_toggle_sublines',
'run': 'click'
},
```
- This issue occurs due to a timing race condition in the barcode client action.
After scanning lots and clicking Put in Pack, backend calls are
still processing (updating move lines and packages) while the frontend re-renders the UI,
the tour continued before these operations were fully completed,
so the `.o_toggle_sublines` button was not yet available in the DOM.
This caused intermittent failures, mainly in slower CI environments like Distro builds/runbot.
- To fix this, the tour step_delay has been increased from 100 to 300,
giving enough time for backend processing and UI rendering
to complete before executing the next step.
---
runbot error:238452
Forward-Port-Of: odoo/enterprise#107766This update resolves an issue where users could incorrectly set both a start and end date simultaneously within the web_studio interface, leading to a validation error. The fix prevents this conflicting input, ensuring date range fields function as expected and improving data accuracy. This change impacts the usability of date-based fields in project configurations.
Original PR description
Steps to reproduce ================== - Install project,web_studio - Click on the three dots in the top right of a project - Click on settings - Open studio - Add a new date field - Set the start date field to Start date - Set the end date field to Expiration Date - Exit studio => The date range field is marked as invalid (red outline) Cause of the issue ================== https://github.com/odoo/odoo/blob/ee15163fe516817da277760752892ea76a699e22/addons/web/static/src/views/fields/datetime/datetime_field.js#L371-L373 We cannot set both the start and end field at the same time. opw-5403670 Forward-Port-Of: odoo/enterprise#108562
This update fixes a problem in the Odoo stock module where error messages about package consistency were unclear. Now, the messages specifically identify the problematic package, allowing users to quickly diagnose and resolve issues, especially during large product transfers. This improves efficiency and reduces support requests.
Original PR description
The current error does not specify which package is problematic. This cause issues on big transfers with many products / packages. Specifying the package in the error helps the customer identify the issue, and correct it themselves. OPW-5923839 --- <img width="673" height="252" alt="image" src="https://github.com/user-attachments/assets/0ccb45be-d813-4933-86fd-0dd3506d2775" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249290
This update resolves an issue where incoming emails with attachments using the 'bin/plain' MIME type would cause the system to crash. The fix now gracefully handles this attachment type by converting it to a standard format, ensuring all emails are processed correctly and preventing disruptions to vendor bill creation.
Original PR description
When parsing incoming emails, mail.thread normalizes some malformed MIME types before calling part.get_content(). However, attachments using Content-Type `bin/plain` are not normalized. As a result,…
When parsing incoming emails, mail.thread normalizes some malformed MIME types before calling part.get_content(). However, attachments using Content-Type `bin/plain` are not normalized.
As a result, Python's email content manager raises KeyError('bin/plain') during parsing, which aborts the whole message processing. This prevents the incoming email from being processed, including vendor bill creation from email aliases.
Steps to reproduce:
- build an email with an attachment using Content-Type `bin/plain`
- parse it through `mail.thread.message_parse`
Before this commit, parsing crashes with KeyError('bin/plain').
This commit treats `bin/plain` like the other unsupported attachment MIME types already handled in stable, by falling back to `application/octet-stream`, allowing the message to be parsed and the attachment to be preserved.
opw-5439156
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#251440This update automatically groups vendor bills during UBL/CII import based on the vendor's previous bill history. The system now checks the last posted bill to determine if lines should be grouped by tax, streamlining the import process and reducing manual adjustments. This improves data accuracy and efficiency for invoice processing.
Original PR description
[FIX] account_edi_ubl_cii: automate bill line grouping
This commit automates vendor bill line grouping during import based on the vendor's most recent posted bill.
- Logic: Added `_has_lines_grouped()` to `account.move` to detect if lines follow the grouping pattern.
- Heuristic: During UBL/CII import, the system now checks the last posted bill from the same vendor; if it was grouped, the new bill is automatically grouped by tax.
task-5979667
Forward-Port-Of: odoo/odoo#251948
Forward-Port-Of: odoo/odoo#251419This update fixes a display issue in the SEPA payment wizard, ensuring the warning message accurately reflects the number of payments being processed (specifically, 2 payments instead of 4). This change improves the user experience by providing accurate information about the payment schedule. Additionally, the 'group payment' button is now correctly hidden when necessary.
Original PR description
[FIX] account: right number of payments skipped in send wizard Steps to reproduce: - install modules account_sepa_direct_debit, account_iso20022 - create 2 vendor bills with payment terms so that there are 2 installments per bill, and post them - from the list view, select both bills and click pay - select SEPA as a payment method, a warning message is displayed mentionning 4 payments We want the warning to display a number of 2 payments because we're paying only the first installment of each bill This commit also fixes the visibility of the "group payment" button: when two bills from different suppliers were selected with one having installments, the button was visible task-5917803 Forward-Port-Of: odoo/odoo#247830
This update fixes a display issue in the SEPA payment wizard, ensuring the warning message accurately reflects the number of payments being processed (originally showing 4 when only the first installment was being paid). Additionally, a bug preventing the 'group payment' button from appearing under certain circumstances has been resolved. This ensures accurate payment tracking and a smoother user experience.
Original PR description
[FIX] account_iso20022: right number of payments skipped in send wizard adding tests to the community commit Steps to reproduce: - install modules account_sepa_direct_debit, account_iso20022 - create 2 vendor bills with payment terms so that there are 2 installments per bill, and post them - from the list view, select both bills and click pay - select SEPA as a payment method, a warning message is displayed mentionning 4 payments We want the warning to display a number of 2 payments because we're paying only the first installment of each bill This commit also fixes the visibility of the "group payment" button: when two bills from different suppliers were selected with one having installments, the button was visible task-5917803 Forward-Port-Of: odoo/enterprise#106894
This update fixes an issue where event tickets in the POS were not correctly calculating prices. Now, ticket prices will dynamically adjust based on the event's price or a linked pricelist, ensuring accurate pricing for event attendees. This improves the POS experience and prevents discrepancies in ticket costs.
Original PR description
Event tickets in POS would have their price locked to the price defined in the event itself. They would be filtered out of any price recalculation inside the POS to keep the POS from recalculating the price based on the `product_template` and to keep the price defined in the event itself. This PR will add event tickets back into price recalculation. It will set the price to the price defined inside the event if no pricelist is applicable, or use the pricelist to calculate the price if there is one applicable. Task-[5092613](https://www.odoo.com/odoo/project/1737/tasks/5092613) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an error that occurred when generating lots without a defined sequence. The fix ensures the system handles cases where the lot sequence is initially empty, preventing a critical error and allowing users to correctly generate lot numbers. This improves the reliability of inventory management.
Original PR description
Currently, an error occurs when a user tries to generate lots while providing a lot number. **Steps to replicate:** - Install purchase (without demo). - Create a product `test`. - Install stock and…
Currently, an error occurs when a user tries to generate lots while providing a lot number.
**Steps to replicate:**
- Install purchase (without demo).
- Create a product `test`.
- Install stock and turn on `Lots and Serial Numbers`
- Open the product `test` and turn on `Track Inventory` `by Lots`.
- Open Receipts > add the product `test`> give demand as 3 > and go to its form view using view button.
- Click `Generate Lots` > type `lot1` in `First lot Number` > Generate > Error-1
- Click `Generate Lots` > type 0 in Quantity received > Generate > Error-2.
**Error-1:**
```
File '/home/odoo/odoo18/community/addons/stock/models/stock_move.py', line 1026, in action_generate_lot_line_vals
if (first_lot and first_lot == product.lot_sequence_id.get_next_char(first_number)):
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File '/home/odoo/odoo18/community/odoo/addons/base/models/ir_sequence.py', line 237, in get_next_char
interpolated_prefix, interpolated_suffix = self._get_prefix_suffix()
^^^^^^^^^^^^^^^^^^^^^^^^^
File '/home/odoo/odoo18/community/odoo/addons/base/models/ir_sequence.py', line 227, in _get_prefix_suffix
self.ensure_one()
File '/home/odoo/odoo18/community/odoo/orm/models.py', line 5640, in ensure_one
raise ValueError('Expected singleton: %s' % self)
ValueError: Expected singleton: ir.sequence()
```
**Error-2:**
```
File '/home/odoo/odoo18/community/addons/stock/models/stock_move.py', line 1025, in action_generate_lot_line_vals
first_number = product.lot_sequence_id.number_next_actual - product.lot_sequence_id.number_increment
^^^^^^^
UnboundLocalError: cannot access local variable 'product' where it is not associated with a value
```
---
**Cause:**
- Both errors originated through a recent [PR].
**Error-1 (Expected singleton: ir.sequence()):**
- As the product was already created before Inventory was installed, the `lot_sequence_id` was empty. (Note:`lot_sequence_id` field has a default value , but default value
assignment triggers only during the record creation, any records created
before stock is installed will not be assigned any value for
`lot_sequence_id`.)
- As no `lot_sequence_id` is assigned to `test` product the line [1] calls `get_next_char()` on an empty recordset which further calls `_get_prefix_suffix()` [2] and raises singletonerror from [here].
**Error-2 (UnboundLocalError: cannot access local variable 'product'):**
- As the `Received Quantity` was given 0, the `count` argument is received as 0 and as a result the `lot_qties` [3] and `lot_names` [4] are received as empty lists.
- This causes their [zip] to be empty list too and the loop never runs, so assignment to [product] variable never happens and causes the error to occur from here [5].
---
**Solution:**
**Error-1:**
- Now we perform write on `product.lot_sequence_id` only if it exists, otherwise we skip it.
**Error-2:**
- Moved the static assignment of variable `product` and `location_dest_id` outside the loop, this will also prevent the browse being called multiple times for browsing the same record.
[PR]: https://github.com/odoo/odoo/pull/240368
[1]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/addons/stock/models/stock_move.py#L1026
[2]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/odoo/addons/base/models/ir_sequence.py#L237
[here]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/odoo/addons/base/models/ir_sequence.py#L227
[3]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/addons/stock/models/stock_move.py#L989
[4]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/addons/stock/models/stock_move.py#L994
[zip]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/addons/stock/models/stock_move.py#L1000
[product]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/addons/stock/models/stock_move.py#L1004
[5]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/addons/stock/models/stock_move.py#L1025
sentry-7254849206,7265844194
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update fixes a bug in how scrap quantities are calculated for products. Previously, if a product didn't have a related Bill of Materials, the calculation would stop, leading to incorrect scrap quantities being reported. Now, all products are correctly processed, ensuring accurate scrap tracking.
Original PR description
### Description of the issue/feature this PR addresses: The `_compute_scrap_qty` method in **mrp/models/stock_scrap.py** exits early with return when a record has no BOM, preventing the computation of `scrap_qty` for remaining records in the recordset. ### Current behavior before PR: When iterating over a multi-record recordset, if any record lacks a `bom_id`, the method does return `super(...)._compute_scrap_qty()`, which exits the entire loop. Records after that one are never computed and keep the default value of 1. ### Desired behavior after PR is merged: Records without a `bom_id` delegate to `super()._compute_scrap_qty()` and the loop continues (continue) to the next record, ensuring all records in the recordset are properly computed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252149
Code cleanup and technical improvements
This pull request streamlines the management of the base module's internationalization (I18N) pot file. By re-exporting the pot file, it simplifies the process for translators to access and work with the necessary localization resources. This ensures consistent and efficient translation workflows across the Odoo platform.
Original PR description
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#250518 Forward-Port-Of: odoo/odoo#248892
3 changes
Resolved issues and error corrections
A recent issue causing tour tests to fail in our automated build process has been resolved. The fix increases the delay in the tour to ensure backend operations complete before the user interface updates, preventing UI elements from disappearing during the test. This improves the reliability of our automated testing.
Original PR description
Distro builds was failing with:
```js
FAILED: [8/14] Tour test_quality_check_packages_lots_tour →
Step .o_line_button.o_toggle_sublines
{
'trigger': '.o_line_button.o_toggle_sublines',
'run': 'click'
},
```
- This issue occurs due to a timing race condition in the barcode client action.
After scanning lots and clicking Put in Pack, backend calls are
still processing (updating move lines and packages) while the frontend re-renders the UI,
the tour continued before these operations were fully completed,
so the `.o_toggle_sublines` button was not yet available in the DOM.
This caused intermittent failures, mainly in slower CI environments like Distro builds/runbot.
- To fix this, the tour step_delay has been increased from 100 to 300,
giving enough time for backend processing and UI rendering
to complete before executing the next step.
---
runbot error:238452
Forward-Port-Of: odoo/enterprise#107766This update resolves an issue where users were unable to correctly set both a start and end date for date range fields within the Web Studio design tool. The fix prevents the system from accepting both date fields simultaneously, ensuring data integrity and preventing invalid date range configurations. This improves the overall usability of Web Studio for creating date-based views.
Original PR description
Steps to reproduce ================== - Install project,web_studio - Click on the three dots in the top right of a project - Click on settings - Open studio - Add a new date field - Set the start date field to Start date - Set the end date field to Expiration Date - Exit studio => The date range field is marked as invalid (red outline) Cause of the issue ================== https://github.com/odoo/odoo/blob/ee15163fe516817da277760752892ea76a699e22/addons/web/static/src/views/fields/datetime/datetime_field.js#L371-L373 We cannot set both the start and end field at the same time. opw-5403670 Forward-Port-Of: odoo/enterprise#108562
Features or functions removed from Odoo
This update streamlines the operation of certified scales in Point of Sale. The previous system's tare management has been removed, consolidating the tare function to the dedicated scale tare button. This simplifies the user experience and ensures accurate weight measurements for certified transactions.
Original PR description
This PR removes the tare managing from Point Of Sale for the certified scales, leaving its management for the scale tare button. Community PR: odoo/odoo#251237 Task [link](https://www.odoo.com/odoo/project.task/5977538) task-5977538 Forward-Port-Of: odoo/enterprise#109093
21 changes
Enhancements to existing features
This update enhances the planning module's user interface by repositioning buttons next to input fields for a cleaner look. Additionally, redundant icons within the kanban card have been removed to streamline the user experience. This change focuses on visual consistency and usability.
Original PR description
This commit improves the UI in planning, by using the o_input_box class around two fields. Instead of having a button right next to the input, the button now floats as a suffix at the right side of the input. Also, two icons were present in the kanban card, since the daterange field already contains an icon in readonly touch mode.
This update reduces the number of template options displayed in the planning view, improving the user interface's clarity and preventing visual clutter. The change limits the badges available to 8, addressing an issue where excessive template choices could overwhelm users. This enhancement focuses on a better user experience.
Original PR description
Add `badge_limit: 8` to the planning template autocomplete widget. **Task~5270283** **Related Community PR: odoo/odoo#252483**
This update enhances the visual appearance of consent emails sent to users when they sign up for Odoo Enterprise. The changes align the email layout with the latest Odoo Finance design standards, creating a more professional and consistent user experience. This improves brand perception and user satisfaction.
Original PR description
- updated consent email template layout as per current odoofin design task-5107776
This update enhances the visibility of VAT return status within Odoo, alerting users immediately when a file is rejected by tax authorities. Previously, errors were only logged in a chat window. Now, the return status will display a visual indicator, allowing for quicker identification and resolution of issues.
Original PR description
Many localisations require some returns (mainly: VAT return) to be sent by API to tax authorities. It frequently happens that the file is rejected by the authorities for xyz reasons. In that case, the response is logged in the return chatter but we should make the failure visual so users directly know that an issue occurred. For that, we'll allow the states widget to be colorful. Now localisation can add custom error messages and alert types and the widget will be colored accordingly and the error message will appear on hover. task-5365547
Resolved issues and error corrections
This update resolves an issue preventing automated tests from correctly opening the POS session. The changes update tour selectors to target the 'Open Register' button and modify the UI rendering to ensure the button is consistently accessible. This improves the reliability of our test automation.
Original PR description
In this commit:
- The POS open UI button is now rendered through a widget and no longer exposes the `name=open_ui` attribute. As a result, the existing tour selectors could not locate the button.
- Update the tour triggers to use `button:contains('Open Register')` so the POS session can still be opened correctly during tests.
Task:5425256
Related PR:
- Community: https://github.com/odoo/odoo/pull/241641
- Upgrade: https://github.com/odoo/upgrade/pull/9205This update resolves an issue preventing correct validation of data properties within the Knowledge and Spreadsheet Edition modules. The fix ensures data integrity and proper functionality for these key features, improving overall system stability.
Original PR description
This commit corrects wrong props validation schema that could not work.
This update fixes a technical issue within Odoo's VoIP system. Previously, the system relied on a single data field for status updates, which created maintenance challenges and lacked crucial information like employee access tokens. This change ensures accurate and complete status updates, improving the reliability of the VoIP feature.
Original PR description
Just reading `im_status` instead of the dedicated method makes the maintenance harder and it is potentially problematic as it doesn't return the `im_status_access_token` nor the necessary extra information from employee records to compute out of office. https://github.com/odoo/odoo/pull/252008
This update resolves a minor visual issue in the Helpdesk module related to the 'Rotting days' field. The change improves the field's appearance and usability by applying a standard UI element. This ensures a consistent and polished user experience for Helpdesk users.
Original PR description
This commit fixes the UI of the 'Rotting days' field, by wrapping it in a o_input_box div and using the o_input_box_overlay_end and the o_input_box_overlay_inline classnames. task-6025631
This update streamlines the spreadsheet experience by grouping data sources into organized submenus under 'Data' and 'Charts'. This change addresses a previous crash related to dynamic pivot tables and enhances usability by reducing the length of the Data menu, making it easier for users to find the information they need.
This update removes a temporary flag from the account reports tour, signifying that it is now fully functional and reliable. This ensures users can consistently access and utilize the tour without encountering unexpected issues. The change improves the overall stability of the account reporting feature.
Original PR description
This commit removes the 'undeterministicTour_doNotCopy' flag from the 'account_reports_sections' tour. This indicates that the tour is now stable.
This update removes a temporary flag from the account reporting audit tour, signifying that it is now reliably functional. This ensures consistent and accurate reporting processes for users. The change improves stability and reduces potential issues with the audit tour.
Original PR description
This commit removes the 'undeterministicTour_doNotCopy' flag from the 'account_reports_audit' tour. This indicates that the tour is now stable.
This update corrects a technical issue where incorrect class names were being used in several Odoo modules. The change ensures all elements use the correct 'o_input_box_overlay_inline' class, improving the stability and consistency of the system. This resolves a potential inconsistency that could have impacted user experience.
Original PR description
In commit [1], the class 'o_input_box_overlay_inline' was introduced, but many elements were using an invalid 'o_input_box_inline' class instead of that one. This commit replaces all the wrong implementation of inline suffixes by the right one. [1]: dc8f38b1054664a0e382530bb4fc73983e2085cb
This update resolves an issue where users couldn't enter values in the 'Allocated Time' field within the planning module, particularly when a break time was scheduled. Now, the field functions correctly with a standard input box, ensuring accurate time tracking and scheduling.
Features or functions removed from Odoo
This update removes a temporary workaround that had been added to ensure appointment scheduling stability. The underlying view fix is now sufficient to resolve the issue, simplifying the system and reducing potential complexity. This change improves the overall reliability of the appointment scheduling feature.
Original PR description
The fix of [commit] from saas-19.2 introduced override of `tz` to provide default value for it. It was done to be stable-friendly. For the master, we can remove the field override because the view fix is sufficient to remove the bug. [commit]: https://github.com/odoo/enterprise/commit/ebb876ce67a9d04116c12394d6385a8b2b562168 Task-5712786
The French Payroll localization module has been removed from Odoo. This decision was made due to the module's outdated and unmaintained state, which posed a risk of confusion and inaccurate implementations. Removing this module simplifies the core system and reduces potential support issues.
Original PR description
The French Payroll localization has been removed as it was unmaintained, outdated, and not suitable for real-world usage. Maintaining it in its current state could lead to confusion or incorrect implementations. TaskID: 6023819
This update removes a technical method used to quickly check billable line items in the database. Following a recent update to the debugging tools, this method is no longer needed and is replaced with a more straightforward interface. This change improves efficiency for users and support teams.
Original PR description
Since PR odoo/odoo#249108, CloC features are availables from the debug menu. That makes the _get_verbose_maintenance method deprecated. The use case those address is the quick check for billable line of codes on some DB by either the user themselves or Odoo Support. Obviously it is more practical to do it via the interface directly part-of-task-5943473
Code cleanup and technical improvements
This update adds the necessary syntax (.this) to Odoo templates to ensure compatibility with OWL3. This change is a preparatory step for a future upgrade, allowing templates to correctly reference component variables, which is crucial for the system's continued functionality.
Original PR description
In preparation for OWL3, where template variables will need to use .this to target component variables, we add .this to template variables that are targetting the component. Script PR: #247965 task: OWL3 prep - add this. to template variables
This update clarifies how message actions are defined within Odoo, enhancing readability and maintainability. The change replaces outdated 'thread' references with 'channel' in the configuration, streamlining the process for developers. This improves the overall organization of communication features.
Original PR description
Introduced by https://github.com/odoo/odoo/issues/243572 for improved readability of message action definition.
This update modifies Odoo's templates to align with upcoming OWL3 requirements. Specifically, it adds `.this` to template variables that target component parts, ensuring compatibility with the new OWL3 framework. This proactive step ensures a smooth transition and avoids potential issues when OWL3 is fully implemented.
Original PR description
In preparation for OWL3, where template variables will need to use `.this` to target component variables, we add `.this` to template variables that are targetting the component. Script PR: https://github.com/odoo/odoo/pull/247965 THIS_TARGETS = ['mrp'] task: OWL3 prep - add `this.` to template variables Community PR : https://github.com/odoo/odoo/pull/252205
This update prepares Odoo for OWL3 by adding the `.this` keyword to template variables that reference components. This change is necessary because OWL3 requires this syntax for targeting component variables within templates. A minor fix was also applied to correct an earlier error in the conversion of boolean values.
Original PR description
…ering context In preparation for OWL3, where template variables will need to use `.this` to target component variables, we add `.this` to template variables that are targetting the component. Script PR: #247965 task: OWL3 prep - add this. to template variables
This update prepares Odoo for a new rendering system (OWL3) that requires a specific syntax (`.this`) to access component variables within templates. The team has added this syntax to several Odoo modules to ensure compatibility and future functionality. This change is a necessary step to support the upcoming OWL3 release.
Original PR description
In preparation for OWL3, where template variables will need to use `.this` to target component variables, we add `.this` to template variables that are targetting the component. Script PR: #247965 task: OWL3 prep - add this. to template variables
3 changes
Resolved issues and error corrections
This update resolves a problem where Odoo Enterprise spreadsheets could crash when taking screenshots to save as thumbnails. The fix prevents the spreadsheet from being unexpectedly closed during the screenshot process, ensuring thumbnails are consistently saved. This improves spreadsheet reliability and data backup functionality.
Original PR description
When we leave a spreadsheet, we take a screenshot of the canvas to save as thumbail. But it's sometime possible for the spreadsheet to be unmounted whe trying to screenshot it, leading to a traceback. Task: [5914708](https://www.odoo.com/web#id=5914708&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#109531
This update corrects a technical issue preventing electronic invoices under the RIMPE Emprendedor regime from being properly processed. The change ensures the correct string value is used for the invoice type, resolving a validation error related to the invoice's electronic signature. This ensures compliance with Ecuadorian tax regulations.
Original PR description
Corrected the hardcoded string for the RIMPE Emprendedor regime to match the SRI structure According to SRI technical specifications, the <contribuyenteRimpe> tag only accepts two specific values:…
Corrected the hardcoded string for the RIMPE Emprendedor regime to match the SRI structure According to SRI technical specifications, the <contribuyenteRimpe> tag only accepts two specific values: CONTRIBUYENTE RÉGIMEN RIMPE (Fixed value) CONTRIBUYENTE NEGOCIO POPULAR - RÉGIMEN RIMPE Steps to reproduce: Install l10n_ec_edi module Go to Settings > Invoicing > Ecuadorian Localization In Electronic Invoicing > Regime, select rimpe_emprendedor In Electronic Invoicing > Regime, configure a SRI Connection Post an customer invoice **Validation error occurring during the electronic signing process (using .p12 certificates):** `35 - Se encontró el siguiente error en la estructura del comprobante: cvc-pattern-valid: Value 'CONTRIBUYENTE EMPRENDEDOR - RÉGIMEN RIMPE' is not facet-valid with respect to pattern 'CONTRIBUYENTE RÉGIMEN RIMPE|CONTRIBUYENTE NEGOCIO POPULAR - RÉGIMEN RIMPE' for type 'contribuyenteRimpe'.. - ARCHIVO NO CUMPLE ESTRUCTURA XML - ERROR ` Forward-Port-Of: odoo/enterprise#109147
This update resolves an issue preventing users with the invoicing & banks role in Odoo 19.0 from accessing key transaction management features. The change grants these users the necessary permissions to view and manage duplicate and missing transactions, improving their workflow efficiency. This fix was implemented based on previous commits to ensure proper role-based access control.
Original PR description
In 19.0 we made a fix to allow users with the invoicing & banks role, to have access to duplicate transaction and missing transaction. https://github.com/odoo/enterprise/commit/748660f7ad9ca30d59f00e69d42a24864f1764d3 https://github.com/odoo/enterprise/commit/6edc057a9c0459af2b6d625415b700daf6280520 This commit will allow user with that role to access those menus task-5998895 Forward-Port-Of: odoo/enterprise#109941
12 changes
Resolved issues and error corrections
This update resolves an issue where expense reports created from incoming emails weren't being generated due to a company mismatch. The fix ensures the system always uses the employee's company when creating an expense, regardless of user assignments, preventing the 'Incompatible companies' error.
Original PR description
**Steps to reproduce:** - Install Expenses - Activate "Incoming Emails" in the settings - Configure the expense Alias - Configure an "Incoming Mail Server" - Create a Branch for a company - Create a…
**Steps to reproduce:** - Install Expenses - Activate "Incoming Emails" in the settings - Configure the expense Alias - Configure an "Incoming Mail Server" - Create a Branch for a company - Create a User: * Email Address: [an existing email address] * Allowed Companies: [the parent company + the branch company] * Default Company: [the branch company] * User Types: Internal User - Create an employee for the user in the parent company - From the email address, send a PDF to the expense alias **Issue:** The expense is not created in the database due to a UserError: "Incompatible companies on records". **Cause:** When the email is received and treated, the system tries to create an expense. From the email address, it retrieves an employee that is linked to the expense. For the company of the expense, if a user is linked to the employee, it takes the default company of the user. Otherwise, it takes the company of the employee. In this case, the company set on the expense is the default company of the user (i.e. the branch company) and the employee set on the expense belongs to the parent company ; which triggers the UserError during the company check. **Solution:** Always use the company of the employee, even if there is a user linked to the employee. opw-5346809 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A bug preventing users from copying their two-factor authentication secret via the portal has been resolved. The update corrects a technical issue where the 'copy' button's functionality was lost after a recent code change. This ensures users can reliably access and copy their security codes.
Original PR description
__Problem__ Since odoo/odoo@e3da5f1 the onclick listener set on `copyButton` is lost because we give the HTML of the body as argument at the dialog creation. __Steps to reproduce__ 1. Go to `/my/security` 2. Click on "Enable two-factor authentication" 3. Confirm password 4. Click on "Cannot scan it?" 5. The "Copy" button doesn't work __Fix__ - Inherit from `InputConfirmationDialog` to add a listener to the button. - At the same time, remove the remaining jQuery dependency in this part of the code Forward-Port-Of: odoo/odoo#251429
This update fixes a potential error in how Odoo fetches Instagram poll IDs. Previously, attempting to retrieve the ID before a poll was fully published would cause an API error. Now, Odoo checks the poll's status first, and only requests the ID when the poll is successfully published, preventing errors and ensuring reliable poll functionality.
Original PR description
Follow-up to 06256aa02cb92378933edd638259dd725a2d04c1 The Instagram API returns an error if the `ig_id` field is requested while the container is still processing. This commit splits the container status check into two steps: 1. Poll for `status_code` only to determine the current state. 2. If the status is `PUBLISHED`, perform a second request to fetch the `ig_id`. Updated the test mocks to simulate this restriction, ensuring that requesting `ig_id` on a non-published container results in a 400 error to prevent future regressions. opw-5081325
This update resolves a recurring issue where the Italian POS system generated errors when offline, specifically when printing receipts. The fix adds a safety mechanism to gracefully handle network disruptions during receipt printing, preventing crashes and improving the user experience. This ensures reliable operation even without an internet connection.
Original PR description
When loosing internet connexion a lot of tracebacks appear is the pos if we use the italian fiscal printer. Steps to reproduce: ------------------- * Setup italian fiscal printer for a shop * Open shop * Turn wi-fi off * Add items to cart * Go to payment screen > Traceback * Add a payment and validate > Traceback Why the fix: ------------ Don't try to reach the printer if we're offline regarding the price to pay. We add a try catch block around the call for printing the receipt. If the try block fails when the network is offline we assume it's just because of the offline mode. If it failed while online we raise the error. opw-5432090
This update fixes an issue where the HTML editor would reset its selection after opening the command palette. The change ensures the current selection is maintained, providing a smoother and more intuitive editing experience. This improves usability and reduces potential frustration for users.
Original PR description
Before this commit: when the whole editable regains the focus, the selection in the editable is reset to the start of it. After this commit: We create a override for hotkey service to open the command palette with an onClose to refocus the editable area without losing the current selection. For the hotkey override, we pass the area option so it's only valid in the editable area. Outside the editable, the command palette is opened in the default way. task-5949705 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a confusing error message in the Odoo stock module that previously didn't identify the specific package causing the issue. By adding the package name to the error, users can quickly diagnose and resolve problems, especially during large product transfers. This improves usability and reduces support requests.
Original PR description
The current error does not specify which package is problematic. This cause issues on big transfers with many products / packages. Specifying the package in the error helps the customer identify the issue, and correct it themselves. OPW-5923839 --- <img width="673" height="252" alt="image" src="https://github.com/user-attachments/assets/0ccb45be-d813-4933-86fd-0dd3506d2775" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249290
This update resolves an issue where emails with attachments using the 'bin/plain' MIME type would cause the system to fail to process them. The fix now handles this attachment type by falling back to a standard format, ensuring all incoming emails, including vendor bill creation, are correctly processed.
Original PR description
When parsing incoming emails, mail.thread normalizes some malformed MIME types before calling part.get_content(). However, attachments using Content-Type `bin/plain` are not normalized. As a result,…
When parsing incoming emails, mail.thread normalizes some malformed MIME types before calling part.get_content(). However, attachments using Content-Type `bin/plain` are not normalized.
As a result, Python's email content manager raises KeyError('bin/plain') during parsing, which aborts the whole message processing. This prevents the incoming email from being processed, including vendor bill creation from email aliases.
Steps to reproduce:
- build an email with an attachment using Content-Type `bin/plain`
- parse it through `mail.thread.message_parse`
Before this commit, parsing crashes with KeyError('bin/plain').
This commit treats `bin/plain` like the other unsupported attachment MIME types already handled in stable, by falling back to `application/octet-stream`, allowing the message to be parsed and the attachment to be preserved.
opw-5439156
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#251440This update ensures that self-order prices are consistently calculated by the backend before payment processing. Currently, changes made to product prices via the client-side interface could lead to incorrect payment amounts without any notification. This fix guarantees accurate pricing for self-order transactions, improving financial reporting and trust.
Original PR description
The price computation is done on the backend only for combo products. This means that someone can order stuff on the self order, change the price of the products through JS on the client, and then when they go to pay the backend would generate a payment for the modified price and register everything as normal without any indication to the owner that the price was modified. This change will force the backend to recompute the price before creating the payment based on the standard prices defined on the backend. This only applies on self orders, so cashiers should still be able to modify prices on the frontend of the normal POS Task-[5864068](https://www.odoo.com/odoo/project/1737/tasks/5864068) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue in the payroll batch payslip wizard where the displayed contract type was incorrectly defaulting to the first contract, regardless of its status. Now, the wizard accurately reflects the running contract type for employees with multiple active contracts, ensuring accurate payroll calculations.
Original PR description
Currently, in the batch payslip wizard, the 'Salary Structure Type' is determined by the first contract found for the employee. ### **Steps to Reproduce:** 1) Install Payroll. 2) Create an employee…
Currently, in the batch payslip wizard, the 'Salary Structure Type' is determined by the first contract found for the employee. ### **Steps to Reproduce:** 1) Install Payroll. 2) Create an employee with two contracts: - Contract A: Expired, From DEC 1st 2025 to 31st DEC 2025, salary structure as 'Employee' - Contract B: Running, Starts from Jan 1st 2026, salary structure as 'worker'. 3) Navigate to Payroll>payslips>Batches and click 'Generate Payslips'. ### **Observed Behaviour:** The column displays the Structure Type of Contract A(Expired): `Employee`. ### **Expected Behaviour:** The column should display Contract B(Running) in the Structure Type column: `Worker`. ### **Root Cause:** The `structure_type_id` field was defined as a related field on `contract_ids`. Due to this, it always fetches the first record based on the default sort order. ### **Fix:** Replace the relation of structure_type_id with `contract_id`. To ensure running contracts (state='open') are recieved, regardless of their start dates. **opw-5311933**
This update fixes several issues related to the mobile view of online orders, including missing buttons and order cancellation problems. Users can now consistently access order details and seamlessly cancel Swiggy online orders, improving the overall mobile ordering experience. This enhancement ensures a smoother and more reliable process for mobile users.
Original PR description
*: pos_restaurant_urban_piper Before this commit: ========== - "Load Order" and "Review" buttons were not visible for online orders. - The "Review" button was missing for paid online orders, preventing users from reviewing their orders. - The "Info" button was not visible for paid orders, restricting users from checking order details after payment. - A traceback occurred when cancelling a Swiggy online order. After this commit: ========== - Improved mobile view for online orders, ensuring a more consistent user experience. - Fixed the issue preventing Swiggy online order cancellations, allowing seamless cancellations. Related PR: - https://github.com/odoo/odoo/pull/213769 task-4657597
This change reverts a recent update that was causing unnecessary complexity in stock management. Previously, multiple stock transfers for the same supply chain were grouped together, streamlining the process for users. This prevents the creation of redundant pickings and reduces manual effort, particularly in scenarios like replenishing warehouses.
Original PR description
This reverts [1]. Let's quote the commit: > - `Observation`: the next transfers for both receipts are merged into a single > transfer, even though both receipts were created manually and not generated > from any common source document like PO/SO. The above behavior was and is the expected one for years and should not suddenly change on stable. Even the tests were protecting the cases but [1] have changed the `assert`. Commit [1] quickly leads to the creation of tickets. For instance, in the mentioned OPW, where the user resupplies a warehouse from another one: he now has several pickings for the same supply chain, which lead to extra work (e.g., printing all the pickings) [1] https://github.com/odoo/odoo/commit/840b42fd2365a652e53d607f38ac78ccb8dd63dc OPW-6011532
This update reverts a previous change that disrupted the initial state of quality control tests. This fix ensures that the tests are functioning correctly, preventing potential issues with product quality checks. The change is related to a previous revert and is tracked under OPW-6011532.
Original PR description
This reverts [1]. It happens because of a revert OC side, cf linked commit. [1] a01d8f0e15de973a94c360c3911e74b768a3aebc OPW-6011532
2 changes
Resolved issues and error corrections
This change corrects a naming error in the ZUGFeRD eInvoice XML file, resolving validation issues with several key e-invoice validators. Previously, the validator incorrectly flagged the file, but now the ZUGFeRD file passes validation across multiple platforms, ensuring proper e-invoice processing and compliance.
Original PR description
Fix the name of the embedded xml for zugferd eInvoice format. Before this PR: For the validator https://www.portinvoice.com/en/, the error > No, the file is called zugferd.xml. The following naming conventions are > permitted: “factur-x.xml”, “xrechnung.xml”, “zugferd-invoice.xml”, > “ZUGFeRD-invoice.xml”, “order-x.xml”, “cida.xml” And also: > The XML has a valid profile? No This corresponds to the document_context, as the french factur-x and the german ZUGFeRD are a common standard, we can put the same context. After this PR: The ZUGFeRD file passes on different validators. Validators: * https://erechnungs-validator.de/ * https://easyfirma.net/e-rechnung/validieren * https://www.portinvoice.com/en/ * https://demo.verapdf.org/ task-6010416 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where generating financial reports (FAIA) for Luxembourg companies using multi-currency transactions resulted in errors. The fix ensures the necessary currency information is included in the report template, preventing rendering problems and ensuring accurate financial reporting.
Original PR description
Steps to reproduce 1/ setup a LU company. The default company currency will be EUR. 2/ create a vendor bill in another currecy (e.g. USD) 3/ take note of the bill date and accounting date (ideally set them in the past, like 1 month) 4/ generate the FAIA report for the period containing the created bill => error while rendering the qweb template The core of the error is when rendering the l10n_lu saft template. Sales invoices and purchase invoices reuse the standard `account_saft.tax_information` report, which expects to find `currency_code` in the object's fields. This commit explicitly re-adds it when creating the document's tax summary. opw-5216057