Wednesday, March 26, 2025
52 changes · saas-18.1
Resolved issues and error corrections
Point of Sale basic receipts now hide price details as intended, making them suitable for gift receipts. This prevents customers from seeing pricing information when businesses choose the basic receipt option.
Original PR description
Steps to reproduce: ------------------- 1. Enable "basic receipt" from pos configs 2. Make an order and on the ticket screen, click "Print basic receipt" -> The price info are shown on the printed receipt, even though it shouldn't be the case since a basic ticket is meant for gifts for instance. Reason and fix: --------------- Commit b83b13030d8fbc1ca51731c13d88b194d93945ac showed some prices infor without taking into consideration the prop `basic_receipt`, which was fixed by this commit. opw-4652730
This fixes a timing issue in Discuss calls where a removed chat channel could cause an error screen or crash. The change makes calls handle missing channel information more gracefully, improving reliability for users in edge cases.
Original PR description
Before this commit, a a race condition could lead to a missing channel for a rtcSession (for example if the channel is removed and that knowledge is obtained before the removal of the session).
Fixed an issue where pinned live chat conversations could appear under the wrong sidebar category after users folded the section and reloaded the page. This keeps the inbox navigation clearer and helps users find active conversations reliably.
Original PR description
Before this PR, live chats were sometimes displayed under the wrong category. Steps to reproduce: - Ensure you have one live chat pinned in the sidebar. - Go to the inbox, fold the live chat category. - Reload the page. - Open the live chat category. - The chat is displayed under the wrong category. This occurs because the t-key used in the side bar template is the index of the category which is not reliable. Change it to the id field which is also unique but more reliable. 
Miscellaneous changes
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 interval. To replicate: 1. set a timeoff to a flexible resource 2. open p
Original PR description
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 interval. To replicate: 1. set a timeoff to a flexible resource 2. open planning app 3. in the gantt view, the day in which the timeoff was set should be grayed. ticket-id: 4492625 enterprise: [79532](https://github.com/odoo/enterprise/pull/79532) 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#198032
## [FIX] resource: make sure flexible resource don't use attendances This commit makes sure the resource calendar attendance is not used for a flexible resource even if that resource has a working schedule with hours per day equals to 0 hour. Remark: this fix has been moved in https://github.com/odoo/odoo/pull/202849 ## [FIX] hr: recompute is_flexible when working schedule becomes flexible Before this commit, when the user sets a working schedule to an employee and convert that wo
Original PR description
## [FIX] resource: make sure flexible resource don't use attendances This commit makes sure the resource calendar attendance is not used for a flexible resource even if that resource has a working…
## [FIX] resource: make sure flexible resource don't use attendances This commit makes sure the resource calendar attendance is not used for a flexible resource even if that resource has a working schedule with hours per day equals to 0 hour. Remark: this fix has been moved in https://github.com/odoo/odoo/pull/202849 ## [FIX] hr: recompute is_flexible when working schedule becomes flexible Before this commit, when the user sets a working schedule to an employee and convert that working schedule into a flexible working schedule, the employee is not considered as working with flexible hours. This commit makes sure the `_compute_is_flexible` method defined in `hr.employee` model is triggered when the `flexible_hours` field of the working schedule linked to the employee is altered. Steps to reproduce the issue: ----------------------------- 0. Install Attendance app (`hr_attendance` module). 1. Set a working schedule A to employee E 2. Go to the form view of the working schedule A and check `Flexible Hours` field to convert the working schedule as flexible working schedule. 3. Go to Attendance app Expected Behavior: ----------------- The Attendance app should loaded without any issue. Current Behavior: ---------------- A traceback is occurred saying we have a division by zero. opw-4492625 Forward-Port-Of: odoo/odoo#203253
When there are lots of `product_template_attribute_lines` the computation of the `product_tmpl_ids` field of `product.attribute` can take a bit of time. This in turn slows down the editing of attribute/attribute_values on product.template's FormView. This commit changes the compute method by first doing a `_read_group` to retrieve the templates by attribute. This skips the `__get__` call on `product_attribute.product_attribute_line_ids`. A compound index on `product_template_attribute_line`
Original PR description
When there are lots of `product_template_attribute_lines` the computation of the `product_tmpl_ids` field of `product.attribute` can take a bit of time. This in turn slows down the editing of attribute/attribute_values on product.template's FormView. This commit changes the compute method by first doing a `_read_group` to retrieve the templates by attribute. This skips the `__get__` call on `product_attribute.product_attribute_line_ids`. A compound index on `product_template_attribute_line` is also added to speedup the `_read_group` mentioned above. #### speedup Customer database with close to 900 000 product_template_attribute_lines and an average of 100 000 product_template_attribute_lines by attribute_id. Adding a new attribute in a template FormView: 3s -> 500ms. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203168
For forensics purposes, having a log when users are doing an export is useful. In this revision, the logger is put in the controller. It would be better to put it in a lower level method, such the `export_data` public method on the models. However: - The domain is only available in the controller. `export_data` does not receive the domain in its params. Putting the logger in `export_data` would therefore lead to the inability to log the domain. Or we would need to do one logger in the con
Original PR description
For forensics purposes, having a log when users are doing an export is useful. In this revision, the logger is put in the controller. It would be better to put it in a lower level method, such the…
For forensics purposes, having a log when users are doing an export is useful. In this revision, the logger is put in the controller. It would be better to put it in a lower level method, such the `export_data` public method on the models. However: - The domain is only available in the controller. `export_data` does not receive the domain in its params. Putting the logger in `export_data` would therefore lead to the inability to log the domain. Or we would need to do one logger in the controller just for the domain, and a second logger in `export_data`. - During an export using a group by (and without import compatibility) `export_data` is called recursively, in `insert_leaf`. Hence, if the logger would be put in `export_data`, there would be one log per group, therefore bloating the logs. Hence, for stable versions, the decision taken is to put the log in the controller rather than in a lower level method. It's better than nothing. A rework of the API of `export_data` is planned in master to solve the above concerns. Forward-Port-Of: odoo/odoo#203388 Forward-Port-Of: odoo/odoo#202568
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#202982 Forward-Port-Of: odoo/odoo#202230
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 Forward-Port-Of: odoo/odoo#202982 Forward-Port-Of: odoo/odoo#202230
Before this commit, making a down payment for a sale order with a product that has a long name would cause a horizontal scroll bar to appear in the receipt. Before: <img width="259" alt="image" src="https://github.com/user-attachments/assets/3db17ad0-e1a7-4653-9e50-edd9dd8c4e9e" /> After: <img width="383" alt="image" src="https://github.com/user-attachments/assets/faa0c3ea-c400-4cb6-96ed-2b496236710f" /> opw-4604797 --- I confirm I have signed the CLA and read the PR guidelines
Original PR description
Before this commit, making a down payment for a sale order with a product that has a long name would cause a horizontal scroll bar to appear in the receipt. Before: <img width="259" alt="image" src="https://github.com/user-attachments/assets/3db17ad0-e1a7-4653-9e50-edd9dd8c4e9e" /> After: <img width="383" alt="image" src="https://github.com/user-attachments/assets/faa0c3ea-c400-4cb6-96ed-2b496236710f" /> opw-4604797 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#200387
**Steps to reproduce:** - Use version 2.12.1 of PyPDF2 as required if python version > 3.10 - Install Accounting - Upload an encrypted PDF as a bill - Go to the bills list view - Select the uploaded bill - Print "Original Bills" **Issue:** A traceback is raised: "PyPDF2.errors.DependencyError: PyCryptodome is required for AES algorithm" **Cause:** When printing the original bill, we try to add a banner on the PDF. If the PDF is encrypted, PyPDF2 (2.12.1) will only try to decrypt
Original PR description
**Steps to reproduce:** - Use version 2.12.1 of PyPDF2 as required if python version > 3.10 - Install Accounting - Upload an encrypted PDF as a bill - Go to the bills list view - Select the uploaded…
**Steps to reproduce:** - Use version 2.12.1 of PyPDF2 as required if python version > 3.10 - Install Accounting - Upload an encrypted PDF as a bill - Go to the bills list view - Select the uploaded bill - Print "Original Bills" **Issue:** A traceback is raised: "PyPDF2.errors.DependencyError: PyCryptodome is required for AES algorithm" **Cause:** When printing the original bill, we try to add a banner on the PDF. If the PDF is encrypted, PyPDF2 (2.12.1) will only try to decrypt it if "PyCryptodome" library is installed. Otherwise, it will raise a "DependencyError", which is not handled in the "except" clause. As "PyCryptodome" library is not part of Odoo requirements, we should handle the raised "DependencyError". **Solution:** Try to import "DependencyError" from "PyPDF2.errors" and catch that exception when adding the banner to the PDF. Our own "DependencyError" exception should be created because version 1.26.0 of PyPDF2 doesn't declare "DependencyError" and therefore the import will fail. "NotImplementedError" is used instead in version 1.26.0 and is already handled. opw-4634417 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203184 Forward-Port-Of: odoo/odoo#202129
In a form view with a many2one field using the res_partner_many2one widget (e.g. in the "Contacts" form view) where this field is set, remove the value. Before this commit, this didn't trigger a change in the model. As a matter of fact, the "save" button in the control panel (the small cloud) wasn't displayed. As a consequence, such a change couldn't be saved. This commit fixes the issue. OPW-4669817 Description of the issue/feature this PR addresses: Current behavior before PR: D
Original PR description
In a form view with a many2one field using the res_partner_many2one widget (e.g. in the "Contacts" form view) where this field is set, remove the value. Before this commit, this didn't trigger a change in the model. As a matter of fact, the "save" button in the control panel (the small cloud) wasn't displayed. As a consequence, such a change couldn't be saved. This commit fixes the issue. OPW-4669817 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#203277
Before this commit, the error message shown when a gift card had already been sold contained incorrect grammar: "This Gift card is already been sold." opw-4656131 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203140
Original PR description
Before this commit, the error message shown when a gift card had already been sold contained incorrect grammar: "This Gift card is already been sold." opw-4656131 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203140
Some users are encountering access error when opening the pos from a child company Steps to reproduce: ------------------- * Create a child company for "My Belgian Company" * Register this company for the user Marc Demo * Create a shop in the brach * Now connect as Marc Demo * Try to open the PoS > Observation: Access error Why the fix: ------------ Account chart template are only defined in the parent company. opw-4644042 Forward-Port-Of: odoo/odoo#202506
Original PR description
Some users are encountering access error when opening the pos from a child company Steps to reproduce: ------------------- * Create a child company for "My Belgian Company" * Register this company for the user Marc Demo * Create a shop in the brach * Now connect as Marc Demo * Try to open the PoS > Observation: Access error Why the fix: ------------ Account chart template are only defined in the parent company. opw-4644042 Forward-Port-Of: odoo/odoo#202506
This commit fixes improper interpolation of SCSS variables assigned to CSS custom properties, leading to malformed generated CSS rules (i.e. `--my-prop: $my-value` in the CSS bundle). Quote from the SASS/SCSS documentation: > CSS custom properties, also known as CSS variables, have an unusual > declaration syntax: they allow almost any text at all in their > declaration values. (...) Because of this, Sass parses custom property > declarations differently than other property declarations.
Original PR description
This commit fixes improper interpolation of SCSS variables assigned to CSS custom properties, leading to malformed generated CSS rules (i.e. `--my-prop: $my-value` in the CSS bundle). Quote from the SASS/SCSS documentation: > CSS custom properties, also known as CSS variables, have an unusual > declaration syntax: they allow almost any text at all in their > declaration values. (...) Because of this, Sass parses custom property > declarations differently than other property declarations. All tokens, > including those that look like SassScript, are passed through to CSS > as-is. The only exception is interpolation, which is the only way to > inject dynamic values into a custom property. Reference: https://sass-lang.com/documentation/style-rules/declarations/#custom-properties Forward-Port-Of: odoo/odoo#203279 Forward-Port-Of: odoo/odoo#203134
The aim of this commit is to fix a display bug where the shipping adress is overlapping the address element when too many address lines are present Steps to reproduce: - Install l10n_din5008_sale - Configure the document to use the din5008 layout - Create a UK customer with all the adress fields filled + phone - Create a quotation for that customer and Print the PDF Quote opw-4575257  Becomes
Original PR description
The aim of this commit is to fix a display bug where the shipping adress is overlapping the address element when too many address lines are present Steps to reproduce: - Install l10n_din5008_sale - Configure the document to use the din5008 layout - Create a UK customer with all the adress fields filled + phone - Create a quotation for that customer and Print the PDF Quote opw-4575257  Becomes  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201850
**Problem**: When adding text followed by **"Shift+Enter"** and a long image, clicking to edit the text triggers `scrollTo`, causing the view to jump to the image instead. This makes it impossible to edit the text, as the selection keeps switching to the image. This happens because, on `pointerdown`, the selection changes to text, triggering a scroll. On `pointerup`, the target becomes the image, changing the selection again. **Solution**: Scroll only if more than half of the content is
Original PR description
**Problem**: When adding text followed by **"Shift+Enter"** and a long image, clicking to edit the text triggers `scrollTo`, causing the view to jump to the image instead. This makes it impossible to edit the text, as the selection keeps switching to the image. This happens because, on `pointerdown`, the selection changes to text, triggering a scroll. On `pointerup`, the target becomes the image, changing the selection again. **Solution**: Scroll only if more than half of the content is not visible. **Steps to Reproduce**: 1. Add text and press **"Shift+Enter"**. 2. Insert a long image below the text. 3. Try to edit the text: - **Issue**: View scrolls to the image, making text uneditable. opw-4606741 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#200161
### Steps to reproduce: - In Accounting create a new Payment Term with an early discount set on "Always(upon invoice)" - Create a new Contact and add the payment term to this contact - Open POS and create an order - Select the new contact as the customer - Go to payment, select the option to create an invoice and validate - The receipt and the generated invoice have different amounts: the payment terms were applied on the invoice but not on the receipt ### Cause: POS does not consider
Original PR description
### Steps to reproduce: - In Accounting create a new Payment Term with an early discount set on "Always(upon invoice)" - Create a new Contact and add the payment term to this contact - Open POS and create an order - Select the new contact as the customer - Go to payment, select the option to create an invoice and validate - The receipt and the generated invoice have different amounts: the payment terms were applied on the invoice but not on the receipt ### Cause: POS does not consider at any point the payment terms so the total to be paid does not include the payment terms. Payment terms were included in invoices from POS with this [commit](https://github.com/odoo/odoo/pull/100100/commits/c1cd62f0b207b3f3bbf5a03009bd8e34ee9b479f) ### Solution: Remove the payment terms on invoices from POS. opw-4458036 Forward-Port-Of: odoo/odoo#202895 Forward-Port-Of: odoo/odoo#199385
The automatic detection of maximum email size was not working anymore. After this commit, the `esmtp_features` attribute is added, to ensure reliable detection of the email's size. opw-4673107 cc: @Julien00859 @Abridbus Forward-Port-Of: odoo/odoo#203326
Original PR description
The automatic detection of maximum email size was not working anymore. After this commit, the `esmtp_features` attribute is added, to ensure reliable detection of the email's size. opw-4673107 cc: @Julien00859 @Abridbus Forward-Port-Of: odoo/odoo#203326
Issue: if user does not have employee in the current company in managment the allocation will try to load his employee calendar which raise the error Fix: check if there is an employee for the user before trying to fetch the data Task: 4660184 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202643
Original PR description
Issue: if user does not have employee in the current company in managment the allocation will try to load his employee calendar which raise the error Fix: check if there is an employee for the user before trying to fetch the data Task: 4660184 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202643
### Description: When opening the replenishment view, the locations are checked to find if some products need to be refilled. If one product needs to be refilled, it will check if an orderpoint already exists, otherwise, it will create it. The issue is that the checks are currently done on all the orderpoints, even the ones not related to the product. The performances are worsened by the compute on `qty_to_order` triggered on all the orderpoints. ### Fix: To fix that, we can add a leaf
Original PR description
### Description: When opening the replenishment view, the locations are checked to find if some products need to be refilled. If one product needs to be refilled, it will check if an orderpoint already exists, otherwise, it will create it. The issue is that the checks are currently done on all the orderpoints, even the ones not related to the product. The performances are worsened by the compute on `qty_to_order` triggered on all the orderpoints. ### Fix: To fix that, we can add a leaf to the domain so that we only retrieve the orderpoints related to the products that need to be refilled. This will reduce the number of records on which we call the `qty_to_order` compute. ### Benchmark (in 18): | # of orderpoint | Before | After | | --------------- | ------ | ----- | | 44145 | 6:52 | 6s | | 22145 | 3:38 | 6s | ### Reference: opw-4618887 Forward-Port-Of: odoo/odoo#203276
When we have an Analytic Plan being Mandatory, confirming an invoice from the form view, if it has a line without an Analytic distribution, correctly raises a ValidationError. Confirming invoices from the list view does not raise the same error, yet it should. To replicate: 1. [Activate](https://www.odoo.com/documentation/18.0/applications/finance/accounting/reporting/analytic_accounting.html) Analytic accounting: a. Install `accountant` b. In Settings, activate Analytic Accounting
Original PR description
When we have an Analytic Plan being Mandatory, confirming an invoice from the form view, if it has a line without an Analytic distribution, correctly raises a ValidationError. Confirming invoices…
When we have an Analytic Plan being Mandatory, confirming an invoice from the form view, if it has a line without an Analytic distribution, correctly raises a ValidationError. Confirming invoices from the list view does not raise the same error, yet it should. To replicate: 1. [Activate](https://www.odoo.com/documentation/18.0/applications/finance/accounting/reporting/analytic_accounting.html) Analytic accounting: a. Install `accountant` b. In Settings, activate Analytic Accounting c. Create an Analytic plan (with an Analytic account associated) 2. Set its default applicability to mandatory 3. Create two invoices, remove the analytic distribution from one of the lines in one invoice. 4. In the invoices list view, select both newly created invoices, click on Actions > Confirm Entries 5. Click Confirm 6. The invoices were posted, even though they have no analytic distributions. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4603919) opw-4603919 Forward-Port-Of: odoo/odoo#203194 Forward-Port-Of: odoo/odoo#201560
**Problem**: After commit [https://github.com/odoo-dev/odoo/commit/80fde992370e4474c27a383a61814ce1159f550c](https://github.com/odoo/odoo/commit/80fde992370e4474c27a383a61814ce1159f550c), if all tabs in a "Tabs" block are removed and saved, the next time the editor is opened, there is a traceback because `navEl` is `null`. **Solution**: Use the first value from `possibleValues` in case `navEl` is `null` this will prevent traceback in that case but does not prevent reaching the no tab si
Original PR description
**Problem**: After commit [https://github.com/odoo-dev/odoo/commit/80fde992370e4474c27a383a61814ce1159f550c](https://github.com/odoo/odoo/commit/80fde992370e4474c27a383a61814ce1159f550c), if all tabs…
**Problem**: After commit [https://github.com/odoo-dev/odoo/commit/80fde992370e4474c27a383a61814ce1159f550c](https://github.com/odoo/odoo/commit/80fde992370e4474c27a383a61814ce1159f550c), if all tabs in a "Tabs" block are removed and saved, the next time the editor is opened, there is a traceback because `navEl` is `null`. **Solution**: Use the first value from `possibleValues` in case `navEl` is `null` this will prevent traceback in that case but does not prevent reaching the no tab situation (Still able to remove all tabs). **Steps to Reproduce**: 1. Add a **"Tabs"** block. 2. Click inside the first tab to edit its content. 3. Press **Backspace** repeatedly until the tab is completely removed. 4. Repeat for all remaining tabs until none are left. 5. Save and exit the editor. 6. Open the editor again. - **Issue**: A traceback occurs due to `navEl` being `null`. **opw-4608389** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202476
Steps to reproduce ================== - Go to the products kanban view - Open a record - Go back to the kanban view => Every product image is downloaded again Cause of the issue ================== There is a unique query param in the url as the browser doesn't fetch twice the same image from the same url in the same session. For non related fields, we use the last record update as a unique timestamp. For related fields, since we don't have the information about the last update
Original PR description
Steps to reproduce ================== - Go to the products kanban view - Open a record - Go back to the kanban view => Every product image is downloaded again Cause of the issue ==================…
Steps to reproduce
==================
- Go to the products kanban view
- Open a record
- Go back to the kanban view => Every product image is downloaded again
Cause of the issue
==================
There is a unique query param in the url as the browser doesn't fetch twice the same image from the same url in the same session.
For non related fields, we use the last record update as a unique timestamp.
For related fields, since we don't have the information about the last update, we generate a unique timestamp when instanciating an ImageField component.
It can happen that a related field points to the same model.
This is the case here where the product kanban view uses the "image_128" field.
```py
image_1920 = fields.Image("Image", max_width=1920, max_height=1920)
image_128 = fields.Image("Image 128", related="image_1920", max_width=128, max_height=128, store=True)
```
Solution
========
When a field is related but the relation points to the same model, we can still use the last record update
We can try to detect this by checking if there is a dot in the related path.
Forward-Port-Of: odoo/odoo#203292Before this commit: When sample data was visible in the view, the pager was also displayed, showing a record count, which could be misleading. After this commit: Now, when sample data is visible, the pager is hidden. Task-4489033 Forward-Port-Of: odoo/odoo#203221 Forward-Port-Of: odoo/odoo#200624
Original PR description
Before this commit: When sample data was visible in the view, the pager was also displayed, showing a record count, which could be misleading. After this commit: Now, when sample data is visible, the pager is hidden. Task-4489033 Forward-Port-Of: odoo/odoo#203221 Forward-Port-Of: odoo/odoo#200624
Before this commit: ====================== Loyalty points were awarded for all orders, including those from UrbanPiper (online orders). This allowed customers to earn loyalty points both for dine-in and online orders, leading to earning loyalty points twice. Since online food delivery platforms have their own reward systems, loyalty points should not be granted for these orders. After this commit: ==================== Loyalty points and rewards are now excluded for UrbanPiper orders. T
Original PR description
Before this commit: ====================== Loyalty points were awarded for all orders, including those from UrbanPiper (online orders). This allowed customers to earn loyalty points both for dine-in and online orders, leading to earning loyalty points twice. Since online food delivery platforms have their own reward systems, loyalty points should not be granted for these orders. After this commit: ==================== Loyalty points and rewards are now excluded for UrbanPiper orders. Task-4585821 Forward-Port-Of: odoo/odoo#198509
This commit is a backport of the display driver changes from commit 078533b. These changes allow displays to be detected and rotated correctly under Wayland. task-4657986 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203061
Original PR description
This commit is a backport of the display driver changes from commit 078533b. These changes allow displays to be detected and rotated correctly under Wayland. task-4657986 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203061
Currently a `ParseError` is arising when the user installs the `pos_event` module after deleting `Event Registration` product from the products. Steps to reproduce: --- - Install `event_product` application (without demo data). - Delete `Event Registration` from products - Now install `pos_event` module Traceback: --- ``` Exception: Cannot update missing record 'event_product.product_product_event' ParseError: while parsing /home/odoo/src/odoo/saas-18.1/addons/pos_event/data/even
Original PR description
Currently a `ParseError` is arising when the user installs the `pos_event` module after deleting `Event Registration` product from the products. Steps to reproduce: --- - Install `event_product`…
Currently a `ParseError` is arising when the user installs the `pos_event` module after deleting `Event Registration` product from the products.
Steps to reproduce:
---
- Install `event_product` application (without demo data).
- Delete `Event Registration` from products
- Now install `pos_event` module
Traceback:
---
```
Exception: Cannot update missing record 'event_product.product_product_event'
ParseError: while parsing /home/odoo/src/odoo/saas-18.1/addons/pos_event/data/event_product_data.xml:4, somewhere inside <record id="event_product.product_product_event" model="product.product">
<field name="available_in_pos">True</field>
<field name="pos_categ_ids" eval="[(6, 0, [ref('pos_event.pos_category_event')])]"/>
</record>
```
The error occurs because the user deleted the product, and then tried to install the other module.
This commit solves the above issue by using `forcecreate="False"` to bypass record creation if it violates checks.
https://github.com/odoo/odoo/blob/f5378fadf910d193cbb44a4d1c10a5a15d8b9a51/odoo/tools/convert.py#L364
sentry-5731062091
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#199010Steps to reproduce: - Create SO with two products. - Apply 10% discount to both lines. - Confirm SO and create an invoice. - Confirm invoice for only one SOL. - Go to 'Orders to Invoice' and add uninvoiced-balance field to the view using Studio. - Check value of the uninvoiced-balance field. Issue: - The uninvoiced-balance field is not calculated correctly. Cause: - line.price_total already includes the discount, so applying the discount again results in an incorrect calculation.
Original PR description
Steps to reproduce: - Create SO with two products. - Apply 10% discount to both lines. - Confirm SO and create an invoice. - Confirm invoice for only one SOL. - Go to 'Orders to Invoice' and add uninvoiced-balance field to the view using Studio. - Check value of the uninvoiced-balance field. Issue: - The uninvoiced-balance field is not calculated correctly. Cause: - line.price_total already includes the discount, so applying the discount again results in an incorrect calculation. Fix: - Remove price_reduce and directly multiply unit_price_total by qty_to_invoice to ensure the correct calculation of amount_to_invoice. opw-4567563 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202821
When looping inside of the `while True` loop because of concurrency, the `sequence_prefix` was not correctly set. This was breaking the behavior of `sequence.mixin` because we were not able to get the last number. Partial revert of 10565c6968a5d0f285f93c4bdc610350999a88e3 Forward-Port-Of: odoo/odoo#203291
Original PR description
When looping inside of the `while True` loop because of concurrency, the `sequence_prefix` was not correctly set. This was breaking the behavior of `sequence.mixin` because we were not able to get the last number. Partial revert of 10565c6968a5d0f285f93c4bdc610350999a88e3 Forward-Port-Of: odoo/odoo#203291
The field `res.company.hr_recruitment_monster_password` has the same label `Password` as the field `res.company.l10n_co_edi_password` from module [`l10n_co_edi`](https://github.com/odoo/enterprise/blob/b2fcd4e679fd6e4dedebdc13a5de0c89fbe3ef9a/l10n_co_edi/models/res_company.py#L15), as well as the related field on `res.config.settings` model, which generates warnings. The label on the field can be changed and the [view](https://github.com/odoo/enterprise/blob/b2fcd4e679fd6e4dedebdc13a5de0c89fb
Original PR description
The field `res.company.hr_recruitment_monster_password` has the same label `Password` as the field `res.company.l10n_co_edi_password` from module [`l10n_co_edi`](https://github.com/odoo/enterprise/blob/b2fcd4e679fd6e4dedebdc13a5de0c89fbe3ef9a/l10n_co_edi/models/res_company.py#L15), as well as the related field on `res.config.settings` model, which generates warnings. The label on the field can be changed and the [view](https://github.com/odoo/enterprise/blob/b2fcd4e679fd6e4dedebdc13a5de0c89fbe3ef9a/hr_recruitment_integration_monster/views/res_config_settings.xml#L16-L21) where it is used will not be affected since the label is set in the view. Forward-Port-Of: odoo/enterprise#81175
Issue: ------ When migrating a database having 'Documents' module installed and also having empty/blank spreadsheets created in version saas-17.2 or lower will lead to a JSON decoder error. This happens when the 'spreadsheet_data' value become an empty `b''` because of empty spreadsheets. Here : https://github.com/odoo/enterprise/blob/17.0/spreadsheet_edition/models/spreadsheet_mixin.py#L224 Solution: ----------- Passing an empty dictionay '{}' if it gets empty quotes as `b''` during pr
Original PR description
Issue: ------ When migrating a database having 'Documents' module installed and also having empty/blank spreadsheets created in version saas-17.2 or lower will lead to a JSON decoder error. This…
Issue:
------
When migrating a database having 'Documents' module installed and also having empty/blank spreadsheets created in version saas-17.2 or lower will lead to a JSON decoder error. This happens when the 'spreadsheet_data' value become an empty `b''` because of empty spreadsheets.
Here :
https://github.com/odoo/enterprise/blob/17.0/spreadsheet_edition/models/spreadsheet_mixin.py#L224
Solution:
-----------
Passing an empty dictionay '{}' if it gets empty quotes as `b''` during processing.
Steps to reproduce:
------------------------
1. Create a database in version 17.2 or lower and install Documents module.
2. Create empty/blank spreadsheets (we can manually upload an empty spreadsheet).
3. Migrate the database to version saas~17.4 or above.
4. Finally, during testcases one of the test case will fail. Because of empty quotes.
Traceback:
```
File "/home/odoo/src/enterprise/saas-17.4/spreadsheet_edition/models/spreadsheet_mixin.py", line 44, in _compute_current_revision_uuid
snapshot = spreadsheet._get_spreadsheet_snapshot()
File "/home/odoo/src/enterprise/saas-17.4/spreadsheet_edition/models/spreadsheet_mixin.py", line 234, in _get_spreadsheet_snapshot
return json.loads(self.spreadsheet_data)
File "/usr/lib/python3.10/json/__init__.py", line 346, in loads
return _default_decoder.decode(s)
File "/usr/lib/python3.10/json/decoder.py", line 337, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
File "/usr/lib/python3.10/json/decoder.py", line 355, in raw_decode
raise JSONDecodeError("Expecting value", s, err.value) from None
json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
```
UPG - 2263261
TBG - 1416
Forward-Port-Of: odoo/enterprise#74921
Forward-Port-Of: odoo/enterprise#74685…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#79532
This commit adds a test to make sure the progress bar of employee fetched in gantt view of attendance returns the expected values without any issue. opw-4492625 Forward-Port-Of: odoo/enterprise#82068
Original PR description
This commit adds a test to make sure the progress bar of employee fetched in gantt view of attendance returns the expected values without any issue. opw-4492625 Forward-Port-Of: odoo/enterprise#82068
Inverse the domain on `subscription_state` from: `not in (selection_values)` -> `in (complement(selection_values))` Using the `in` operator gives Postgres the possibility to use an index on `subscription_state`, which cannot be done with a `not in` domain operator for `Selection` fields. Forward-Port-Of: odoo/enterprise#81703
Original PR description
Inverse the domain on `subscription_state` from: `not in (selection_values)` -> `in (complement(selection_values))` Using the `in` operator gives Postgres the possibility to use an index on `subscription_state`, which cannot be done with a `not in` domain operator for `Selection` fields. Forward-Port-Of: odoo/enterprise#81703
### Issue: Currently, the `use_create_components_lots` of the manufacturing picking type is not used in barcode to allow/forbid the creation of new lots. ### Steps to reproduce: - Inventory > Configuration > Warehouse Management > Operation Types - Manufacturing > uncheck: Create New Lots/Serial Numbers for Component - Create a product tracked by SN and put one SN in stock. - Create and confirm an MO for an other product using your tracked product as component. - Go to the barcode a
Original PR description
### Issue: Currently, the `use_create_components_lots` of the manufacturing picking type is not used in barcode to allow/forbid the creation of new lots. ### Steps to reproduce: - Inventory >…
### Issue: Currently, the `use_create_components_lots` of the manufacturing picking type is not used in barcode to allow/forbid the creation of new lots. ### Steps to reproduce: - Inventory > Configuration > Warehouse Management > Operation Types - Manufacturing > uncheck: Create New Lots/Serial Numbers for Component - Create a product tracked by SN and put one SN in stock. - Create and confirm an MO for an other product using your tracked product as component. - Go to the barcode app > Manufacturing > your MO - Click on the component line and scan a string that do not correspond to an existing SN of your tracked product. > The Scanned string is added as a "lot_name" on a new line. In particular, at validation a new move line without lot and with a set lot_name will be created. This line without lot will be used in all the `pre_button_mark_done` checks like: `_check_sn_uniqueness` which btw will fail if you scanned 2 non-existing lots. And, if you manage to pass all check for instance by scanning a non-existing lot and the initially reserved one, the validation of the new move line will create the lot. Cause of the issue: Scanning the non existing lot will correctly fail to find a match via the barcode parser: https://github.com/odoo/enterprise/blob/026a5b8a83bd6b94588baa9a35530495d9e067cd/stock_barcode/static/src/models/barcode_model.js#L963 As such and since a line is selected, you will end up setting the barcode as a lotName: https://github.com/odoo/enterprise/blob/026a5b8a83bd6b94588baa9a35530495d9e067cd/stock_barcode/static/src/models/barcode_model.js#L1018-L1034 This happens notably because you `this.canCreateNewLot` is always set to `True` on productions but should not: https://github.com/odoo/enterprise/blob/026a5b8a83bd6b94588baa9a35530495d9e067cd/stock_barcode_mrp/static/src/models/barcode_mrp_model.js#L126-L128 opw-4618963 Forward-Port-Of: odoo/enterprise#81897 Forward-Port-Of: odoo/enterprise#81272
- after having long name of signature request linked to the contract, it's conflicting the visual of kanban view - with same path, kanban state can not stable on their position - because of that, to make stability of kanban state changed path too - Before fix: - for long name of signature request, overwrite the kanban view  - After fix - perfectly fit the name in kanban view, - only
Original PR description
- after having long name of signature request linked to the contract, it's conflicting the visual of kanban view - with same path, kanban state can not stable on their position - because of that, to make stability of kanban state changed path too - Before fix: - for long name of signature request, overwrite the kanban view  - After fix - perfectly fit the name in kanban view, - only show the limited character and appending `...`  - OPW-4590161 Forward-Port-Of: odoo/enterprise#79913
As defined in https://github.com/odoo/odoo/blob/17.0/addons/web/static/src/views/form/form_controller.js#L322 A record save in Form Controllers can be prevented when `onWillSaveRecord` returns `false`. But since the override in `HelpdeskTeamController` did not consider `super`, it would always break such a flow. Forward-Port-Of: odoo/enterprise#81853 Forward-Port-Of: odoo/enterprise#81769
Original PR description
As defined in https://github.com/odoo/odoo/blob/17.0/addons/web/static/src/views/form/form_controller.js#L322 A record save in Form Controllers can be prevented when `onWillSaveRecord` returns `false`. But since the override in `HelpdeskTeamController` did not consider `super`, it would always break such a flow. Forward-Port-Of: odoo/enterprise#81853 Forward-Port-Of: odoo/enterprise#81769
Since changes made in https://github.com/odoo/enterprise/pull/75552 that changes the semantic of the field 'private_car_missing_days', we need to adapt the value used for simulations from 0 to 20 days (average nb of days in a month) Forward-Port-Of: odoo/enterprise#82022 Forward-Port-Of: odoo/enterprise#81943
Original PR description
Since changes made in https://github.com/odoo/enterprise/pull/75552 that changes the semantic of the field 'private_car_missing_days', we need to adapt the value used for simulations from 0 to 20 days (average nb of days in a month) Forward-Port-Of: odoo/enterprise#82022 Forward-Port-Of: odoo/enterprise#81943
Accessing the tax report from a branch company raised a user error due to attempting to fetch tax group XML IDs using the company’s CID. While this could be resolved by using `self.env["account.chart.template"].ref`, the report isn’t intended to be shown for branch companies. Instead, a constraint was added to prevent access in such cases. opw-4569580 Forward-Port-Of: odoo/enterprise#82101
Original PR description
Accessing the tax report from a branch company raised a user error due to attempting to fetch tax group XML IDs using the company’s CID. While this could be resolved by using `self.env["account.chart.template"].ref`, the report isn’t intended to be shown for branch companies. Instead, a constraint was added to prevent access in such cases. opw-4569580 Forward-Port-Of: odoo/enterprise#82101
[This commit] updated the XBRL version of the Dutch tax reports from the 2024 version (NT18) to the 2025 version (NT19). However, users still need to be able to submit reports for 2024 using the previous scheme. In order to allow this, we keep both the 2024 and 2025 version of the XBRL template and choose the right one depending on the year of the report. In subsequent years, we can then remove the oldest version and add the newest version. The report IDs are suffixes with the year. [op
Original PR description
[This commit] updated the XBRL version of the Dutch tax reports from the 2024 version (NT18) to the 2025 version (NT19). However, users still need to be able to submit reports for 2024 using the previous scheme. In order to allow this, we keep both the 2024 and 2025 version of the XBRL template and choose the right one depending on the year of the report. In subsequent years, we can then remove the oldest version and add the newest version. The report IDs are suffixes with the year. [opw-4600111](https://www.odoo.com/odoo/project.task/4600111) [opw-4664515](https://www.odoo.com/odoo/project.task/4664515) [This commit]: https://github.com/odoo/enterprise/commit/f1710461f37f3560486a1410f9b9ff420b052b7b Forward-Port-Of: odoo/enterprise#82026
Before this commit, in the restaurant, splitting an order could result in an `IndexError: list index out of range`. This issue occurred due to incorrect handling of order lines during the split process. This fix ensures proper validation and handling of order lines to prevent such errors, improving the stability of the POS system. Steps to reproduce: - Create an order - Refresh browser - Attempt to split the order. - Observe the `IndexError: list index out of range` traceback. opw-4
Original PR description
Before this commit, in the restaurant, splitting an order could result in an `IndexError: list index out of range`. This issue occurred due to incorrect handling of order lines during the split process. This fix ensures proper validation and handling of order lines to prevent such errors, improving the stability of the POS system. Steps to reproduce: - Create an order - Refresh browser - Attempt to split the order. - Observe the `IndexError: list index out of range` traceback. opw-4451836 Forward-Port-Of: odoo/enterprise#78184
Before this commit, it was possible to pay payment links linked to renewed orders. It would cause issues as the renewed order would be reopened once the transaction was set to done. Two subscription in progress would live side by side. This commit ensure that such links can't be created and existing links can't be used. taskid: 4607315 Forward-Port-Of: odoo/enterprise#80388
Original PR description
Before this commit, it was possible to pay payment links linked to renewed orders. It would cause issues as the renewed order would be reopened once the transaction was set to done. Two subscription in progress would live side by side. This commit ensure that such links can't be created and existing links can't be used. taskid: 4607315 Forward-Port-Of: odoo/enterprise#80388
When updating the module, the bank data is reloaded. When the account is already trusted (`allow_out_payment == True`), the write fails due to checks to prevent fraud. To fix this, we wrap the data in a `noupdate` to prevent further writes from happening. If ever the account number changes, a new record will be created instead of updating the existing one. Since this account is the default one stipulated on the official belastingdienst site, it can be trusted by default. https://www.belast
Original PR description
When updating the module, the bank data is reloaded. When the account is already trusted (`allow_out_payment == True`), the write fails due to checks to prevent fraud. To fix this, we wrap the data in a `noupdate` to prevent further writes from happening. If ever the account number changes, a new record will be created instead of updating the existing one. Since this account is the default one stipulated on the official belastingdienst site, it can be trusted by default. https://www.belastingdienst.nl/wps/wcm/connect/bldcontenten/belastingdienst/business/payroll_taxes/you_are_not_established_in_the_netherlands_are_you_required_to_withhold_payroll_taxes/when_you_are_going_to_withhold_payroll_taxes/filing_payroll_tax_returns_and_paying_payroll_tax/payment similar: d4595b856045fe9d35a4ac0f28faf12f0d19cd88 Forward-Port-Of: odoo/enterprise#81740
When automatically sending the receipt in a DE PoS, there was 2 receipt sent to the printer, one of them was empty and showing an error. Steps to reproduce: ------------------- * Setup a fiskaly PoS * Activate the automatic receipt printing * Open PoS and make an order * Pay the order > Observation: Two receipt are sent to the printer, one of them is empty and showing an error. Why the fix: ------------ We were calling the `super` method twice. This was causing the receipt to be p
Original PR description
When automatically sending the receipt in a DE PoS, there was 2 receipt sent to the printer, one of them was empty and showing an error. Steps to reproduce: ------------------- * Setup a fiskaly PoS * Activate the automatic receipt printing * Open PoS and make an order * Pay the order > Observation: Two receipt are sent to the printer, one of them is empty and showing an error. Why the fix: ------------ We were calling the `super` method twice. This was causing the receipt to be printed twice. We now call the `super` method only once. opw-4520201 Forward-Port-Of: odoo/enterprise#81771
This commit fixes improper interpolation of SCSS variables assigned to CSS custom properties, leading to malformed generated CSS rules (i.e. `--my-prop: $my-value` in the CSS bundle). Quote from the SASS/SCSS documentation: > CSS custom properties, also known as CSS variables, have an unusual > declaration syntax: they allow almost any text at all in their > declaration values. (...) Because of this, Sass parses custom property > declarations differently than other property declarations.
Original PR description
This commit fixes improper interpolation of SCSS variables assigned to CSS custom properties, leading to malformed generated CSS rules (i.e. `--my-prop: $my-value` in the CSS bundle). Quote from the SASS/SCSS documentation: > CSS custom properties, also known as CSS variables, have an unusual > declaration syntax: they allow almost any text at all in their > declaration values. (...) Because of this, Sass parses custom property > declarations differently than other property declarations. All tokens, > including those that look like SassScript, are passed through to CSS > as-is. The only exception is interpolation, which is the only way to > inject dynamic values into a custom property. Reference: https://sass-lang.com/documentation/style-rules/declarations/#custom-properties Forward-Port-Of: odoo/enterprise#82084 Forward-Port-Of: odoo/enterprise#82012
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#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#80490
Minor improvements on HK payroll: - Update legal name for hk office employees - Remove several sensitive data on payslip - Fix demo data error Forward-Port-Of: odoo/enterprise#81819
Original PR description
Minor improvements on HK payroll: - Update legal name for hk office employees - Remove several sensitive data on payslip - Fix demo data error Forward-Port-Of: odoo/enterprise#81819
__Steps to reproduce:__ - Navigate to *Working Schedules* > *Standard 40 hours/week* - Remove the Lunch period - Create overlapping `Morning` and `Afternoon` periods on multiple days - Example: Morning: `08:00` to `12:00`, Afternoon: `12:00` to `16:00` - Go to *Planning* > *New* - Generate a slot within this period as an open shift - Go to the next week and select *Copy previous week* - Traceback error appears: - `TypeError: '<' not supported between instances of 'NoneType' an
Original PR description
__Steps to reproduce:__ - Navigate to *Working Schedules* > *Standard 40 hours/week* - Remove the Lunch period - Create overlapping `Morning` and `Afternoon` periods on multiple days - Example:…
__Steps to reproduce:__ - Navigate to *Working Schedules* > *Standard 40 hours/week* - Remove the Lunch period - Create overlapping `Morning` and `Afternoon` periods on multiple days - Example: Morning: `08:00` to `12:00`, Afternoon: `12:00` to `16:00` - Go to *Planning* > *New* - Generate a slot within this period as an open shift - Go to the next week and select *Copy previous week* - Traceback error appears: - `TypeError: '<' not supported between instances of 'NoneType' and 'datetime.datetime'` __Description of the issue:__ - In Planning, `calender._attendance_intervals_batch` function returns dict() of `workInterval`, which does not merge overlapping intervals. The `_merge` function in `Intervals` assumes input intervals are already merged, This mismatch caused issues in the planning app when unmerged overlapping intervals were passed to `_merge` __Description of the solution:__ - Convert `workInterval` instances to `Intervals` by passing `workInterval._items` directly to `Intervals`, as it performs merging on overlapping intervals during instantiation. - bug introduced in: [#f283540][1] - opw-4282039 [1]:https://github.com/odoo/odoo/commit/f283540336b29037fe8af9c1a951c3d27c941b3d#diff-357c95d58ea67c00f24d3a4c5a8a987041c42de13ca9f5535e7bb250b2927af6L214 Forward-Port-Of: odoo/enterprise#78499 Forward-Port-Of: odoo/enterprise#73618
When the name of the partner is too long, we truncate the name but we should have added text-no-wrap on the date and amount. opw-4502699 Forward-Port-Of: odoo/enterprise#81316
Original PR description
When the name of the partner is too long, we truncate the name but we should have added text-no-wrap on the date and amount. opw-4502699 Forward-Port-Of: odoo/enterprise#81316
When canceling a payment linked to an entry, we try to unlink the entry, but we end up in the following constains: `ir_attachment._unlink_except_cfdi_document` Steps: - Create, confirm an invoice and sent cfdi - Register a payment with `Por Definir` as payment method - Click on `Update Payments` - On CFDI tab, click on `Force CFDI` on payment line - Go to the payment - Reset it to draft and cancel it -> Error: `You can't unlink an attachment being an EDI document sent to the gover
Original PR description
When canceling a payment linked to an entry, we try to unlink the entry, but we end up in the following constains: `ir_attachment._unlink_except_cfdi_document` Steps: - Create, confirm an invoice and sent cfdi - Register a payment with `Por Definir` as payment method - Click on `Update Payments` - On CFDI tab, click on `Force CFDI` on payment line - Go to the payment - Reset it to draft and cancel it -> Error: `You can't unlink an attachment being an EDI document sent to the government.` Fix: Backport of https://github.com/odoo-dev/enterprise/commit/6f21aedf1a107acb4c89f7a8264171597068e102 opw-4644528 Forward-Port-Of: odoo/enterprise#82001
Invalid values were not being validated before sending to the FedEx REST API. Some values were longer than allowed and some states were not using the correct codes. Length limits were found from the FedEx REST API docs and the correct Indian state codes were provided by FedEx support directly. Added a mapping for Mexican states and one Indian state that did not have the correct state codes. State codes for Mexico were from the API specifications page and updated state codes for India were p
Original PR description
Invalid values were not being validated before sending to the FedEx REST API. Some values were longer than allowed and some states were not using the correct codes. Length limits were found from the FedEx REST API docs and the correct Indian state codes were provided by FedEx support directly. Added a mapping for Mexican states and one Indian state that did not have the correct state codes. State codes for Mexico were from the API specifications page and updated state codes for India were provided from FedEx support. opw-4461150 Forward-Port-Of: odoo/enterprise#81977 Forward-Port-Of: odoo/enterprise#79617
Steps to reproduce the bug: - Install l10n_es_real_estate module - Create a customer invoice on the accounting app - Invoice's AEAT data should be real estate type for mod347 doc - Generate the BOE of tax report document of mod 347 Traceback is thrown while generating the boe of the mod347 document, the traceback is for an issue related to the param of the operation key and that was because the function _call_on_partner_sublines is run for each real estate invoice and it has a callback
Original PR description
Steps to reproduce the bug: - Install l10n_es_real_estate module - Create a customer invoice on the accounting app - Invoice's AEAT data should be real estate type for mod347 doc - Generate the BOE of tax report document of mod 347 Traceback is thrown while generating the boe of the mod347 document, the traceback is for an issue related to the param of the operation key and that was because the function _call_on_partner_sublines is run for each real estate invoice and it has a callback to be executed on each of them. The callback function is _write_type2_partner_record which should have the report option as param, but it wasn't sent that made a traceback for the params. After fixing that, another traceback was thrown because the xmlid of the real estate invoices of both sold and bought are not in the invoice types map of _write_type2_partner_record function. opw-4589314 Forward-Port-Of: odoo/enterprise#82008 Forward-Port-Of: odoo/enterprise#81033