Daily updates from Odoo
Friday, February 23, 2024
45 changes · 17.0
Enhancements to existing features
This update migrates and completes German language translations across localization modules that were reorganized after version 15.0. German localization features were consolidated into shared DIN5008 modules to serve multiple countries more efficiently. The translation updates ensure all modules have complete and accurate German language support.
Original PR description
*datev_reports,pos_cert,pos_res_cert,reports After 15.0, part of the German localization modules have been moved to the DIN5008 modules to be shared with other countries. We migrate the translations here to the correct modules in the versions after 15.0 and complete missing ones. opw-3669388 Related to https://github.com/odoo/odoo/pull/153845 Forward-Port-Of: odoo/enterprise#57158 Forward-Port-Of: odoo/enterprise#56503
This update improves the workflow for creating Service Order Lines (SOLs) directly from helpdesk tickets. Previously, users could only use the "Create and Edit" option, which required additional steps. Now users can quickly create SOLs with a streamlined quick create option, saving time and reducing friction in the ticket-to-sales process.
Original PR description
When creating SOLs on the fly for tickets, only the "Create and Edit" option is available. This PR enables the quick create for SOLs on tickets. Community: https://github.com/odoo/odoo/pull/142720 Task-3553151 Forward-Port-Of: odoo/enterprise#53833
This update improves the user experience of the individual account feature in Belgian payroll processing. The changes streamline the interface and reporting for employees viewing their payroll information, making it easier to access and understand their account details.
Original PR description
TaskID: 3762935
This update reorganizes and completes German language translations across localization modules. After version 15.0, German localization features were consolidated into shared DIN5008 modules to serve multiple countries more efficiently. This change migrates and fills in missing translations to ensure all modules have complete language support in the correct locations.
Original PR description
*de,de_skr03,de_skr04,din5008,din5008_purchase,din5008_repair,din5008_sale,din5008_stock After 15.0, part of the German localization modules have been moved to the DIN5008 modules to be shared with other countries. We migrate the translations here to the correct modules in the versions after 15.0 and complete missing ones. opw-3669388 Related to https://github.com/odoo/enterprise/pull/56503 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154915 Forward-Port-Of: odoo/odoo#153845
This update improves the speed of opening the messaging menu in Odoo by optimizing how the system calculates and accesses message information. The changes reduce unnecessary repeated calculations and data access operations, resulting in faster menu load times—especially noticeable when opening the menu multiple times. Users will experience a smoother, more responsive messaging experience.
Original PR description
Slight speed improvement initially, good improvement especially for subsequent openings. See individual commits. On my machine, with populate medium. Duration of the different calls to sort (the most problematic method) during opening: Before: 150ms, 165ms, 141ms After: 118ms, 50ms, 40ms
This update adds comprehensive testing for dropdown menus and submenus in the web interface to ensure they function correctly across all versions. By backporting this test from a recent improvement, the team ensures consistent quality and reliability of menu interactions for all users.
Original PR description
This commit backports the test introduced in odoo/odoo#155154, as it is relevant to have it in every versions to ensure that dropdown menu (i.e. submenus) are correctly tested. 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#155156
This update prevents the system from sending emails when payment validation transactions are processed and tokens are assigned to orders. This reduces unnecessary email notifications to customers and improves the overall email communication experience by only sending relevant transactional emails.
Original PR description
Before this commit, validation transactions would send an email when the token is assigned to the order. taskid: 3675875 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154650 Forward-Port-Of: odoo/odoo#151773
Resolved issues and error corrections
This update corrects the spacing and alignment of form fields in the Frontdesk Drinks section. Previously, an image field was causing misalignment of input fields relative to their labels. The fix adjusts the spacing settings to ensure all form elements line up properly, improving the visual consistency and usability of the form.
Original PR description
The o_field_image in the Drinks in the form view is cancelling the negative margin applied by the row class on the o_group. Using a gutter-x 0 on the o_group removes the padding allowing the inputs to be aligned with the title. This is a quickfix and the behavior of the o_field_image in a form view should be reviewed consistently across Odoo because different module seems to use their own fix for this (Ref: new task-3584778) task-3584529 | Before | | :--: | |  | After | |  |
This update resolves critical issues in the India payroll system that were causing calculation failures. The fix corrects how gross salary is calculated and updates the rules for salary attachments and assignments, ensuring payroll processes run smoothly without errors.
Original PR description
- A traceback was caused because the gross variable was not defined correctly. - Revise the Python condition 'Attachment of Salary' and 'Assignment of Salary' for the salary rules **Note**: The upgrade script is not needed because the data file is noupdate="0". task-3649463
This fix resolves an issue where orders synchronized from Amazon's Fulfillment by Amazon (FBA) service were creating incomplete stock movements. The system now correctly marks these stock movements as completed when products are delivered by Amazon, ensuring accurate inventory tracking and order fulfillment records.
Original PR description
Currently, synchronizing done order in FBA creates some stock move that are not in the state done anymore. This is due to some changes in the management of the quantity done in stock, that needs to see if the quantity was picked or not. As, in this case, we are confirming a move for products that were stocked in an Amazon Warehouse and then delivered by Amazon, we can manually set the move as being picked. opw-3594556 opw-3662990
This fix prevents subscription email templates from being reset to default values when the sales subscription module is upgraded. By marking these templates as protected during updates, customizations made to subscription emails will now be preserved, ensuring consistent communication with customers across system upgrades.
Original PR description
Fixes that sale_subscription mail templates is reverted on module upgrade When upgrading the sale_subscription module all subscription email templates was reverted due to missing noupdate=1
Fixed issues with Shiprocket delivery integration where long warehouse or company names caused validation errors. The system now automatically truncates names to 36 characters as required by Shiprocket, and prevents delivery orders from being validated when the Shiprocket server is unreachable, improving reliability and user experience.
Original PR description
Before this commit: ================================ - When we use a longer warehouse address name or company name, the shiprocket will return an error message with `The vendor details / pick up location cannot be longer than 36 characters.` After this commit: ================================ - It will only take 36 characters if the warehouse address name or company name is longer than 36 characters while validating the delivery order. - `Cannot reach the server. Please try again later.` - If shiprocket returns this error, the delivery order should not be validated. task-3650073 Forward-Port-Of: odoo/enterprise#53507
This update fixes several issues with the Belgian CodaBox bank connection feature. The main improvements include preventing accidental disconnection when using deprecated functions, improving user-facing terminology for clarity, and ensuring bank files are correctly matched to the right currency accounts. These fixes help users with multiple accounts in different currencies avoid importing transactions to the wrong journal.
Original PR description
task-id 3755037 Documentation PR https://github.com/odoo/documentation/pull/7840
This update fixes an issue where intrastat report lines could have duplicate identifiers despite having different details like incoterm codes, transport methods, or currencies. The fix ensures all relevant transaction details are included in the line identifier so each unique combination is properly tracked and reported separately.
Original PR description
The aim of this commit is making sure that we don't have inconstancies between the `GROUP BY` in the `_build_query_group` and the intrastat report line generic id. Indeed, before this commit, the `incoterm code`, the transport code and the `invoice_currency_id` were not included in the generic id. It means that we can have several lines with the same generic id but with different values (for example incoterm code). This commit adds a test that check that all elements in the `GROUP BY` (except the `system`, type and` region code`) are used in the generation of the generic id. For the excepted keys, `system` and `type` are already separated. Concerning the `region_code`, its value related to the company, it means that this value is not discriminant. opw-3741658 Forward-Port-Of: odoo/enterprise#57180 Forward-Port-Of: odoo/enterprise#57097
This update fixes a bug where users would encounter an error when deselecting all measures in pivot view reports on mobile devices. Instead of showing an error, the system now properly displays a helpful message, improving the mobile user experience for report analysis.
Original PR description
Before this commit user was getting traceback on unselecting all measures in pivot view on mobile. Steps to reproduce: - switch to mobile view. - open the pivot view of any report (tested with the 'tasks analysis' one here). - unselect all measures, the traceback will appear. Observed behavior: a traceback is generated. Expected behavior: no traceback, the action helper is displayed After this commit user will not get traceback on unselecting all measures in pivot view on mobile. Instead of that an action helper will be displayed. Task-3630703 Forward-Port-Of: odoo/enterprise#54051
This update removes two unnecessary guided tours from the accounting module that were providing redundant or confusing user guidance. The tours were creating sample bills and displaying unhelpful instruction bubbles that didn't add value to the user experience. This cleanup helps streamline the application and reduce maintenance burden.
Original PR description
The file `test_ui` is currently not imported. The tour is pretty useless and has been improved in 17.0. We will keep it in that version, to be sure that we don't break the equivalent tour, but we can remove in these versions (it just creates a sample bill and post it, currently). The tour `account_accountant_tour_upload_ocr_step` has been deemed useless. It pops a bubble on a button where it makes no sense, with a self-explanatory message already. Forward-Port-Of: odoo/enterprise#57120 Forward-Port-Of: odoo/enterprise#56726
This fix resolves a critical error that occurred when validating shipments to Canada or Puerto Rico through the UPS delivery integration. The system was looking for shipping information in the wrong location, causing the validation to fail. With this correction, users can now successfully validate and process international deliveries to these destinations.
Original PR description
Steps to reproduce:
Make a delivery operation from the United States to Canada or Puerto Rico. Attept to validate the delivery. A traceback appears:
```
File "/home/odoo/src/enterprise/delivery_ups_rest/models/delivery_ups.py", line 154, in ups_rest_send_shipping
result = ups._send_shipping(
File "/home/odoo/src/enterprise/delivery_ups_rest/models/ups_request.py", line 406, in _send_shipping
request['Shipment']['InvoiceLineTotal'] = {
KeyError: 'Shipment'
```
To fix the issue we need to access `request['ShipmentRequest']['Shipment']` instead of `request['Shipment']`.
opw-3710939
Forward-Port-Of: odoo/enterprise#56891Fixed a bug where employees appeared available for appointments even when they had calendar events that spanned across timezone boundaries. When events were created in certain timezones (like Brussels), they could be stored in UTC on a different day, causing the appointment system to incorrectly show the employee as available. The fix now properly checks for overlapping events across day boundaries to ensure accurate availability.
Original PR description
Current behaviour: --- When an employee places an event on a certain day starting at 00:15 to 18:00 on a brussels TZ, the event is stored on the UTC TZ, so starting the day before at 23:15 to 17:00.…
Current behaviour: --- When an employee places an event on a certain day starting at 00:15 to 18:00 on a brussels TZ, the event is stored on the UTC TZ, so starting the day before at 23:15 to 17:00. This behavior shows the employee as available. Expected behaviour: --- The employee should not be available even if the event start on another day. Steps to reproduce: --- 1. Employee and db has a Brussels TZ 2. Go to Calendar 3. Add an event when employee is available 4. Event starts at 00:15 and ends at 18:00 5. Go to website > Appointment 6. Select Mitchell Admin 7. Look at the date, should be unavailable 8. => Still available Cause of the issue: --- https://github.com/odoo/enterprise/blob/d6135811316837d6523e59163739fc9b954be2e6/appointment/models/calendar_appointment_type.py#L295 If the event starts on another day than the slot, it isn't taken into account. Fix: --- Adding events from yesterday and tomorrow to know if they overlap with the slot opw-3599209 Co-authored-by: Boulif Nasreddin <bon@odoo.com> Forward-Port-Of: odoo/enterprise#57284 Forward-Port-Of: odoo/enterprise#52935
This update fixes how appointment availability is calculated for resources by implementing a default calendar that covers all hours of every day. Previously, when a resource's custom calendar was removed, the system would incorrectly fall back to the company's working schedule, causing confusing availability windows for users. The fix also improves the leave management interface by making the resource field required and hiding irrelevant calendar options.
Original PR description
Add and use a default resource calendar encompassing every hours of every days. This allows to take into account leaves for resource easily as we need a resource calendar for the computation. Indeed when the resource calendar was removed, the one set on the company was used in place which led to weird result for the end user as he didn't expect a working schedule after removing the one set on the resource. task-3562191 Forward-Port-Of: odoo/enterprise#56617
This update prevents the snailmail account followup feature from being automatically activated when the module is installed. Since this feature incurs additional costs, it will now require explicit user activation rather than being enabled by default, helping avoid unexpected charges.
Original PR description
The module is auto-installed, and activating its feature is paying, so not desired. [opw-3180544](https://www.odoo.com/web#id=3180544&model=project.task) Forward-Port-Of: odoo/enterprise#40219
The VAT units menu in the accounting reports module was difficult for users to locate because it was hidden in the configuration menu and only accessible in debug mode. This update makes the menu more discoverable and accessible, improving the user experience for teams managing VAT reporting.
Original PR description
Our users, even our best trained colleagues, don't find the `VAT units` menu. It's too hidden in the configuration menu and in debug mode. this commit makes it discoverable. task-3746523 Forward-Port-Of: odoo/enterprise#56765
This fix corrects how SEPA payment files are generated for Swiss bank accounts. A previous attempt to exclude a specific payment service level (NURG) in Switzerland had a logic error that wasn't caught by testing. The fix simplifies the condition to properly exclude this service level only in Switzerland, ensuring Swiss payments are formatted correctly while other countries remain unaffected.
Original PR description
https://github.com/odoo/enterprise/commit/3479940bf8ba5b0efcc5ce9e10a07e30af1d6f87 intended to fix the conditions under which this node appears in the file, but it was wrong. The functional testing missed this, as the sepa_pain_version field got recomputed when updating the account code; so, checking the pain version was indeed the Swiss one, then modifying the account and putting and IBAN recomputed the pain version to 'Generic', hence compromising the test. The condition can actually be made simpler: we want the SvcLvl everywhere but in Switzerland. Forward-Port-Of: odoo/enterprise#57164 Forward-Port-Of: odoo/enterprise#57104
When customers add optional products to a rental item, the rental duration was not displaying correctly in the cart, even though the price was accurate. This fix ensures that rental duration information is properly shown for all optional products by updating the template structure to include the necessary parent element for the rental details display.
Original PR description
Steps to reproduce: - Install eCommerce Rental module - For a rentable product add an optional product - Now go to the shop and to the rentable product - Select the rental period to a week for exemple - Click on "add to cart" Issues: The price is right but the duration displayed is wrong. Solution: The info are updated by this code: https://github.com/odoo/enterprise/blob/7172d0cd24dbfd9efcb01a793b8e30b797159903/website_sale_renting/static/src/js/variant_mixin.js#L44-L46. Since we didn't have the o_renting_details parent the code couldn't put the right info. opw-3730055 Forward-Port-Of: odoo/enterprise#56715
This update ensures that all sublines in intrastat reports have unique identifiers, just like the main report lines. The fix applies additional identifying values to sublines so they can be properly distinguished from one another in the system, preventing potential data confusion or reporting errors.
Original PR description
In this commit (https://github.com/odoo/enterprise/commit/0f31f77665b10ac85396ed890786f630401f0503), we ensure that generic report line ids are unique by using all discriminant values. This commit ads these discriminant values in the where to make sure that sublines have unique ID as well. no task id Forward-Port-Of: odoo/enterprise#57343 Forward-Port-Of: odoo/enterprise#57256
This update corrects an XML identifier in the Belgian CodaBox Bridge configuration settings module. The fix ensures that the system properly recognizes and references the correct configuration element, preventing potential issues with the bank connection setup process for Belgian users.
This fix resolves a crash that occurred when users tried to verify a partner's Peppol endpoint through the Actions menu. The system was incorrectly returning a boolean value instead of a proper action, causing an error. Now the verification process works correctly and either performs the action or returns nothing as expected.
Original PR description
### Steps to reproduce * install `account_peppol` * open a partner's list view * select a contact * on the top middle, click Actions > Verify Peppol You should be met with a traceback: `AttributeError: 'bool' object has no attribute 'setdefault'` ### Cause `button_account_peppol_check_partner_endpoint` is expected to return an action or a falsy value (no action to perform). opw-3683612
This update removes two payment method options that were not functioning properly: Amazon Pay with Adyen and BLIK with Stripe. These combinations are being discontinued because they either require complex setup processes that don't justify their value or are not supported by the payment provider's current technical capabilities. This cleanup simplifies the payment options available to users.
Original PR description
The following combinations of payment methods and providers are removed: - Amazon Pay - Adyen: The payment method cannot be activated because it requires saving a public key in Odoo, and no field was made available for that. Also, a custom configuration is necessary and the public key must be generated through a lengthy process that is too cumbersome for the added value of the payment method anyway. - BLIK - Stripe: The payment method is not supported by Stripe when the PaymentIntent object is created after collecting the payment details. See https://stripe.com/docs/payments/accept-a-payment-deferred?platform=web&type=payment#enable-payment-methods opw-3736511
Fixed an issue where payment terms were displaying only in English twice instead of showing the correct language translation. When creating invoices for Saudi Arabian companies with payment terms configured in both English and Arabic, the system now properly displays the translated payment terms based on the user's language preference.
Original PR description
Have a SA company In Accounting settings activate invoice terms Add a payment terms string in english, add the arabic translation Create an invoice Click preview Issue: Payment terms will be shown in english twice This occurs because, even if `narration` field is translatable the translation is not automatically copied when the field is copied from the company `invoice_terms`. opw-3530811 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153139 Forward-Port-Of: odoo/odoo#138949
This update corrects a technical issue in how the system calculates accounting entries related to inventory movements. The fix ensures that financial data is properly processed when recording stock transactions, improving the accuracy of accounting records.
Original PR description
This commit fixes summing list of dicts returned by _prepare_analytic_lines. NB: This code is not yet covered by a test use case. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#152819
This fix improves the efficiency of how activity deadline information is retrieved in the mail system. Previously, the system was loading deadline data inefficiently one record at a time. The update now batches these reads together, reducing the number of database queries and improving overall system performance when working with activities and calendar features.
Original PR description
`__getitem__()` of BaseModel, reset the prefetch set of the recordset. Fix _compute_activity_date_deadline, to batched the reading of activity's deadline. Forward-Port-Of: odoo/odoo#154728 Forward-Port-Of: odoo/odoo#154159
This update ensures that only active internal users can be assigned to project tasks. The change improves data quality and security by preventing external or inactive users from being selected as task assignees. The restriction is now enforced at the system level rather than just in the user interface.
Original PR description
decided to add the domain condition in the project.task user_ids field definition, which means we can remove identical domains in views Added empty domains where we could want to add external/inactive user to project.task Task-3698867 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#150710
This fix restores the 'Secured by' payment provider information that was being hidden when certain payment modules were installed. Users will now see which payment provider is processing their transaction, improving transparency and trust in the checkout process.
Original PR description
If payment_custom or payment_demo is installed 'Secured by' element is overriden and becomes hidden for all payment providers. We removed xpath as it is more convenient for the users to see which provider is behind a payment method. After this commit 'Secured by' element is shown for all providers except for custom. Proper fix is available in master - https://github.com/odoo/odoo/pull/154985
This release includes multiple bug fixes and improvements across accounting, inventory, HR, and e-commerce modules. Key improvements include fixing duplicate bill warnings in accounting, correcting event booth counts in sales, adding Italian tax ID support for checkout, and resolving various operational issues in inventory and expense management. These changes enhance system reliability and user experience across multiple business functions.
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
When messages are posted, the system now correctly identifies which conversation thread needs its pin state updated. Previously, the notification was missing the thread model information, causing pin states to not update properly. This fix ensures users see accurate pin status for their conversations.
Original PR description
When a message is posted, the server sends a `mail.record/insert` notification to update the related channel pin state. In order to recognize the thread, the client needs its id and its model. Currently, only the id is passed so the thread pin state is not updated. This PR adds the model to the notification.
The text editor's "clear format" button now completely removes all styling (background color, text color, and other formatting) from selected text. Previously, some color styles were not being fully removed, which could leave unwanted formatting behind.
Original PR description
**Before this PR:** When using the removeFormat button, the backgroundColor and foregroundColor were not completely removed. **After this PR:** The removeFormat button will completely remove all the styles applied to it. **task-3344762** Forward-Port-Of: odoo/odoo#130670
This fix corrects an issue where the system was not properly matching customer states to their selected countries when processing address information. The system now first looks for the correct state based on both the country and state code, and falls back to searching by state code alone if needed. This ensures customer address data is accurately captured and prevents data loss during the address processing.
Original PR description
- Before this commit, `_include_country_and_state_in_address` finding state is not respect the country. - So fix by find state by country and code first. If there is no state, we will find state by code to avoid losing data. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents users from changing a payment provider's company when transactions have already been processed. This protects data integrity by ensuring that payment records remain properly associated with their original company, avoiding potential accounting and reconciliation issues.
Original PR description
opw-3696841
This fix removes unnecessary warning messages that appeared in system logs after importing modules. The system was incorrectly trying to update its internal module tracking graph for imported modules, which doesn't apply to them. This change cleans up the logs and reduces confusion for system administrators.
Original PR description
Before this PR, after having imported a module, a warning appears in the log, because it tries to update the graph which does not make sense for an imported module. This commit makes sure the warning is skipped if the module was imported. This commit can be backported to previous versions, if useful.
This fix resolves an issue where product selections made in loyalty program rules were being cleared when saving the program. Users can now select products in the rule's 'Products' field before saving the loyalty program, and those selections will be preserved instead of being lost.
Original PR description
**Current behavior:** Creating a promo type loyalty program and editing the 'products' field in the 'Among' section of the rule created by default at the bottom of the form view before saving the…
**Current behavior:**
Creating a promo type loyalty program and editing the
'products' field in the 'Among' section of the rule created by
default at the bottom of the form view before saving the
program will cause the products selected in this field to be
cleared upon saving the program.
**Expected behavior:**
Filling out this field of the default rule before saving the
overarching loyalty program should result in the same behavior
as doing so after saving the program. That is, the field should
save the user's input.
**Steps to reproduce:**
1. Create a new loyalty program in the Discount & Loyalty tab
2. Give it a name and, before saving the program, edit the
'Products' field of the default rule that is created at
the bottom of the form to have at least one value
3. Now save the program and observe that the 'Products' field
has been cleared of the previously selected values
**Cause of the issue:**
In the form view for the loyalty.program there are two
instances of the field trigger_product_ids which are set to be
invisible unless creating a specific program type. This field
is set to be related to rule_ids.product_ids in its definition
within the loyalty.program class definition. Thus, when the
user saves the program and rule concurrently, the empty
trigger_product_ids field overwrites the product_ids field
and whatever the user had populated it with is cleared.
The reason it only happens to the default rule and not ones
which are manually added before saving the program is because
in the traverse_related() method in fields.py, only the first
record of the related field is returned to be modified. In this
case, it means only the first rule's product_ids field is
overwritten.
**Fix:**
Overwrite the create() method in program.loyalty and check if
the program being created is of type 'gift_card' or 'ewallet'
then, if so, delete the trigger_product_ids key,val from the
dictionary so it will not later override the products specified
in the loyalty rule.
opw-3669953
Forward-Port-Of: odoo/odoo#150418This fix resolves a critical error that occurred when previewing draft invoices with multi-line payment terms. The issue prevented users from viewing invoices when payment terms included multiple installment lines without early payment discounts. The fix ensures the system properly handles these payment term configurations.
Original PR description
Description of the issue this PR addresses: --- On obtains a 500: Internal Server Error when creating an invoice with a 2 lines payment term. Error while rendering the template…
Description of the issue this PR addresses: --- On obtains a 500: Internal Server Error when creating an invoice with a 2 lines payment term. Error while rendering the template "account.report_invoice_document". Steps to reproduce: --- - Accounting > Configuration > invoicing > Payment Terms - New > Create and save a payment term with 2 lines: - name 80/20 test - line_1 : 80% after 0 days - line_2 : 20% after 30 days - Sales > Orders > Quotations - Chose any > use payment terms 80/20 test - Save and create associated invoice > chose regular invoice - Create draft invoice > preview > 500: Internal Server Error Cause of the issue: --- The method "_get_amount_due_after_discount" called during the rendering of the template does not return a value in case self.early_discount is False. Fix: --- Return total_amount by default since no discount is applied. opw-3683708 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#149934
This fix resolves a critical issue that prevented Odoo from starting up during system updates. When removing accounting report expressions, the system now properly cleans up related external values, preventing database constraint violations that would crash the upgrade process.
Original PR description
Cascade removal of account.report.expression records to corresponding account.report.external.value, avoiding the following issue when upgrading: ``` Traceback (most recent call last): File…
Cascade removal of account.report.expression records to corresponding account.report.external.value, avoiding the following issue when upgrading:
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/17.0/odoo/service/server.py", line 1302, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "<decorator-gen-16>", line 2, in new
File "/home/odoo/src/odoo/17.0/odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/src/odoo/17.0/odoo/modules/registry.py", line 113, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/odoo/src/odoo/17.0/odoo/modules/loading.py", line 536, in load_modules
env['ir.model.data']._process_end(processed_modules)
File "/tmp/tmpwrjjshgf/migrations/base/0.0.0/pre-models-no-model-data-delete.py", line 103, in _process_end
return super(IrModelData, self)._process_end(modules)
File "/home/odoo/src/odoo/17.0/odoo/addons/base/models/ir_model.py", line 2562, in _process_end
self._process_end_unlink_record(record)
File "/home/odoo/src/odoo/17.0/addons/website/models/ir_model_data.py", line 36, in _process_end_unlink_record
return super()._process_end_unlink_record(record)
File "/home/odoo/src/odoo/17.0/odoo/addons/base/models/ir_model.py", line 2491, in _process_end_unlink_record
record.unlink()
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4218, in unlink
cr.execute(SQL(
File "/home/odoo/src/odoo/17.0/odoo/sql_db.py", line 332, in execute
res = self._obj.execute(query, params)
psycopg2.errors.ForeignKeyViolation: update or delete on table "account_report_expression" violates foreign key constraint "account_report_external_value_target_report_expression_id_fkey" on table "account_report_external_value"
DETAIL: Key (id)=(94) is still referenced from table "account_report_external_value".
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#154191This update improves the user experience when creating sales order lines by eliminating unnecessary form popups. When users quickly create a sales order line with a name matching an existing product, the system now completes the action immediately instead of opening an edit form. This makes the workflow faster and more intuitive for sales teams managing projects.
Original PR description
When creating a SOL on the fly, if the name entered matches an existing service product, selecting 'Create' should create the SOL without opening a form view modal. We do that by fetching the `default_name` from the context. However, from the Many2one field, since the name will already be present in the create vals, in will not be in the default values in the context. To fix this, this PR adds a new context key when calling `name_create` that allows us to retrieve the name from the `default_get` Enterprise: https://github.com/odoo/enterprise/pull/53833 Task-3553151 Forward-Port-Of: odoo/odoo#142720
This fix resolves an issue where users couldn't create new records with property fields if they lacked read access to the parent record. The system now uses elevated permissions to fetch the parent record's property definitions, allowing users to create records with default values even when they can't directly access the parent record.
Original PR description
When the user creates a new record having a property field, the system fetches the property definition of the parent record to retrieve the field's default values (see: `_add_default_values`). If the user lacks read access on the parent record, the user gets an access error when retrieving the property definition of the parent record. To prevent this error, we will perform a sudo call on the parent record before reading the property definition of the parent record. This allow the user to create a new record, even if they do not have access to the parent record. task-3594814 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154651 Forward-Port-Of: odoo/odoo#146265
This fix resolves an issue where batch processing of multiple Saudi invoices would fail when generating QR codes. The problem occurred because the system attempted to generate QR codes for invoices that hadn't yet been signed, causing errors during automated EDI submission. The fix ensures QR codes are only generated for invoices that have already been signed.
Original PR description
### Steps to reproduce * install `l10n_sa_edi` * switch to a Saudi company * deactivate the "EDI : Perform web services operations" scheduled action. (this will help ease the reproduction process) *…
### Steps to reproduce * install `l10n_sa_edi` * switch to a Saudi company * deactivate the "EDI : Perform web services operations" scheduled action. (this will help ease the reproduction process) * create and post two invoices for a partner that's an individual (not a company) * manually run that scheduled action. You should be met with a traceback. ### Cause When a ZATCA document is submitted, the system performs several operations, two of which are important for this issue: 1. Generating a signature (`l10n_sa_invoice_signature`) 2. Using this signature to generate a QR code (`l10n_sa_qr_code_str`) The QR code generation relies on the assumption that the signature (`l10n_sa_invoice_signature`) already exists, which is a reasonable expectation as the signature is typically created prior to the QR code. However, complications arise when multiple documents are submitted simultaneously in a batch process. During batch processing, each document in the batch undergoes the same two operations mentioned above. The issue emerges due to the behavior of non-stored computed fields. In Odoo, computed fields are evaluated in batches, meaning that if you access a computed field for one record, Odoo may also compute the same field for other records fetched in the same operation. For example, if you have two records, `A` and `B` such that `B.id in A._prefetch_ids`, and you access a computed field on `A`, Odoo will also compute this field for `B` at the same time. This behavior leads to an issue when submitting two documents (`D1` and `D2`) together. The system will generate a signature and then compute the QR code for `D1`. However, when computing the QR code for `D1`, it inadvertently attempts to also compute the QR code for `D2` due to the batch computation behavior. Since `D2`'s signature has not yet been generated at this point, this results in an error. opw-3696146 Forward-Port-Of: odoo/odoo#153810
Code cleanup and technical improvements
The manufacturing unbuild process has been restructured to make it easier for developers to customize and extend. Previously, adding new parameters to unbuild operations required completely rewriting the entire function. Now developers can make targeted modifications to specific parts of the process, reducing complexity and maintenance burden.
Original PR description
With the current design, when we want to pass more parameters from the original move lines of MO to the unbuild move lines, we can't easily extend action_unbuild() and it seems we need to completely override it. After this refactoring commit, developers can easily extend and add more parameters. @qrtl --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#151983