Monday, February 10, 2025
40 changes · 18.0
Enhancements to existing features
This update expands and reorganizes automated checks for online sales, stock availability, and store pickup flows. It helps reduce the risk of future issues in checkout, payment, delivery, and stock-related customer journeys without changing day-to-day functionality.
Original PR description
Improve test coverage of the `website_sale_collect` and rework test commons in `website_sale_stock` module. task-4199783
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
Resolved issues and error corrections
This fixes an error that could appear when a user enabled secure hashing for posted accounting entries and immediately returned to the dashboard before any entries were hashed. The dashboard now handles that transition safely, helping accounting users avoid an unexpected interruption.
Original PR description
**To reproduce:** 1. Check the field 'Secure Posted Entries with Hash' in a journal with existing entries 2. Immediately return to the Dashboard, before posting new entries 3. An error is raised…
**To reproduce:** 1. Check the field 'Secure Posted Entries with Hash' in a journal with existing entries 2. Immediately return to the Dashboard, before posting new entries 3. An error is raised **Cause:** In odoo/odoo#196748, the secured group usability was changed to only grant access to the new features relating to securing entries if moves from a journal without "Hash on Post" are secured. However, if before any entries are hashed, either by posting a new move in a journal with 'Hash on Post' or using the 'Secure Entries' wizard, the user returns to the dashboard, an error is raised. This is due to _get_chains_to_hash() being called with early_stop = True, in which case chain_info is an int. **Fix:** The key 'journal_restrict_move', which information on whether the journal is 'Hash on Post' to chain_info, should only be added after the function returns True in case of early_stop. This avoids the item assignment on an int. no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
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
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
This update fixes an issue that could cause errors when Point of Sale data was updated using a specific internal update command. It helps keep related sales information processing reliably and reduces the chance of interruptions for users.
Original PR description
Fix error with "set" command in related models.
This fixes an intermittent issue in automated checks where a button could be treated as hidden even though it was present. The change makes the two-factor authentication flow tests more reliable, reducing false failures and helping teams ship updates with greater confidence.
Original PR description
Fix nondeterministic JS errors of button trying to be clicked while detected as not visible (while being there). HOOT rely on DOM mutation to check if elements visible state change or not. We suspect if the tab load fast enough the button will be considered invisible as the fading didn't started yet. The issue is nondeterministic but fail more consistently by toggling Chrome CPU to 10x, it will then fail 3/4 of the times rb-112019
This fixes cases where the HTML editor could record unintended background changes while users changed selections or undid embedded content. The fix helps keep undo history cleaner and prevents unexpected editor behavior without changing normal editing workflows.
Original PR description
This PR handles 2 cases of ghost mutations generation: When switching the selection, the hint plugin generated mutations that were not part of a step. They should be ignored. When undoing the insertion of nested embedded components, the post-processing allowing for OWL Component destruction was generating ghost mutations. They should also be ignored. See commits for further details task-4561045
This fix removes two unsupported text matching options from the condition editor used in Studio. Users will no longer hit an error when configuring required-field rules, improving reliability while editing views.
Original PR description
Example of steps:
- Install `web_studio`
- Open any view editor with `web_studio`
- Try to edit a field required condition
- Pick a char field
- Add `starts_with` or `ends_with` operator
- Traceback
The solution is to remove these two operators from expression_editor as
this is not a python expression,
`starts_with` and `ends_with` are interpreted as `=ilike`, but there is
no way to translate it easily to a python expression like for `=`, `>=`, etc..
opw-4551688This fix makes several automated website walkthroughs more reliable by adding checks that ensure each test is on the correct path before continuing. It reduces unpredictable test behavior across website, eCommerce, recruitment, live chat, blog, and eLearning areas, helping maintain release stability without changing customer-facing features.
Original PR description
In this commit, we fix multiple tours on step that can cause non deterministic behaviors by adding additionnal steps to ensure tour is well on the way to taking the right path. 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
This fix makes an automated mail template test more reliable by allowing enough time for the page content to render after opening a dropdown. It helps reduce false test failures and keeps development checks stable without changing customer-facing behavior.
Original PR description
mail_template_dynamic_placeholder_tour is failing, as the delay between two steps is too small and dom is rendering right after clicking the dropdown. this pr fixes the issue. [failing runbot builds](https://runbot.odoo.com/odoo/action-573/111986) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A broken automated website page properties test has been fixed and re-enabled. This helps ensure website page settings continue to work correctly and reduces the chance of regressions reaching users.
Original PR description
In this commit, we make the fixes in order to reactivate the tour. runbot-error-id~106391 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
Chatbot steps that ask users to choose an answer can no longer be saved without any available answers. This prevents live chat bots from failing during testing or customer conversations.
Original PR description
*= crm_livechat, website_livechat **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 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Worldline payment cancellations and declines are now recognized correctly instead of being shown as invalid transaction statuses. This helps staff understand failed checkout payments more clearly by showing the relevant error code and marking canceled payments appropriately.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Go to eCommerce; 2. add items to cart; 3. go to checkout; 4. pay with Worldline; 5. on Worldline's site, cancel transaction; 6. open order in the backend. Issue ----- Chatter displays: > Error: Worldline: Received invalid transaction status CANCELLED Cause ----- The cancel & declined statuses aren't handled when processing Worldline's response, leading to them being displayed as invalid. Solution -------- Handle the `cancel` and `declined` statuses and display the given error code. Also, when canceled, call `_set_canceled` instead of `_set_error`. opw-4481602
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
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
Forward-Port-Of: odoo/odoo#197095 Forward-Port-Of: odoo/odoo#193528
Original PR description
Forward-Port-Of: odoo/odoo#197095 Forward-Port-Of: odoo/odoo#193528
Related Enterprise PR : https://github.com/odoo/enterprise/pull/64454 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196891 Forward-Port-Of: odoo/odoo#194627
Original PR description
Related Enterprise PR : https://github.com/odoo/enterprise/pull/64454 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196891 Forward-Port-Of: odoo/odoo#194627
Version: - 17.0 Steps to Reproduce: - Install the Calendar app. - Create an event and enable the "All Day" option. - Duplicate the event. Issue: - When duplicating an All Day event, a traceback error occurs because the start_date and stop_date values are missing. Solution: - The start_date and stop_date are now properly set when duplicating an event resolving the traceback error. task-4353039 Forward-Port-Of: odoo/odoo#196972 Forward-Port-Of: odoo/odoo#188171
Original PR description
Version: - 17.0 Steps to Reproduce: - Install the Calendar app. - Create an event and enable the "All Day" option. - Duplicate the event. Issue: - When duplicating an All Day event, a traceback error occurs because the start_date and stop_date values are missing. Solution: - The start_date and stop_date are now properly set when duplicating an event resolving the traceback error. task-4353039 Forward-Port-Of: odoo/odoo#196972 Forward-Port-Of: odoo/odoo#188171
Since the function message_post on mail thread has been built to be called on exactly one record and the function write on employee is for multiple records, we need to call it for each employee we are writing on. It has been introduced in: https://github.com/odoo/odoo/pull/143217 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196257
Original PR description
Since the function message_post on mail thread has been built to be called on exactly one record and the function write on employee is for multiple records, we need to call it for each employee we are writing on. It has been introduced in: https://github.com/odoo/odoo/pull/143217 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196257
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
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
Scenario: - install hr_recruitment but not documents (to have the right view) - go to Employee > Configuration > Recruitment | Job Positions - choose a job positions with documents and click on Documents - click on Applicant column on one of the rows => traceback shown: OwlError: Invalid props for component 'FormController': 'resId' is not a number or boolean at Object.validateProps Reason: In saas-17.2 with a7586fdb4123481fd8794ef99fdc372e95de7459 merged in february 2024, m
Original PR description
Scenario: - install hr_recruitment but not documents (to have the right view) - go to Employee > Configuration > Recruitment | Job Positions - choose a job positions with documents and click on…
Scenario: - install hr_recruitment but not documents (to have the right view) - go to Employee > Configuration > Recruitment | Job Positions - choose a job positions with documents and click on Documents - click on Applicant column on one of the rows => traceback shown: OwlError: Invalid props for component 'FormController': 'resId' is not a number or boolean at Object.validateProps Reason: In saas-17.2 with a7586fdb4123481fd8794ef99fdc372e95de7459 merged in february 2024, many2one_reference was changed from a simple integer to either 0 if unset, or a object containing resId and displayName keys. Fix: Get the id with .resId and this should not happen, but test if the record is set with "if(res_id && ...)" in case res_id was 0. Note: without the fix, the added test fails by opening the view if res_id was 0, and if not the next click would fail with: OwlError: Invalid props for component 'FormController': 'resId' is not a number or boolean opw-4384139 PR note: the test could be run without mails models, but then we would need to mock a lot of models for services (like `mail.ChatHub`) or a method like `prepareRegistry` [from studio](https://github.com/odoo/enterprise/blob/f5b7b53963829b351446e9b6f71e00f21291bc58/web_studio/static/tests/view_editor_tests_utils.js#L123-L153) that would remove all unnecessary services for the test. Forward-Port-Of: odoo/odoo#191510
This commit make brazilen fields always display in address form even though b2b fields settings disabled from edition because in LATAM country `ID Type` and `ID Number` field are required for billing. Also revert wrong fixed PR https://github.com/odoo/odoo/pull/194110 task-3628329 Forward-Port-Of: odoo/odoo#196925 Forward-Port-Of: odoo/odoo#196182
Original PR description
This commit make brazilen fields always display in address form even though b2b fields settings disabled from edition because in LATAM country `ID Type` and `ID Number` field are required for billing. Also revert wrong fixed PR https://github.com/odoo/odoo/pull/194110 task-3628329 Forward-Port-Of: odoo/odoo#196925 Forward-Port-Of: odoo/odoo#196182
Backport of the original issue (ref.1) with the following message: The issue occurs when an email is sent to create a `project.task`. If the sender of the email is an existing user, this user is later set as the author of any outgoing emails related to that task. Since the system is configured to skip sending emails to the author, no email is delivered to the sender in this scenario. Reproduce --- - -i project,contacts - add `example.com` to domains in the settings - create new projec
Original PR description
Backport of the original issue (ref.1) with the following message: The issue occurs when an email is sent to create a `project.task`. If the sender of the email is an existing user, this user is later set as the author of any outgoing emails related to that task. Since the system is configured to skip sending emails to the author, no email is delivered to the sender in this scenario. Reproduce --- - -i project,contacts - add `example.com` to domains in the settings - create new project with an alias: `project@example.com` - Have a stage with some "Email Template" set - send email creating project tasks as a portal user - BUG: email about stage update is NOT sent (even tho task appeared in stage) (ref.1) [FIX] project_task,hr_recruitment: include ticket author in stage update email c1a430a6ee8ade9c27a0c01d8840139942e168ef opw-3941928 opw-4262422 Forward-Port-Of: odoo/odoo#196185
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