Wednesday, May 28, 2025
29 changes · saas-18.2
Resolved issues and error corrections
Pinned message cards in Discuss now use a lighter border so they blend better with surrounding conversation items. This makes the interface feel more consistent and less visually distracting for users.
Original PR description
Was using default `.border-secondary` which is too strong compared to other discuss items.
The Discuss app now shows a subtle separator above its main area instead of hiding it entirely or using a line that draws too much attention. This improves visual balance while keeping the interface clear for users handling many messages and items.
Original PR description
The default separator color of control panel is too strong, which doesn't fit well in discuss app that has a lot of items that needs enough attention. This was overridden to remove it completely, but now that many work as been done to adjust the right balance of color in discuss app, this separator can be shown at a reduced opacity.
This fixes a small visual spacing issue in Mail conversations where a regular message could appear too close to a following notification, such as a live conference notice. The change makes message lists easier to read while keeping the layout compact.
Original PR description
Before this commit, visual of a message without reactions just above a notification like "started a live conference" looked slightly off. This comes from lack of spacing between them. This commit fixes the issue by specifically adding minimal spacing in-between message without reaction and the notification in the message list. The spacing of message bubbles and notification is intentionally small to be efficient with space and add only when desired. When a message has a reaction, there's already bottom spacing so there's no need to add even more. As a reminder, the bottom spacing on reaction helps to see which message this reaction it is attached to. 
Belgian payroll slip generation has been corrected to avoid an error when multiple worked-day entries are present. This helps payroll teams generate payslips reliably without manual workaround or interruption.
Original PR description
We get a traceback when trying to generate pyslip because we try to read number_of_hours from a recordset containing more than one record. So we are now taking the max of the records.
Miscellaneous changes
Trigger an onchange requiring res_model_id to be returned. Before this commit, there was an error because the dependency field "res_model" was False and injected into a function that required it not to be. After this commit, there is no crash. runbot-error-223466 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 F
Original PR description
Trigger an onchange requiring res_model_id to be returned. Before this commit, there was an error because the dependency field "res_model" was False and injected into a function that required it not to be. After this commit, there is no crash. runbot-error-223466 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#211696
If a user tries to open a combo product on the website and the combo item has been deleted, a traceback will appear. Steps to reproduce the error: - Install ``website_sale_stock`` module - Create ``Product A`` > product type: ``Goods`` > Save - Go to Website > eCommerce > Combo choices > Create New(``Combo choice A``) > Add ``Product A`` in combo item - Create ``Product Combo A`` > product type: ``combo`` > Combo Choices: ``Combo choice A`` - Delete ``Product A`` - Go to Website > S
Original PR description
If a user tries to open a combo product on the website and the combo item has been deleted, a traceback will appear. Steps to reproduce the error: - Install ``website_sale_stock`` module - Create…
If a user tries to open a combo product on the website and the combo item
has been deleted, a traceback will appear.
Steps to reproduce the error:
- Install ``website_sale_stock`` module
- Create ``Product A`` > product type: ``Goods`` > Save
- Go to Website > eCommerce > Combo choices > Create New(``Combo choice A``) >
Add ``Product A`` in combo item
- Create ``Product Combo A`` > product type: ``combo`` > Combo Choices: ``Combo choice A``
- Delete ``Product A``
- Go to Website > Shop > Open ``Product Combo A``
Traceback:
```
File "/home/odoo/src/odoo/addons/website_sale_stock/models/product_combo.py", line 25, in _get_max_quantity
return max(max_quantities) if (None not in max_quantities) else None
ValueError: max() iterable argument is empty
```
https://github.com/odoo/odoo/blob/4d3b220b0ec6e718f962979b3f271ea161997322/addons/website_sale_stock/models/product_combo.py#L21-L24
Here, when the user deletes the product, ``self.combo_item_ids`` becomes empty,
resulting in ``max_quantities`` being an empty list ([]),
which causes the above traceback.
sentry-6589160704
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#208766In this PR: - A `Print` button allows users to generate the E-Waybill or Challan PDF. - The PDF is attached to the chatter and gets downloaded. - Applies only when the document is marked as an E-Waybill or Challan. Task-4807694 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#211543 Forward-Port-Of: odoo/odoo#210998
Original PR description
In this PR: - A `Print` button allows users to generate the E-Waybill or Challan PDF. - The PDF is attached to the chatter and gets downloaded. - Applies only when the document is marked as an E-Waybill or Challan. Task-4807694 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#211543 Forward-Port-Of: odoo/odoo#210998
In this commit, we have addressed a crucial issue related to translation. We discovered that certain key terms in our application were not properly marked for translation, resulting in a lack of support for different languages. To rectify this, we have implemented the necessary changes to make these terms translatable. By doing so, we have successfully resolved the language compatibility problem and improved the overall internationalization of our application. This commit ensures that all terms
Original PR description
In this commit, we have addressed a crucial issue related to translation. We discovered that certain key terms in our application were not properly marked for translation, resulting in a lack of support for different languages. To rectify this, we have implemented the necessary changes to make these terms translatable. By doing so, we have successfully resolved the language compatibility problem and improved the overall internationalization of our application. This commit ensures that all terms, previously overlooked or untranslatable, are now fully accessible for translation, enhancing the localization experience for our users across the globe. task:3358438 Forward-Port-Of: odoo/odoo#211023 Forward-Port-Of: odoo/odoo#127190
When mixing cross-dock (XD), MTO and MTS products, it may lead to incorrect partners on the pickings. To reproduce the issue: 1. Enable Multi-Routes 2. Edit the warehouse: 2-steps reception, 2-steps delivery 3. Unarchive MTO route 4. Setup 3 products: - Storable - Routes: - All with buy - One MTO - One XD - Same supplier 5. Create and confirm one SO for each product (starting with XD one), each one with a different customer 6. Validate the generated re
Original PR description
When mixing cross-dock (XD), MTO and MTS products, it may lead to incorrect partners on the pickings. To reproduce the issue: 1. Enable Multi-Routes 2. Edit the warehouse: 2-steps reception, 2-steps…
When mixing cross-dock (XD), MTO and MTS products, it may lead to
incorrect partners on the pickings.
To reproduce the issue:
1. Enable Multi-Routes
2. Edit the warehouse: 2-steps reception, 2-steps delivery
3. Unarchive MTO route
4. Setup 3 products:
- Storable
- Routes:
- All with buy
- One MTO
- One XD
- Same supplier
5. Create and confirm one SO for each product (starting with XD one),
each one with a different customer
6. Validate the generated replenish
7. Confirm the PO
8. Process the receipts
Error: The internal pickings have the same defined partner, the
customer of the XD product.
There are two issues:
- The destination address of a purchase is defined on the PO level,
not the POL one
- When looking for a PO, the `_run_buy` mechanism doesn't filter on
the destination address
This explains why:
- All purchases are gathered on the same PO
- On the internal pickings, we will find the first destination address
Even though the first point is convenient, since the destination
address is defined on the PO level, it leads to incorrect results.
However, changing this on stable is too risky. The only (and sad)
thing we can do so far is the creation of an ICP that would split
all PO based on their destination address. On master, this address
will be defined on POL level.
OPW-4552316
Forward-Port-Of: odoo/odoo#211431Problem: Bootstrap grid classes like `row` and `col` are not handled properly when placed inside an `o_text_columns` container. During processing (e.g., for email rendering), rows are expected to be converted to tables — but since `o_text_columns` is not included in the selector query, the transformation is skipped. As a result, when rendering the email, columns are not preserved and fall back to stacked layout. Solution: Update the container selection logic to include `o_text_columns` w
Original PR description
Problem: Bootstrap grid classes like `row` and `col` are not handled properly when placed inside an `o_text_columns` container. During processing (e.g., for email rendering), rows are expected to be…
Problem: Bootstrap grid classes like `row` and `col` are not handled properly when placed inside an `o_text_columns` container. During processing (e.g., for email rendering), rows are expected to be converted to tables — but since `o_text_columns` is not included in the selector query, the transformation is skipped. As a result, when rendering the email, columns are not preserved and fall back to stacked layout. Solution: Update the container selection logic to include `o_text_columns` when querying Bootstrap-based containers that need to be transformed into tables. Steps to reproduce: 1. Go to Email Marketing. 2. Create a new email. 3. Add a Text snippet. 4. Type `/col` and choose "2 Columns". 5. Add text to both columns. 6. Save and send the email. → In the received email, the two columns appear stacked vertically instead of side by side. opw-4675310 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#211109
Issue: In Odoo, it is impossible to generate an NLCIUS document for a partner with a valid Peppol endpoint using their Netherlands VAT (schemeID=9944) instead of a Dutch KVK/OIN identification number (schemeID=0106/0190). The latter is required for the PartyLegalEntity section of the document, but shares fields with the Peppol endpoint values, thus the two are incompatible. Solution: When the Peppol endpoint is not set to KVK/OIN, the number is instead taken from the generic res_partner.co
Original PR description
Issue: In Odoo, it is impossible to generate an NLCIUS document for a partner with a valid Peppol endpoint using their Netherlands VAT (schemeID=9944) instead of a Dutch KVK/OIN identification number (schemeID=0106/0190). The latter is required for the PartyLegalEntity section of the document, but shares fields with the Peppol endpoint values, thus the two are incompatible. Solution: When the Peppol endpoint is not set to KVK/OIN, the number is instead taken from the generic res_partner.company_registration field which is used for similar purposes for other locales, and the length of the number is used to determine the type. Addresses ticket-4624350 task-4624366 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#211620 Forward-Port-Of: odoo/odoo#209875
Problem: In `getAdjacentCharacter`, accessing `focusNode.textContent[focusOffset - 1]` directly fails when there are child nodes between text nodes. Example: Given `<p>ab<span>\u0009</span>\u200B[]</p>`: - `focusNode.childNodes` → [text("ab"), span, text("\u200B")] - `focusNode.textContent` → ["a", "b", "/TAB/", "/ZWS/"] - `focusOffset` → 3 (nodes offset not text offset) - Accessing `focusNode.textContent[2]` is wrong because `focusOffset` counts nodes, not characters, it should return
Original PR description
Problem:
In `getAdjacentCharacter`, accessing `focusNode.textContent[focusOffset - 1]` directly fails when there are child nodes between text nodes.
Example:
Given `<p>ab<span>\u0009</span>\u200B[]</p>`:
- `focusNode.childNodes` → [text("ab"), span, text("\u200B")]
- `focusNode.textContent` → ["a", "b", "/TAB/", "/ZWS/"]
- `focusOffset` → 3 (nodes offset not text offset)
- Accessing `focusNode.textContent[2]` is wrong because `focusOffset` counts nodes, not characters, it should return `/ZWS/` not `/TAB/`.
Solution:
Align with 18.0+ (`html_editor`) behavior by calling `getDeepestPosition(focusNode, focusOffset)` inside `getAdjacentCharacter`.
Steps to reproduce:
1. Type `ab`
2. Press `Tab`
3. Press `Arrow Left` → Caret does not move left as expected.
opw-4720904
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#205745Importing new public holidays from an xlsx file can take quite some time at the moment because Odoo has to reclaim past time off if it overlaps with one of the new public holidays. Currently this whole process is not properly batched. There is a single record creation in `hr_holidays:_reevaluate_leaves` and a single record write in `planning:_compute_allocated_hours`. This commit optimizes the Public Holidays creation by batching the two methods mentioned above. Batching the create call is
Original PR description
Importing new public holidays from an xlsx file can take quite some time at the moment because Odoo has to reclaim past time off if it overlaps with one of the new public holidays. Currently this…
Importing new public holidays from an xlsx file can take quite some time at the moment because Odoo has to reclaim past time off if it overlaps with one of the new public holidays. Currently this whole process is not properly batched. There is a single record creation in `hr_holidays:_reevaluate_leaves` and a single record write in `planning:_compute_allocated_hours`. This commit optimizes the Public Holidays creation by batching the two methods mentioned above. Batching the create call is straightforward. Batching the write might seem useless at first as UPDATE queries are already batched on the ORM level. But actually the performance bottleneck comes from the post-processing done after writing a new `planning_slot.allocated_hours` value. By grouping the slots by allocated_hours we can speed up this post-processing. #### speedup Trying to import 72 new Public Holidays that lead to writing allocated hours on 85 planning slots - 2min -> 4.76s --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209846
**Steps to reproduce this issue:** 1) Install Time Off 2) Create an approved leave record 3) Click on the approved leave record in month mode(calendar view) 4) The Delete button appears instead of the Cancel button **Issue:-** In the Time off dashboard, in the year view, if I click on a leave and open the popup, I can click on “Cancel” to cancel my leave But this “Cancel” button appears as “Delete” in the month, week and day views. However, it does cancel the leave, not delet
Original PR description
**Steps to reproduce this issue:** 1) Install Time Off 2) Create an approved leave record 3) Click on the approved leave record in month mode(calendar view) 4) The Delete button appears instead of the Cancel button **Issue:-** In the Time off dashboard, in the year view, if I click on a leave and open the popup, I can click on “Cancel” to cancel my leave But this “Cancel” button appears as “Delete” in the month, week and day views. However, it does cancel the leave, not delete it. **Solution:-** This button should be renamed “Cancel” to be consistent with the system. opw-4782277 Forward-Port-Of: odoo/odoo#209285
Steps to reproduce =================== 1. Install l10n_pe or l10n_se 2. Switch to the newly installed company. 3. Open the contact form. The address fields are misaligned. Technical ========== With commit https://github.com/odoo/odoo/commit/4dd27bba346e50f40769d1412fbca0b5f65bb5a6, the contact form renders address fields dynamically based on the selected country. The `_view_get_address` method in the `format.address.mixin` replaces the default address `div` with the XML arch of the vi
Original PR description
Steps to reproduce =================== 1. Install l10n_pe or l10n_se 2. Switch to the newly installed company. 3. Open the contact form. The address fields are misaligned. Technical ========== With commit https://github.com/odoo/odoo/commit/4dd27bba346e50f40769d1412fbca0b5f65bb5a6, the contact form renders address fields dynamically based on the selected country. The `_view_get_address` method in the `format.address.mixin` replaces the default address `div` with the XML arch of the view linked in the current company's `address_view_id` field. Since this arch is wrapped within the `<form>` tags, the JS framework adds an extra div element and `o_form_nosheet` class, causing layout misalignment. After this commit ============== This commit only includes address `div` element inside the `<form>` tag. Task-4744412 Forward-Port-Of: odoo/odoo#208965
### Steps to reproduce: - Navigate to Recruitment > Job Position > Any job position > Job applications (smart button) - Create an applicant - Set a Recruiter for the applicant - Move the stage to 'Contract Signed' - Click on 'Create Employee' - Notice a validation error that the opertion cannot be completed ### Cause: This is happening as the 'Job applications' smart button has default value for the user_id in context https://github.com/odoo/odoo/blob/889f25f1322f00dff7cacad95
Original PR description
### Steps to reproduce: - Navigate to Recruitment > Job Position > Any job position > Job applications (smart button) - Create an applicant - Set a Recruiter for the applicant - Move the stage to…
### Steps to reproduce: - Navigate to Recruitment > Job Position > Any job position > Job applications (smart button) - Create an applicant - Set a Recruiter for the applicant - Move the stage to 'Contract Signed' - Click on 'Create Employee' - Notice a validation error that the opertion cannot be completed ### Cause: This is happening as the 'Job applications' smart button has default value for the user_id in context https://github.com/odoo/odoo/blob/889f25f1322f00dff7cacad95236d6f045c30d64/addons/hr_recruitment/views/hr_job_views.xml#L207-L211 so when creating an employee it will add the missing fields from defaults and it will get the default value in the context which for an existing user so when creating the employee with this user_id it will trigger the sql constraint https://github.com/odoo/odoo/blob/889f25f1322f00dff7cacad95236d6f045c30d64/addons/hr/models/hr_employee.py#L145-L148 ### Fix: clean the context before creating the partner and the employee corresponding to this applicant opw-4629219 Forward-Port-Of: odoo/odoo#210896 Forward-Port-Of: odoo/odoo#204997
Add localization for Oman: - Accounts - Taxes - Fiscal positions - States - Tax reports task ID: 3927925 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#211301 Forward-Port-Of: odoo/odoo#201016
Original PR description
Add localization for Oman: - Accounts - Taxes - Fiscal positions - States - Tax reports task ID: 3927925 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#211301 Forward-Port-Of: odoo/odoo#201016
*: l10n_cl, l10n_nz, sale_expense --- Description of the issue this commit addresses: [This PR](https://github.com/odoo/odoo/pull/211150) has brought our attention to some files that were in the codebase but not included in their module's manifest. Therefore they are useless as is and can either be deleted or need to be put in the manifest. --- Desired behavior after this commit is merged: Unused useless files have been removed from the codebase. Unused useful files have been
Original PR description
*: l10n_cl, l10n_nz, sale_expense --- Description of the issue this commit addresses: [This PR](https://github.com/odoo/odoo/pull/211150) has brought our attention to some files that were in the codebase but not included in their module's manifest. Therefore they are useless as is and can either be deleted or need to be put in the manifest. --- Desired behavior after this commit is merged: Unused useless files have been removed from the codebase. Unused useful files have been added to their module's manifest. --- task-4822341 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#211762 Forward-Port-Of: odoo/odoo#211609
*: account_sepa_direct_debit --- Description of the issue this commit addresses: [This PR](odoo#211150) has brought our attention to some files that were in the codebase but not included in their module's manifest. Therefore they are useless as is and can either be deleted or need to be put in the manifest. --- Desired behavior after this commit is merged: Unused useless files have been removed from the codebase. Unused useful files have been added to their module's manifest.
Original PR description
*: account_sepa_direct_debit --- Description of the issue this commit addresses: [This PR](odoo#211150) has brought our attention to some files that were in the codebase but not included in their module's manifest. Therefore they are useless as is and can either be deleted or need to be put in the manifest. --- Desired behavior after this commit is merged: Unused useless files have been removed from the codebase. Unused useful files have been added to their module's manifest. --- task-4822341 Forward-Port-Of: odoo/enterprise#86513 Forward-Port-Of: odoo/enterprise#86397
Changed translations to use the legal term used in Mexico. This is done because "Cada dos semanas" and "Quincenal" don't have exactly the same meaning Forward-Port-Of: odoo/enterprise#86291 Forward-Port-Of: odoo/enterprise#83982
Original PR description
Changed translations to use the legal term used in Mexico. This is done because "Cada dos semanas" and "Quincenal" don't have exactly the same meaning Forward-Port-Of: odoo/enterprise#86291 Forward-Port-Of: odoo/enterprise#83982
The failed WhatsApp message icon turns green after 15 days or once the message is deleted. PROBLEM: WhatsApp messages are deleted after 15 days, leading to data loss and causing the default green icon to be displayed. SOLUTION: Introduced `getWhatsappStatusClass` to display appropriate icons based on the message state: - Green icon for `sent`, `delivered`, `read`, and `received` states. - Orange icon for the `outgoing` state. - Red icon for the `error` and `cancel` states. - Grey ico
Original PR description
The failed WhatsApp message icon turns green after 15 days or once the message is deleted. PROBLEM: WhatsApp messages are deleted after 15 days, leading to data loss and causing the default green icon to be displayed. SOLUTION: Introduced `getWhatsappStatusClass` to display appropriate icons based on the message state: - Green icon for `sent`, `delivered`, `read`, and `received` states. - Orange icon for the `outgoing` state. - Red icon for the `error` and `cancel` states. - Grey icon for the `undefined` state (i.e., deleted WhatsApp message). Also introduced was `getWhatsappStatusTitle`, which returns the correct title based on the message state. Task-4481123 Forward-Port-Of: odoo/enterprise#86458 Forward-Port-Of: odoo/enterprise#77739
If you try to remove the Valid Until date to make the sign request valid without expiration, you get an rpc error. Steps to reproduce: ------------------- * Head to the sign app. * Upload a document or use pre-existing document * Click on the 3 dots and click on details. * Add a validity date save and then attempt to remove it. > Observation: TypeError: '<' not supported between instances of 'NoneType' and 'datetime.date' Why the fix: ------------ When removing the date, `write(
Original PR description
If you try to remove the Valid Until date to make the sign request valid without expiration, you get an rpc error.
Steps to reproduce:
-------------------
* Head to the sign app.
* Upload a document or use pre-existing document
* Click on the 3 dots and click on details.
* Add a validity date save and then attempt to remove it.
> Observation:
TypeError: '<' not supported between instances of 'NoneType' and 'datetime.date'
Why the fix:
------------
When removing the date, `write()` gets `vals{'validity': False}` `fields.Date.from_string(False)` returns `<class 'NoneType'>` which can not be compared with the operator `<`
opw-4795212
Forward-Port-Of: odoo/enterprise#86405
Forward-Port-Of: odoo/enterprise#85891After a recent change in German EDI, the data exported in CSV from the EC Sales List can no longer be uploaded because the expected structure has changed Steps to reproduce (with a DE Company): - Make an invoice to an EU Partner - Open EC Sales List - Export CSV When uploading the file on the Elster portal it will be rejected with an explicit error message, saying that we're using an old CSV format now deprecated, and prompts the user to refer to the new specifications Original mes
Original PR description
After a recent change in German EDI, the data exported in CSV from the EC Sales List can no longer be uploaded because the expected structure has changed Steps to reproduce (with a DE Company): -…
After a recent change in German EDI, the data exported in CSV from the EC Sales List can no longer be uploaded because the expected structure has changed Steps to reproduce (with a DE Company): - Make an invoice to an EU Partner - Open EC Sales List - Export CSV When uploading the file on the Elster portal it will be rejected with an explicit error message, saying that we're using an old CSV format now deprecated, and prompts the user to refer to the new specifications Original message: Ihre CSV-Datei wurde für eine ältere Version der CSV-Schnittstelle erstellt. Bitte informieren Sie sich in der Versionstabelle der Importhilfe über die aktuellste Version der Schnittstelle sowie Änderungen. Sind die Versionsangaben korrekt, prüfen Sie bitte das Encoding Ihrer CSV-Datei. Das zulässige Encoding ist UTF-8. Sources: https://www.elster.de/eportal/helpGlobal?themaGlobal=zmdo_import_eop https://www.datev-community.de/t5/Betriebliches-Rechnungswesen/Import-CSV-Daten-nacvh-Elster-f%C3%BCr-ZM/td-p/480079 opw-4751667 opw-4674533 Forward-Port-Of: odoo/enterprise#85992
Related to odoo/odoo#209846 Forward-Port-Of: odoo/enterprise#85454
Original PR description
Related to odoo/odoo#209846 Forward-Port-Of: odoo/enterprise#85454
Issue Before This Commit: ============================ In MO barcode interface, the by-products section displays the source location instead of the destination location for each by-product line. This is misleading, as by-products are outputs of a production process and should reference a destination location. Steps to Reproduce: ============================ - Install the stock_barcode_mrp module. - Activate multi-step routes and By-Products. - Create a Manufacturing Order with by
Original PR description
Issue Before This Commit: ============================ In MO barcode interface, the by-products section displays the source location instead of the destination location for each by-product line. This…
Issue Before This Commit:
============================
In MO barcode interface, the by-products section displays the
source location instead of the destination location for each by-product line.
This is misleading, as by-products are outputs of a production
process and should reference a destination location.
Steps to Reproduce:
============================
- Install the stock_barcode_mrp module.
- Activate multi-step routes and By-Products.
- Create a Manufacturing Order with by-products.
- Open the MO using the barcode app.
- In the by-product section notice that:
- The lines are grouped by Source Location.
- If you edit by-product line then user has option to edit source location.
- If the MO operation type has Source Location scan as mandatory,
user can't edit by-product line.
With This Commit:
============================
- By-product lines are now grouped by their destination location.
- The destination location is displayed for each by-product line.
- The source location field is hidden when editing by-product lines.
- Even if the MO operation type has Source Location scan as mandatory,
users can still edit by-product lines.
This fix improves clarity and usability for production operators by ensuring
that the appropriate location context is accurately displayed and
can be edited when necessary.
task - [4654161](https://www.odoo.com/odoo/my-tasks/4654161)
Forward-Port-Of: odoo/enterprise#83617In this commit, we have addressed a crucial issue related to translation. We discovered that certain key terms in our application were not properly marked for translation, resulting in a lack of support for different languages. To rectify this, we have implemented the necessary changes to make these terms translatable. By doing so, we have successfully resolved the language compatibility problem and improved the overall internationalization of our application. This commit ensures that all terms
Original PR description
In this commit, we have addressed a crucial issue related to translation. We discovered that certain key terms in our application were not properly marked for translation, resulting in a lack of support for different languages. To rectify this, we have implemented the necessary changes to make these terms translatable. By doing so, we have successfully resolved the language compatibility problem and improved the overall internationalization of our application. This commit ensures that all terms, previously overlooked or untranslatable, are now fully accessible for translation, enhancing the localization experience for our users across the globe. task:3358438 Forward-Port-Of: odoo/enterprise#86078 Forward-Port-Of: odoo/enterprise#43574
This PR updates the `l10n_pe_withhold_code` field in the `product.template` model for the Peruvian localization (`l10n_pe_edi`) to reflect the latest official SUNAT withholding catalog (as of April 2025). Changes were made directly in the `fields.Selection`, maintaining compatibility with existing data by preserving obsolete values used in previous versions. This update helps ensure consistency with current SUNAT requirements while avoiding potential issues in existing databases. Refere
Original PR description
This PR updates the `l10n_pe_withhold_code` field in the `product.template` model for the Peruvian localization (`l10n_pe_edi`) to reflect the latest official SUNAT withholding catalog (as of April 2025). Changes were made directly in the `fields.Selection`, maintaining compatibility with existing data by preserving obsolete values used in previous versions. This update helps ensure consistency with current SUNAT requirements while avoiding potential issues in existing databases. Reference: [Reglas de Validación actualizado al 21/04/2025 (Nuevo)](https://cpe.sunat.gob.pe/sites/default/files/inline-files/AjustesValidacionesCPEv20250421.xlsx) Forward-Port-Of: odoo/enterprise#85917
In this PR: - Added Bank of Slovenia to the list of currency providers. - Fetches exchange rates using the official API and updates the rates. Task-4794271 Forward-Port-Of: odoo/enterprise#85575
Original PR description
In this PR: - Added Bank of Slovenia to the list of currency providers. - Fetches exchange rates using the official API and updates the rates. Task-4794271 Forward-Port-Of: odoo/enterprise#85575
Before this PR: When generating the Libro Giornale Journal Audit report as PDF, journal items with long descriptions would cause rendering issues. The Name column would expand excessively to accommodate the long text, resulting in the Debit and Credit columns being cropped or completely missing from the printed report as seen in below image.  After this PR: The Libro Giornale Journal Audit report no
Original PR description
Before this PR: When generating the Libro Giornale Journal Audit report as PDF, journal items with long descriptions would cause rendering issues. The Name column would expand excessively to accommodate the long text, resulting in the Debit and Credit columns being cropped or completely missing from the printed report as seen in below image.  After this PR: The Libro Giornale Journal Audit report now correctly handles journal items with long descriptions. The report template has been modified to ensure proper column width distribution, preventing the Name column from expanding excessively. The Debit and Credit columns are now consistently displayed in the PDF report regardless of description length.  OPW-4788257 Forward-Port-Of: odoo/enterprise#86049