Daily updates from Odoo
Friday, May 3, 2024
54 changes · 17.0
New functionality added to Odoo
A new reporting feature has been added to the UAE payroll module that allows users to generate master reports in Excel format. These reports display employee earnings data across one or more months, providing a comprehensive view of payroll information for compliance and analysis purposes.
Original PR description
This will add a new Reporting menu for the UAE to create a master report. This master report is an excel file representing one or more month(s) with each employee and the amount earned by them. Task: 3744558
Odoo now supports Hungarian e-invoicing requirements by integrating with the NAV (Hungarian tax authority) API. This new module enables Hungarian companies to automatically submit invoices to the tax authority and generate mandatory tax audit exports, ensuring compliance with local regulations.
Original PR description
In Hungary, companies are required to submit their invoices to the NAV (tax authority) via a dedicated API. This API uses a simple invoicing flow (no cancellation, use credit notes to reverse). The new module `l10n_hu_edi` provides an integration for this API, enabling Hungarian users to make use of Odoo. The new module also provides functionality for tax audit export which is mandatory for accounting software in Hungary. Based on #137301 by Csaba Tóth. taskid: 3213959
Enhancements to existing features
A helpful tooltip has been added to the Prorata Date field in the Asset Management module to guide users on how to use this feature. This enhancement improves the user experience by providing clearer instructions directly within the application, reducing confusion and support requests.
Original PR description
[ADD] account_asset: Add tooltip to Prorata Date Add tooltip to Prorata Date field in account_asset module and add its translation Reason: Enhance user-experience Task-3864117
This update improves how double holiday pay recovery is calculated in the Belgian payroll system to ensure compliance with legal requirements. The change affects how employees' double holiday compensation is computed, ensuring accurate and legally compliant payroll processing for Belgian operations.
Original PR description
This will fix the computation of the double holiday pay recovery to match legal requirements. Task: 3893867
This update removes unnecessary duplicate requests to Google Calendar when synchronizing appointments. The system now reuses information returned from Google during the initial sync instead of making additional requests, resulting in faster synchronization and reduced API calls. Google Meet URLs continue to be added to appointments correctly with this more efficient approach.
Original PR description
This commit removes the write override of calendar.event records, since this override was doing unnecessary requests on Google side when synchronizing again events that were just synchronized. After this commit, the function get_post_sync_values() will reuse the values returned by the insertion in Google and write in the event right away, saving requests to Google. The objective of the previous write override was to write the google meet URL in the event, and now this is still being done correctly by means of the new strategy. related-to: https://github.com/odoo/odoo/pull/163364 task-389382
The quiz feature in website slides now uses green to highlight correct answers instead of purple, making it much easier for learners to quickly distinguish between correct and incorrect responses. This improves the user experience by providing clearer visual feedback during quiz interactions.
Original PR description
Currently, if we select the correct answer for a quiz question, `primary theme color(purple)` is applied to the `fa-check` icon. Hence, it is difficult to distinguish between the correct and incorrect answers. This PR changes the color applied to the `fa-check` icon in case a correct answer is selected, from `primary theme color(purple)` to `success theme color(green)`. Task-[3884674](https://www.odoo.com/web#id=3884674&menu_id=4722&cids=2&action=333&active_id=965&model=project.task&view_type=form)
This update improves how Google Calendar events are created and synchronized. When events are added to Google Calendar, the system now captures and saves important information (like meeting URLs) immediately after creation, rather than discarding it. This reduces the need for additional updates later and makes the synchronization process more efficient.
Original PR description
Before this commit, when inserting an event in Google side, we were throwing away the insertion values returned by Google and keeping only the event id. This was not a good practice because we could…
Before this commit, when inserting an event in Google side, we were throwing away the insertion values returned by Google and keeping only the event id. This was not a good practice because we could already write important values such as meeting URL and then spare future write calls. Additionaly, when writing values from google, we were sending through the context the 'write_dates' key, that would only be used once but would be kept in the context (when it is not needed). After this commit, a callback function was added to write the event information right after the 'insert' function is executed, alongside of a function to get the desired post sync values describing which fields will be written in the event. Thus, we can write in the event right away after its creation. Since we are in a stable branch, this strategy was the only option to avoid changing the 'insert' function return and, by consequence possibly breaking custom code. In addition, now we delete the recently used 'write_dates' context key from the context in order to prevent future misuse of it. task-3893827
Resolved issues and error corrections
This fix restores the ability to view customer information when making or receiving calls in the VoIP module. Previously, this functionality was accidentally removed during a system upgrade. Now when you enter a phone number or receive a call, the system will automatically look up and display the associated customer details if found in your contacts.
Original PR description
Functionality was removed during the refactor of the voip module between 16 and 17 where you could enter any number through the phone keypad on voip or receive a call and have access to the information on the customer with the associated phone number. This was a functionality that the customer on the ticket was using prior to upgrade. I have added back this functionality through a non blocking call to a new function in res.partner that will search up the contact based on the phone number entered in the softphone. When the data comes back from the back end the UI will be updated with the partner information if it found it. This also has a side effect of fixing the customer wizard button as well. opw-3770625
This fix corrects an issue where payroll reports were showing duplicate pay records when the same salary rule appeared multiple times on a payslip. The system now properly aggregates these repeated rules so payroll reporting accurately reflects the actual pay data without duplicates.
Original PR description
**Current behavior:** On a payslip, creating multiple lines with the same rule code will result in a misreport with duplicate pay records. **Expected behavior:** Payroll reporting should accurately…
**Current behavior:**
On a payslip, creating multiple lines with the same rule code
will result in a misreport with duplicate pay records.
**Expected behavior:**
Payroll reporting should accurately reflect reality.
**Steps to reproduce:**
1. Create a new salary rule (e.g., Commission) and set its
'code' field to 'COMMISSION' and tick the option
`View on Payroll Reporting`
2. Set its 'Condition Based on' to 'Python Expression' and enter
`result = (inputs.get("COMMISSION") or 0)`
3. Set its 'Computation' to 'Python code' and enter
`result = (inputs.get("COMMISSION") or 0).amount`
`result_name = (inputs.get("COMMISSION") or 0).name`
4. Create a `hr.payslip.input.type` (other input type) record
to permit the newly created salary rule to appear on a
payslip (e.g., Country of current company and 'Regular Pay'
for 'Availability in Structure' and 'code' = 'COMMISSION'
5. Create a payslip record (To Pay) for some employee, selecting
the structure that permits the newly created rule to be
applied (e.g., 'Regular Pay') (Note the pay period)
6. In the 'Other Inputs' table add two lines both set to the
'COMMISSION' code -> Compute Sheet -> Create Draft Entry
7. Go to the Reporting -> Payroll -> Pivot View, collapse the
y-axis; Expand y-axis -> Employee -> Employee from payslip
-> Add Custom Group -> End Date; Observe multiple entries
pay period defined when creating the payslip
**Cause of the issue:**
In `hr.payroll.report` these rules will be grouped by their
'total' fields. When we have a repeated rule code with some
'total' amount, we will create two reports for the same
payslip.
**Fix:**
Use a SUM to aggregate these additional_rules in the SELECT and
remove them from the GROUP BY. We need another DISTINCT clause
to ensure we aren't summing redundant row values.
opw-3614679This fix resolves a problem where customers in timezones ahead of UTC (UTC+X) were unable to complete rental orders for products available on certain days. The issue occurred because rental dates were being converted to UTC before checking availability, causing the system to check the wrong day. The fix now properly accounts for the customer's local timezone when determining product availability.
Original PR description
To reproduce : ============== - from rental settings, make rental unavailable on Sunday - with a customer, on timezone UTC+X, create a rental order for a product that is available on Monday -> the checkout button is disabled Problem: ======== the selected dates are converted to UTC before sending them to server, which makes the server think that the selected date is the day before the actual selected date. Solution: ========= localize the selected dates to the user's timezone as we need to retrieve the day of the week in the user's timezone. opw-3778366
This update corrects how subscription invoice amounts are calculated in the customer portal, fixing issues introduced by a previous change. The fix ensures customers see accurate upcoming invoice amounts when managing their subscriptions, improving transparency and reducing billing confusion.
Original PR description
Fix for regressions introduced by https://github.com/odoo/enterprise/pull/58690
This fix resolves an error that occurred when importing accounting data from Winbooks files containing items with zero balance. Previously, the system would attempt to reconcile these zero-balance items, causing a conflict since Odoo automatically treats zero-balance lines as already reconciled. The fix now skips reconciliation for zero-balance items during import, allowing the import process to complete successfully.
Original PR description
The reconciliation of journal items imported from Winbooks is done when all those items are posted. However if one of the imported items to reconcile have zero as balance, it will trigger an error "You are trying to reconcile some entries that are already reconciled." because Odoo consider zero balance lines as reconciled and block the user of posting the entries. This fix removes the reconciliation data when the Winbooks file is imported if the item has a zero balance since this item does not need to be reconciled in the future. opw-3830355
Portal users encountered a system error when navigating between signatures using arrow buttons. This fix resolves a technical issue where an access token was being passed twice to the system, causing the navigation to fail. Users can now smoothly browse through signatures without interruption.
Original PR description
Before this commit: When a portal user navigates through the Signatures using the arrow buttons, an error "500: Internal Server Error" is raised. Traceback error: values = self._get_page_view_values(sign_item_sudo, sign_item_sudo.access_token, values, TypeError: CustomerPortal._get_page_view_values() got multiple values for argument 'access_token' This happened because the argument 'access_token' is passed two times: 1. sign_item_sudo.access_token 2. in **kwargs This commit aims to fix the issue by deleting 'access_token' from kwargs. Task: 3853020 Forward-Port-Of: odoo/enterprise#60299
This update corrects how rounding precision is applied in the Field Service Stock module. Previously, precision values were being passed using incorrect parameter names, which could have caused calculation inaccuracies. The fix ensures rounding is applied correctly, improving the accuracy of stock-related calculations in field service operations.
Original PR description
Versions -------- - 15.0+ Issue ----- `precision_rounding` values were being passed incorrectly as `precision_digits` parameters. Solution -------- Pass them as named `precision_rounding` parameters instead. Community branch: https://github.com/odoo/odoo/pull/162977 Forward-Port-Of: odoo/enterprise#61311
Fixed an issue where certain mandatory fields in Luxembourg electronic financial reports were missing from XML exports when their values were zero. These fields are now always included in the XML output as required by Luxembourg tax authorities, ensuring compliance with regulatory requirements.
Original PR description
**Steps to reproduce:** - Install l10n_lu_reports - Switch to a company in Luxembourg (e.g. LU Company) - Go to "Accounting / Reporting / Statement Reports / Balance Sheet" - Export electronic report via "XML" button **Issue:** Some fields (i.e. "201", "202", "405", "406") don't appear in the XML if their value is 0. These fields are mandatory and should always appear in the XML. **Source:** https://ecdf.b2g.etat.lu/ecdf/forms/popup/CA_BILAN_ABR/2024/en/1/rules opw-3802589 Forward-Port-Of: odoo/enterprise#61446
This update corrects the service product unit of measure code used in India's GSTR-1 tax reporting from 'UNT' to 'NA' in the HSN JSON configuration. This ensures compliance with GST reporting requirements and prevents potential reporting errors for service-based transactions.
Original PR description
Changed service product UOM code from `UNT` to `NA` in the HSN JSON file for GSTR-1 reporting. Task ID: 3907971
This update fixes automated tests in the Appointment module to work with a new way that links are formatted in the system. The tests were adapted to match the updated link implementation, ensuring the appointment booking system continues to function correctly.
Original PR description
Community PR: https://github.com/odoo/odoo/pull/159995 task-3604728 Forward-Port-Of: odoo/enterprise#61558 Forward-Port-Of: odoo/enterprise#60751
This update corrects a formatting issue in the error message that appears when social media posts fail to publish. The fix ensures that error messages display correctly to users, improving the clarity of post failure notifications.
Original PR description
string format was broken on post fail message, this commit fix it. [Task-3775424](https://www.odoo.com/web#id=3775424&cids=1&menu_id=6478&action=4043&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#61857
Users were unable to download signed documents from the Sign app due to permission errors. This fix simplifies the download process by routing requests through the proper authorization flow, allowing users to successfully download completed documents without encountering access errors.
Original PR description
**Current behavior:** When downloading sign documents via buttons in the form and tree views, user will get an access error on the read perm for the `sign.request.item.value` model. **Expected…
**Current behavior:** When downloading sign documents via buttons in the form and tree views, user will get an access error on the read perm for the `sign.request.item.value` model. **Expected behavior:** These buttons should permit the download of the corresponding document. **Steps to reproduce:** 1. In the Sign app go to Documents 2. In the tree view click the download button by a document which has not already been generated (e.g., any of the demo data documents) **Cause of the issue:** The download buttons call `get_completed_document()` which, if the completed doc has not been generated, will directly call `_generate_completed_document()` where we do a `read_group()` on the `sign.request.item.value` model. This model must be read with `.sudo()` because access rights are never granted to any group. **Fix:** Get rid of the `_generate_completed_document()` call in `get_completed_document()`, letting the program go to the `act_url` flow, into `download_document()`. Here we will access the `sign.request` record with `env.su is True` which will permit the `read_group()` later on in the aforementioned flow. Because we always route from `get_completed_document()` with a `download_type='completed'`, there is no reason to generate the document here. opw-3834177 Forward-Port-Of: odoo/enterprise#61332 Forward-Port-Of: odoo/enterprise#60399
This fix improves the performance of GST Return (GSTR1) report generation for Indian businesses by preventing the system from reprocessing POS orders that have already been invoiced. The change eliminates duplicate order matches and speeds up report generation, especially when most orders have been invoiced.
Original PR description
Remove unwanted matches of POS orders that have already been invoiced Also, speed improves if max of orders is invoiced. taskid: 3906396
This fix resolves a system error that occurred when viewing the ATS (Anexo Transaccional Simplificado) tax report for Ecuador after cancelling draft invoices. The system was trying to process cancelled draft invoices that shouldn't be included in the report, causing the report to fail. Now cancelled draft invoices are properly filtered out, allowing the report to generate successfully.
Original PR description
**Steps to reproduce:** - Install l10n_ec_reports_ats - Switch to an Ecuadorian company (e.g. EC Company) - Create a draft invoice - Cancel the invoice - Go to "Accounting / Reporting / Statement Reports / Tax Report" - Filter the report on the same month than the cancelled invoice - Click on upper-left ATS button **Issue:** A traceback is raised: "TypeError: 'bool' object is not subscriptable" while trying to render the cancelled moves: <secuencialInicio t-out="void_move.l10n_latam_document_number[-9:]"/> **Cause:** "l10n_latam_document_number" field is a computed field that depends on the name of the account move. When the move is in draft, it doesn't have a name (i.e. "/") and "l10n_latam_document_number" has False as value. **Solution:** Cancelled draft invoices should not be taken into account in ATS report. opw-3857645 Forward-Port-Of: odoo/enterprise#61737
This fix corrects a rounding error that occurred when exporting German accounting data to DATEV format for invoices with early payment discounts. Previously, exported amounts differed by 0.01 from the actual payment records because the export process didn't apply the same rounding adjustments that the payment system uses. Now the export process matches the payment calculations exactly.
Original PR description
Configure 'Cash Discount Tax Reduction' on 'On early payment' Have a payment term configured with 2% discount for early payment Create an invoice with the said payment terms and the following lines:…
Configure 'Cash Discount Tax Reduction' on 'On early payment' Have a payment term configured with 2% discount for early payment Create an invoice with the said payment terms and the following lines: 1) qty 1, price unit 468, discount 28, tax 19% 2) qty 1, price unit 480, discount 28, tax 19% 3) qty 1, price unit 85, discount 28, tax 19% 4) qty 1, price unit 6, discount 0, tax 19% 5) qty 2, price unit 6, discount 0, tax 19% Register the payment with the early payment discount Check the payment Early payment lines amount are 15.23 + 2.90 (tax discount) = 18.13 Go to General Ledger Export "DATEV (ZIP)" and check accounting_entries.csv Early payment line amount will be 18.12 This occurs because when exporting the system recompute the tax amount due for each line with tax, so we give just a line with the gross amount. However, when the payment is created, the system check for rounding errors and adjust the computed tax amount. This is not done when exporting data and we have a 0.01 difference with the payment entry opw-3801374 Forward-Port-Of: odoo/enterprise#61745 Forward-Port-Of: odoo/enterprise#60927
Fixed an issue where confirmation emails were not being sent to attendees when a paid event registration order was confirmed. The system now properly triggers the email scheduler when an order is confirmed, ensuring attendees receive their registration confirmation messages as expected.
Original PR description
**Steps to reproduce the issue:** - Install the `website_event_sale` module (for test purpose) - Create an event with a paid ticket - Go to the website and register to the event - Go to backend and…
**Steps to reproduce the issue:** - Install the `website_event_sale` module (for test purpose) - Create an event with a paid ticket - Go to the website and register to the event - Go to backend and confirm the sale order if pending payment - Go to the event and open the new registration **Issue:** No mail send to the attendee. **Cause:** Since the following commit, the registration state is overwritten in the `event_sale` module where we added a compute method to the state field: `_compute_registration_status`, compute method already used by the `sale_status` field (compute method was renamed) and depending on the `sale_order_id.state` field. https://github.com/odoo/odoo/commit/4a20cb320b8e251c3670c4fb25ee1b6ba9d2d19b When confirming the sale order, the registration state is computed but the mail scheduler is not run (scheduler executed only in `create` and `write` method). **Solution:** Run the mail scheduler for open registrations in the `action_confirm` method of the `sale.order` model. opw-3820441
This update fixes automated tests in the Peppol accounting module by ensuring all external service responses are properly simulated during testing. The tests were failing because they weren't mocking a required participant verification check that occurs when importing supplier documents. This fix ensures tests run reliably without depending on external services.
Original PR description
Responses should be mocked according to requests that are made during tests. The tests use a sample Peppol file, where the supplier is `0198:dk16356706`. When the document is imported and its content is extracted, the corresponding partner is created with these `peppol_eas` and `peppol_endpoint` values. That triggers a participant check but the response is not mocked for this endpoint. This commit adds a mock response for the endpoint that matches the test file. no task, reported by gawa --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix corrects a display issue in the Accounting module where credit notes were incorrectly shown instead of invoices and bills in the "Amounts to Settle" sections for both customers and vendors. The problem was caused by an incorrect filter configuration in the system, which has now been corrected to show the right documents.
Original PR description
Steps: - Go to Accounting/Customers/Amounts to Settle or Accounting/Vendors/Amounts to Settle - The credit notes are displayed instead of the invoices/bills This is due to a wrong domain in the window action. opw-3858520
This fix ensures that when inventory is automatically replenished through purchase orders, items are directed to the correct storage location specified in the warehouse operations setup. Previously, the system was using a less precise location, which could cause inventory to be placed in the wrong shelf or area. This correction ensures inventory locations are handled consistently and accurately throughout the replenishment process.
Original PR description
### Steps to reproduce: - Create a storable product and add a vendor - Go to settings and activate the Multi-step Routes - Go to Inventory > Configuration > Warehouse Manag. > Operations Types -…
### Steps to reproduce: - Create a storable product and add a vendor - Go to settings and activate the Multi-step Routes - Go to Inventory > Configuration > Warehouse Manag. > Operations Types - Create a new Operation type of type Receipt with WH/Stock/Shelf 1 as default Destination Location - Go to Inventory > Operations > Replenishment - Create a new replenishment for one unit of your storable product using the Buy route with destination WH/Stock - Click on the truck icon > go to the associated Purchase order - Add your receipt operation in the deliver to field - Confirm the purchase order and go to the associated receipt ### Current behavior: The destination of the stock picking is set to WH/Stock/Shelf1 but the detailed operation of the stock move line is set to WH/Stock. ### Expected behavior: The destination of the stock move line should always be more or equally as precise as the associated stock picking. In this case the destination should be WH/Stock/Shelf1. ### Cause of the issue: Confirming the PO, will first create a stock picking and then generate the associated stock moves from the purchase order lines and the picking: https://github.com/odoo/odoo/blob/3f7b19ba05acf59c5780444be2446fcb0da7a907/addons/purchase_stock/models/purchase.py#L225-L230 However, since the purchase order was created via an orderpoint (our replenishment), the purchase order line is associated with an orderpoint, so that the stock move destination will be set to the destination of the orderpoint in priority: https://github.com/odoo/odoo/blob/3f7b19ba05acf59c5780444be2446fcb0da7a907/addons/purchase_stock/models/purchase.py#L514 opw-3812952 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163235 Forward-Port-Of: odoo/odoo#161285
When duplicating a product that has attributes with extra prices configured, those price adjustments are now properly copied to the new product. Previously, the extra prices would be lost during duplication, requiring manual reconfiguration. This fix ensures that product copies maintain all pricing configurations automatically.
Original PR description
Current Behavior: - Creating a copy of a product with attributes and extra prices set for the values of this attribute will not copy the extra prices. Expected Behavior: - These prices should be…
Current Behavior: - Creating a copy of a product with attributes and extra prices set for the values of this attribute will not copy the extra prices. Expected Behavior: - These prices should be matched with the newly created objects if possible. Steps to reproduce: - - Create a product > add an attribute line with at least one value. - Save the product > configure the attribute line and set an extra price for that value. - Duplicate the product. Fix: - Since copies are not created in cascade by the framework, we need to match by hand the `price_extra` and the `exlude_for` of the newly created `product.template.attribute.value` with the old ones. As this matching might not be deterministic when the same attribute and value combination is used on multiple lines, we expect that the extra price and the exclusion rule depend only on this combination. opw-3731192 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162972 Forward-Port-Of: odoo/odoo#154692
This update corrects how numbers are converted to Arabic text. Previously, the system was incorrectly adding the word "one" before thousands, millions, and billions in Arabic translations. For example, 1234.56 was being translated with an unnecessary "one" prefix. This fix removes that erroneous word, making Arabic number translations grammatically correct and more professional for business documents and reports.
Original PR description
patch fixed Arabic class from newer version of num2words package. ## Description of the issue/feature this PR addresses the num2words library does not correctly convert some numbers to words in Arabic. It erroneously appends the Arabic equivalent of "one" to the translation of 1000 (one thousand), when it must be implicit. Also, it was noticed that this behaviour happens in all multiple of 1000s. It appends 'one' to million and billion, etc. ## Current behaviour before PR ``` >>> from num2words import num2words >>> num2words(1234.56, lang="ar") 'واحد ألف و مئتان و أربعة و ثلاثون , ست و خمسون' ``` ## Desired behaviour after PR is merged: ``` >>> from num2words import num2words >>> num2words(1234.56, lang="ar") 'ألف و مئتان و أربعة و ثلاثون , ست و خمسون' ``` Forward-Port-Of: odoo/odoo#156286
A syntax error in the CRM module was corrected by removing an extra closing curly brace that was not properly matched. This fix ensures the code is syntactically correct and functions as intended.
Original PR description
WHY: There is one extra "}" curly brace which is not needed to close the opening one. I think it is a syntax error. WHAT: I removed the curly brace, it also needs testing to make sure, but it is very obvious to observe. This is my first commit in the code, forgive me for not following the required instructions, but I was happy to commit in the documentation repository and I hope you help me with that in this repository too. Thanks, --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a critical error that occurred during the Luxembourg localization module upgrade. The tax loading script was running too early in the system startup process, before all required modules were fully initialized. By moving the script to run at the end of the startup sequence, the system can now successfully complete the upgrade without errors.
Original PR description
Load taxes in an end script when all modules are loaded. Move script to end. ``` Traceback (most recent call last): File "/home/odoo/src/odoo/saas-17.1/odoo/service/server.py", line 1286, in…
Load taxes in an end script when all modules are loaded.
Move script to end.
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/saas-17.1/odoo/service/server.py", line
1286, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "<decorator-gen-14>", line 2, in new
File "/home/odoo/src/odoo/saas-17.1/odoo/tools/func.py", line 87, in
locked
return func(inst, *args, **kwargs)
File "/home/odoo/src/odoo/saas-17.1/odoo/modules/registry.py", line
119, in new
odoo.modules.load_modules(registry, force_demo, status,
update_module)
File "/home/odoo/src/odoo/saas-17.1/odoo/modules/loading.py", line
476, in load_modules
processed_modules += load_marked_modules(env, graph,
File "/home/odoo/src/odoo/saas-17.1/odoo/modules/loading.py", line
364, in load_marked_modules
loaded, processed = load_module_graph(
File "/home/odoo/src/odoo/saas-17.1/odoo/modules/loading.py", line
232, in load_module_graph
migrations.migrate_module(package, 'post')
File "/home/odoo/src/odoo/saas-17.1/odoo/modules/migration.py", line
240, in migrate_module
migrate(self.cr, installed_version)
File
"/home/odoo/src/odoo/saas-17.1/addons/l10n_lu/migrations/2.2/post-migrate_update_taxes.py",
line 7, in migrate
env['account.chart.template'].try_loading('lu', company)
File
"/home/odoo/src/odoo/saas-17.1/addons/account/models/chart_template.py",
line 144, in try_loading
return self._load(template_code, company, install_demo)
File
"/home/odoo/src/odoo/saas-17.1/addons/account/models/chart_template.py",
line 195, in _load
self._post_load_data(template_code, company, template_data)
File
"/home/odoo/src/enterprise/saas-17.1/account_reports/models/chart_template.py",
line 31, in _post_load_data
company._get_and_update_tax_closing_moves(fields.Date.today(),
include_domestic=True)
File
"/home/odoo/src/enterprise/saas-17.1/account_reports/models/res_company.py",
line 162, in _get_and_update_tax_closing_moves
report, tax_closing_options =
tax_closing_move._get_report_options_from_tax_closing_entry()
File
"/home/odoo/src/enterprise/saas-17.1/account_reports/models/account_move.py",
line 209, in _get_report_options_from_tax_closing_entry
report_options =
tax_report.with_context(allowed_company_ids=company_ids).get_options(previous_options=options)
File
"/home/odoo/src/enterprise/saas-17.1/account_reports/models/account_report.py",
line 1631, in get_options
return
self.env['account.report'].browse(options['report_id']).get_options(variant_options)
File
"/home/odoo/src/enterprise/saas-17.1/account_reports/models/account_report.py",
line 1636, in get_options
initializer(options, previous_options=previous_options)
File
"/home/odoo/src/enterprise/saas-17.1/account_reports/models/account_report.py",
line 1470, in _init_options_section_buttons
options['buttons'] =
sections_source.get_options(previous_options={**options,
'no_report_reroute': True})['buttons']
File
"/home/odoo/src/enterprise/saas-17.1/account_reports/models/account_report.py",
line 1636, in get_options
initializer(options, previous_options=previous_options)
File
"/home/odoo/src/enterprise/saas-17.1/account_reports/models/account_report.py",
line 1585, in _init_options_custom
self.env[custom_handler_model]._custom_options_initializer(self,
options, previous_options)
File "/home/odoo/src/odoo/saas-17.1/odoo/api.py", line 534, in
__getitem__
return self.registry[model_name](self, (), ())
File "/home/odoo/src/odoo/saas-17.1/odoo/modules/registry.py", line
224, in __getitem__
return self.models[model_name]
KeyError: 'l10n_lu.tax.report.handler'
```
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#163114This update corrects how rounding precision is applied in event sales and purchase order calculations. The system was using incorrect parameters when rounding monetary amounts, which could lead to calculation errors. This fix ensures amounts are rounded correctly according to company standards.
Original PR description
Versions -------- - 15.0+ Issue ----- `precision_rounding` values were being passed incorrectly as `precision_digits` parameters. Solution -------- Pass them as named `precision_rounding` parameters instead. Enterprise branch: https://github.com/odoo/enterprise/pull/61311 Forward-Port-Of: odoo/odoo#162977
This update fixes several text editing problems on mobile devices, particularly with iOS dictation features that were causing text to be duplicated or inserted in the wrong location. It also addresses issues with keyboard composition on different devices and improves how the editor handles text input on mobile platforms.
Original PR description
In iOS, there is a dictation feature accessible from the keyboard. This feature modifies the DOM directly and triggers input events. From observations made on [1], it seems it triggers each event…
In iOS, there is a dictation feature accessible from the keyboard. This feature modifies the DOM directly and triggers input events. From observations made on [1], it seems it triggers each event twice for unknown reason. Since there is custom editor code bound on this event, the `insertText` function was called twice, thus resulting in the text being duplicated. Note that the bug is in fact subtle because, if the selection reported by iOS was always accurate when triggering those events, then calling `insertText` twice would have no visual effect. However, in the case where the user chooses to manually stop the dictation mechanism through the dedicated button on the keyboard before it has finished writing the whole sentence, then the selection is not updated accordingly and the second call to `insertText` ends up inserting the text at the wrong place, thus triggering the symptom of duplicating the text. This commit fixes the issue by restricting the cases where a manual call to `insertText` is needed. The previous comment specified that the only case in which it was needed was when some text was selected. This is not entirely true. The only case in which it is needed is when text is selected in a way that spans multiple block elements, as this is the only case where the browser can alter those nodes by removing or merging them. Note that the first line of the `insertText` conditional branch, the one that fetches the current selection, actually looks fishy. It is possible the bug is caused by the fact that this selection is used instead of `this._currentStep.selection`. That being said, changing that part of the code in stable would not be worth the risk of breaking something that might rely on it, especially considering the dictation on iOS is a pretty niche feature. Also note that, for some reason, the issue only happens when the paragraph was empty when the dictation started. If some previous text was already present in the paragraph, for example from a previous dictation test, then the duplication will not occur. In this case however, a traceback can sometimes occur due to the fact that when checking for a potential url match, the `pop` method is called on an array multiple times then the result value is used as an object even though no check were made to make sure that the return value was not `undefined` because the array had nothing more to pop. This commit fixes that second issue by adding the missing check. task-3374520 opw-3167676 [1]: https://w3c.github.io/uievents/tools/key-event-viewer-ce.html Forward-Port-Of: odoo/odoo#163894 Forward-Port-Of: odoo/odoo#160363
This fix ensures that when a user changes the fiscal position on a sales order, the system properly displays the 'Update taxes' prompt. Previously, this notification may not have appeared, potentially causing users to miss the opportunity to recalculate taxes based on the new fiscal position rules.
Original PR description
opw-3869944 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents users from including password-protected or encrypted PDF files within quote documents in the PDF Quote Builder. The system now validates PDF files when they are added to quotes to ensure they are not encrypted, which prevents potential issues with quote generation and document processing.
Original PR description
opw-3863423
This fix resolves an issue where serial-tracked components that were scrapped and then unscrapped could not be reused in new manufacturing orders. The system was incorrectly preventing their use due to overly strict uniqueness checks. Now, the system properly allows these components to be reused by only tracking their usage within manufacturing contexts, ignoring scrap and unscrap operations.
Original PR description
It is currently not possible to use a scrapped tracked-by-SN component in a new MO To reproduce the issue: 1. In Settings, enable "Multi Locations" 2. Create two products P_finished, P_comp: -…
It is currently not possible to use a scrapped tracked-by-SN
component in a new MO
To reproduce the issue:
1. In Settings, enable "Multi Locations"
2. Create two products P_finished, P_comp:
- Storable
- P_comp tracked by SN
3. Update the quantity of P_comp:
- WH/Stock: 1 x SN01
4. Process a manufacturing order:
- Product: P_finished
- Components:
- 1 x P_comp
5. Process a repair order:
- Product: P_finished
- Remove:
- Product: P_comp
- Lot: SN01
- Destination Location: Virtual Location/scrap
6. Unscrap SN01 (via an internal transfer from scrap to stock)
7. Repeat 4
Error: a UserError is displayed because the SN of the component has
already been consumed. It should be possible to use it
When checking the uniqueness, we are working on the SMLs (see the
lines removed by this commit).
`duplicates` contains the SML from step 4. `duplicates_returned` is
zero since we did not return the component back to the stock.
`removed` is zero too, because we look at the scrapped SML from an
internal location. However, step 5 generates an SML that starts from
the production location. As a result, nothing compensate the value
of `duplicates`, hence the raised error.
Removing the condition of the source location of `removed` would
lead to another bug, so we can't do that. So, this commit suggests a
new implementation based on the following rationale:
- The uniqueness checking simply ensures that one and only one
existing finished product consumed a specific SN
- What happened outside this context does not matter here
That way, we should only look at the SML from/to production
locations, for tracked-by-sn products used as components only. All
other SML (scrap, unscrap, SML for SN production, and so on) should
not be considered here.
OPW-3834835
Forward-Port-Of: odoo/odoo#163972
Forward-Port-Of: odoo/odoo#163394This pull request contains multiple bug fixes addressing issues in the web editor, project sharing, CRM, email marketing, accounting, and sales modules. Key improvements include fixing text formatting in lists, correcting table menu alignment in right-to-left languages, restricting portal user access in certain workflows, fixing image sizing in email templates, and preventing incorrect price calculations in sales orders with expensed items.
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
Accountants with full accounting rights can now upload vendor bills without encountering an access error. Previously, when uploading the first vendor bill in a company, the system would block access to the onboarding guide because it was restricted to administrators only. This fix allows accountants to complete the vendor bill upload process smoothly.
Original PR description
Currently, in a database that lacks vendor bill records, if a user with all accounting rights attempts to upload a vendor bill, they encounter an access error. ### Steps to Reproduce 1. Install the `account_accountant` module. 2. Switch to a company that does not have any vendor bills. 3. Use an account that has full accounting rights but lacks administration rights. 4. On the accounting dashboard, within the vendor bills journal, click on 'Upload'. You should be met with an access error stating, "You are not allowed to access 'Onboarding Step' (onboarding.onboarding.step)." ### Cause When no bill has been previously created and a user tries to upload one, the system triggers an onboarding popup. However, access to this popup is restricted to the 'Administration/Settings' (base.group_system) group. opw-3887851 opw-3890044 Forward-Port-Of: odoo/odoo#163709
This update fixes an issue where text content couldn't be edited after dragging columns into website forms. Previously, when users added multi-column text layouts inside forms, the text became locked and uneditable. The fix allows these columns to be properly edited while maintaining form functionality.
Original PR description
Steps to reproduce: - Go to a website page (in "edit" mode) > Drop a "Form" block. - Drop a "Text" snippet above the form. - Change text layout into two columns. - Drag and drop one column inside the form (between two fields). - Click inside the text > You can't edit it. The text column was considered as “editable” (its editability was inherited from its parent element). And right after the drag & drop, the code in the form option will set the whole snippet as non-editable (`[contentEditable=false]`) and only allow some specific elements to be edited (buttons, description...). The goal of this commit is to fix this issue by simply including the columns "that are not fields" in the list of form editable elements. task-3702824 Forward-Port-Of: odoo/odoo#163953 Forward-Port-Of: odoo/odoo#153894
This fix resolves an error that occurred when using Quick Encoding in invoices with section lines. The system was incorrectly applying accounting field values (like account assignments) to non-accounting lines such as sections and notes, causing the invoice to fail validation. Now, Quick Encoding values are only applied to actual accounting lines, allowing invoices with sections to save properly.
Original PR description
### Steps to Reproduce 1. Install the `account` module. 2. Activate Quick Encoding in the settings. 3. Create an invoice and populate the 'Total (Tax inc.)' field, which will automatically generate an invoice line. 4. Add a section line to the invoice. 5. Attempt to save the invoice. An error message should appear, stating: "The operation cannot be completed: Forbidden balance or account on non-accountable line." ### Cause The issue arises due to a constraint that prevents non-accounting lines (such as sections and notes) from having values in accounting fields (debit, credit, account, etc.). When Quick Encoding is enabled and the 'Total (Tax inc.)' field is populated, the system automatically suggests and applies default values to new lines. Unfortunately, these defaults are also applied to non-accounting lines, leading to the assignment of an `account_id` to the section line, which violates the existing constraint. opw-3852844 Forward-Port-Of: odoo/odoo#163717
This fix resolves a crash that occurred when editing form fields during the checkout process in website sales. When users tried to customize the Extra Info step form, the system would encounter an error. The update ensures the form editor properly handles all model types, preventing the application from breaking when accessing form field properties.
Original PR description
### Steps to reproduce * install `website_sale` * in the settings, enable 'Extra Step During Checkout' * go to the Extra Info step in the checkout process * switch to edit mode and click on any input in the form You should be met with a traceback: "Cannot read property of undefined (reading 'website_form_label')" ### Cause This issue was introduced with odoo/odoo@3626e36a9c4995286be48206b0d927f1de51e295 Basically, if you try to edit a form whose model is not one of the `compatible_form_models`, you get a traceback because the system attempts to access `website_form_label` on an empty form. opw-3891255 Forward-Port-Of: odoo/odoo#163962
This update fixes how users can interact with links in the web editor, allowing the cursor to be placed both inside and outside links more naturally. The system now uses invisible spacing characters around links to improve selection behavior, and fixes issues with Bootstrap buttons in the backend where text selection was previously impossible. These changes make link editing more intuitive and reliable.
Original PR description
This implements a new approach to solve selection issues around links (allowing the cursor at the inner _and_ outer edges of links). In the sanitization process, every link now receives 4 zero-width…
This implements a new approach to solve selection issues around links (allowing the cursor at the inner _and_ outer edges of links). In the sanitization process, every link now receives 4 zero-width non-breaking spaces (unicode FEFF characters, hereafter referred to as ZWNBSP): - one before the link - one as the link's first child - one as the link's last child - one after the link like so: `//ZWNBSP//<a>//ZWNBSP//label//ZWNBSP//</a>//ZWNBSP`. An advantage of ZWNBSP over regular ZWSP (unicode 200B) is they're less likely to be used deliberately by the user, so much so that we can safely assume all of them are technical and can be removed indiscriminately. ZWSP and ZWNBSP are used to mark a separation between words in languages that don't use spaces for that purpose (eg, Lao). ZWNBSP are to ZWSP what NBSP (unicode 00A0) are to regular spaces. Because of that advantage, we don't need to track the ZWNBSP (so there is no need to wrap them in `span` elements), simplifying the code considerably. We therefore now remove all ZWNBSP when saving. There is a possibility to introduce "orphaned" ZWNBSP during the editing process, if for instance the link has a big enough padding or margin that it's possible to click between two of a link's ZWNBSP (one outer, the other inner). Inserting a character or a paragraph break in such a position will move the ZWNBSP to a place where it's not useful anymore. The sanitizer will then reintroduce the useful ZWNBSP in their rightful places. We remove the orphaned ZWNBSP from the sanitizer whenever that is possible without risking to break the selection. To properly deal with this change, we also change the handlers for the delete/backspace/deleteRange, enter and arrow keys. This PR also makes some indirectly related changes: - It fixes a bug with Bootstrap buttons in the "backend" where it's currently impossible to put the selection within them (and the wrong cursor appears) because of a Boostrap CSS. - It introduces a debugging utility function to log the selection. - It slightly modifies the way the `enter` key handler works at the inner edges of links so that a paragraph break will never be inserted at the end of the link (creating an empty link). Co-authored-by: Sébastien Geelen <sge@odoo.com> task-3604728 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163548 Forward-Port-Of: odoo/odoo#157200
This fix resolves an issue where SVG images would disappear from the editor after being cropped and the user clicked elsewhere or saved their work. Users can now confidently crop SVG images in the web editor without losing them.
Original PR description
**Before this commit:** SVG images disappeared after cropping and clicking elsewhere or saving. **After this commit:** Now the images don't disappear after cropping. task-3809854 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163895 Forward-Port-Of: odoo/odoo#162032
This fix resolves an issue where customers using the same pick-up location would incorrectly share delivery contact information. Previously, the system would reuse the first customer's contact details for subsequent orders at the same location. Now each customer gets their own separate contact record, ensuring accurate delivery information for all orders.
Original PR description
Steps to reproduce: 1. Configure Sendcloud shipping with pick-up locations 2. Go to website and use the shipping method and select a pick-up location 3. Try step 2 again, using the same pick-up point but with a different name 4. Checking the delivery address of the second customer, we see the name of the first customer is used The problem is that if a pick-up location is already saved, we re-use the same contact for the delivery address. This commit ensures separate contacts are created for different customers. opw-3853716 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162950
Fixed an issue where non-administrator users with Advisor accounting rights would encounter a rendering error when accessing sales journals in Saudi Arabia. The fix hides ZATCA compliance fields from users who don't have permission to view them, allowing these users to access journals without errors.
Original PR description
Steps to reproduce ------------------ 1. Install the `l10n_sa_edi` module. 2. Create a user X with `Advisor` as Accounting Rights only 3. Log in as user X and try accessing a sales Journal for company SA Issue ----- Error: Rendering Failed Cause ----- When a user without the group `base.group_system` tries to access the `l10n_sa_compliance_csid_json` or `l10n_sa_production_csid_json` fields (needed to display the ZATCA process steps) in the journal form view, the rendering fails. Solution -------- Hide the ZATCA process steps if the user does not have access to `l10n_sa_compliance_csid_json` or `l10n_sa_production_csid_json` fields. opw-3812234 Forward-Port-Of: odoo/odoo#163572 Forward-Port-Of: odoo/odoo#161024
This fix ensures that customers who have earned free shipping rewards through loyalty programs can now properly apply them when using Stripe's Express Checkout payment method. Previously, these free shipping discounts were being ignored during the express checkout process, resulting in customers being charged for shipping they shouldn't have to pay for.
Original PR description
Before this commit, free shipping rewards were ignored when customers used Express Checkout to pay for their orders. Now, Express Checkout will consider free shipping rewards when `loyalty` is installed. opw-3822059 Forward-Port-Of: odoo/odoo#164222 Forward-Port-Of: odoo/odoo#164176
A test for email template scheduling was failing intermittently due to time changes occurring during test execution. This fix freezes the system clock during the test to ensure consistent, reliable results. The change ensures that email template dynamic date calculations work correctly without being affected by real-world time passing during testing.
Original PR description
A test exists on mail.template to test dynamic evaluation of scheduled_date field, based on datetime. However it currently runs on non-mocked datetime and it sometimes fails due to a minute-switch between test begin and end. In this commit we freeze the time to ensure test is fixed. However we also have to somehow hack "safe_eval.datetime" usage as it is not covered by standard usage of "freeze_time", probably because it is wrapped. Simplest solution is to mock it directly, assuming safe_eval itself is working as intended (breaking safe_eval itself will probably break other tests; purpose of mail.template test is to check its dynamic rendering is effectively called and taken into account when sending emails based on templates). Task-3872732 Runbot-54946 Forward-Port-Of: odoo/odoo#163943
This fix resolves an issue where sales orders with multiple products were creating separate pickings instead of consolidating them into a single picking. The problem occurred when warehouse settings were configured in a certain way. The fix ensures that location checks only apply to three-step manufacturing processes, preventing unnecessary duplication of picking documents.
Original PR description
The steps to reproduce: - Go to a warehouse. Under the technical information tab, change the field sam_loc_id from "WH/Post-Production" to "WH/Stock". - Create a sales order with 2 different products and confirm it. - 2 pickings will be created with different group_id MO/XXXX instead of a single picking. After this commit, we only check the sam_loc_id if we are in 3 steps manufacturing. OPW-3871886 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#164221 Forward-Port-Of: odoo/odoo#162947
A field label for the "Register of Legal Entities" was not displaying in the Norwegian localization when creating company contacts. This fix restores the proper display of the field name, ensuring users can see what information they're entering when setting up Norwegian business contacts.
Original PR description
Problem: For the Norwegian localization, the field name "Register of Legal Entities (Brønnøysund Register Center)" is not displayed Steps to reproduce: - Install "Contacts" app and "l10n_no" module - Create a new Norwegian contact as company, the field below "Tax ID" has no name Cause: Probably a change in the framework making the behavior different compared to previous versions opw-3863407 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162836
A test for the website media dialog feature was not running because it was missing the required "test_" prefix in the Python method name. This fix corrects the naming issue and updates the test to work properly with the current website preview system, ensuring the media dialog functionality is properly validated.
Original PR description
The test `website_media_dialog_undraw` (introduced in [this commit]) wasn't launched because the python method was not prefixed by `test_`. [this commit]: https://github.com/odoo/odoo/commit/d6ca59ed9bf6877ee6b1b311223472adfa4db549 Forward-Port-Of: odoo/odoo#163616 Forward-Port-Of: odoo/odoo#163555
A syntax error in the CRM module's team views configuration file has been corrected by removing an extra closing curly brace. This fix ensures the configuration file is properly formatted and functions as intended without any syntax issues.
Original PR description
WHY: There is one extra "}" curly brace which is not needed to close the opening one. I think it is a syntax error. WHAT: I removed the curly brace, it also needs testing to make sure, but it is very obvious to observe. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes inconsistent test behavior in the Website Sales module by applying proven improvements from newer versions. The change makes automated tests run more reliably and predictably, reducing false failures and improving overall system stability.
Original PR description
Since this issue does not happen in more recent versions, it has probably been fixed by the recent improvements in the tests setups of website_sale. This commits backports those changes to hopefully make the tour more deterministic and solve the issue. runbot issue 47213 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix corrects a rounding error in early payment discounts that was causing a 1-cent difference in the final amount due. When customers received an early payment discount that included taxes, the system was rounding the discount amount and the final price separately, leading to inconsistent results. The fix ensures rounding happens consistently after calculating the discounted amount, so customers see accurate payment amounts.
Original PR description
Versions -------- - saas-16.3+ Issue ----- If early pay discount includes taxes, its amount was calculated by first multiplying the total amount by the discount's complementary percentage, and take…
Versions
--------
- saas-16.3+
Issue
-----
If early pay discount includes taxes, its amount was calculated by first multiplying the total amount by the discount's complementary percentage, and take the difference between its result and the total amount.
Let's assume discount is 10% and total price is 1725.05.
- We want to pay 90% of the full amount, which is 1552.545;
- to get the discount, we subtract it from the full amount:
1725.05 - 1552.545 = 172.505;
- we then round this discount to 172.51;
- and return total amount minus discount as amount due after discount:
1725.05 - 172.51 = 1552.54
- elsewhere we round 1552.545 to 1552.55, a 1 cent difference
Cause
-----
The `_get_amount_due_after_discount` adds half a cent to the discount by rounding half-up, while elsewhere the reduced price gets rounded half-up, increasing it by half a cent, this adds up to a 1 cent discrepancy.
Solution
--------
Call the rounding method after subtracting discount from the total amount, so rounding happens in the same direction.
Issue found working on opw-3705546
Forward-Port-Of: odoo/odoo#163786This update fixes two critical issues that prevented users from properly creating repair orders from returned items. Previously, repair parts would incorrectly link to the return transfer instead of the repair order, making them unavailable, and users would encounter validation errors when creating repairs immediately after processing returns. These fixes ensure repair orders work seamlessly in the return workflow.
Original PR description
This PR addresses two issues related to creating repair orders from return transfers: ### The First issue: Steps to reproduce the issue: - Activate `is_repairable` option on any picking type, let's…
This PR addresses two issues related to creating repair orders from return transfers: ### The First issue: Steps to reproduce the issue: - Activate `is_repairable` option on any picking type, let's say "Receipts" - Create a delivery order with any product(s). - Validate it. - Return it. - Validate the generated receipt transfer. - From the generated receipt, click on "Repair" button on the top. - Fill the required fields of the repair order and confirm it. - Add any part (`stock.move`) to the repair order. Expected behavior: - The new `stock.move` is created and the availability is determined based on quantities in stock. Current behavior: - The created `stock.move` is not only attached to the repair order, but is also attached to the related return transfer. - Since the return transfer may be done, no stock move lines are assigned to the newly linked move, which affects the availability making it unavailable. - This availablity status also affects the repair order making it unable to reserve any quantity for its parts. The issue is because clicking on "Repair" button from `stock.picking` form, adds `default_picking_id` to the context variable to be used on the `repair.order` form. When creating stock moves from the repair order form, the `default_picking_id` key in the context is propagated and used to link the new move to a picking, hence, leading to this undesired behavior. ### The Second Issue: Steps to reproduce the issue: - Create a delivery order. - Validate it. - Return it. - Without navigating to another page, validate the generated receipt order. - Click on "Repair" button. - Select any product on the RO form. Expected behavior: - Form is saved and the repair order is created. Current behavior: - Validation error shows: "A mandatory field is not set", `parts_location_id`. The issue is caused by `default_picking_type_id` key that exists in the context variable when a return order is created from another transfer. This variable propagates to the creation of the repair order and is used instead of the correct picking type which is "Repairs" in that case. Task-3877625 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162452
Documentation and clarification updates
This pull request adds a Contributor License Agreement (CLA) signature file for kobros-tech, confirming their legal agreement to contribute to the Odoo project. This is a standard administrative requirement for all external contributors to the Odoo repository.
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