Thursday, May 22, 2025
30 changes · saas-18.1
Resolved issues and error corrections
Users can now create and edit a product while adding a sales order line from a project task without encountering an error. The update ensures the correct product form is used in this flow, making task-related sales entry smoother and more reliable.
Original PR description
Before this commit, when the user creates a SOL from scratch inside the form view of a task and would like to also create and edit the product linked to that new SOL, a traceback is occurred because a certain field cannot be computed correctly. The reason is because the form view loaded is the one of the `product.template` module instead of `product.product`. This commit adds a new product form view to hide the product type if the user creates a product inside the SOL form view displayed when he creates a SOL in sale_line_id field of `project.task` model. This commit also changes the form view to load for `product.product` model to use the one added inside that commit. task-4781817
Miscellaneous changes
Forward-Port-Of: odoo/odoo#210625
Original PR description
Forward-Port-Of: odoo/odoo#210625
Description of the issue/feature this PR addresses: The audit trail error is displayed eventhough the audit_trail is disabled for the company. Current behavior before PR: Attachments cannot be deleted with deactivated audit trail feature. Desired behavior after PR is merged: Only prevent deleting audit trail attachments, when audit trail setting is active. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr https://github.com/odoo/odoo/pull/207024 Forwa
Original PR description
Description of the issue/feature this PR addresses: The audit trail error is displayed eventhough the audit_trail is disabled for the company. Current behavior before PR: Attachments cannot be deleted with deactivated audit trail feature. Desired behavior after PR is merged: Only prevent deleting audit trail attachments, when audit trail setting is active. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr https://github.com/odoo/odoo/pull/207024 Forward-Port-Of: odoo/odoo#209024
Before this commit, mapping over `suggestedPartners['res.partner']` without checking caused runtime errors when the RPC returned no data. removed the mapping step and adding data to store as returned by server task-[4737958](https://www.odoo.com/odoo/project/1519/tasks/4737958) Forward-Port-Of: odoo/odoo#207743
Original PR description
Before this commit, mapping over `suggestedPartners['res.partner']` without checking caused runtime errors when the RPC returned no data. removed the mapping step and adding data to store as returned by server task-[4737958](https://www.odoo.com/odoo/project/1519/tasks/4737958) Forward-Port-Of: odoo/odoo#207743
Before this patch, it was impossible to resequence vendor bills if already sent to SII/tbai. However, it is required to be able to resequence them, and the move name isn't sent anymore since https://github.com/odoo/odoo/pull/195113 was merged. Thus, here I'm lifting that constraint to allow accountants do the resequencing. @moduon MT-8728 OPW-4567144 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209305 Forward-
Original PR description
Before this patch, it was impossible to resequence vendor bills if already sent to SII/tbai. However, it is required to be able to resequence them, and the move name isn't sent anymore since https://github.com/odoo/odoo/pull/195113 was merged. Thus, here I'm lifting that constraint to allow accountants do the resequencing. @moduon MT-8728 OPW-4567144 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209305 Forward-Port-Of: odoo/odoo#197284
Do not use t-out/t-esc to build human-readable content. This is basically the same as string concatenation. This commit wraps the entire string in a gettext call to prevent it from being split into several non-reorderable translations. As a lucky side effect, it also creates a separate translation for the word "table" (as in restaurant tables) which won't overlap with the translation for spreadsheet tables. opw-4754410 Forward-Port-Of: odoo/odoo#210841
Original PR description
Do not use t-out/t-esc to build human-readable content. This is basically the same as string concatenation. This commit wraps the entire string in a gettext call to prevent it from being split into several non-reorderable translations. As a lucky side effect, it also creates a separate translation for the word "table" (as in restaurant tables) which won't overlap with the translation for spreadsheet tables. opw-4754410 Forward-Port-Of: odoo/odoo#210841
Adding CLA Forward-Port-Of: odoo/odoo#210640 Forward-Port-Of: odoo/odoo#161944
Original PR description
Adding CLA Forward-Port-Of: odoo/odoo#210640 Forward-Port-Of: odoo/odoo#161944
Before this commit: - 'In Progress' payment states were shown with a green tag, which could misleadingly suggest that the payment process was complete. - 'Paid' payment states were shown with a grey tag, implying that some action might still be pending. After this commit: - 'In Progress' tags are now orange, signaling that further actions (such as batching or reconciliation) are still required. - 'Paid' tags are now green, indicating that the process is fully complete and no further user
Original PR description
Before this commit: - 'In Progress' payment states were shown with a green tag, which could misleadingly suggest that the payment process was complete. - 'Paid' payment states were shown with a grey tag, implying that some action might still be pending. After this commit: - 'In Progress' tags are now orange, signaling that further actions (such as batching or reconciliation) are still required. - 'Paid' tags are now green, indicating that the process is fully complete and no further user action is needed. Task Id: 4797098 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210071
**Current behaviour before PR:** Steps to reproduce: - Select a text, open color selector. - Switch to custom tab. - Apply any custom color. - Switch to any other tab without closing color selector. - Switch back to the custom color tab. - Selected default color in colorpicker is old one rather than applied one. **Desired behaviour after PR is merged:** Applied custom color should be selected by default when switching back to custom tab. task-4737027 --- I confirm I hav
Original PR description
**Current behaviour before PR:** Steps to reproduce: - Select a text, open color selector. - Switch to custom tab. - Apply any custom color. - Switch to any other tab without closing color selector. - Switch back to the custom color tab. - Selected default color in colorpicker is old one rather than applied one. **Desired behaviour after PR is merged:** Applied custom color should be selected by default when switching back to custom tab. task-4737027 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208963
When generating the self-invoice XML, the system incorrectly uses the invoice_date field, which reflects the supplier’s invoice date. However, for self-invoices in Italy, the date field (i.e., the accounting date) should be used instead. According to Italian regulations, self-invoices must be issued within 15 days of the transaction, and the invoice date must fall within the month the invoice is received. Using the supplier’s invoice date (e.g., April 2025) when the invoice is actually receiv
Original PR description
When generating the self-invoice XML, the system incorrectly uses the invoice_date field, which reflects the supplier’s invoice date. However, for self-invoices in Italy, the date field (i.e., the accounting date) should be used instead. According to Italian regulations, self-invoices must be issued within 15 days of the transaction, and the invoice date must fall within the month the invoice is received. Using the supplier’s invoice date (e.g., April 2025) when the invoice is actually received in May 2025 results in non-compliance. References Official: https://www.agenziaentrate.gov.it/portale/documents/20143/451259/Guida_compilazione-FE-Esterometro-V_1.9_2024-03-05.pdf/67fe4c2d-1174-e8de-f1ee-cea77b7f5203 , page 14 Extra: https://www.fiscoetasse.com/approfondimenti/16247-reverse-charge-interno-e-reverse-charge-esterno.html , entry 5  Forward-Port-Of: odoo/odoo#210342
Steps to Reproduce : - Drag and drop text snippet / or select some text. - Apply the back-ground color to the text. - Click on the Animate button. - You will notice that the background got removed/misplaced. The issue was caused because the animated text is wrapped in an element with "display: inline-block". To fix the bug, we moved the element with the background color inside the wrapper of the animated text, instead of keeping it outside. This fix works as long as the animated text
Original PR description
Steps to Reproduce : - Drag and drop text snippet / or select some text. - Apply the back-ground color to the text. - Click on the Animate button. - You will notice that the background got removed/misplaced. The issue was caused because the animated text is wrapped in an element with "display: inline-block". To fix the bug, we moved the element with the background color inside the wrapper of the animated text, instead of keeping it outside. This fix works as long as the animated text is exactly the same as the one with the background color. If only a portion of the text with a background color is animated, the fix doesn’t work. That case was too complex to handle, and in any case, the most common user scenarios are now fixed. task-4690318 Forward-Port-Of: odoo/odoo#210953 Forward-Port-Of: odoo/odoo#206240
This is a continuation of [this fix](https://github.com/odoo/odoo/commit/291518a7e7708690d183b9d1ca53c84d0c56ad90) following a feedback on its working state. --- Description of the issue this commit addresses: On purchase orders, it was decided that sections and notes would still be editable after the order has been confirmed so it would seem logic to be able to delete them too but at the moment, doing so raises an error. --- Desired behavior after this commit is merged: It is
Original PR description
This is a continuation of [this fix](https://github.com/odoo/odoo/commit/291518a7e7708690d183b9d1ca53c84d0c56ad90) following a feedback on its working state. --- Description of the issue this commit addresses: On purchase orders, it was decided that sections and notes would still be editable after the order has been confirmed so it would seem logic to be able to delete them too but at the moment, doing so raises an error. --- Desired behavior after this commit is merged: It is possible to delete a section or note line on a confirmed purchase order. --- opw-4744367 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210760
- Fixes the error coming from using discounts in invoices: the node `AllowanceChargeReasonCode` was added while not accepted by the Turkish implementation, and the amounts might not respect the asked format in some cases. - Fixes the error coming from invoices using a different currency than the company one (TRY). Although the documentation says the node `PricingExchangeRate` is only needed "If the prices of goods or services on the invoice are shown in a currency other than the 'Docum
Original PR description
- Fixes the error coming from using discounts in invoices: the node `AllowanceChargeReasonCode` was added while not accepted by the Turkish implementation, and the amounts might not respect the asked format in some cases. - Fixes the error coming from invoices using a different currency than the company one (TRY). Although the documentation says the node `PricingExchangeRate` is only needed "If the prices of goods or services on the invoice are shown in a currency other than the 'Document Currency", and our file did indeed use only one currency at a time (either all TRY or all USD amounts, e.g.), the server was still refusing our file. - Limits the decimal precision to 2 for most amoutns, as requested by the nilvera format. - Use uppercase on invoice names when putting them in the xml. task-4356940 Forward-Port-Of: odoo/odoo#210622 Forward-Port-Of: odoo/odoo#205749
The usecase occurs in x2many lists in form views. The total width of the table's parent div may change, for instance if a scrollbar appears on the sheet at some point. When this happens, the widths must be recomputed, to properly fit with the new available space. Before this commit, we only listened to window resize, not to the parent div itself. This could lead to an horizontal scrollbar being sometimes displayed, for instance: - with the chatter below the form view, as it is loaded asynch
Original PR description
The usecase occurs in x2many lists in form views. The total width of the table's parent div may change, for instance if a scrollbar appears on the sheet at some point. When this happens, the widths…
The usecase occurs in x2many lists in form views. The total width of the table's parent div may change, for instance if a scrollbar appears on the sheet at some point. When this happens, the widths must be recomputed, to properly fit with the new available space. Before this commit, we only listened to window resize, not to the parent div itself. This could lead to an horizontal scrollbar being sometimes displayed, for instance: - with the chatter below the form view, as it is loaded asynchronously, when it contains messages such that there's no (vertical) scrollbar before it is loaded, and there's one after. - with the document previewer, as its width changes when it is loaded. This commit fixes the issue by using a resize observer to listen to the parent div directly, instead of on a window, which is more accurate. Bug reported by our cto 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#210798 Forward-Port-Of: odoo/odoo#210366
After commit https://github.com/odoo/odoo/commit/692992a25dc8f583ef70517088ec963a8d30802b, updates to existing records in indexedDB were not properly saved due to incorrect logic. As a result, changes to records were not persisted in the local database. This commit corrects the update logic to ensure that modifications to existing records are correctly saved in indexedDB. opw-4802025 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-
Original PR description
After commit https://github.com/odoo/odoo/commit/692992a25dc8f583ef70517088ec963a8d30802b, updates to existing records in indexedDB were not properly saved due to incorrect logic. As a result, changes to records were not persisted in the local database. This commit corrects the update logic to ensure that modifications to existing records are correctly saved in indexedDB. opw-4802025 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210542
<b>Steps to reproduce:</b> 1. Go to Sales > Create a Quotation 2. Add Customer > Set Customer's lang to French or German 3. Add a product, confirm the quotation 4. Click "Create Invoice" > Select "Down Payment (percentage)" 5. Set amount (e.g., 20.5%) and create the invoice <b>Issue:</b> - When creating a down payment invoice using the "percentage" option, description text is translated correctly to partner's language (e.g., French or German), but amount in description remains f
Original PR description
<b>Steps to reproduce:</b> 1. Go to Sales > Create a Quotation 2. Add Customer > Set Customer's lang to French or German 3. Add a product, confirm the quotation 4. Click "Create Invoice" > Select "Down Payment (percentage)" 5. Set amount (e.g., 20.5%) and create the invoice <b>Issue:</b> - When creating a down payment invoice using the "percentage" option, description text is translated correctly to partner's language (e.g., French or German), but amount in description remains formatted using English conventions (e.g. "20.5%" instead of "20,5 %" in French or German). <b>Cause:</b> - This happens because the amount is inserted as a raw float without localization. <b>Solution:</b> - This fix uses `formatLang()` with the correct context to format the percentage amount according to the partner's language (i.e., proper decimal separator). <b>opw-4743326</b> Forward-Port-Of: odoo/odoo#210927 Forward-Port-Of: odoo/odoo#210570
This **PR** introduces manual input for lines 01, 04, 10, and 25 in the mod.111 report. The previous automatic calculation based on tax tags was unreliable and could produce inaccurate values, so manual entry ensures the data correctly reflects actual figures. **task**-4797773 Forward-Port-Of: odoo/odoo#210279
Original PR description
This **PR** introduces manual input for lines 01, 04, 10, and 25 in the mod.111 report. The previous automatic calculation based on tax tags was unreliable and could produce inaccurate values, so manual entry ensures the data correctly reflects actual figures. **task**-4797773 Forward-Port-Of: odoo/odoo#210279
Currently because of the changes in ca35adf7412b132e37c22d09 both the test `test_increase_available_quantity_3` and `test_decrease_available_quantity_3` are always skipped, even with demo data. That's because `self.stock_location` points to a new location created in `setUpClass`. So no demo data quant can have this location_id as it cannot be referenced from a demo data file. However, "stock.stock_location_stock" is actually created in a data file, `stock_data.xml`. So we can revert back to u
Original PR description
Currently because of the changes in ca35adf7412b132e37c22d09 both the test `test_increase_available_quantity_3` and `test_decrease_available_quantity_3` are always skipped, even with demo data. That's because `self.stock_location` points to a new location created in `setUpClass`. So no demo data quant can have this location_id as it cannot be referenced from a demo data file. However, "stock.stock_location_stock" is actually created in a data file, `stock_data.xml`. So we can revert back to using `env.ref` instead of creating a new location. With that both tests are properly executed when demo data are installed while they are skipped without demo data. We're also creating the quants in case they are not found in the database so we ensure the test is always run. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204682
This PR removes the `onchange` logic previously used to auto-set the l10n_in_gst_treatment field based on company_type and country_id. The GST Treatment is now set dynamically by the PartnerAutoComplete service. If a user manually creates a partner (without using autocomplete), they will need to select the GST Treatment manually. Related IAP-https://github.com/odoo/iap-apps/pull/1051 Forward-Port-Of: odoo/odoo#205714
Original PR description
This PR removes the `onchange` logic previously used to auto-set the l10n_in_gst_treatment field based on company_type and country_id. The GST Treatment is now set dynamically by the PartnerAutoComplete service. If a user manually creates a partner (without using autocomplete), they will need to select the GST Treatment manually. Related IAP-https://github.com/odoo/iap-apps/pull/1051 Forward-Port-Of: odoo/odoo#205714
This is used in the event a request is timing out or has an out of memory issue. This would cause the profile to be committed to the database before the request gets terminated. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205155 Forward-Port-Of: odoo/odoo#204673
Original PR description
This is used in the event a request is timing out or has an out of memory issue. This would cause the profile to be committed to the database before the request gets terminated. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205155 Forward-Port-Of: odoo/odoo#204673
*Behavior before this PR* When sending an Invoice to MyInvois, tracebacks could be raised if the `party_identification_vals` dictionary held values other than `id_attrs`. This was the case for the Customer Reference (`ref`), added in PR #206655 *Behavior after this PR* Invoices can be properly submitted to MyInvois, even with Customer References. opw-4807559 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210768
Original PR description
*Behavior before this PR* When sending an Invoice to MyInvois, tracebacks could be raised if the `party_identification_vals` dictionary held values other than `id_attrs`. This was the case for the Customer Reference (`ref`), added in PR #206655 *Behavior after this PR* Invoices can be properly submitted to MyInvois, even with Customer References. opw-4807559 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210768
In the kanban template there is a `row` container that is not wrapped into a `container` DIV, so it has negative margin and produce an overflow (horizontal scroll). This commit adds the `g-0` class on the `row` container. Steps to reproduce: * On Odoo on small screen * Go to the app "eLearning" * Try to scroll horizontally => BUG --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210825
Original PR description
In the kanban template there is a `row` container that is not wrapped into a `container` DIV, so it has negative margin and produce an overflow (horizontal scroll). This commit adds the `g-0` class on the `row` container. Steps to reproduce: * On Odoo on small screen * Go to the app "eLearning" * Try to scroll horizontally => BUG --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210825
This commit fixes an issue with the Facebook app and the management of pages. For Facebook to identify the user as able to manage a page, we need to provide another permission to the scope. The permission `business_management` is needed for the API to understand that the user is able to manage its pages. Thus we are adding it to the scope but as an optional permission. Some users may not have this permission set up for their own applications, thus we are adding the system parameter `social.
Original PR description
This commit fixes an issue with the Facebook app and the management of pages. For Facebook to identify the user as able to manage a page, we need to provide another permission to the scope. The permission `business_management` is needed for the API to understand that the user is able to manage its pages. Thus we are adding it to the scope but as an optional permission. Some users may not have this permission set up for their own applications, thus we are adding the system parameter `social.facebook_no_business_management`. This parameter blocks the addition of the permission to the scope if set to any value, if not set it adds the permission to the scope. task-4719790 Forward-Port-Of: odoo/enterprise#84032
Description ----------- Installing the `helpdesk_timesheet` module on databases with millions of `account.analytic.lines` would reach the default memory limit of 2 GiB due to excessive ORM caching. The main memory consumption came from `_check_no_link_task_and_ticket` and `_compute_helpdesk_ticket_id` methods loading large amounts of records into the ORM cache. This commit adds manual column initialization and optimizes constraints to reduce ORM cache memory usage. Reference ------
Original PR description
Description ----------- Installing the `helpdesk_timesheet` module on databases with millions of `account.analytic.lines` would reach the default memory limit of 2 GiB due to excessive ORM caching. The main memory consumption came from `_check_no_link_task_and_ticket` and `_compute_helpdesk_ticket_id` methods loading large amounts of records into the ORM cache. This commit adds manual column initialization and optimizes constraints to reduce ORM cache memory usage. Reference --------- opw-4743742 Forward-Port-Of: odoo/enterprise#86099 Forward-Port-Of: odoo/enterprise#85974
Steps to reproduce: - Install Stock and Field Service apps. - Create a product that tracks inventory by lot. - Add some on-hand quantity with a created lot. - In Field Service, create a task with `under_warranty` checked. - Add the created product to the task. Issue: - A sale order is generated with order lines at the product's price. - The price should be 0 since the customer should not be charged. Fix: - Ensure the sale order line price is set to 0 when `under_warranty` is checke
Original PR description
Steps to reproduce: - Install Stock and Field Service apps. - Create a product that tracks inventory by lot. - Add some on-hand quantity with a created lot. - In Field Service, create a task with `under_warranty` checked. - Add the created product to the task. Issue: - A sale order is generated with order lines at the product's price. - The price should be 0 since the customer should not be charged. Fix: - Ensure the sale order line price is set to 0 when `under_warranty` is checked in the _generate_lot() which is called on adding product tracked by lot. opw-4648542 opw-4646960 Forward-Port-Of: odoo/enterprise#85867 Forward-Port-Of: odoo/enterprise#82341
pain.001.001.09 is a newer version of the ISO20022 format. Before this commit, we only supported it for SEPA Credit Transfer, using the same selection field as the one allowing to choose national variants of SEPA. This fix only intends to solve the issue for existing customers by using a system parameter that needs to be switched from "False" to "True". A cleaner solution will come in the future, after a refactoring of the payment methods. task-4647016 Forward-Port-Of: odoo/enterprise#85597
Original PR description
pain.001.001.09 is a newer version of the ISO20022 format. Before this commit, we only supported it for SEPA Credit Transfer, using the same selection field as the one allowing to choose national variants of SEPA. This fix only intends to solve the issue for existing customers by using a system parameter that needs to be switched from "False" to "True". A cleaner solution will come in the future, after a refactoring of the payment methods. task-4647016 Forward-Port-Of: odoo/enterprise#85597
Summary ----- When you generate an entry via the deferred revenue report, if the original journal item has an analytic distribution at x%, then the lines of the deferred entries have an analytic distribution at -x%. Steps to reproduce ----- 1. In Accounting > Settings, enable the analytic accounting and set the "Generate Revenue Entries" as "Manually & Grouped". 2. Create an invoice with an analytic distribution, a start date and an end date. 3. Generate an entry with the deferred reven
Original PR description
Summary ----- When you generate an entry via the deferred revenue report, if the original journal item has an analytic distribution at x%, then the lines of the deferred entries have an analytic distribution at -x%. Steps to reproduce ----- 1. In Accounting > Settings, enable the analytic accounting and set the "Generate Revenue Entries" as "Manually & Grouped". 2. Create an invoice with an analytic distribution, a start date and an end date. 3. Generate an entry with the deferred revenue report by selecting a period including the created invoice. 4. Observe the negative analytic distribution in the generated entries. opw-4502556 Forward-Port-Of: odoo/enterprise#85039 Forward-Port-Of: odoo/enterprise#82594
**Steps to reproduce:** With mexican localisation installed: - Open form view for the model 'l10n_mx_edi.document' - Prepare a payment document in the Payment-20 format (https://www.sat.gob.mx/sitio_internet/cfd/Pagos/Pagos20.xsd) - Remove existing attachment - Change the attachment on the document to the relatively long XML file **Issue:** After saving the change, the attachment_uuid (Fiscal Folio) is left blank. **Cause:** Normally, the uuid should be extracted from the uploaded a
Original PR description
**Steps to reproduce:** With mexican localisation installed: - Open form view for the model 'l10n_mx_edi.document' - Prepare a payment document in the Payment-20 format…
**Steps to reproduce:** With mexican localisation installed: - Open form view for the model 'l10n_mx_edi.document' - Prepare a payment document in the Payment-20 format (https://www.sat.gob.mx/sitio_internet/cfd/Pagos/Pagos20.xsd) - Remove existing attachment - Change the attachment on the document to the relatively long XML file **Issue:** After saving the change, the attachment_uuid (Fiscal Folio) is left blank. **Cause:** Normally, the uuid should be extracted from the uploaded attachment, but the computation of the 'raw' field on the attachment returns the value "b'56.00 bytes'", leaving the attachment_uuid field empty because the XML is assumed to be in the wrong format. The issue doesn't exist for shorter XML files in the Payment-10 format (https://www.sat.gob.mx/sitio_internet/cfd/Pagos/Pagos10.xsd) **Solution:** Before computing the attachment_uuid from the attachment, we set the bin_size to False in the context. opw-4641487 Forward-Port-Of: odoo/enterprise#83538
Currently, entering only spaces in the Full Name field when signing in auto mode enables the sign button, allowing users to proceed without a valid name. Steps to reproduce: 1. Sign > Create a request 2. Attempt to sign in auto mode with only spaces in the Full Name field 3. Observe that the sign button becomes enabled Cause: The system does not checks for whitespace-only name Solution: Add a validation to disable the sign button if the trimmed name is empty in auto mode. opw-462
Original PR description
Currently, entering only spaces in the Full Name field when signing in auto mode enables the sign button, allowing users to proceed without a valid name. Steps to reproduce: 1. Sign > Create a request 2. Attempt to sign in auto mode with only spaces in the Full Name field 3. Observe that the sign button becomes enabled Cause: The system does not checks for whitespace-only name Solution: Add a validation to disable the sign button if the trimmed name is empty in auto mode. opw-4628577 Forward-Port-Of: odoo/enterprise#85860 Forward-Port-Of: odoo/enterprise#84613
If the subject serial number is not set in the certificate and the user clicks the ``Send now to SII`` button on the invoice, a traceback will appear. Steps to reproduce the error: - Install ``l10n_cl_edi`` module and switch to CL company - Go to Invoicing > Configuration > Settings > SII Web Services: SII - Test - Create a new invoice > customer: CL company > add a line > Confirm > ``Send now to SII`` Traceback: ``` TypeError: 'bool' object is not subscriptable ``` https://git
Original PR description
If the subject serial number is not set in the certificate and the user clicks the ``Send now to SII`` button on the invoice, a traceback will appear. Steps to reproduce the error: - Install ``l10n_cl_edi`` module and switch to CL company - Go to Invoicing > Configuration > Settings > SII Web Services: SII - Test - Create a new invoice > customer: CL company > add a line > Confirm > ``Send now to SII`` Traceback: ``` TypeError: 'bool' object is not subscriptable ``` https://github.com/odoo/enterprise/blob/7acf9b1f0cdd5c0968188ac6c2351ae9ab228689/l10n_cl_edi/models/account_move.py#L290 Here, If ``subject_serial_number`` of certificate is False. It will lead to the above traceback. ``subject_serial_number`` can be False because Some certificates do not provide this number. ref-https://github.com/odoo/enterprise/blob/7acf9b1f0cdd5c0968188ac6c2351ae9ab228689/l10n_cl_edi/models/certificate.py#L19-L20 sentry-6591311577 Forward-Port-Of: odoo/enterprise#84980