Daily updates from Odoo
Thursday, March 6, 2025
32 changes · 18.0
Enhancements to existing features
This update improves internal testing for the Point of Sale restaurant features by allowing multiple guided test sessions to run at the same time. It helps verify that shared restaurant orders stay synchronized across different browser sessions, reducing the risk of issues in real-world multi-device use.
Original PR description
This PR aims to add a way to run multiple tours in parallel in order to test the synchronization feature in the `pos_restaurant` module. The introduced `run_parallel_tours` method runs the given prepared tours in different threads. But in order to do this, we need to make changes around: - the SIGXCPU signal handling, and, - the authentication For simplicity, we kept the authentication behavior such that it only works for one user. So in this implementation, all the opened browsers share the same user and session. As for the SIGXCPU signal handling, setting the signal handler can only be done in the main thread. So we introduced a context manager that sets the custom SIGXCPU handler when starting the tours and restores the previous signal handler when the tours are finished.
Resolved issues and error corrections
Fixes an issue where a point of sale session could reuse an empty order from a previous session, causing customer order tracking numbers to continue from the wrong place. New sessions now start tracking numbers correctly at 1, making receipts and order tracking clearer for staff and customers.
Original PR description
Currently, when you make a os order, close the session an then re-open it without going through the backend, the starting tracking number is related to the previous session. Steps to reproduce: ------------------- * Open pos shop * Make an order and pay it * Select **New order** * Close the session, do not go in the backend * Re-open the session > Observation: The tracking number is like `X03`. If we make an order, the tracking number will then be `(X+1)01`. Why the fix: ------------ When closing the register the current order is marked as cancelled and a reloading of the page is done. When reloading, the `onMounted` of the product screen is triggered which creates a new order. We will condition the effect of the `onMounted` in a `useEffect` so that we don't create new orders when we are closing the session. opw-4435140
This update adjusts an accounting test so it works correctly when certain secured accounting access is assigned to users by default, such as in the German localization. It helps keep automated checks reliable without changing business functionality.
Original PR description
The test `test_account_group_account_secured` introduced in #197558 fails when the `group_account_secured` group is added by default to the users, as is the case in l10n_de. This fix modifies the test by checkign that the user groups didn't change after hashing moves from the only journal with 'Hash on Post', instead of checking that `group_account_secured` is not part of the user's groups. runbot-159826 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Spreadsheet dashboard date filters now display their configured label, making it easier to tell similar filters apart. This helps users choose the correct filter when dashboards include multiple date-based controls.
Original PR description
Currently, the date filters do not have their title displayed in the `FilteValue` component which is an issue in dashboards where one could have multiple date filters defined and could not differentiate them. This revision adds the fiter label as a title such that users can identify the right filter given that they gave it an appropriate label. task-4606670 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 fixes a crash that could happen in the HTML editor when the selected content changed around links. Users can continue editing content more reliably without being interrupted by an error.
Fixes an issue where creating a Point of Sale store for a Mexican company could fail if a default accounting tag had been deleted. The system now continues account creation without that missing tag, helping users complete POS setup without manual technical intervention.
Original PR description
Currently, an error occurs when creating an account with a default tag `Debit Balance Account`, if it has been deleted. **Steps to reproduce:** - Install `l10n_mx`, `accountant`, `point_of_sale`…
Currently, an error occurs when creating an account with a default tag `Debit Balance Account`, if it has been deleted. **Steps to reproduce:** - Install `l10n_mx`, `accountant`, `point_of_sale` modules without demo data. - Change company country to `Mexico`. - Delete the records `Debit Balance Account` of **account tag**, `Cash` of **journals** and **chart of Accounts** from `Accounting > Configuration `. - Create a POS store. - Observe the error. **Error:** `ValueError: External ID not found in the system: l10n_mx.tag_debit_balance_account` The error occurs because the system attempts to fetch the tag `l10n_mx.tag_debit_balance_account` at [1], but it is unavailable as the user has already deleted it. This commit ensures that if the tag does not exist, it proceeds without assigning it, preventing the error. [1] - https://github.com/odoo/odoo/blob/63fc0d1cefaf8f59acd0743a225d1002425ff156/addons/l10n_mx/models/account_account.py#L12 sentry-6356695465 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an error that could occur after hiding the website header on course pages. Users can now save pages with the header disabled without encountering a crash, improving reliability for website editing.
Original PR description
**Problem**: After commit [9cf7726](https://github.com/odoo/odoo/commit/9cf7726d0402353ccef551148010aaff8a2059be), `headerEl` can be `null` if the "Show Header" option is turned off, causing a traceback. **Solution**: Check if `#wrapwrap header` exists and ensure `headerEl` is not `null`. **Steps to Reproduce**: 1. Install **E-learning**. 2. Open **Website > Site > Courses**. 3. Open any course. 4. Switch to **Edit mode**. 5. In the editor menu, disable **"Show Header"** under **Theme > Advanced**. 6. Save. 7. A traceback occurs. opw-4565265 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix keeps long channel member names contained within the member list in Discuss and Live Chat. It improves readability and prevents names from spilling into surrounding interface areas.
Original PR description
**Purpose:** to remove text overflow bug in the channel member name within the member list. **before :**  **after:**  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes how EDI proxy client key files are named when identifying details are not yet available. Instead of creating unclear names like `False_False.key`, the system now uses a more meaningful file name, making setup and troubleshooting easier.
Original PR description
In most cases, at this time of the process the edi_identification and the client_id are not known and the key's name end up to be `False_False.key`, which is not very descriptive. task-no **Before:**  **After:** 
The calendar view now correctly centers the red dot that marks today. This small visual fix makes the current date easier to identify and improves polish in back-end calendars.
Original PR description
This commit fixes vertical misalignment of today indicator in back-end calendars. task-4617623 | Before | After | |--------|--------| | <img width="1115" alt="Screenshot 2025-03-04 at 16 55 25" src="https://github.com/user-attachments/assets/b879fcb1-c416-44ea-956d-ce9c4c8328f2" /> | <img width="1095" alt="Screenshot 2025-03-04 at 14 17 45" src="https://github.com/user-attachments/assets/47e64b96-2ca2-4ec5-83ab-d3d8e133175d" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When an Argentinian company generates a certificate request without choosing a private key, the newly created key is now automatically shown in settings. Automatically generated keys also receive time-based names, making it easier to identify the correct key when uploading the official certificate later.
Original PR description
Steps to reproduce: 1. Install l10n_ar_edi 2. Use an Argentinian company 3. Go to the "Argentinean Localization" section of the settings 4. Make sure "Private Key" and "Certificate" are empty. Save.…
Steps to reproduce: 1. Install l10n_ar_edi 2. Use an Argentinian company 3. Go to the "Argentinean Localization" section of the settings 4. Make sure "Private Key" and "Certificate" are empty. Save. 5. Click on "Generate Request". 6. A key has been created but looks like it's not set on the company. --- Description of the issue this commit addresses: When generating a certificate request without selecting a private key to generate the certificate request with, a private key is generated by the system but in the settings windows, the field remains empty. Also, later, after retrieving the certificate from the official platform and trying to insert it in the database, it is required to link it with the private key that was used for its generation but since all automatically generated keys share the same name, this can be quite hard. --- Desired behavior after this commit is merged: When using the "Generate Request" button with no private key selected, the Private Key fields is populated with the key that was created for the generation of the request. Also, the names of the automatically generated keys use the current time for differenciation purposes. --- Note on the fix: The error happened because when using the Generate Request button, the key is created by a method called via another request so virtually, the assignment happens in another window. To fix that issue, the key has to be created and assigned before making any other request. --- task-4393259
Work entries based on employee attendances now exclude overtime that has been refused. This prevents payroll-related work entry durations from incorrectly including time that should not be paid or tracked as worked.
Original PR description
### Issue: - Refused overtime in attendance, is not correctly excluded from work entries, for employees where the contract work entry resource is attendances. ### Steps To Reproduce: - Create a new employee with a 40h work schedule. - Create a new contract for the employee, and set the `Work Entry Source` to `Attendances` - Change the contract status to running. - Go to the attendance tab. - Create a new attendance for the employee. - Make sure the attendance interval includes some overtime. - Confirm the attendance. - Refuse the overtime in the attendance. - Go to work entries and regenerate new ones. - Notice the work entry duration includes refused overtime. ### Solution: - In `_get_attendance_intervals` we rely on the `check_out` date to determine the attendance interval. however this date coresponds to the end of the attendance including refused overtime. - We modified the attendance `check_out` date to remove hours that are refused overtime. opw-4571285
This change prevents users from accidentally creating company-related folders in the wrong personal area from configuration screens. It also lets teams delete unused app folders after disabling related integrations, while restoring the right folder when those integrations are re-enabled.
Original PR description
See included commits that * allow deleting unused company folders * prevent quick creating folders in the config settings opw-4444537 Task-4531261
This update ensures document owners and inherited folder members keep the correct access when documents are created or copied. It fixes access issues for HR Payroll employee declarations so the right payroll folder members can view generated documents, while hiding owner-only access details from the permissions panel.
Original PR description
\+ tests update in documents_approval Fix owner edit role member after copy or creating inside a folder, including while specifying access_ids. Allow client code to add members to the default members…
\+ tests update in documents_approval Fix owner edit role member after copy or creating inside a folder, including while specifying access_ids. Allow client code to add members to the default members added by the base logic of documents (owner's log) and folders inherited values => Fix HR Payroll Employee Declaration where members of the payroll folder would not have access to the generated documents. The paradigm is: * The owner should always have a "document.access" record created * It should be possible to add a member in addition to the inherited ones. * If one passes values for a member when creating, it should override the default value for that partner. * If access_ids is passed as `False`, it should prevent inheriting access (but not prevent a role=False record for owner). * Follow-up of https://github.com/odoo/enterprise/pull/77783, there is no need to enforce logic for owner's `documents.access` role as the owner is basically an empowered editor. Additionally, make sure that * No membership (document.access with role) is created for odoobot * The access of owner is not shown on the permission panel Task-4593290
Fixed an issue where shortcuts to link and video documents could appear incorrectly in the Documents kanban view. Users will now see the proper preview format in My Drive, making shortcuts easier to recognize and use.
Original PR description
Steps to reproduce: 1. Upload a link and Video type documents 2. Create a shortcut 3. Go to My drive 4. Kanban card not displayed correctly Technical Reason: When creating a shortcut via 'action_create_shortcut', missing 'mimetype' and 'url' fields caused improper rendering of link/video shortcuts. After this commit: will display the proper format of the link/video. Task-4477679
This change makes a helpdesk knowledge test run reliably whether or not demo data is installed. It standardizes the admin user's signature in the test so automated checks are not affected by differences in sample data.
Original PR description
Before this commit, the `helpdesk_pick_template_as_message_from_knowledge` tour fails in no demo because the admin user is not named `Mitchell Admin` and so the step does not find the signature field. This commit adds the signature on the admin user to make sure the signature will be the same with demo data and without demo data.
Appointment confirmation emails are now properly translated when customers book through the website in Spanish. This improves the customer experience by ensuring booking details are communicated in the selected language.
Original PR description
Steps to reproduce: - Go to website and set the lang to Spanish - Book an appointment from the website Bug: The confirmation email sent to the customer is not correctly translated to Spanish opw:4382606
Fixed an issue where using the jump-to-target action from a shortcut document could fail to select the original source document. This makes navigation from shortcuts in Documents more reliable for users working in My Drive.
Original PR description
Steps to reproduce: 1. create a shortcut document in My Drive 2. select that document 3. click on the jumpToTarget button to access the source document 4. it won't select the source document / original document Technical Reason: When selecting a document, it was incorrectly assigning the wrong res_id to originalSelection. After this commit: will select the correct source document from the shortcut document. Task-4506244
Miscellaneous changes
### Steps to reproduce: - In the settings: - Add a second language say FR + Change the language - Enable Multi-step routes - Put your warehouse in receipt in 2-steps. - Create a storable product with a different FR name and a set vendor - Click on the "Reordering Rules" smart button of the product form - Create a reordering rule using the buy route for your product - Add a quantity to reorder > "Order Once" - Open the associated purchase order in a second window - Repeat the operation
Original PR description
### Steps to reproduce: - In the settings: - Add a second language say FR + Change the language - Enable Multi-step routes - Put your warehouse in receipt in 2-steps. - Create a storable product with…
### Steps to reproduce: - In the settings: - Add a second language say FR + Change the language - Enable Multi-step routes - Put your warehouse in receipt in 2-steps. - Create a storable product with a different FR name and a set vendor - Click on the "Reordering Rules" smart button of the product form - Create a reordering rule using the buy route for your product - Add a quantity to reorder > "Order Once" - Open the associated purchase order in a second window - Repeat the operation of adding a quantity to reorder > "Order Once" ** A new POL is created instead of being merged to the first one** ### Cause of the issue: Clicking on Order once will trigger a call of the `_run_pull`. At the end of this call, a stock move will be created and confirmed but the user of the env will be replaced by a SUPERUSER_ID for access rights purposes: https://github.com/odoo/odoo/blob/39d7207aae187d055f19c7bce41df8110c045185/addons/stock/models/stock_rule.py#L283-L286 However, while the move data's were correctly generated using the language of the user that clicked on order once: https://github.com/odoo/odoo/blob/39d7207aae187d055f19c7bce41df8110c045185/addons/stock/models/stock_rule.py#L278 https://github.com/odoo/odoo/blob/39d7207aae187d055f19c7bce41df8110c045185/addons/stock/models/stock_rule.py#L315 The language that will be used during the action confirm to compare with the picking description in the procurement values will be the language of the new user that is the SUPERUSER_ID in en_US: https://github.com/odoo/odoo/blob/39d7207aae187d055f19c7bce41df8110c045185/addons/stock/models/stock_move.py#L1451-L1456 This will lead to a set (and incorrect) `product_description_variants` on that procurement. However, this value will be used to determine in the `_run_buy` if an existing POL could absorb the newly created need: https://github.com/odoo/odoo/blob/39d7207aae187d055f19c7bce41df8110c045185/addons/purchase_stock/models/stock_rule.py#L131-L135 https://github.com/odoo/odoo/blob/39d7207aae187d055f19c7bce41df8110c045185/addons/purchase_stock/models/purchase_order_line.py#L341-L350 Since already existing POL will not be found to match the incorrect `product_description_variants` a new one will be created on that same PO. ### Fix: We do not rely on the language of the user in case it is the SUPERUSER_ID. opw-4397376 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196626 Forward-Port-Of: odoo/odoo#192751
### Steps to reproduce: - In the settings enable "Multi-Step Routes" and "Subcontracting" - Inventory > Configuration > Warehouse Management > Operation Types - Unarchive "Subcontracting" - Create a product tracked by SN with: - A set vendor - A bom of type subcontracting with your vendor set as subcontractor - Create and confirm a PO for 3 units of your product with your vendor. - Go to inventory > Subcontracting (operation type) > the related SBC - Click on "Produce All" (this
Original PR description
### Steps to reproduce: - In the settings enable "Multi-Step Routes" and "Subcontracting" - Inventory > Configuration > Warehouse Management > Operation Types - Unarchive "Subcontracting" - Create a…
### Steps to reproduce:
- In the settings enable "Multi-Step Routes" and "Subcontracting"
- Inventory > Configuration > Warehouse Management > Operation Types
- Unarchive "Subcontracting"
- Create a product tracked by SN with:
- A set vendor
- A bom of type subcontracting with your vendor set as subcontractor
- Create and confirm a PO for 3 units of your product with your vendor.
- Go to inventory > Subcontracting (operation type) > the related SBC
- Click on "Produce All" (this should pop a batch produce wizard)
#### > It does not and you have validated the MO for 0 units without backorder
### Cause of the issue:
Since Commit 5722286a36838f644bb4e95c305b65b412774d75 (saas-17.1), the `action_mass_produce` used to split a tracked MO and generate the assocated SN:
https://github.com/odoo/odoo/blob/bc5414602920ee712c45397d7992863a0b1ea161/addons/mrp/models/mrp_production.py#L2281-L2292
should be returned by the `pre_button_mark_done` to be performed: https://github.com/odoo/odoo/blob/bc5414602920ee712c45397d7992863a0b1ea161/addons/mrp/models/mrp_production.py#L2128 https://github.com/odoo/odoo/blob/bc5414602920ee712c45397d7992863a0b1ea161/addons/mrp/models/mrp_production.py#L1994-L1997
However, for subcontracted MO, the returned value of the `pre_button_mark_done` is currently always True, skipping the batch production wizard:
https://github.com/odoo/odoo/blob/bc5414602920ee712c45397d7992863a0b1ea161/addons/mrp_subcontracting/models/mrp_production.py#L105-L108
opw-4447631
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#197459How to reproduce: ============== - Have Marc Demo work in another sales team that yours. - Go to a kanban view of leads, grouped by salesperson. - Quick create a new lead. Current behavior: ============= It gets assigned to your team, probably because the default value is not properly updated. Expected behavior: ============== - The lead belongs to Marc and should be linked to his team. - It works fine if you do it from the form view. task-4438021 --- I confirm I hav
Original PR description
How to reproduce: ============== - Have Marc Demo work in another sales team that yours. - Go to a kanban view of leads, grouped by salesperson. - Quick create a new lead. Current behavior: ============= It gets assigned to your team, probably because the default value is not properly updated. Expected behavior: ============== - The lead belongs to Marc and should be linked to his team. - It works fine if you do it from the form view. task-4438021 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#200230 Forward-Port-Of: odoo/odoo#192934
Steps: - Create and confirm an invoice with 3 lines for the same product P: 1 - 10 quantity, 10$ 2 - 5 quantity, 5$ 3 - 20 quantity, 2$ - Go to invoice analysis, pivot view - Filter to see only product P - Measure Untaxed Amount, Product Quantity and Average Price -> The average price is 5.67 instead of 4.71 This is because the SQL query calculates the average of each line before calculating the average of the 3 lines instead of calculating the global average. With this commit,
Original PR description
Steps:
- Create and confirm an invoice with 3 lines for the same product P:
1 - 10 quantity, 10$
2 - 5 quantity, 5$
3 - 20 quantity, 2$
- Go to invoice analysis, pivot view
- Filter to see only product P
- Measure Untaxed Amount, Product Quantity and Average Price
-> The average price is 5.67 instead of 4.71
This is because the SQL query calculates the average of each line before
calculating the average of the 3 lines instead of calculating the global
average.
With this commit, we override the `read_group` method to make the
correct calcultaion of the average price.
opw-4503562
Forward-Port-Of: odoo/odoo#196975When trying to sign in (for a new user) after making a purchase (existing token), we can choose a password of less than the minimum length allowed in the configuration. The _check_password_policy method prevents the save of the password to the user but arrives too late in the flow as the initiation of the user creation is half done leading to an Invalid token issue at the next attempt (no partner found for the existing token with _signup_retrieve_partner). By adding the minlength attribute in
Original PR description
When trying to sign in (for a new user) after making a purchase (existing token), we can choose a password of less than the minimum length allowed in the configuration. The _check_password_policy method prevents the save of the password to the user but arrives too late in the flow as the initiation of the user creation is half done leading to an Invalid token issue at the next attempt (no partner found for the existing token with _signup_retrieve_partner). By adding the minlength attribute in the form of the sign up, we force the respect of the password policy minimum length in the front end and minimize the risk to encounter the issue. previous PR unmerged: https://github.com/odoo/odoo/pull/186622 opw-4514350 Forward-Port-Of: odoo/odoo#199549
Currently one can still edit section / note lines on posted moves (but not save the move). This commit makes the section / notes lines readonly when they should be. task: none Forward-Port-Of: odoo/odoo#200155
Original PR description
Currently one can still edit section / note lines on posted moves (but not save the move). This commit makes the section / notes lines readonly when they should be. task: none Forward-Port-Of: odoo/odoo#200155
This commit e35b3b088584b45b0278174da355d09e7e47633b was a fix for wrong calculation of base_url but the old calculation still there This was not detected because the test was not imported in __init__ file now it is removed and the test is imported in `__init__.py` opw-4235176 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199268
Original PR description
This commit e35b3b088584b45b0278174da355d09e7e47633b was a fix for wrong calculation of base_url but the old calculation still there This was not detected because the test was not imported in __init__ file now it is removed and the test is imported in `__init__.py` opw-4235176 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199268
- Incorrect "Sent" Status: When generating the XML with the UBL checkbox selected but without checking the Nilvera option, the move was incorrectly marked as "Sent" (is_move_sent). This behavior has been corrected. - Traceback During Send and Print with Nilvera: In the flow where the XML is first generated with UBL, and then the Send and Print action is performed with Nilvera, a traceback appeared since the ubl_cii_xml_attachment_values was not in the invoice_data anymore. Also Nilver
Original PR description
- Incorrect "Sent" Status: When generating the XML with the UBL checkbox selected but without checking the Nilvera option, the move was incorrectly marked as "Sent" (is_move_sent). This behavior has been corrected. - Traceback During Send and Print with Nilvera: In the flow where the XML is first generated with UBL, and then the Send and Print action is performed with Nilvera, a traceback appeared since the ubl_cii_xml_attachment_values was not in the invoice_data anymore. Also Nilvera didn't accept the xml because they needed the issues date of the document to accept it. - City Name and Subdivision Inversion in XML The values in the CitySubDivisionName and CityName elements of the XML were inverted. This has been corrected to align with the expected structure. task-4457092 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199998 Forward-Port-Of: odoo/odoo#192733
**Current behavior before PR:** - In mass mailing, when the link popover opens, clicking on a link that is available near the edge of the mailing template beside the sidebar would sometimes cause the popover to appear behind the sidebar. **Desired behavior after PR is merged:** - Clicking on a link near the edge of the mailing template now ensures that the link popover does not appear behind the sidebar. task-4237091 Forward-Port-Of: odoo/odoo#198252
Original PR description
**Current behavior before PR:** - In mass mailing, when the link popover opens, clicking on a link that is available near the edge of the mailing template beside the sidebar would sometimes cause the popover to appear behind the sidebar. **Desired behavior after PR is merged:** - Clicking on a link near the edge of the mailing template now ensures that the link popover does not appear behind the sidebar. task-4237091 Forward-Port-Of: odoo/odoo#198252
When handling errors on runbot, it can be difficult to know where a message comes from. It can be problematic to identify automatically the source of an error. This branch give the possibility to add metadata to log_db. The current only metadata is the canonical tag. Some other information, like the stack, or the subtest could be added in the future. This is not the case for now to make the review easier. ```patch def get_log_metadata(self): + stack = traceback.format_
Original PR description
When handling errors on runbot, it can be difficult to know where a message comes from. It can be problematic to identify automatically the source of an error.
This branch give the possibility to add metadata to log_db.
The current only metadata is the canonical tag.
Some other information, like the stack, or the subtest could be added in the future. This is not the case for now to make the review easier.
```patch
def get_log_metadata(self):
+ stack = traceback.format_stack()
+ start = next((index for index, frame in enumerate(stack) if self._testMethodName in frame), 0)
metadata = {
'canonical_tag': self.canonical_tag,
+ 'stack': '\n'.join(traceback.format_stack()[start:-7]),
+ 'subtest': str(self._subtest),
}
return metadata
```
Forward-Port-Of: odoo/odoo#199964Fix the traceback appearing when trying to create live session sample data. The live session survey is initialized with the 'session_speed_rating' field set to True meaning a 'session_speed_rating_time_limit' value is required but wasn't given. related PR: odoo/odoo#115141 Task-4569972 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197584
Original PR description
Fix the traceback appearing when trying to create live session sample data. The live session survey is initialized with the 'session_speed_rating' field set to True meaning a 'session_speed_rating_time_limit' value is required but wasn't given. related PR: odoo/odoo#115141 Task-4569972 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197584
Issue: When the user tries to create a contact from the approval form, they get a "Missing Record" error. Steps to reproduce: - Install the Approvals app - Create a new Approval Type with Contact set as either 'Required' or 'Optional' - When creating a new Request from the created Type, try to create a new Contact Cause: Both Approvals and Partners have a 'category_id' field. In the approval form, the context has the approval's value for 'category_id', which is being used for the part
Original PR description
Issue: When the user tries to create a contact from the approval form, they get a "Missing Record" error. Steps to reproduce: - Install the Approvals app - Create a new Approval Type with Contact set as either 'Required' or 'Optional' - When creating a new Request from the created Type, try to create a new Contact Cause: Both Approvals and Partners have a 'category_id' field. In the approval form, the context has the approval's value for 'category_id', which is being used for the partner creation. Solution: In the approval form view, change the context used by the partner field to not have a default 'category_id'. Ticket: opw-4328371 Forward-Port-Of: odoo/enterprise#80177 Forward-Port-Of: odoo/enterprise#74579
- hr_payroll > Dashboard - After completing all the steps of onboarding when the user is refreshing all the menuitems get hidden or whenever user does a level up and refresh/ press F5 then also all the menuitme gets hidden. Before this commit, after completing all the onboarding steps or whenever user does a level up after that refreshing the page (F5). so, all menu items to disappear. This occurs because the `hr_referral_welcome` client action is missing the required path. Now, the stati
Original PR description
- hr_payroll > Dashboard - After completing all the steps of onboarding when the user is refreshing all the menuitems get hidden or whenever user does a level up and refresh/ press F5 then also all the menuitme gets hidden. Before this commit, after completing all the onboarding steps or whenever user does a level up after that refreshing the page (F5). so, all menu items to disappear. This occurs because the `hr_referral_welcome` client action is missing the required path. Now, the static path has been added to the `hr_referral_welcome` client action. in that way, when reloading ,after completing all the onboarding steps or level up, all menu items is not disappear Task-4391729 Forward-Port-Of: odoo/enterprise#77478
### Steps to reproduce: - Enable "Multi-Steps Routes" in the settings - Inventory > Configuration > Warehouse Management > Warehouses - Put your warehouse in manufacturing in 2 steps - Create an MO for a product and add an operation (no need of component) - Confirm the MO and go to your operation in the shopfloor - Click on the 3 dots > Add component > add any component #### > Back to the MO: No transfer was created from stock to pre-prod ### Cause of the issue: When you add comp
Original PR description
### Steps to reproduce: - Enable "Multi-Steps Routes" in the settings - Inventory > Configuration > Warehouse Management > Warehouses - Put your warehouse in manufacturing in 2 steps - Create an MO…
### Steps to reproduce: - Enable "Multi-Steps Routes" in the settings - Inventory > Configuration > Warehouse Management > Warehouses - Put your warehouse in manufacturing in 2 steps - Create an MO for a product and add an operation (no need of component) - Confirm the MO and go to your operation in the shopfloor - Click on the 3 dots > Add component > add any component #### > Back to the MO: No transfer was created from stock to pre-prod ### Cause of the issue: When you add component from the shopfloor, you will trigger a call of the `add_product` method to create and confirm the raw move associated to the MO: https://github.com/odoo/enterprise/blob/2e2efe8421b2f85950e50ff102cdabf98d2d91ab/mrp_workorder/wizard/additional_product.py#L36-L37 However, if the `procure_method`` of this move is not set to mto/mtso it will not trigger other rules in order to generate the other transfers ### Note: A priori, the issue should not be reproducible in 18.0+ as this part of the code was refactored and the issue was fixed by 235047b68e6a24a14e32b94b1d4a15a580dc5ad2 opw-4236272 Forward-Port-Of: odoo/enterprise#75260 Forward-Port-Of: odoo/enterprise#74178