Daily updates from Odoo
Friday, March 28, 2025
35 changes
10 changes
Enhancements to existing features
This update streamlines how several Odoo screens reuse and adjust existing view settings. It makes future changes easier to maintain and reduces the chance that updates in a parent screen are missed in related screens.
Original PR description
This commit uses the `|` operator introduced in odoo/odoo#198551 to simplify fields' context and options in views. This improvement increases: - readability: as it is more obvious what keys are added/modified by the XPath, and - maintainability: as previously, any modifications to the parent view needed to be applied to the child views as well to have an effect.
Resolved issues and error corrections
This fixes spreadsheet filter side panels so they continue to open and collapse correctly after an internal naming change. It helps avoid small interface issues when users edit global filters in spreadsheets.
Original PR description
`collapsedAtInit` has been renamed to `isInitiallyCollapsed`
This fix makes an automated rental checkout test update date inputs more reliably. It helps prevent intermittent build warnings, improving confidence in release checks without changing the customer-facing shopping experience.
Original PR description
Before this commit, we had a non-deterministic warning on some runbot builds: see "shop_buy_rental_product" tour. This is because we set the new value via the daterange picker and we need to trigger an "enter" event to force an input update. runbot error: 161483 Related PR #82005
Code cleanup and technical improvements
Social media post and comment formatting logic has been reorganized into a shared place to make the system easier to maintain. This cleanup improves consistency across Facebook, LinkedIn, Twitter, and YouTube integrations without changing the intended user experience.
Original PR description
- we ensure that the methods which involve formatting the tweet/comment are in the same modal. - along the way, we also had a look at other different methods which we felt could could be moved at one place for better code organisation. - also changed the names of the methods which were involved in formatting the comment/tweet. Made the names consistent. Task-4184968
Miscellaneous changes
task-4577617 Forward-Port-Of: odoo/enterprise#80252
Original PR description
task-4577617 Forward-Port-Of: odoo/enterprise#80252
When we have a lot of data in the germany company we face a performance issue while exporting as zip file - modified the l10n_de_datev_export_to_zip function to search for the needed data rather that calling get lines again that improves the performance by 65%. - modified _format_column_values to add if options.get('export_mode') == 'file' not do formating to save time task-4502158 Forward-Port-Of: odoo/enterprise#81171
Original PR description
When we have a lot of data in the germany company we face a performance issue while exporting as zip file
- modified the l10n_de_datev_export_to_zip function to search for the needed data rather that calling get lines again that improves the performance by 65%.
- modified _format_column_values to add if options.get('export_mode') == 'file' not do formating to save time
task-4502158
Forward-Port-Of: odoo/enterprise#81171This commit ensures that sheet names in exported excel files are unique. The names may not be unique in case a composite report contains multiple section reports all having the same very long prefix. An example to that could be found in l10n_fr_reports: 1) IMB - Intermediate management balances 2) IMB - Intermediate management balances (2024) task-4678129 Forward-Port-Of: odoo/enterprise#82381 Forward-Port-Of: odoo/enterprise#82333
Original PR description
This commit ensures that sheet names in exported excel files are unique. The names may not be unique in case a composite report contains multiple section reports all having the same very long prefix. An example to that could be found in l10n_fr_reports: 1) IMB - Intermediate management balances 2) IMB - Intermediate management balances (2024) task-4678129 Forward-Port-Of: odoo/enterprise#82381 Forward-Port-Of: odoo/enterprise#82333
…nning gantt Prior to this commit, flexible resources did not have their leaves reflected as gray cells in the planning gantt view. This was due to the work_intervals being ignored for the calculation of flexible resources availability. This commit adds measures to handle the leaves for flexible resources by setting a dummy attendance (which covers the whole length of the period in gantt interval), and then injects their leaves intervals. To replicate: 1. set timeoffs to a flexible res
Original PR description
…nning gantt Prior to this commit, flexible resources did not have their leaves reflected as gray cells in the planning gantt view. This was due to the work_intervals being ignored for the…
…nning gantt Prior to this commit, flexible resources did not have their leaves reflected as gray cells in the planning gantt view. This was due to the work_intervals being ignored for the calculation of flexible resources availability. This commit adds measures to handle the leaves for flexible resources by setting a dummy attendance (which covers the whole length of the period in gantt interval), and then injects their leaves intervals. To replicate: 1. set timeoffs to a flexible resource (whole day and half day) 2. open planning app 3. in the gantt view, the day in which the timeoff was set for a whole day should be fully grayed (in the default month granularity view) 4. when selecting only a day as the granularity of the gantt view, the day in which the timeoff was set for a half day should be half grayed. (from 00:00-12:00 in case of a morning timeoff, and from 12:00-24:00 in case of an afternoon timeoff) ticket-id: 4492625 community: [198032](https://github.com/odoo/odoo/pull/198032) Forward-Port-Of: odoo/enterprise#82274 Forward-Port-Of: odoo/enterprise#79532
eLearning uses server date when processing dashboard values, which causes a mismatch from the perspective of the user. This commit changes the source of "today" to use the user's timezone on the dashboard and actions, while keeping compute functions on the server date as these values should not change based on the timezone of the observer. opw-4411615 Forward-Port-Of: odoo/enterprise#82199 Forward-Port-Of: odoo/enterprise#80490
Original PR description
eLearning uses server date when processing dashboard values, which causes a mismatch from the perspective of the user. This commit changes the source of "today" to use the user's timezone on the dashboard and actions, while keeping compute functions on the server date as these values should not change based on the timezone of the observer. opw-4411615 Forward-Port-Of: odoo/enterprise#82199 Forward-Port-Of: odoo/enterprise#80490
It is possible for a user to sync an existing whatsapp account and only after install some whatsapp bridge module. In that case the user will get an error as the template is created on the existing account with an existing name. We now prevent using the default value if a template with the same name already exists on it. task-4369979 Forward-Port-Of: odoo/enterprise#82260 Forward-Port-Of: odoo/enterprise#79786
Original PR description
It is possible for a user to sync an existing whatsapp account and only after install some whatsapp bridge module. In that case the user will get an error as the template is created on the existing account with an existing name. We now prevent using the default value if a template with the same name already exists on it. task-4369979 Forward-Port-Of: odoo/enterprise#82260 Forward-Port-Of: odoo/enterprise#79786
25 changes
Enhancements to existing features
The Documents app is now included in the standard web code style checks. This helps maintain consistent quality and makes future updates easier to review and maintain, with no direct change for end users.
Original PR description
Purpose ======= We want to enforce the web style in the Documents app, therefor we enable the eslint configuration for the application.
Resolved issues and error corrections
Creating a new Point of Sale payment method no longer fails when the company setup is missing a default outstanding payment account. This prevents an unexpected error during configuration and helps businesses complete POS setup more reliably.
Original PR description
Fix issue when trying to create new payment methods and no `account_journal_payment_debit_account_id` exist in the current chart template.
Calling `_get_outstanding_account('inbound')` on an empty `account.payment` was failing because `self.env.company` was not properly set. This issue only occurred when the outstanding account was not found in the chart template, leading to an exception.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prWhen a bill of materials is created from a manufacturing order linked to a project, it now keeps that project information automatically. This prevents missing project links and helps teams keep manufacturing and project tracking aligned.
Original PR description
Backport of this commit: https://github.com/odoo/odoo/commit/eaf2ea619644c29c9fbccd5410db77053b82d64d
Steps to reproduce the bug:
- Create a storable product “P1”
- Create a MO:
- Product to produce: P1
- Project: set any project
- Save
- Click on the “Generate BoM” button or try to create a BoM directly from the BoM field
- Open the BoM
Problem:
The project field is not inherited from the MO.
opw-4669529This fix makes the HTML editor’s automated tests more reliable by targeting the correct page elements and safely handling images that are still loading when an editor component closes. It helps prevent false test failures and tracebacks in Odoo’s validation system, improving release confidence without changing user-facing behavior.
Original PR description
**Problem**: Tests introduced in commit [`b7a63f7d60494c65889ba6ce3fa18847a0abbb62`] (https://github.com/odoo/odoo/commit/b7a63f7d60494c65889ba6ce3fa18847a0abbb62) are failing on **runbot** due to improper element selection and handling of image loading when the component is destroyed. **Solution**: - Ensure the test properly targets the correct elements. - Handle cases where the image is still loading while the component is destroyed, preventing potential tracebacks. **Steps to Reproduce**: 1. Run the test suite on runbot. 2. Observe test failures related to incorrect element selection or missing image references due to component destruction. **opw-4607020** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue in the HTML editor where pasting different list types together could convert them all to the same style. This helps users preserve formatting, such as standard lists and checklists, when copying content into Odoo.
Original PR description
**Problem**:
When pasting lists of different types (`UL` and `CL`), a new list is created with all `li` elements matching the type of the first list.
**Solution**:
If `nodeToInsert` is a list element, use its `mode` to create the list instead of using the `mode` of
the container.
**Steps to reproduce**:
1. Copy two lists: ```html <ul><li>1</li></ul> <ul class="o_checklist"><li>1</li><li>2</li><li>3</li></ul> ```
2. Paste into the editor.
Issue: The second list is pasted using the same
type as the first list.
opw-4670379
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fix ensures the quantity field remains visible when creating manufacturing orders, even at high browser zoom levels or different screen resolutions. Users can reliably enter production quantities without the unit of measure field pushing it out of view.
Original PR description
Steps to reproduce: - Install manfacturing app - Activate the Unit of measure setting in the mrp settings - Go to create new manafcturing order and start zooming in with different screen resolutions…
Steps to reproduce: - Install manfacturing app - Activate the Unit of measure setting in the mrp settings - Go to create new manafcturing order and start zooming in with different screen resolutions Problem: The product_qty field starts disappearing on zooming in and this makes the user can't enter a value in it. This happens because the width:auto applied to the field of the uom beside it that takes as much space as possible so the product_qty field disappears. opw-4560205 Description of the issue/feature this PR addresses: Current behavior before PR: the product_qty field in the creating manufacturing order disappears while zooming in with different screen resolutions. Desired behavior after PR is merged: The product_qty field is appearing on all zoom levels from 100 to 400 and tested on all screen resolutions in the settings of display in Ubuntu **Before**:  **After**:  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Updating the allocation amount on a time-off allocation record without an assigned employee no longer triggers an error. This prevents interruptions for HR users when reviewing or editing incomplete allocation records.
Original PR description
An error occurs when updating the **Allocation** field in a time-off allocation record that does not have an assigned employee. **Steps to reproduce:** - Install the `hr_holidays` module. - Navigate to `Time Off > Management > Allocations` (form view). - Remove the employee and modify the **Allocation** field. - Observe the error. **Error:** KeyError - False The issue occurs because `_compute_number_of_hours_display` depends on `employee_id._get_hours_per_day(allocation.date_from)`, when `employee_id` is empty, attempting to access `self.id` at [1] results in a key error. [1] - https://github.com/odoo/odoo/blob/51097d978a698fa94d021ca72bcd69c24d9c768b/addons/hr_holidays/models/hr_employee.py#L349 This commit ensures that the computation of `number_of_hours_display` checks if `employee_id` exists before proceeding. If no employee is assigned, it will be skipped. Sentry - 6423050142
The barcode app now shows product expiration dates immediately when a package is scanned. This helps warehouse users see shelf-life information right away without needing to open or save the line first.
Original PR description
When scanning a package, its content is added on the view, but we don't display the expiration date. To reproduce the issue: 1. In Settings, enable: - Packages - Expiration dates 2. Create a product - Tracked by lot - Expiration date 3. Update its quantity - Lot L - Package P - Quantity > 0 4. Set an expiration date on L 5. Open a new delivery through the barcode app 6. Scan P "Error": a line is added for the product, with its lot L, but we don't display the expiration date. Once the line is saved (for instance, through the edit button), we will finally display it. This is because we don't provide any information about the expiration date when converting the package quant into relevant data. OPW-4516410
Miscellaneous changes
LATAM task 1299 / Adhoc Task 47453 --- ### Description of the issue/feature this PR addresses: Update the Argentinean Legal Invoice Report regarding ARCA's new legal requirement: Tax breakdown on B2C. This only affects Factura B and related documents. Now, we will show an extra tax detail section with the title "Fiscal Transparency Regime for the Final Consumer (Law 27.743)" and show the details of the taxes grouped by type: VAT Taxes and Other National Internal Indirect Taxes. For m
Original PR description
LATAM task 1299 / Adhoc Task 47453 --- ### Description of the issue/feature this PR addresses: Update the Argentinean Legal Invoice Report regarding ARCA's new legal requirement: Tax breakdown on…
LATAM task 1299 / Adhoc Task 47453 --- ### Description of the issue/feature this PR addresses: Update the Argentinean Legal Invoice Report regarding ARCA's new legal requirement: Tax breakdown on B2C. This only affects Factura B and related documents. Now, we will show an extra tax detail section with the title "Fiscal Transparency Regime for the Final Consumer (Law 27.743)" and show the details of the taxes grouped by type: VAT Taxes and Other National Internal Indirect Taxes. For more info about the RG, go to https://servicioscf.afip.gob.ar/publico/sitio/contenido/novedad/ver.aspx?id=4448 ### Current behavior before PR: Old version of legal PDF report; we are not showing vat taxes, and summarying internal and national taxes on the tax totals  ### Desired behavior after PR is merged: We add a special table at the end of the report (ask required in the RG) with the detail of the taxes group by type: vat taxes, and other internal and national taxes  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203374 Forward-Port-Of: odoo/odoo#201257
Description of the issue this commit addresses: The Italian localization currently doesn't allow users to export the periodic tax report to xml format. This feature is missing. --- Desired behavior after the commit is merged: The Italian monthly tax report has a button that allows the user to export the report to an xml format. --- Enterprise PR: https://github.com/odoo/enterprise/pull/80009 task-4507942 --- I confirm I have signed the CLA and read the PR guidelines at w
Original PR description
Description of the issue this commit addresses: The Italian localization currently doesn't allow users to export the periodic tax report to xml format. This feature is missing. --- Desired behavior after the commit is merged: The Italian monthly tax report has a button that allows the user to export the report to an xml format. --- Enterprise PR: https://github.com/odoo/enterprise/pull/80009 task-4507942 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195948
Required upgrade to sdk 5.65.0 or higher: https://docs.adyen.com/online-payments/release-notes/?Web+Components%2FDrop-in=&title%5B0%5D=Web+Components%2FDrop-in#releaseNote=2024-05-27-web-componentsdrop-in-5.65.0 Upgrade sdk to 6.9.0 and api to 71 task-4649327 Forward-Port-Of: odoo/odoo#202498
Original PR description
Required upgrade to sdk 5.65.0 or higher: https://docs.adyen.com/online-payments/release-notes/?Web+Components%2FDrop-in=&title%5B0%5D=Web+Components%2FDrop-in#releaseNote=2024-05-27-web-componentsdrop-in-5.65.0 Upgrade sdk to 6.9.0 and api to 71 task-4649327 Forward-Port-Of: odoo/odoo#202498
Before this commit, customers were facing problems during the first synchronization related to the abundance of invitations sent through Outlook from previously created events in Odoo side. This should not happen because most of the time it is not useful synchronizing events that were already created before starting the synchronization with Outlook (from feedbacks discussed with customers and internally). After this commit, we no longer synchronize events that were created before the first sy
Original PR description
Before this commit, customers were facing problems during the first synchronization related to the abundance of invitations sent through Outlook from previously created events in Odoo side. This should not happen because most of the time it is not useful synchronizing events that were already created before starting the synchronization with Outlook (from feedbacks discussed with customers and internally). After this commit, we no longer synchronize events that were created before the first synchronization of any user in a database if we don't find any token created in it (i.e. if no user synchronized its Odoo Calendar with Outlook before this improvement). In case of any user already have synchronized its calendar with Outlook, we won't change the synchronization behavior (since the biggest part of the invitations were already sent). task-4294884 Forward-Port-Of: odoo/odoo#200957 Forward-Port-Of: odoo/odoo#185911
…ring orders **Issue:** When using a language other than English and setting the Manufacturing Order name field to read-only via Studio, the name is not automatically converted into a unique value. As a result, after saving the first order (which defaults to "New"), any subsequent order creation fails with an error, stating that the name must be unique. **Steps to Reproduce:** 1. Install the Manufacturing app. 2. Install the Studio app. 3. Change the language to one other than English.
Original PR description
…ring orders **Issue:** When using a language other than English and setting the Manufacturing Order name field to read-only via Studio, the name is not automatically converted into a unique value.…
…ring orders
**Issue:**
When using a language other than English and setting the Manufacturing Order name field to read-only via Studio, the name is not automatically converted into a unique value. As a result, after saving the first order (which defaults to "New"), any subsequent order creation fails with an error, stating that the name must be unique.
**Steps to Reproduce:**
1. Install the Manufacturing app.
2. Install the Studio app.
3. Change the language to one other than English.
4. Navigate to Manufacturing > Operations > Manufacturing Orders.
5. Create a new Manufacturing Order.
6. Open Studio and set the name field to read-only.
7. Save the first Manufacturing Order with the default name ("New").
8. Attempt to create another Manufacturing Order.
9. Error: The system prevents saving due to a duplicate name.
Expected Behavior: The Manufacturing Order name should be automatically updated to a unique value upon saving, regardless of the selected language.
Actual Behavior: The name remains "New", but it is not translated when using a different language. Since the name field is set to read-only, the system does not trigger the automatic conversion to a unique name. As a result, when attempting to create another order, the system detects a duplicate and prevents saving due to a name conflict.
**Root Cause**
The system always sets the default name to "New" in English. However, the automatic name conversion process expects a translated name before updating it to a unique value. Because "New" remains untranslated, the system does not recognize it as a placeholder and fails to convert it.
**Fix**
Modify the default value of the name field to use a localized translation like it’s done for the sale order https://github.com/odoo/odoo/blob/7bc38562f1988ba15525c04168e30c06a8f1d33c/addons/sale/models/sale_order.py#L55. This ensures that the default name is translated according to the user's language, allowing the system to properly detect and replace it with a unique value when saving.
Opw-4553109
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#200138Steps to reproduce: - Create a non-storable product (e.g. a service) - Create a new RFQ - Add that product to a PO line Issue: The forecast icon is visible, even though the product is non-storable and the forecast doesn't make any sense. 73170f0 was a bit too optimistic on the invisible condition, as it needs a field directly on the model to be able to check these clauses. So we add a related as it's done for other. opw-4672513 --- I confirm I have signed the CLA and read the PR
Original PR description
Steps to reproduce: - Create a non-storable product (e.g. a service) - Create a new RFQ - Add that product to a PO line Issue: The forecast icon is visible, even though the product is non-storable and the forecast doesn't make any sense. 73170f0 was a bit too optimistic on the invisible condition, as it needs a field directly on the model to be able to check these clauses. So we add a related as it's done for other. opw-4672513 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203545
An incorrect date being represented (14/11/2007 is displayed as 20/07/1114) on the payment field. The date was parsed two times with the format of the user's language, while the first parse should be based on the current format of the database. To reproduce: - Change user language to Spanish or French. - Register a payment for an invoice with a payment date between October 1st and December 31st, from 2001 to 2012. - "Paid on 20/07/1114" appears. Ticket [link](https://www.odoo.com/odoo/
Original PR description
An incorrect date being represented (14/11/2007 is displayed as 20/07/1114) on the payment field. The date was parsed two times with the format of the user's language, while the first parse should be based on the current format of the database. To reproduce: - Change user language to Spanish or French. - Register a payment for an invoice with a payment date between October 1st and December 31st, from 2001 to 2012. - "Paid on 20/07/1114" appears. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4486653) opw-4486653 Forward-Port-Of: odoo/odoo#203535 Forward-Port-Of: odoo/odoo#202258
### Issue: The community runs of the test: `test_portal_subcontractor_record_production_with_dropship` fail since the field `backorder_ids` of the mrp.production model is part of the `stock_barcode_mrp` module (part of the entreprise repo). runbot-build-error-159951 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203654
Original PR description
### Issue: The community runs of the test: `test_portal_subcontractor_record_production_with_dropship` fail since the field `backorder_ids` of the mrp.production model is part of the `stock_barcode_mrp` module (part of the entreprise repo). runbot-build-error-159951 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203654
The CSS of global filters in dashboard was broken if there was too many filters or if a filter was too tall (e.g. relation filter with many options). This commit fixes those issues. Now the filters are wrapped in multiple lines if there are too many filters. That mean that we have to define a fixed width for the filters, otherwise the filters won't be aligned over multiple lines and will be ugly. The commit also adds max-height and overflow on the filters to avoid the filters being too tall.
Original PR description
The CSS of global filters in dashboard was broken if there was too many filters or if a filter was too tall (e.g. relation filter with many options). This commit fixes those issues. Now the filters…
The CSS of global filters in dashboard was broken if there was too many filters or if a filter was too tall (e.g. relation filter with many options). This commit fixes those issues. Now the filters are wrapped in multiple lines if there are too many filters. That mean that we have to define a fixed width for the filters, otherwise the filters won't be aligned over multiple lines and will be ugly. The commit also adds max-height and overflow on the filters to avoid the filters being too tall. It also changes the style of the `Select period...` option to be more placeholder-like. Note: the same fix cannot easily be done in 16.0, because there the date picker isn't a popover there, this adding `overflow` to the CSS breaks it. Task: [4624108](https://www.odoo.com/web#id=4624108&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) 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#201391
The E-invoicing is mandatory in Jordan, and most of the users need it. So, it's simpler if they have it already installed when they install the base module. task-4669464 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203266
Original PR description
The E-invoicing is mandatory in Jordan, and most of the users need it. So, it's simpler if they have it already installed when they install the base module. task-4669464 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203266
Amazon SP-API is dropping support for the `POST_INVENTORY_AVAILABILITY_DATA` feed type. This was previously used in Odoo to synchronize the stock level with Amazon. This commit upgrades the feed api to use the new `JSON_LISTINGS_FEED` as a replacement. This new feed needs new informations that were not stored previously. Since this is a fix targeting stable versions of Odoo, it was decided to store this new inforamtion as a json dictionary in the `amazon.offer.amazon_feed_ref` field.
Original PR description
Amazon SP-API is dropping support for the `POST_INVENTORY_AVAILABILITY_DATA` feed type. This was previously used in Odoo to synchronize the stock level with Amazon. This commit upgrades the feed api to use the new `JSON_LISTINGS_FEED` as a replacement. This new feed needs new informations that were not stored previously. Since this is a fix targeting stable versions of Odoo, it was decided to store this new inforamtion as a json dictionary in the `amazon.offer.amazon_feed_ref` field. task-3820591 Forward-Port-Of: odoo/enterprise#82317 Forward-Port-Of: odoo/enterprise#78897
Issue ===== Scanning a product while beeing in the stock move line Barcode form view or in the quand Barcode form view can cause a traceback and the impossibility to exit a Barcode operation. How to reproduce ================ 1. Create two products with a barcode; 2. Open the Barcode app and create an operation; 3. Scan a product then click on the edit button to open the form view; 4. Update the product quantity field; 5. While still in the form view, scan another barcode -> You can s
Original PR description
Issue ===== Scanning a product while beeing in the stock move line Barcode form view or in the quand Barcode form view can cause a traceback and the impossibility to exit a Barcode operation. How to…
Issue ===== Scanning a product while beeing in the stock move line Barcode form view or in the quand Barcode form view can cause a traceback and the impossibility to exit a Barcode operation. How to reproduce ================ 1. Create two products with a barcode; 2. Open the Barcode app and create an operation; 3. Scan a product then click on the edit button to open the form view; 4. Update the product quantity field; 5. While still in the form view, scan another barcode -> You can see the quantity was reset; 6. Update again the quantity and save; 7. Try to exit the operation -> Bim badaboum, traceback 💥! Cause of the issue ================== When a barcode is scanned, the app doesn't check where is the current state and process the barcode anyway which lead to strange behavior and inconsistencies between the current lines and the lines to save. Solution ======== Disable the scan while somewhere else that in the barcode line view. Miscellaneous ============= Remove an old forgotten `console.warn` 😬 [OPW-4567723](https://www.odoo.com/odoo/project/49/tasks/4567723) Forward-Port-Of: odoo/enterprise#82029 Forward-Port-Of: odoo/enterprise#81512
Installing stock_barcode without base_import installed results in errors in the assets when loading `ImportBlockUI`. This occurs because `stock_barcode` requires a component from `base_import` but does not explicitly declare it as a dependency. opw-4613302 Forward-Port-Of: odoo/enterprise#81368
Original PR description
Installing stock_barcode without base_import installed results in errors in the assets when loading `ImportBlockUI`. This occurs because `stock_barcode` requires a component from `base_import` but does not explicitly declare it as a dependency. opw-4613302 Forward-Port-Of: odoo/enterprise#81368
The list of approvers is computed based on the selected category for the approval request. Before the fix, the list would keep previous approvers when changing the category. This could lead to issues where users could add themselves as approvers on unauthorized categories. Steps to reproduce: - Create an approval request category (c1) with yourself as approver. - Create another approval request category (c2) with someone else as approver. - Create a request with category c1 and change to c
Original PR description
The list of approvers is computed based on the selected category for the approval request. Before the fix, the list would keep previous approvers when changing the category. This could lead to issues where users could add themselves as approvers on unauthorized categories. Steps to reproduce: - Create an approval request category (c1) with yourself as approver. - Create another approval request category (c2) with someone else as approver. - Create a request with category c1 and change to category c2. - You are now an approver of the approval request. This commit fixes the issue by reseting the list of approvers to only take the ones configured on the category. task-4637083 Forward-Port-Of: odoo/enterprise#82133 Forward-Port-Of: odoo/enterprise#81129
It is possible for a user to sync an existing whatsapp account and only after install some whatsapp bridge module. In that case the user will get an error as the template is created on the existing account with an existing name. We now prevent using the default value if a template with the same name already exists on it. task-4369979 Forward-Port-Of: odoo/enterprise#82260 Forward-Port-Of: odoo/enterprise#79786
Original PR description
It is possible for a user to sync an existing whatsapp account and only after install some whatsapp bridge module. In that case the user will get an error as the template is created on the existing account with an existing name. We now prevent using the default value if a template with the same name already exists on it. task-4369979 Forward-Port-Of: odoo/enterprise#82260 Forward-Port-Of: odoo/enterprise#79786
This commit ensures that sheet names in exported excel files are unique. The names may not be unique in case a composite report contains multiple section reports all having the same very long prefix. An example to that could be found in l10n_fr_reports: 1) IMB - Intermediate management balances 2) IMB - Intermediate management balances (2024) task-4678129 Forward-Port-Of: odoo/enterprise#82333
Original PR description
This commit ensures that sheet names in exported excel files are unique. The names may not be unique in case a composite report contains multiple section reports all having the same very long prefix. An example to that could be found in l10n_fr_reports: 1) IMB - Intermediate management balances 2) IMB - Intermediate management balances (2024) task-4678129 Forward-Port-Of: odoo/enterprise#82333
Versions -------- - 17.0+ Steps ----- 1. Have a salesman user without accounting rights; 2. assign user to a subscription; 3. create an invoice for the subscription; 4. assign a different salesman to the subscription; 5. as the initial salesman, try to close the subscription. Issue ----- Depending on the state of the cache, one of two things happen: 1. You get a validation error, saying the subscription has no invoices. 2. You get an access error if the invoice lines exist in t
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have a salesman user without accounting rights; 2. assign user to a subscription; 3. create an invoice for the subscription; 4. assign a different salesman to the subscription; 5. as the initial salesman, try to close the subscription. Issue ----- Depending on the state of the cache, one of two things happen: 1. You get a validation error, saying the subscription has no invoices. 2. You get an access error if the invoice lines exist in the cache. Cause ----- The salesman only has read access to their own invoices. The first error happens because they cannot search for others' invoices. The second error happens because they cannot read the cached records. Solution -------- Use `sudo` to check for existing invoices. opw-4554639 Forward-Port-Of: odoo/enterprise#82243