Daily updates from Odoo
Navigate
Branch
Monday, February 10, 2025
76 changes
21 changes
New functionality added to Odoo
This change adds a new Gelato connector to support print-on-demand product fulfillment from Odoo sales flows. It introduces related delivery, product, company, and settings configuration so businesses can manage Gelato-based orders more directly inside Odoo.
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
Resolved issues and error corrections
This fixes a display issue in the mass mailing editor where the snippet sidebar could slide under the control panel when using the Event Promo template at higher browser zoom levels. The sidebar now adjusts to the template height while scrolling, keeping the editor controls visible and easier to use.
Original PR description
How to reproduce: 1. create a new mailing. 2. from the existing available Mail Body templates, select Event Promo. 3. zoom In to around 125% or greater scale. 4. scroll the page to the end. Issue: 5.…
How to reproduce: 1. create a new mailing. 2. from the existing available Mail Body templates, select Event Promo. 3. zoom In to around 125% or greater scale. 4. scroll the page to the end. Issue: 5. as you scroll, you will notice the snippet sidebar stays sticky till a certain point, but as we reach the end of the template itself, and the page starts to scroll, the sidebar goes under the control panel. video of the issue --> https://www.awesomescreenshot.com/video/33360044?key=46734c8ba59b1144830c3939e24ed12f Reason: 7. in previous version (i.e. 17.0) the sidebar's top and bottom was dynamically controlled on every scroll. refer --- https://github.com/odoo/odoo/blob/17.0/addons/mass_mailing/static/src/js/mailing_mailing_view_form_full_width.js#L91-L96 8. we use `position: sticky` in the current version to achieve that outcome, but when the template itself starts to scroll, the stickiness disappears. Fix: 9. once the page has started scrolling we recalculate the height of the sidebar to match it with the height of the template. Task-4137980
Fixed a display issue in mass mailing templates where the editing sidebar could overlap the email content after returning to a template. This makes template editing more reliable and prevents layout confusion for users.
Original PR description
Previously, the has_snippets_sidebar class was only applied when clicking the template during creation. Now, the fix ensures that the class is correctly applied on load, preventing the body from overlapping with the sidebar when returning to the template. Task-4266339
This fixes an issue where the second step of a two-step delivery could be sent to the general customer location instead of the specific customer sub-location. Businesses using detailed customer delivery locations will now see stock transfers created with the correct destination, reducing delivery errors and manual corrections.
Original PR description
to reproduce: ============= - make warehouse with 2-step delivery - create contact with Customer Location = Partners/Customers/Test (make sure location type = Customer location) - create a sale order with this contact - confirm the sale order - confirm first delivery -> the second delivery is created but the destination location is set to **Partners/Customers** instead of **Partners/Customers/Test** Problem: ======== - starting from 17.2 the second pick is created after validating the first one at creation used vals received from the move has the wrong destination location, it will be recomputed after creating the second pick but it's too late to change the destination location of the second pick Solution: ========= - recompute the destination location of move when preparing vals of the second pick opw-4374075 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Spreadsheet pivot formulas now show the available measures when a user enters an invalid measure. This helps users correct mistakes faster and reduces confusion when working with pivot reports.
Original PR description
Before this commit, applying a pivot formula with an invalid measure returns an error message without showing possible measures. This commit fixed that Task 3754942 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The FACe/Factura-e section on invoices now appears only when the related company is located in Spain. This avoids showing Spain-specific electronic invoicing fields to companies in other countries, reducing confusion for users.
Original PR description
We should show the FACe/Factura-e section on invoice when the related company is located in Spain. opw-4397651 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a payment validation issue where incoming payments could be blocked by a requirement intended for outgoing payments. It helps avoid confusion and supports payment methods such as Italian RiBa that need a bank account for incoming money without treating it as an outgoing payment.
Original PR description
The `require_partner_bank_account` flag on the payment shouldn't require the `allow_out_payment` flag on it when the payment type is `inbound` as it leads to confusion. This generates an issue with the `l10n_it_riba` RiBa payment method. It requires the bank account, but the money is incoming, not outgoing. Enterprise PR: odoo/enterprise#77901 Task [link](https://www.odoo.com/odoo/project/967/tasks/4497749) task-4497749
This fix improves how invoice changes are protected from unintended automatic recalculations during updates. It helps keep accounting data consistent when invoices or invoice lines are created or modified.
Original PR description
Missing commit from the forward-port of https://github.com/odoo/odoo/pull/193528
Miscellaneous changes
When creating a SOL on the fly from a project or a ticket, we try to match an existing product from what was typed in the field. However, we should be excluding recurring services Task-4354482 Forward-Port-Of: odoo/odoo#188309
Original PR description
When creating a SOL on the fly from a project or a ticket, we try to match an existing product from what was typed in the field. However, we should be excluding recurring services Task-4354482 Forward-Port-Of: odoo/odoo#188309
Fixup for this commit https://github.com/odoo/odoo/commit/c9cefd88bb6f38f8fd504b7c4a8abf263aa1aa4b A test in 17.4 highlighted a issue with the use of with_context which was overriding it completely instead of adding to it. opw-4310781 Forward-Port-Of: odoo/odoo#196901
Original PR description
Fixup for this commit https://github.com/odoo/odoo/commit/c9cefd88bb6f38f8fd504b7c4a8abf263aa1aa4b A test in 17.4 highlighted a issue with the use of with_context which was overriding it completely instead of adding to it. opw-4310781 Forward-Port-Of: odoo/odoo#196901
The state changes right check was only done on specific method but it wasn't check at write level. Which allowed to bypass it. The record rule on hr_expense_user without a check on the state is in draft allow to change data on approved expense sheets. Forward-Port-Of: odoo/odoo#180400 Forward-Port-Of: odoo/odoo#165663
Original PR description
The state changes right check was only done on specific method but it wasn't check at write level. Which allowed to bypass it. The record rule on hr_expense_user without a check on the state is in draft allow to change data on approved expense sheets. Forward-Port-Of: odoo/odoo#180400 Forward-Port-Of: odoo/odoo#165663
Revert changes from [commit] due to `m.facebook.com` using 'X-Frame-Options' header set to 'deny', which prevented iframe embedding across domains. META has now fixed this issue, so this PR restores the snippet's visibility on mobile devices. [commit]: https://github.com/odoo/odoo/commit/588f910da03d6284a57c2fab8fd042ef3169666f task-4507102 Forward-Port-Of: odoo/odoo#195853 Forward-Port-Of: odoo/odoo#194843
Original PR description
Revert changes from [commit] due to `m.facebook.com` using 'X-Frame-Options' header set to 'deny', which prevented iframe embedding across domains. META has now fixed this issue, so this PR restores the snippet's visibility on mobile devices. [commit]: https://github.com/odoo/odoo/commit/588f910da03d6284a57c2fab8fd042ef3169666f task-4507102 Forward-Port-Of: odoo/odoo#195853 Forward-Port-Of: odoo/odoo#194843
__Current behavior before commit:__ If an unexpected error that has no body is thrown inside `printHtml`, the popup shows "undefinedDo you want to print using the web printer?" and nothing is written in the console, making it impossible to troubleshoot. __Description of the fix:__ Don't print "undefined" in the popup if the error has no body but write the error in the console. opw-4322339 Forward-Port-Of: odoo/odoo#194985
Original PR description
__Current behavior before commit:__ If an unexpected error that has no body is thrown inside `printHtml`, the popup shows "undefinedDo you want to print using the web printer?" and nothing is written in the console, making it impossible to troubleshoot. __Description of the fix:__ Don't print "undefined" in the popup if the error has no body but write the error in the console. opw-4322339 Forward-Port-Of: odoo/odoo#194985
__Current behavior before commit:__ Sometimes when a Worldline terminal makes a payment with Edenred or Sodexo, it creates a ticket with special ascii characters like `0x0E` that are not supposed to be printed. Some of those characters make the [`createImage`][1] method throw an error with the `onerror` Event. __Description of the fix:__ Added the `sanitizeNodeText` function to remove all problematic ascii characters that should not be printed anyway. Added a test to make sure `htmlToCanva
Original PR description
__Current behavior before commit:__ Sometimes when a Worldline terminal makes a payment with Edenred or Sodexo, it creates a ticket with special ascii characters like `0x0E` that are not supposed to be printed. Some of those characters make the [`createImage`][1] method throw an error with the `onerror` Event. __Description of the fix:__ Added the `sanitizeNodeText` function to remove all problematic ascii characters that should not be printed anyway. Added a test to make sure `htmlToCanvas` can handle all ascii characters without crashing. opw-4322339 [1]:https://github.com/odoo/odoo/blob/a98e802976f6798f3aea07231a366fbcd8002ce2/addons/point_of_sale/static/src/app/utils/html-to-image.js#L217 Forward-Port-Of: odoo/odoo#195004
Repro steps: - Add `Tax String` to `Product Page Extra Fields` for one of your websites - Add taxes from a company that isn't linked to that website for one of your products - Open that product's product page in eCommerce - You get an access error The issue is that we try to read the taxes for all companies when opening the product page. Instead, we should only read the taxes for the current company. opw-4435721 Forward-Port-Of: odoo/odoo#194881
Original PR description
Repro steps: - Add `Tax String` to `Product Page Extra Fields` for one of your websites - Add taxes from a company that isn't linked to that website for one of your products - Open that product's product page in eCommerce - You get an access error The issue is that we try to read the taxes for all companies when opening the product page. Instead, we should only read the taxes for the current company. opw-4435721 Forward-Port-Of: odoo/odoo#194881
This error occurs when a user does not enter a Webhook Secret. As a result, when processing the payment, the missing secret causes the verification to fail, leading to a payment failure. - Install the `eCommerce` module without demo data and with Indian localization. - Install `Razorpay payment provider` and activate `developer mode`. - Add `Key ID` and `Key Secret` in Razorpay payment `provider`. - Set up webhook in Razorpay dashboard with a random `Webhook Secret`. - Go to the `website`
Original PR description
This error occurs when a user does not enter a Webhook Secret. As a result, when processing the payment, the missing secret causes the verification to fail, leading to a payment failure. - Install…
This error occurs when a user does not enter a Webhook Secret. As a result, when processing the payment, the missing secret causes the verification to fail, leading to a payment failure. - Install the `eCommerce` module without demo data and with Indian localization. - Install `Razorpay payment provider` and activate `developer mode`. - Add `Key ID` and `Key Secret` in Razorpay payment `provider`. - Set up webhook in Razorpay dashboard with a random `Webhook Secret`. - Go to the `website`, add the product to the cart, and proceed to payment using `UPI`.` `Error: 'bool' object has no attribute 'encode'` This issue occurs because the Webhook Secret is missing, returning False and causing payment verification to fail. This commit solves the error by handling missing `Webhook Secret` values by logging a warning and skipping the signature check instead of returning a False. Sentry: 6208134651 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196125
### Steps to reproduce: - Create a storable product FP tracked by SN with a BOM: - 1 Operation: - instruction: Register Production type (per product) - 1 x Comp (storable product in stock) - Create and confirm an MO for one unit of FP. - Go to the shopfoor app > open the instruction of your operation - Type a non-existing serial number in the search bar > Create "new_sn" > This opens a form view of the stock.lot model - Save and close the new stock.lot > Invalid operation: You
Original PR description
### Steps to reproduce: - Create a storable product FP tracked by SN with a BOM: - 1 Operation: - instruction: Register Production type (per product) - 1 x Comp (storable product in stock) - Create…
### Steps to reproduce:
- Create a storable product FP tracked by SN with a BOM:
- 1 Operation: - instruction: Register Production type (per product)
- 1 x Comp (storable product in stock)
- Create and confirm an MO for one unit of FP.
- Go to the shopfoor app > open the instruction of your operation
- Type a non-existing serial number in the search bar > Create "new_sn"
> This opens a form view of the stock.lot model
- Save and close the new stock.lot
> Invalid operation: You are not allowed to create or edit a lot or serial number for the components with the operation type
> "Manufacturing". To change this, go on the operation type and tick the box "Create New Lots/Serial Numbers for
> Components"
#### Expected behavior:
The invalid operation should not be raised as the "required" option concerns only componenets and not final products.
### Cause of the issue:
Creating a stock lot will first launch a call of the `_check_create`: https://github.com/odoo/odoo/blob/c25d71f14fa168807f07cd88bed805d15db8add5/addons/stock/models/stock_lot.py#L150-L153 However, since this check does not verifies that the product for which we create the lot is indeed related to a component of the MO it will raise the invalid operation even for final products: https://github.com/odoo/odoo/blob/c25d71f14fa168807f07cd88bed805d15db8add5/addons/mrp/models/stock_lot.py#L11-L17
### Issue 2:
Currently, the `quickCreate` ("Create *sn_name*") option of the lot field of te "register production" dialog calls a `name_create` that will set an error message in the logs as the product_id required field can not be provided neither in the vals or the context of the `name_create`. You then fall back on the same form dialog than the "Create and edit". The `quickCreate` option should therefore just be disabled.
Enterprise: https://github.com/odoo/enterprise/pull/77265
opw-4452747
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#193965if they use import export or any automated action that write same journal then it's take new number. here assume that journal_id is only change on draft and if posted then it's raise error but not consider what is same journal_id come to write. 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#19
Original PR description
if they use import export or any automated action that write same journal then it's take new number. here assume that journal_id is only change on draft and if posted then it's raise error but not consider what is same journal_id come to write. 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#196777
Scenario: set a menu to be visible only to a group you don't have Result: the menu is not shown in the list of menu on the group form view Why: in 17.0, web_read was added that is adding a search for ordering results of x2many according to order in specification. This is interfering with custom code of ir.ui.menu that is filtering out menu that are not visible (in the interface) to you. Fix: add context key that bypass the ir.ui.menu filtering in the res.groups window action. opw-4376374 For
Original PR description
Scenario: set a menu to be visible only to a group you don't have Result: the menu is not shown in the list of menu on the group form view Why: in 17.0, web_read was added that is adding a search for ordering results of x2many according to order in specification. This is interfering with custom code of ir.ui.menu that is filtering out menu that are not visible (in the interface) to you. Fix: add context key that bypass the ir.ui.menu filtering in the res.groups window action. opw-4376374 Forward-Port-Of: odoo/odoo#195329
This is a backport of 183741 which missed earlier versions where attendance geolocation is available. Forward-Port-Of: odoo/odoo#193393
Original PR description
This is a backport of 183741 which missed earlier versions where attendance geolocation is available. Forward-Port-Of: odoo/odoo#193393
In the survey stats, the number of votes for a multiple choice answer displayed the label "Votes" without it being translatable. This commit makes it translatable. [task-4421055](https://www.odoo.com/odoo/project.task/4421055) Forward-Port-Of: odoo/odoo#196856 Forward-Port-Of: odoo/odoo#196704
Original PR description
In the survey stats, the number of votes for a multiple choice answer displayed the label "Votes" without it being translatable. This commit makes it translatable. [task-4421055](https://www.odoo.com/odoo/project.task/4421055) Forward-Port-Of: odoo/odoo#196856 Forward-Port-Of: odoo/odoo#196704
29 changes
New functionality added to Odoo
Businesses can now send WhatsApp text confirmations when validating delivery orders, alongside the existing SMS option. This helps customers receive delivery updates through a widely used messaging channel, provided an approved WhatsApp template is configured.
Original PR description
PURPOSE This commit adds a feature to send WhatsApp messages as a text confirmation while validating a delivery order, similar to the existing functionality for SMS. SPECIFICATION This module introduces a new feature that allows sending text confirmation using WhatsApp when validating a delivery order. This can be done by ticking the `Text Confirmation` and selecting WhatsApp within the shipping settings. It is required to define an approved WhatsApp template that applies to the `stock.picking` model for sending text confirmation. Related Upgrade PR: https://github.com/odoo/upgrade/pull/5758 Task-3510974
Enhancements to existing features
This update adds a reworked Mexican payroll localization designed to comply with local authority requirements. It enables payroll processing for full-time jobs in Mexico, with other employment cases planned separately, and includes small fixes for Australian payroll handling.
Original PR description
This is a rework of the mexican localisation to make it compliant with the local authorities. In our case, it will be a working system only for the full-time jobs. The other cases will be coming separately. Task: 3673251
The bank reconciliation view now clearly labels entries that are not linked to a bank statement with “No bank Statement.” This makes it easier for users to distinguish these entries at a glance and reduces confusion during reconciliation.
Original PR description
Before this change, lines without statements were visually indistinguishable from those with statements in the bank reconciliation view. This update improves clarity by ensuring such lines are easier to differentiate by adding "No bank Statement" above the lines task: 4412424
Odoo can now hide or show menu entries based on business conditions, such as the companies a user can access. This helps keep navigation cleaner and more relevant for each user without custom workarounds.
Original PR description
This commit adds the ability to conditionally render menus. This is done by adding a new field: `web_invisible`. Note that, this field accepts Python expressions. task-id: 4250356
This update modernizes automated tests for several Odoo Studio editing tools, including reports, lists, calendars, maps, charts, pivots, and new model creation. It helps ensure these Studio features remain stable and easier to maintain, without changing day-to-day user workflows.
This update improves automated checks around test bundles in Odoo Enterprise. It helps ensure export-related behavior in Web Studio remains reliable without introducing direct user-facing changes.
The Gantt view is easier to work with thanks to more compact rows, steadier drag behavior, and faster creation when selecting time cells. Planning users also get smoother shift splitting because split controls no longer interfere with dragging scheduled items.
Original PR description
We improve the gantt view in several aspects: - the height of rows is a bit reduced so that more data is visible - the pills do not rotate when dragged - the form dialog is directly opened when one or several cells are selected by drag and drop - (planning) the splitting tools do not block the drag and drop of pills anymore Task ID: 4350819
Follow-up levels that assign activities to salespeople now create activities for every salesperson linked to the invoices in the follow-up. This helps ensure all responsible salespeople are notified, reducing missed follow-up actions when several salespeople are involved.
Original PR description
When a follow-up level is set to create an activity to Salespeople, it now creates an activity to all Salespersons from all Invoices part of the follow-up. Where before an activity would only be created for one SSalespersons. Task: 4374391
Activity summaries for tax report reminders no longer repeat the deadline, since the due date is already shown separately. This makes dashboard activities shorter and easier for users to scan.
Original PR description
We're removing the "deadline" from the summary as the actual deadline on the activity is enough for the users to know when it is due. This also makes the activity look more concise and easier to read on the dashboard. Task ID: 4501944
Resolved issues and error corrections
This update streamlines how live chat creates and manages helpdesk tickets, making the process easier to maintain and less prone to errors. It also updates related tests to help ensure ticket access and timesheet behavior remain reliable.
Original PR description
follow up of task-4432728 community: https://github.com/odoo/odoo/pull/196567
The Belgian payroll declaration export has been corrected so users can generate the 274.XX XML file successfully. This helps payroll teams complete required reporting without being blocked by an export error.
Original PR description
STEP TO REPRODUCE: 1- Install The belgium payroll 2- Go to Payroll 3- Go to reporting > Declaration 274.XX 4- Click on generate xml file
Opening documents from a record's documents button now applies the correct filter and creation context, so newly created documents stay linked to the original record. The update also removes unused document action code and simplifies how user and contact document links are maintained.
Original PR description
Bug === 1. Open the form view of `fleet.vehicle` e.g. 2. Click on the documents stat button => The domain is not set => If you create a document it won't be linked to the `fleet.vehicle` Remove dead code and simplify some related code. Simplify the document_ids field on res.users / `res.partner`. Task-4550993
Miscellaneous changes
Steps: - enable rental transfers - activate MTO route - create a product with MTO route and 0 stock - create a rental order for that product, validate Issue: The rental order will create 2 pickings that are waiting for each other. This is because the MTO move is using the same rental route with the stock destination, so it ends on the return rental picking. Fix: Force the procurement to use the `route_id` of the `rule_id` of the origin move. This way it will correctly create a new
Original PR description
Steps: - enable rental transfers - activate MTO route - create a product with MTO route and 0 stock - create a rental order for that product, validate Issue: The rental order will create 2 pickings that are waiting for each other. This is because the MTO move is using the same rental route with the stock destination, so it ends on the return rental picking. Fix: Force the procurement to use the `route_id` of the `rule_id` of the origin move. This way it will correctly create a new picking from Vendor to Stock for the product. If the product has a Buy or Manufacture route, it will use those instead. Also found another issue when enabling, then disabling, then re-enabling rental pickings: the stock rule stays archived. It is now fixed and a test has been added. Forward-Port-Of: odoo/enterprise#78648 Forward-Port-Of: odoo/enterprise#76477
GroupingCategory and GroupingCode nodes have changed from optional to mandatory in SAF-T V1.3. For the category, we use RF-1167 for now as it's the most common value. task-4374014 Forward-Port-Of: odoo/enterprise#78778 Forward-Port-Of: odoo/enterprise#77423
Original PR description
GroupingCategory and GroupingCode nodes have changed from optional to mandatory in SAF-T V1.3. For the category, we use RF-1167 for now as it's the most common value. task-4374014 Forward-Port-Of: odoo/enterprise#78778 Forward-Port-Of: odoo/enterprise#77423
The override of `_action_launch_stock_rule` was passing its `previous_product_uom_qty` keyword argument as a positional parameter to the `super` call, preventing other overrides from passing it with its key name. This commit ensures that the argument is now passed correctly with its key name. It also makes the override kwargs-agnostic by packing and unpacking them with `**`, thus preventing future issues related to signature changes in the parent method. See also: - https://github.com/odo
Original PR description
The override of `_action_launch_stock_rule` was passing its `previous_product_uom_qty` keyword argument as a positional parameter to the `super` call, preventing other overrides from passing it with its key name. This commit ensures that the argument is now passed correctly with its key name. It also makes the override kwargs-agnostic by packing and unpacking them with `**`, thus preventing future issues related to signature changes in the parent method. See also: - https://github.com/odoo/enterprise/pull/77839 - https://github.com/odoo/documentation/pull/11823 Forward-Port-Of: odoo/enterprise#78786 Forward-Port-Of: odoo/enterprise#77839
Issue: ------ When making changes in version 17.0 using studio the correspondent standard view's noupdate becomes 'True' as per the logic implemented. But when we migrate the database to the further versions like 18.0. The changes made in that particular view in 18.0 will not be loaded and will cause errors since its inherited view's will not be compatible enough. For ex: If we make changes in a "Purchase Order"(i.e; purchase.report_purchaseorder) report then after saving the changes the n
Original PR description
Issue: ------ When making changes in version 17.0 using studio the correspondent standard view's noupdate becomes 'True' as per the logic implemented. But when we migrate the database to the further…
Issue: ------ When making changes in version 17.0 using studio the correspondent standard view's noupdate becomes 'True' as per the logic implemented. But when we migrate the database to the further versions like 18.0. The changes made in that particular view in 18.0 will not be loaded and will cause errors since its inherited view's will not be compatible enough. For ex: If we make changes in a "Purchase Order"(i.e; purchase.report_purchaseorder) report then after saving the changes the noupdate of that report view which is "purchase.report_purchaseorder_document" will be updated to 'true'. And the action record i.e; "purchase.action_report_purchase_order" noupdate will be updated to 'true'.   If the customer makes changes using studio then those changes will be recorded in the studio view and there is no point of making the standard view's noupdate to 'true'. Solution: ----------- Remove redundant code to overcome updating noupdate to 'true'. Steps to reproduce: ------------------------ 1. Create a database in version 17.0. 2. Make changes in any report using studio and save. 3. Migrate the database and try opening that report. 4. You'll encounter issues due to incompatibilty of views. Since, the changes made in the standard will not be loaded because it's noupdate is true. REF PRS: Enterprise PR: 1.https://github.com/odoo/enterprise/commit/2ae63d9a43ba973d905232105201d88e423a8245#diff-cf8f46a54f86279b4d773f0d39b23d22f046eb6d33a39c851f2a86dcd2b5b202R463 Forward-Port-Of: odoo/enterprise#78582
Before this commit, the /my/subscriptions/<int:order_id>/transaction route would create a draft invoice when it was called to anticipate a payment. post processing of payment.transaction is able to create the invoice and to associate it with the correct sale.order. In order to simplify the code by limiting the part of the code where subscription invoices can be created, we decided to let the _post_process do the work. taskid: 4368037 Forward-Port-Of: odoo/enterprise#77432
Original PR description
Before this commit, the /my/subscriptions/<int:order_id>/transaction route would create a draft invoice when it was called to anticipate a payment. post processing of payment.transaction is able to create the invoice and to associate it with the correct sale.order. In order to simplify the code by limiting the part of the code where subscription invoices can be created, we decided to let the _post_process do the work. taskid: 4368037 Forward-Port-Of: odoo/enterprise#77432
During testing of the "new" Chrome's headless mode (by default since version 128), a concurrency issue arise at the end of those tours: a last request to the server is actually sent during the unload of the view. This request actually reach the server even if Chrome is already closed and the test is cleaning itself (rollbacking the changes made in the database), resulting into a "release savepoint" mismatch on an already aborted transaction (example build's error [1]). This commit is kind of
Original PR description
During testing of the "new" Chrome's headless mode (by default since version 128), a concurrency issue arise at the end of those tours: a last request to the server is actually sent during the unload of the view. This request actually reach the server even if Chrome is already closed and the test is cleaning itself (rollbacking the changes made in the database), resulting into a "release savepoint" mismatch on an already aborted transaction (example build's error [1]). This commit is kind of a follow-up of a previous PR [2] where a last step allowing for the spreadsheet to unload was added and adding one more to actually wait to be back on the Document app. [1] https://runbot.odoo.com/runbot/build/74602509 [2] https://github.com/odoo/enterprise/pull/51795 Forward-Port-Of: odoo/enterprise#78896 Forward-Port-Of: odoo/enterprise#78797
During testing of the "new" Chrome's headless mode (by default since version 128), a concurrency issue arise at the end of those tours: a last request to the server is actually sent during the unload of the view (cf. save). This request actually reach the server even if Chrome is already closed and results into a SQl constraint error. Indeed, the (very basic) form views created for those tours are based on the "res.partner" model and only display the "name" field. This field isn't marked as "
Original PR description
During testing of the "new" Chrome's headless mode (by default since version 128), a concurrency issue arise at the end of those tours: a last request to the server is actually sent during the unload of the view (cf. save). This request actually reach the server even if Chrome is already closed and results into a SQl constraint error. Indeed, the (very basic) form views created for those tours are based on the "res.partner" model and only display the "name" field. This field isn't marked as "required" neither in the model, nor the view BUT has a SQL constraint attached to it... which makes it implicitly "required". This commit fixes it by properly marking them as such in the arch to let the client-side validation prevent the ultimate "save" request made during the unload. Forward-Port-Of: odoo/enterprise#78903 Forward-Port-Of: odoo/enterprise#78810
Versions -------- - 17.0+ Steps ----- 1. Use Belgian localization; 2. create an invoice for a Belgian customer; 3. pay the invoice using SEPA Direct Debit; 4. go to Accounting / Bank; 5. create a bank statement matching the SDD mandate details; 6. go to payment transactions linked to the invoice. Issue ----- The transaction is still pending, and the SDD Mandate hasn't been confirmed. Cause ----- When matching transactions to bank statement lines, it checks whether `tx.refer
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Use Belgian localization; 2. create an invoice for a Belgian customer; 3. pay the invoice using SEPA Direct Debit; 4. go to Accounting / Bank; 5. create a bank statement matching the SDD mandate details; 6. go to payment transactions linked to the invoice. Issue ----- The transaction is still pending, and the SDD Mandate hasn't been confirmed. Cause ----- When matching transactions to bank statement lines, it checks whether `tx.reference == line.payment_ref`. The `tx.reference` is based on the invoice name, whereas `payment_ref` depends on localization, with Belgian payment request being structured as `+++000/0000/12345+++`. Solution -------- When creating a SDD mandate transactions, display `tx.reference` as payment communication. opw-4380832 Forward-Port-Of: odoo/enterprise#78787 Forward-Port-Of: odoo/enterprise#78413
It is possible for a user to empty the value for `l10n_au_medicare_reduction` from an employee's form. Since this field is used in the computation of `l10n_au_tax_treatment_code`, doing so will trigger an error: ``` File "/home/odoo/src/enterprise/18.0/l10n_au_hr_payroll/models/hr_employee.py", line 347, in _compute_l10n_au_tax_treatment_code code += rec.l10n_au_medicare_reduction # Sixth Character TypeError: can only concatenate str (not "bool") to str ``` This error can also happe
Original PR description
It is possible for a user to empty the value for `l10n_au_medicare_reduction` from an employee's form. Since this field is used in the computation of `l10n_au_tax_treatment_code`, doing so will trigger an error:
```
File "/home/odoo/src/enterprise/18.0/l10n_au_hr_payroll/models/hr_employee.py", line 347, in _compute_l10n_au_tax_treatment_code
code += rec.l10n_au_medicare_reduction # Sixth Character
TypeError: can only concatenate str (not "bool") to str
```
This error can also happen during upgrades, when employee records are created before the module `l10n_au_hr_payroll` is loaded.
Forward-Port-Of: odoo/enterprise#78834[task-4421055](https://www.odoo.com/odoo/project.task/4421055) Forward-Port-Of: odoo/enterprise#78734
Original PR description
[task-4421055](https://www.odoo.com/odoo/project.task/4421055) Forward-Port-Of: odoo/enterprise#78734
With the introduction of Invoicing Enterprise (access to bank recon etc) a new user group was created "Invoicing & Banks" (`group_account_basic`) This group should also be able to access the customer statement / partner ledger (from the partner smart button) Task-4465208 Forward-Port-Of: odoo/enterprise#78807
Original PR description
With the introduction of Invoicing Enterprise (access to bank recon etc) a new user group was created "Invoicing & Banks" (`group_account_basic`) This group should also be able to access the customer statement / partner ledger (from the partner smart button) Task-4465208 Forward-Port-Of: odoo/enterprise#78807
Steps to Reproduce: - create a helpdesk ticket from the website form without attachments. - creation message in the chatter is missing. Cause: - subtype_id for helpdesk ticket messages was explicitly set in the bridge module's insert_attachment method. When no attachments were present, this prevented the _creation_subtype logic in the helpdesk.ticket model from executing, resulting in the missing creation message. Solution: - Added a condition in the insert_attachment method to skip mo
Original PR description
Steps to Reproduce: - create a helpdesk ticket from the website form without attachments. - creation message in the chatter is missing. Cause: - subtype_id for helpdesk ticket messages was explicitly set in the bridge module's insert_attachment method. When no attachments were present, this prevented the _creation_subtype logic in the helpdesk.ticket model from executing, resulting in the missing creation message. Solution: - Added a condition in the insert_attachment method to skip modifying messages when no attachments are present. It ensures that the default _creation_subtype logic handles subtype assignment, maintaining consistent and accurate creation message logging in the chatter. task-4397661 Forward-Port-Of: odoo/enterprise#78777 Forward-Port-Of: odoo/enterprise#76111
In the tree view of the payslip model, we can do mass edit to create a journal entry. Before, we were able to perform this action on a paid payslip which does not make sense. Now we have an error message if we try to do it. Task: 3874129 Forward-Port-Of: odoo/enterprise#78730 Forward-Port-Of: odoo/enterprise#75035
Original PR description
In the tree view of the payslip model, we can do mass edit to create a journal entry. Before, we were able to perform this action on a paid payslip which does not make sense. Now we have an error message if we try to do it. Task: 3874129 Forward-Port-Of: odoo/enterprise#78730 Forward-Port-Of: odoo/enterprise#75035
TaskID: 4558836 Forward-Port-Of: odoo/enterprise#78840
Original PR description
TaskID: 4558836 Forward-Port-Of: odoo/enterprise#78840
The aim of this commit is cleaning a weird indentation introduced by this commit [[1]]. no task id [1]: https://github.com/odoo/enterprise/commit/103369fb171654f4b0457d9b1629224def7465eb Forward-Port-Of: odoo/enterprise#78811
Original PR description
The aim of this commit is cleaning a weird indentation introduced by this commit [[1]]. no task id [1]: https://github.com/odoo/enterprise/commit/103369fb171654f4b0457d9b1629224def7465eb Forward-Port-Of: odoo/enterprise#78811
When the user claims the document and there is no valid token Odoo tries to re-generate the token, and instead of recalling to try to claim the document the code is wrongly calling the method to accept the document This logic was added in this https://github.com/odoo/enterprise/commit/3e906a93b91b5f66a4da850acc2b5ff2f43dd267 but for reason when the methods for accept/claim were merged into one method (_l10n_cl_action_response) -- Adhoc Ticket 86396 Forward-Port-Of: odoo/enterprise#782
Original PR description
When the user claims the document and there is no valid token Odoo tries to re-generate the token, and instead of recalling to try to claim the document the code is wrongly calling the method to accept the document This logic was added in this https://github.com/odoo/enterprise/commit/3e906a93b91b5f66a4da850acc2b5ff2f43dd267 but for reason when the methods for accept/claim were merged into one method (_l10n_cl_action_response) -- Adhoc Ticket 86396 Forward-Port-Of: odoo/enterprise#78248
In [1] the `params` section was refactored, but removing the `]` was missed. This caused an error, always returning "No encontrado". [1] https://github.com/odoo/enterprise/commit/14c1b2f8b36ade09be021d2ae202da19f88c0b78 Forward-Port-Of: odoo/enterprise#78891
Original PR description
In [1] the `params` section was refactored, but removing the `]` was missed. This caused an error, always returning "No encontrado". [1] https://github.com/odoo/enterprise/commit/14c1b2f8b36ade09be021d2ae202da19f88c0b78 Forward-Port-Of: odoo/enterprise#78891
26 changes
Enhancements to existing features
This update improves how the Indian GST reports module retrieves a specific return status field. The change is internal and should make the related process slightly more efficient and easier to maintain without changing user workflows.
Original PR description
In this PR: - Replaced the `search` method with `_get` to directly fetch the `gstr1_status` field from `l10n_in.gst.return.period`, improving efficiency and readability.
Activity summaries on accounting dashboards are now shorter by removing deadline text that already appears on the activity itself. Some activity messages were refined, and the generic tax payment reminder was removed except where it remains relevant for Belgian reporting.
Original PR description
We're removing the "deadline" from the activity summary as the actual deadline on the activity record is enough for the users to know when it is due. This also makes the activity look more concise and easier to read on the dashboard. This commit also makes minor adjustments to the summary messages and removes the "pay tax" activity since it's irrelevant. We'll keep that activity for l10n_be only. Task ID: 4501944
Document-related settings are simplified so new spreadsheets go to My Drive, Sign uses its standard Sign folder, and Projects can choose where company project folders are created. Labels and defaults are updated to make document storage easier to understand and reduce empty or confusing settings sections.
Resolved issues and error corrections
The Chilean PoS localization now detects when the required 'Consumidor Final Anónimo' customer record has been archived and shows a clearer message instead of failing unexpectedly. This helps store staff and administrators understand the setup issue quickly so the PoS can be restored with less disruption.
Original PR description
Before this commit, if the 'Consumidor Final Anónimo' partner was archived, attempting to open the PoS would lead to an error. This commit shows a clearer error message. opw-4506474
Luxembourg payroll now correctly calculates indexed wages for employees paid by the hour. This prevents payslips from showing a zero basic salary and helps ensure hourly employees are paid accurately.
Original PR description
## Issue: In Luxembourg companies, when creating an employee contract with an hourly wage, the indexed wage is always displayed as 0, causing the payslip to incorrectly show 0 for the basic salary. ## Steps to reproduce: 1. Create a new employee 2. Create a new contract for this employee with a hourly wage and Luxembourg: Regular Pay structure 3. Create a new payslip for this employee 4. Check the basic salary: it will be 0 ## Root cause: - The previous implementation did not account for hourly wage contracts when computing the indexed wage, leading to incorrect salary calculations. ## Solution: - Added logic to correctly compute the indexed wage for hourly contracts. - Adjusted related salary rules to differentiate between hourly and monthly wage types. - Updated views to reflect the correct unit (per month or per hour) based on the wage type. - Added a test case to validate the correct computation for hourly contracts. OPW-4460735
Fixed an issue where a parent company could be flagged for follow-up action, but its overdue invoice list appeared empty when invoices were issued to a child contact. The overdue invoice view now matches the follow-up status, helping accounting teams find and act on outstanding payments correctly.
Original PR description
Steps to reproduce: ------------------- 1. create 2 contacts : - one as a company (named parent contact for example) - and one as individual (named child contact) and set its parent company to the (parent contact). 2. create an invoice and set the partner to the (child contact). 3. set the invoice date and due date of the invoice to one month ago. 4. open the parent company (parent contact) -> accounting -> followup. You will see that Follow-up Status = in need of action, but if you clicked the Overdue Invoices, you will not find any invoices. Cause: ----- Since action_open_overdue_entries() introduced in V18.0, the window action filters invoices by partner set on the invoice while the Follow-up Status query checks the move lines which is always set to the parent company of the partner. Fix: --- Use commercial_partner_id instead of partner_id for the domain filter. OPW-4501051
The Belgian payroll declaration export has been corrected so the 274.XX XML file can be generated properly. This helps payroll teams submit the required Belgian reporting without being blocked by an export error.
Original PR description
STEP TO REPRODUCE: 1- Install The belgium payroll 2- Go to Payroll 3- Go to reporting > Declaration 274.XX 4- Click on generate xml file
This update fixes several issues in the Documents app details panel, including alias setup problems, unnecessary reloads, save validation errors, and fields that should be read-only for some users. This makes folder configuration smoother and helps prevent users from editing settings they should not change.
Original PR description
Commit 1: [FIX] documents: fix showing alias fields on details panel Reproduce: 1. Go to a folder on the kanban view 2. If not configured, configure Email Servers, then redo 1. 3. Clear the domain of…
Commit 1: [FIX] documents: fix showing alias fields on details panel Reproduce: 1. Go to a folder on the kanban view 2. If not configured, configure Email Servers, then redo 1. 3. Clear the domain of the alias 4. You are asked to configure servers again and you cannot set any value for the alias. Redirecting to the company settings is cumbersome and unlikely useful. Erp managers should be able to quick create here as in the company settings, as aliases are not company specific when receiving. Technically, removing `load=False` on `documents_unique_folder_id` (added when there is a `search_panel_default_folder_id` without `no_documents_unique_folder_id` in context) is necessary to load the existing `alias_domain_id`'s `display_name`. Commit 2: [FIX] documents: fix reloading only search panel It is not necessary to reload the model when we want to reload the search panel. Commit 3: [FIX] documents: fix validation error on saving container These records' methods are sometimes called when there is no point (and don't work), because the record is not part of the view. This can be seen for example when adding alias tags. Commit 4: Reproduce: As an internal user not documents manager, open the details panel on a company root folder with access_internal="edit". The fields are not rendered as readonly as they should. Test data updated in documents_spreadsheet. Task-4543501
The Documents app list view now correctly supports the full Select All behavior again. This makes bulk selection work as expected for users managing documents, reducing friction when selecting many records at once.
Original PR description
During sharepocalypse, we injected the ListView.Selection component from the control panel directly instead of using t-slots. This made our list view component limited to the features we want to support in the kanban view, so fewer than what the webclient supports. This commit restores the List View features on the list view. Task-4544692
The Italian Point of Sale localization now handles taxes that are added on top of the listed price, instead of only taxes already included in the price. This helps businesses using Italian POS calculate receipts and fiscal data correctly when tax-exclusive pricing is configured.
Original PR description
Related: https://github.com/odoo/odoo/pull/191637
This update stops helpdesk live chat bot question steps from being saved unless they include at least one answer option. This prevents errors when the bot is tested or used, making chatbot setup more reliable.
Original PR description
**Current behavior before PR**: It was possible to save a step with step_type set to "question selection" without any answers. However, this would cause an error when the bot was tested or executed. **Desired behavior after PR is merged**: A constraint has been added to ensure that a "question selection" step cannot be saved without at least one answer. **task-id**:4522835
Miscellaneous changes
GroupingCategory and GroupingCode nodes have changed from optional to mandatory in SAF-T V1.3. For the category, we use RF-1167 for now as it's the most common value. task-4374014 Forward-Port-Of: odoo/enterprise#78778 Forward-Port-Of: odoo/enterprise#77423
Original PR description
GroupingCategory and GroupingCode nodes have changed from optional to mandatory in SAF-T V1.3. For the category, we use RF-1167 for now as it's the most common value. task-4374014 Forward-Port-Of: odoo/enterprise#78778 Forward-Port-Of: odoo/enterprise#77423
The computation for the cars bik has changed in belgium for 2025. This adds rule parameters and changes the computation to reflect those changes. Task: 4409219 Forward-Port-Of: odoo/enterprise#77557
Original PR description
The computation for the cars bik has changed in belgium for 2025. This adds rule parameters and changes the computation to reflect those changes. Task: 4409219 Forward-Port-Of: odoo/enterprise#77557
ELM 5.0 Swissdec Certification Forward-Port-Of: odoo/enterprise#78783 Forward-Port-Of: odoo/enterprise#64454
Original PR description
ELM 5.0 Swissdec Certification Forward-Port-Of: odoo/enterprise#78783 Forward-Port-Of: odoo/enterprise#64454
A standard such as RiBa that everyone calls RiBA should not have any invented translation like Payment Receipt (IT). Followup for the Ri.Ba. task: odoo/enterprise#74097 Documentation PR: odoo/documentation#11847 Task [link](https://www.odoo.com/odoo/project/967/tasks/4497749) task-4497749 Forward-Port-Of: odoo/enterprise#78886 Forward-Port-Of: odoo/enterprise#77991
Original PR description
A standard such as RiBa that everyone calls RiBA should not have any invented translation like Payment Receipt (IT). Followup for the Ri.Ba. task: odoo/enterprise#74097 Documentation PR: odoo/documentation#11847 Task [link](https://www.odoo.com/odoo/project/967/tasks/4497749) task-4497749 Forward-Port-Of: odoo/enterprise#78886 Forward-Port-Of: odoo/enterprise#77991
During testing of the "new" Chrome's headless mode (by default since version 128), a concurrency issue arise at the end of those tours: a last request to the server is actually sent during the unload of the view. This request actually reach the server even if Chrome is already closed and the test is cleaning itself (rollbacking the changes made in the database), resulting into a "release savepoint" mismatch on an already aborted transaction (example build's error [1]). This commit is kind of
Original PR description
During testing of the "new" Chrome's headless mode (by default since version 128), a concurrency issue arise at the end of those tours: a last request to the server is actually sent during the unload of the view. This request actually reach the server even if Chrome is already closed and the test is cleaning itself (rollbacking the changes made in the database), resulting into a "release savepoint" mismatch on an already aborted transaction (example build's error [1]). This commit is kind of a follow-up of a previous PR [2] where a last step allowing for the spreadsheet to unload was added and adding one more to actually wait to be back on the Document app. [1] https://runbot.odoo.com/runbot/build/74602509 [2] https://github.com/odoo/enterprise/pull/51795 Forward-Port-Of: odoo/enterprise#78896 Forward-Port-Of: odoo/enterprise#78797
Issue: ------ When making changes in version 17.0 using studio the correspondent standard view's noupdate becomes 'True' as per the logic implemented. But when we migrate the database to the further versions like 18.0. The changes made in that particular view in 18.0 will not be loaded and will cause errors since its inherited view's will not be compatible enough. For ex: If we make changes in a "Purchase Order"(i.e; purchase.report_purchaseorder) report then after saving the changes the n
Original PR description
Issue: ------ When making changes in version 17.0 using studio the correspondent standard view's noupdate becomes 'True' as per the logic implemented. But when we migrate the database to the further…
Issue: ------ When making changes in version 17.0 using studio the correspondent standard view's noupdate becomes 'True' as per the logic implemented. But when we migrate the database to the further versions like 18.0. The changes made in that particular view in 18.0 will not be loaded and will cause errors since its inherited view's will not be compatible enough. For ex: If we make changes in a "Purchase Order"(i.e; purchase.report_purchaseorder) report then after saving the changes the noupdate of that report view which is "purchase.report_purchaseorder_document" will be updated to 'true'. And the action record i.e; "purchase.action_report_purchase_order" noupdate will be updated to 'true'.   If the customer makes changes using studio then those changes will be recorded in the studio view and there is no point of making the standard view's noupdate to 'true'. Solution: ----------- Remove redundant code to overcome updating noupdate to 'true'. Steps to reproduce: ------------------------ 1. Create a database in version 17.0. 2. Make changes in any report using studio and save. 3. Migrate the database and try opening that report. 4. You'll encounter issues due to incompatibilty of views. Since, the changes made in the standard will not be loaded because it's noupdate is true. REF PRS: Enterprise PR: 1.https://github.com/odoo/enterprise/commit/2ae63d9a43ba973d905232105201d88e423a8245#diff-cf8f46a54f86279b4d773f0d39b23d22f046eb6d33a39c851f2a86dcd2b5b202R463 Forward-Port-Of: odoo/enterprise#78582
Steps: - enable rental transfers - activate MTO route - create a product with MTO route and 0 stock - create a rental order for that product, validate Issue: The rental order will create 2 pickings that are waiting for each other. This is because the MTO move is using the same rental route with the stock destination, so it ends on the return rental picking. Fix: Force the procurement to use the `route_id` of the `rule_id` of the origin move. This way it will correctly create a new
Original PR description
Steps: - enable rental transfers - activate MTO route - create a product with MTO route and 0 stock - create a rental order for that product, validate Issue: The rental order will create 2 pickings that are waiting for each other. This is because the MTO move is using the same rental route with the stock destination, so it ends on the return rental picking. Fix: Force the procurement to use the `route_id` of the `rule_id` of the origin move. This way it will correctly create a new picking from Vendor to Stock for the product. If the product has a Buy or Manufacture route, it will use those instead. Also found another issue when enabling, then disabling, then re-enabling rental pickings: the stock rule stays archived. It is now fixed and a test has been added. Forward-Port-Of: odoo/enterprise#78648 Forward-Port-Of: odoo/enterprise#76477
In the tree view of the payslip model, we can do mass edit to create a journal entry. Before, we were able to perform this action on a paid payslip which does not make sense. Now we have an error message if we try to do it. Task: 3874129 Forward-Port-Of: odoo/enterprise#78730 Forward-Port-Of: odoo/enterprise#75035
Original PR description
In the tree view of the payslip model, we can do mass edit to create a journal entry. Before, we were able to perform this action on a paid payslip which does not make sense. Now we have an error message if we try to do it. Task: 3874129 Forward-Port-Of: odoo/enterprise#78730 Forward-Port-Of: odoo/enterprise#75035
If a user has an appointment in an appointment type they may not read. They should still be able to sync it to their calendar. Related to this fix: e52b13c9fc9cb309351f527bfbe961fcb0fb961e task-4526059 Forward-Port-Of: odoo/enterprise#78877 Forward-Port-Of: odoo/enterprise#78849
Original PR description
If a user has an appointment in an appointment type they may not read. They should still be able to sync it to their calendar. Related to this fix: e52b13c9fc9cb309351f527bfbe961fcb0fb961e task-4526059 Forward-Port-Of: odoo/enterprise#78877 Forward-Port-Of: odoo/enterprise#78849
### Steps to reproduce: - Create a bom for a product FP: - 1 x COMP (component) - operations: OP1: - instruction: - type: pass/fail, - Create and confirm an MO for 1 unit of FP - Go to the shopfloor, click on the instruction to open a dialog. - Spam the Pass button #### > Traceback: Uncaught Promise: Cannot read properties of undefined (reading 'resId') ### Cause of the issue: Clicking on a footer button of the `MrpQualityCheckConfirmationDialog` will trigger a
Original PR description
### Steps to reproduce: - Create a bom for a product FP: - 1 x COMP (component) - operations: OP1: - instruction: - type: pass/fail, - Create and confirm an MO for 1 unit of FP - Go to the shopfloor,…
### Steps to reproduce:
- Create a bom for a product FP:
- 1 x COMP (component)
- operations: OP1:
- instruction: - type: pass/fail,
- Create and confirm an MO for 1 unit of FP
- Go to the shopfloor, click on the instruction to open a dialog.
- Spam the Pass button
#### > Traceback: Uncaught Promise: Cannot read properties of undefined (reading 'resId')
### Cause of the issue:
Clicking on a footer button of the `MrpQualityCheckConfirmationDialog` will trigger a call of the `doActionAndClose` method: https://github.com/odoo/enterprise/blob/55c6292ff9d59ff09b1d81a61752765cf70d72c0/mrp_workorder/static/src/mrp_display/dialog/mrp_quality_check_confirmation_dialog.js#L93-L113 A the end of this call a `qualityCheckDone` is called to complete the operation which to work properly expects a `lastOpenedQualityCheck` to be set. However, at the end of this call, `displayInstruction` is called to generate a new MRP dialog for the next instuction if even exist. And, during this call if th ecurrent record (instruction) correspond to the `lastOpenedQualityCheck`, the value will be erased: https://github.com/odoo/enterprise/blob/55c6292ff9d59ff09b1d81a61752765cf70d72c0/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L337-L340 This causes the error because if you click too fast you will clean the value that you are suppose to use in the next call `qualityCheckDone` which will explode.
### Fix:
We diasble the buttons of the Dialog once a a call of the `doActionAndClose` is triggered. That way, it becomes impossible to spam an action that is already processing the info. This is a backport the part of e4190f1ea2c89439d2cd4afa5137d0fedb06431e related to our issue. In addition to this bacport we apply this change on the `MrpRegisterProductionDialog` extending the `MrpQualityCheckConfirmationDialog` to limit the amount of rpc called performed by validating a registration (prior, you could spam the validate button to encode the exact same value multiple times).
### Note:
By opposition to e4190f1ea2c89439d2cd4afa5137d0fedb06431e we do not disable the buttons during the `openWorksheet` since a priori this action does not close the dialog and we might want to press other buttons on the dialog once this action has been performed.
opw-4352828
Forward-Port-Of: odoo/enterprise#78012
Forward-Port-Of: odoo/enterprise#74795Bug introduced by this commit: https://github.com/odoo/enterprise/commit/4b312d56e7fa01ab4e8f534a1e62ef59e1421f77 Steps to reproduce the bug: - Create a storable product “P1” - Create two different MOs: - First MO: 1 unit of P1 - Second MO: 2 units of P1 - Confirm and mark them as done - Go to the manufacturing list view - Select both MOs - Print Cost Analysis Problem: The mo_qty is 2 units instead of 3; only the quantity of the last MO is taken into account. This is beca
Original PR description
Bug introduced by this commit: https://github.com/odoo/enterprise/commit/4b312d56e7fa01ab4e8f534a1e62ef59e1421f77
Steps to reproduce the bug:
- Create a storable product “P1”
- Create two different MOs:
- First MO: 1 unit of P1
- Second MO: 2 units of P1
- Confirm and mark them as done
- Go to the manufacturing list view
- Select both MOs
- Print Cost Analysis
Problem:
The mo_qty is 2 units instead of 3;
only the quantity of the last MO is taken into account. This is because, to calculate the total quantity of all MOs, we use a variable mo_qty, but it is initialized twice, once before the loop and again within the MO loop, so for each MO, the counter is reset to 0.
opw-4529333
Forward-Port-Of: odoo/enterprise#78731Steps to Reproduce: - create a helpdesk ticket from the website form without attachments. - creation message in the chatter is missing. Cause: - subtype_id for helpdesk ticket messages was explicitly set in the bridge module's insert_attachment method. When no attachments were present, this prevented the _creation_subtype logic in the helpdesk.ticket model from executing, resulting in the missing creation message. Solution: - Added a condition in the insert_attachment method to skip mo
Original PR description
Steps to Reproduce: - create a helpdesk ticket from the website form without attachments. - creation message in the chatter is missing. Cause: - subtype_id for helpdesk ticket messages was explicitly set in the bridge module's insert_attachment method. When no attachments were present, this prevented the _creation_subtype logic in the helpdesk.ticket model from executing, resulting in the missing creation message. Solution: - Added a condition in the insert_attachment method to skip modifying messages when no attachments are present. It ensures that the default _creation_subtype logic handles subtype assignment, maintaining consistent and accurate creation message logging in the chatter. task-4397661 Forward-Port-Of: odoo/enterprise#78777 Forward-Port-Of: odoo/enterprise#76111
During testing of the "new" Chrome's headless mode (by default since version 128), a concurrency issue arise at the end of those tours: a last request to the server is actually sent during the unload of the view (cf. save). This request actually reach the server even if Chrome is already closed and results into a SQl constraint error. Indeed, the (very basic) form views created for those tours are based on the "res.partner" model and only display the "name" field. This field isn't marked as "
Original PR description
During testing of the "new" Chrome's headless mode (by default since version 128), a concurrency issue arise at the end of those tours: a last request to the server is actually sent during the unload of the view (cf. save). This request actually reach the server even if Chrome is already closed and results into a SQl constraint error. Indeed, the (very basic) form views created for those tours are based on the "res.partner" model and only display the "name" field. This field isn't marked as "required" neither in the model, nor the view BUT has a SQL constraint attached to it... which makes it implicitly "required". This commit fixes it by properly marking them as such in the arch to let the client-side validation prevent the ultimate "save" request made during the unload. Forward-Port-Of: odoo/enterprise#78810
When the user claims the document and there is no valid token Odoo tries to re-generate the token, and instead of recalling to try to claim the document the code is wrongly calling the method to accept the document This logic was added in this https://github.com/odoo/enterprise/commit/3e906a93b91b5f66a4da850acc2b5ff2f43dd267 but for reason when the methods for accept/claim were merged into one method (_l10n_cl_action_response) -- Adhoc Ticket 86396 Forward-Port-Of: odoo/enterprise#782
Original PR description
When the user claims the document and there is no valid token Odoo tries to re-generate the token, and instead of recalling to try to claim the document the code is wrongly calling the method to accept the document This logic was added in this https://github.com/odoo/enterprise/commit/3e906a93b91b5f66a4da850acc2b5ff2f43dd267 but for reason when the methods for accept/claim were merged into one method (_l10n_cl_action_response) -- Adhoc Ticket 86396 Forward-Port-Of: odoo/enterprise#78248
We need to give fields in the module right group, otherwise we'll get error as these fields won't be avaliable for public profiles. [link to broken build errors](https://runbot.odoo.com/odoo/action-573/70494) Forward-Port-Of: odoo/enterprise#76374
Original PR description
We need to give fields in the module right group, otherwise we'll get error as these fields won't be avaliable for public profiles. [link to broken build errors](https://runbot.odoo.com/odoo/action-573/70494) Forward-Port-Of: odoo/enterprise#76374