Daily updates from Odoo
Thursday, May 14, 2026
71 changes
17 changes
Resolved issues and error corrections
This update corrects a discrepancy in how ARCA-related invoices (document types 51-59) are displayed. The change ensures the documents align with current ARCA regulations and avoids potential issues with tax reporting. This update maintains backward compatibility with existing ARCA validations.
Original PR description
**Context:** * ARCA (formerly AFIP) has deprecated the "Documentos M" classification for document types with codes 51-59. * These are now classified as "Documentos A con leyenda 'Operación sujeta a…
**Context:** * ARCA (formerly AFIP) has deprecated the "Documentos M" classification for document types with codes 51-59. * These are now classified as "Documentos A con leyenda 'Operación sujeta a retención'" while retaining the same codes for backward compatibility with ARCA validations. **Steps to Reproduce:** * Install `l10n_ar` module. * Go to `Accounting -> Configuration -> Document types`. **Observed behavior:** * Document types 51-59 still display letter "M" and use the old naming convention (e.g. "INVOICES M", "DEBIT MEMOS M"), which no longer reflects the current ARCA classification. **Fix:** * Updated `name` fields to include the "WITH LEGEND" / "CON LEYENDA" suffix. * Changed `l10n_ar_letter` from "M" to "A" so the PDF header renders an "A". * Changed `doc_code_prefix` from `*-M` to `*-A` (FA-A, ND-A, NC-A, RE-A). * The existing `res.config.settings` option for injecting the PDF legend remains untouched. Sources: - ARCA: https://www.afip.gob.ar/facturacion/regimen-general/comprobantes.asp Ref: https://www.odoo.com/mail/message/1025488740 opw-5953504 Forward-Port-Of: odoo/odoo#254975
This update resolves an issue where reports would fail when the fiscal year ended on February 29th. The fix ensures that the system correctly handles leap year fiscal years, defaulting to March 1st for calculations. This prevents reporting errors and ensures accurate financial data.
Original PR description
**Steps to Reproduce:** 1. Install the Accounting module. 2. Go to Settings and set the fiscal year's last day to 29 February. 3. Accounting > Reporting > open any report. **Error:** `ValueError - day is out of range for month` **Cause:** At [1], a fixed year (2025) is used to compute the fiscal year end. However, 2025 is not a leap year, so creating a date with February 29 raises an error. **Fix:** Ensure that when the fiscal year’s last day is Feb 29, a leap year (2024) is used for the computation. For all other dates, the year remains unchanged (2025). As a result; - If the last day is February **28** (non-leap year) -> `fy_start` becomes **March 1** - If the last day is February **29** (leap year) -> `fy_start` also becomes **March 1** [1] - https://github.com/odoo/enterprise/blob/4fa1c0c13308bd8de06646543391f8cbcf28d05e/account_reports/models/account_report.py#L820 sentry-7438598965 Forward-Port-Of: odoo/enterprise#115400
This update resolves an issue that prevented users from creating quality checks when a product wasn't specified during the quality point setup. The fix ensures that the system handles missing product information gracefully, preventing a ValueError and allowing quality checks to be created successfully. This improves the reliability of the quality control process.
Original PR description
When creating a quality check from a quality point, a traceback occurs if no product is set. Steps to reproduce the error: - Install ``quality_control`` module with demo data - Go to Quality > Quality Control > Control Points > Create a new Control point > Set Control per: Quantity, Partial Test: 99 > Save - Click on Quality Checks smart button > Click on New Traceback: ```py ValueError: Expected singleton: uom.uom() ``` https://github.com/odoo/enterprise/blob/4fa1c0c13308bd8de06646543391f8cbcf28d05e/quality_control/models/quality.py#L369 During creation of a quality check, ``product_id`` is not set. The compute method ``_compute_qty_to_test`` accesses ``product_id.uom_id``, which leads to the above traceback. sentry-7440188763 Forward-Port-Of: odoo/enterprise#115292
This update resolves an issue that occurred when installing the Saudi Arabia EDI module, specifically during demo data setup. The problem arose from deleting demo invoices, which triggered an error when the system attempted to update records. The fix ensures the system handles missing records gracefully, preventing the error and allowing users to successfully install and utilize the module.
Original PR description
Currently, error occurs when user tries to install Saudi Arabia EDI module. Steps to replicate: - Install `l10n_sa` with demo and switch to SA company. - Open Invoices > `INV/2026/00001` > Reset to…
Currently, error occurs when user tries to install Saudi Arabia EDI module.
Steps to replicate:
- Install `l10n_sa` with demo and switch to SA company.
- Open Invoices > `INV/2026/00001` > Reset to draft > Delete.
- Open Invoices > `INV/2026/00002` > Reset to draft > Delete.
- Install `l10n_sa_edi`.
Error:
```
File '/home/odoo/src/odoo/saas-19.2/addons/l10n_sa_edi/demo/account_demo.py', line 16, in _l10n_sa_edi_onboard_sa_sale_demo
self.ref('demo_sa_invoice_1', raise_if_not_found=False)
TypeError: unsupported operand type(s) for +: 'NoneType' and 'NoneType'
```
Cause:
- As the user deleted `INV/2026/00001` (linked to `demo_sa_invoice_1`) and `INV/2026/00002` (linked to `demo_sa_invoice_2`), [here] when we try to create a recordlist to update we get this error.
Solution:
- Avoided direct concatenation of `self.ref(...)`, which may return None.
- Iterated over the expected IDs, fetched records safely, and skipped missing ones before processing.
[here]: https://github.com/odoo/odoo/blob/b8bcaa6af2531f49654d804231942b6af2261933/addons/l10n_sa_edi/demo/account_demo.py#L15-L20
sentry-7458234787
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#262666A technical issue preventing background video previews was resolved. The commit removed a broken Vimeo video link from the system, preventing error messages when users selected background videos. This ensures a smoother experience for website builders.
Original PR description
Steps to reproduce: 1. Drop any snippet. 2. Click on the background video option. 3. Observe Traceback. The Vimeo video with ID `499761556` is no longer available, causing a traceback when opening the background video options. This commit removes the unavailable video from the preview list. task-6088772 Forward-Port-Of: odoo/odoo#264080 Forward-Port-Of: odoo/odoo#263555
This update fixes a minor discrepancy in the Norwegian tax settings. The tax rate for code 32 was incorrectly set to 11.0. This change ensures accurate tax calculations for Norwegian businesses using Odoo, aligning with official tax regulations. This was coordinated with a related Enterprise PR.
Original PR description
The tax rate(`amount`) for code 32 was mistakenly set to '11.0'. To properly align with the official Norwegian tax rates, it needs to be updated to '11.11'. Related Enterprise PR: https://github.com/odoo/enterprise/pull/110792 task-6033027 Forward-Port-Of: odoo/odoo#264221 Forward-Port-Of: odoo/odoo#258390
This update resolves an issue where Ctrl+A selection in the HTML editor would crash when used with images that had captions. The fix ensures the selection correctly targets the editable content, regardless of whether it's an image or a caption, improving the user experience and preventing unexpected errors.
Original PR description
#### Description of the issue this PR addresses: - When an image with caption is selected, it is wrapped in a `<figure>`, making `<figure>` the anchor node - `selectAll` was resolving the container using `[contenteditable]`, which keeps `<figure>` as the container even though it is `contenteditable=false` - This leads to `<figure>` being passed to `getDeepestEditablePosition`, which cannot resolve a valid `nodeLevelAncestor` and returns null, causing a traceback #### Desired behavior after PR is merged: - `selectAll` now targets the nearest `contenteditable=true` ancestor instead of any `[contenteditable]` #### Steps to reproduce: - Add image and enable caption - Select the image - Press Ctrl+A task-6174371 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261968
This update fixes a limitation in how attachments are uploaded through cron jobs. Previously, a single cron job was restricted to uploading only one attachment at a time. Now, the system allows multiple attachments to be uploaded within a single cron job run, improving efficiency for automated uploads.
Original PR description
make the `limit_time_real > 0` when --limit-time-real-cron=0 --limit-time-real=0 to allow multiple attachments to be uploaded in a single cron job. 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#264328
The 'Waiting for Me' filter in the Sign app was incorrectly fetching all documents instead of filtering those requiring the current user's signature. This update corrects a technical issue related to how the system processes filter criteria, ensuring the filter functions as intended and displays only relevant documents.
Original PR description
When applying the 'Waiting for me' filter in the Sign app, all documents are fetched instead of filtering out documents that do not need the current user's signature. Steps to reproduce: 1) Install…
When applying the 'Waiting for me' filter in the Sign app, all documents are fetched instead of filtering out documents that do not need the current user's signature.
Steps to reproduce:
1) Install sign with demo data
2) Open sign app and remove default filter
3) Add a filter Waiting for me
Observed Behavior:
All the documents are fetched.
Expected Behavior:
Documents should be filtered out to only show those where the current user is a signer.
Root Cause:
Since [commit](https://github.com/odoo/enterprise/pull/76079/changes/8b5048f63f91a38a710b611d17f5cf27fbd0a18a), The `_search_need_my_signature` method returned `NotImplemented` for any operator other than `in` at [1]. While the filter uses `=` at [2]. Following a recent ORM optimization with the mentioned commit, the operators are now standardized as shown
From:
`('need_my_signature', '=', True)]`
To:
`[('need_my_signature', 'in', [True])]`
This means the search method now receives the expected `in` operator. However, the return logic uses a `not in` condition when filtering documents waiting for signature.
As a result, instead of filtering documents, all documents are returned.
[1]- https://github.com/odoo/enterprise/blob/012b42c20b48e8e36298875e3291936e68e72375/sign/models/sign_request.py#L107-L108
[2]- https://github.com/odoo/enterprise/blob/012b42c20b48e8e36298875e3291936e68e72375/sign/views/sign_request_views.xml#L177
Fix:
Corrected the return domain logic to fetch the correct documents.
opw-6026935
Forward-Port-Of: odoo/enterprise#117049
Forward-Port-Of: odoo/enterprise#113760This update fixes a potential issue where users could accidentally assign multiple POS shops to a single cash payment method. Now, the system will prevent this, ensuring accurate payment tracking and avoiding errors when processing transactions. This improves data integrity and simplifies the payment process.
Original PR description
**Before this commit** The user will be able to assign two different POS shop to a cash payment method by going to POS -> Configuration -> Payment Methods -> Cash -> Point of sale, this will not raise a validation error when they try to save it but it will prevent the user from opening the POS session. **After this commit** It will raise a validation error if a user tries to assign more than one POS shop to one cash payment method and save it. opw-6015025 Forward-Port-Of: odoo/odoo#252603
This update resolves an issue where users could create attachments that pointed back to themselves, leading to errors. The fix prevents attachments from being linked to themselves in the user interface and during data writing, ensuring data integrity and preventing system crashes. This improves stability and reliability.
Original PR description
Currently, users have the option to attach an ir.attachment to itself. This causes a recursion depth error when accessing attachments. This commit prevents this in the UI and the write. Firstly, the ir.attachment does not show itself in the dropdown when selecting the resource ID. Second, the write raises a UserError if attempting to write an ir.attachment with the same ID as the Resource ID. Steps to reproduce: 1. Create an attachment and save 2. Set the Resource Model `(res.model)` to "ir.attachment" 3. Select the same attachment in Resource ID `(res_id)` 4. Attempt to view attachments: `RecursionError: maximum recursion depth exceeded` opw-6206075 closes #263591 Forward-Port-Of: odoo/odoo#264439 Forward-Port-Of: odoo/odoo#263591
A test within the l10n_latam_check module failed due to a dependency on the l10n_ar module not being installed. This update ensures the test runs correctly by requiring l10n_ar to be present, resolving a technical error.
Original PR description
Steps to reproduce: 1- Install l10n_latam_check on a fresh database instance 2- Run the test `test_invoice_status_after_voided_check` Issue: `ValueError: External ID not found in the system: l10n_ar.dc_liq_uci_a` Why this happens: The test used a document type from the l10n_ar module, so running the test without it being installed caused an error. runbot-243341 Forward-Port-Of: odoo/odoo#262800
This update corrects inaccuracies in the French Chart of Accounts translations within the Odoo accounting module. The fix ensures that financial reports and data displayed in French adhere to the correct accounting standards, improving accuracy and compliance.
Original PR description
task-6210436
This update resolves an issue where dragging calendar events on touch screens would cause the application to crash. Now, dragging and releasing events works smoothly on both touch and mouse devices, improving the user experience for all calendar users.
Original PR description
When using the Calendar app on a touch screen, dragging an event and releasing it would raise a client error. Releasing a dragged event now works smoothly on both mouse and touch devices. task-6124833 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#263361
This update fixes a previous issue where the closing popup for bank payments didn't accurately display the number of payments made. Now, the popup correctly shows the total count of payments associated with a bank method, reducing user confusion and improving the clarity of payment information. This enhancement ensures users have a complete understanding of their transactions.
Original PR description
Before this commit, in the closing popup if a bank payment method had more than one payment, it would not show the count of payments, which could lead to confusion for the user. opw-6198656 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263234
This update fixes an issue where large tablets with touch capabilities incorrectly displayed the mobile toolbar instead of the desktop toolbar. The change now considers screen size, ensuring the correct toolbar is shown on all devices, improving the user experience for tablet users.
Original PR description
Problem: On large tablets with touch capability and high resolution, the mobile toolbar is displayed instead of the desktop toolbar. Cause: The mobile toolbar condition relied on touch capability alone, without considering screen size. Devices with large screens but touch support were therefore incorrectly treated as mobile. Solution: Use `utils.isSmall()` to determine whether the device should display the mobile toolbar, ensuring screen resolution is taken into account. Steps to reproduce: - Open the editor on a large tablet. - Observe that the mobile toolbar is shown. - The desktop toolbar should be displayed instead. task-6106531 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259605
This update resolves an issue where changing a heading tag within a selection didn't properly remove the original heading style. The fix utilizes a different function within the HTML editor to ensure heading styles are accurately reset when a tag is modified, improving the consistency of formatting.
Original PR description
Problem: When applying `h1` to part of a selection already inside an `h2`, the selected content still keeps the `class="h2"` style. Cause: `removeFormats` internally uses `formatSelection`, but in this case we only want to change the tag and not reformat the selection. This causes existing heading styles to remain applied. Solution: Use `removeFormat` instead, as it removes formatting without applying additional formatting to the selection. Steps to reproduce: - Go to Website and drop the "Text-Image" snippet. - Copy the text "Enhance Your Experience". - Paste the text into a new To-Do. - Select part of the pasted text. - Change it from "Header 2" to "Header 1 Display 1". - Observe that part of the text still keeps the "Header 2" style. task-6204505 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263810
17 changes
Resolved issues and error corrections
This update corrects a discrepancy in how ARCA-related documents are displayed in Odoo. The system has been updated to align with recent ARCA regulations, ensuring accurate reporting and compliance. The changes update document names and codes to reflect the new 'Operation subject to withholding' classification.
Original PR description
**Context:** * ARCA (formerly AFIP) has deprecated the "Documentos M" classification for document types with codes 51-59. * These are now classified as "Documentos A con leyenda 'Operación sujeta a…
**Context:** * ARCA (formerly AFIP) has deprecated the "Documentos M" classification for document types with codes 51-59. * These are now classified as "Documentos A con leyenda 'Operación sujeta a retención'" while retaining the same codes for backward compatibility with ARCA validations. **Steps to Reproduce:** * Install `l10n_ar` module. * Go to `Accounting -> Configuration -> Document types`. **Observed behavior:** * Document types 51-59 still display letter "M" and use the old naming convention (e.g. "INVOICES M", "DEBIT MEMOS M"), which no longer reflects the current ARCA classification. **Fix:** * Updated `name` fields to include the "WITH LEGEND" / "CON LEYENDA" suffix. * Changed `l10n_ar_letter` from "M" to "A" so the PDF header renders an "A". * Changed `doc_code_prefix` from `*-M` to `*-A` (FA-A, ND-A, NC-A, RE-A). * The existing `res.config.settings` option for injecting the PDF legend remains untouched. Sources: - ARCA: https://www.afip.gob.ar/facturacion/regimen-general/comprobantes.asp Ref: https://www.odoo.com/mail/message/1025488740 opw-5953504 Forward-Port-Of: odoo/odoo#254975
A technical issue preventing users from selecting a background video from Vimeo was resolved. This commit removed a broken video link from the preview options, ensuring a smooth user experience when setting background videos on the website. This improves the functionality of the website builder.
Original PR description
Steps to reproduce: 1. Drop any snippet. 2. Click on the background video option. 3. Observe Traceback. The Vimeo video with ID `499761556` is no longer available, causing a traceback when opening the background video options. This commit removes the unavailable video from the preview list. task-6088772 Forward-Port-Of: odoo/odoo#264080 Forward-Port-Of: odoo/odoo#263555
This update resolves an issue where changes made on a POS ticket screen weren't being reprinted correctly. The fix corrects the underlying logic to ensure all previous order modifications are accurately reflected when the 'reprint all changes' function is used. This improves the reliability of printed POS tickets.
Original PR description
Steps: ---------- - Install point_of_sale. - Open a POS session with a preparation printer configured. - Process an order with two different changes. - Open the ticket screen and try to reprint all previous changes. Issue: ---------- - No changes are printed. Cause: ---------- - Incorrect logic used when reprinting all changes. Fix: ---------- - Correct the logic to properly reprint all previous changes. Task-6008291
This update fixes a minor discrepancy in the Norwegian tax settings. The tax code 32's rate was incorrectly set to 11.0. This change ensures accurate tax calculations for Norwegian businesses using Odoo, aligning with official tax regulations. This was coordinated with a related Enterprise PR.
Original PR description
The tax rate(`amount`) for code 32 was mistakenly set to '11.0'. To properly align with the official Norwegian tax rates, it needs to be updated to '11.11'. Related Enterprise PR: https://github.com/odoo/enterprise/pull/110792 task-6033027 Forward-Port-Of: odoo/odoo#264221 Forward-Port-Of: odoo/odoo#258390
A technical issue causing a 'singleton' error when generating time off reports for employees was resolved. This fix ensures the 'By Employee' reporting feature under time off functionality works correctly, preventing disruptions to payroll and reporting processes. This update improves the reliability of the French company's time off reporting.
Original PR description
A singleton error appears when opening the "By Employee" report under Time Off. **Steps to reproduce:** - Install the l10n_fr_hr_holidays module. - Switch to the French company. - Open any employee record. - Set Working Hours (resource_calendar_id) to empty. - Set Hours Per Week. - Create a time off request for any past date. - Go to Reporting → By Employee. Task:-6043142 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
This update fixes a limitation in how Odoo handles attachments uploaded through its automated cron jobs. Previously, a single cron job was restricted to uploading only one attachment at a time. Now, the system allows multiple attachments to be uploaded within a single cron job run, improving efficiency and reducing the need for multiple uploads.
Original PR description
make the `limit_time_real > 0` when --limit-time-real-cron=0 --limit-time-real=0 to allow multiple attachments to be uploaded in a single cron job. 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#264328
This update resolves a test failure in the 'pos_self_order' module that occurred due to how order slots were being generated. The fix freezes the time to '00:00' to ensure all available slots are considered, preventing the test from failing on specific days. This ensures consistent test results and reliable order scheduling.
Original PR description
Before this commit: = - The test test_slot_limit_orders created slots only for the first day of the week (Monday). - The test scenario includes a slot at "18:00". - On Mondays, the test fails between 18:01 and 23:59 because the "18:00" slot no longer exists for the current day. - On other days, the test passes since slots are generated for the upcoming Monday. After this commit: = - Freezed the time to current day at "00:00" so that slot list can have every slot for that day. task-6043739 runbot-241836 Forward-Port-Of: odoo/odoo#263198 Forward-Port-Of: odoo/odoo#254775
This update fixes a potential issue where users could accidentally assign multiple POS shops to a single cash payment method. Now, the system prevents this, ensuring accurate payment tracking and avoiding errors when processing transactions. This change enhances the reliability of our point-of-sale system.
Original PR description
**Before this commit** The user will be able to assign two different POS shop to a cash payment method by going to POS -> Configuration -> Payment Methods -> Cash -> Point of sale, this will not raise a validation error when they try to save it but it will prevent the user from opening the POS session. **After this commit** It will raise a validation error if a user tries to assign more than one POS shop to one cash payment method and save it. opw-6015025 Forward-Port-Of: odoo/odoo#252603
This update resolves an issue where users could create attachments that repeatedly referenced themselves, leading to errors. The fix prevents attachments from being linked to themselves in the user interface and during data writing, ensuring data integrity and stability.
Original PR description
Currently, users have the option to attach an ir.attachment to itself. This causes a recursion depth error when accessing attachments. This commit prevents this in the UI and the write. Firstly, the ir.attachment does not show itself in the dropdown when selecting the resource ID. Second, the write raises a UserError if attempting to write an ir.attachment with the same ID as the Resource ID. Steps to reproduce: 1. Create an attachment and save 2. Set the Resource Model `(res.model)` to "ir.attachment" 3. Select the same attachment in Resource ID `(res_id)` 4. Attempt to view attachments: `RecursionError: maximum recursion depth exceeded` opw-6206075 closes #263591 Forward-Port-Of: odoo/odoo#264439 Forward-Port-Of: odoo/odoo#263591
A test within the l10n_latam_check module failed due to a dependency on the l10n_ar module not being installed. This update ensures the test runs correctly by requiring l10n_ar to be present during execution, preventing a runtime error.
Original PR description
Steps to reproduce: 1- Install l10n_latam_check on a fresh database instance 2- Run the test `test_invoice_status_after_voided_check` Issue: `ValueError: External ID not found in the system: l10n_ar.dc_liq_uci_a` Why this happens: The test used a document type from the l10n_ar module, so running the test without it being installed caused an error. runbot-243341 Forward-Port-Of: odoo/odoo#262800
This update resolves an issue where dragging and releasing calendar events on touch screens would cause a browser error. Now, dragging and releasing events works smoothly on both touch and mouse devices, improving the Calendar app's usability for all users.
Original PR description
When using the Calendar app on a touch screen, dragging an event and releasing it would raise a client error. Releasing a dragged event now works smoothly on both mouse and touch devices. task-6124833 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#263361
This update resolves a problem that occurred when creating consolidated POS invoices from multiple orders for the same customer. The previous issue caused errors due to how refund reasons were being handled across multiple orders. Now, the system safely collects and validates refund reason values, ensuring invoices are created correctly and preventing potential errors.
Original PR description
When creating a consolidated POS invoice from multiple orders for the same customer, `_prepare_invoice_vals` is called on a multi-record set. Accessing `self.l10n_es_tbai_refund_reason` directly on such a set raised a ValueError because `fields.Selection.__get__` internally calls `ensure_one()`. Use `mapped()` to safely collect all distinct refund reason values across the recordset. Raise a UserError if orders have conflicting values, consistent with the existing TicketBAI validation pattern for mixed required/non-required orders. opw-6192225 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262967
This update fixes an issue where completion and refusal emails for signatures were incorrectly using the signer's partner email instead of the correct, validated email defined for the sign request. Now, emails sent to signers will use the accurate email address, ensuring proper communication and notification delivery. This improves the reliability of the signature process.
Original PR description
Previously, completion and refusal emails were sent using the partner email directly, ignoring the computed email defined on the sign request item. The computed email includes validation rules and should be the main email for signer communication. This commit ensures that completion and refusal emails are sent using the computed signer email instead of the partner email. task-6148765 Forward-Port-Of: odoo/enterprise#114606
This update fixes an issue where large tablets with touch screens incorrectly displayed the mobile toolbar instead of the desktop toolbar. The change now considers screen size, ensuring the correct toolbar is shown on all devices, improving the user experience for tablet users.
Original PR description
Problem: On large tablets with touch capability and high resolution, the mobile toolbar is displayed instead of the desktop toolbar. Cause: The mobile toolbar condition relied on touch capability alone, without considering screen size. Devices with large screens but touch support were therefore incorrectly treated as mobile. Solution: Use `utils.isSmall()` to determine whether the device should display the mobile toolbar, ensuring screen resolution is taken into account. Steps to reproduce: - Open the editor on a large tablet. - Observe that the mobile toolbar is shown. - The desktop toolbar should be displayed instead. task-6106531 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259605
This update resolves an issue where changing a text tag (like from 'Header 2' to 'Header 1') didn't fully remove the previous heading style. The fix ensures that selected text correctly loses its original heading formatting, improving the accuracy of text editing within Odoo.
Original PR description
Problem: When applying `h1` to part of a selection already inside an `h2`, the selected content still keeps the `class="h2"` style. Cause: `removeFormats` internally uses `formatSelection`, but in this case we only want to change the tag and not reformat the selection. This causes existing heading styles to remain applied. Solution: Use `removeFormat` instead, as it removes formatting without applying additional formatting to the selection. Steps to reproduce: - Go to Website and drop the "Text-Image" snippet. - Copy the text "Enhance Your Experience". - Paste the text into a new To-Do. - Select part of the pasted text. - Change it from "Header 2" to "Header 1 Display 1". - Observe that part of the text still keeps the "Header 2" style. task-6204505 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263810
This update optimizes PDF report generation by compressing files after merging, reducing file sizes and memory usage. It addresses a previous memory leak and leverages newer pypdf versions for better performance, particularly with large reports. The result is faster report generation and reduced storage needs.
Original PR description
When merging pages with pypdf, the resulting content is uncompressed. A compression pass should be done right after to reduce the resulting file size. Additionally, this helps alleviate a memory leak in PyPDF2 where resources in the merged page are not properly released. Newer versions of pypdf (>=3.15.4) do not have this leak but still see benefits in the output file size. In practice the CPU overhead is negligible, and we actually see a speed increase in cases with high memory usage. Benchmark Printing 400 page annual report | |Print Time|Peak Memory|Output File| |------|----------|-----------|-----------| |Before|142s |3.6GB |103MB | |After |127s |0.4GB |5MB | opw-6148786 Forward-Port-Of: odoo/odoo#264451 Forward-Port-Of: odoo/odoo#261879
This update optimizes PDF generation by compressing files after merging, resulting in significantly smaller file sizes and faster processing times. It addresses a previous memory leak issue and leverages newer PDF library versions for better efficiency, particularly when handling large documents. This improves user experience and reduces storage needs.
Original PR description
When merging pages with pypdf, the resulting content is uncompressed. A compression pass should be done right after to reduce the resulting file size. Additionally, this helps alleviate a memory leak in PyPDF2 where resources in the merged page are not properly released. Newer versions of pypdf (>=3.15.4) do not have this leak but still see benefits in the output file size. In practice the CPU overhead is negligible, and we actually see a speed increase in cases with high memory usage. Benchmark Printing 400 page annual report | |Print Time|Peak Memory|Output File| |------|----------|-----------|-----------| |Before|142s |3.6GB |103MB | |After |127s |0.4GB |5MB | opw-6148786 Forward-Port-Of: odoo/enterprise#117308 Forward-Port-Of: odoo/enterprise#115550
13 changes
Resolved issues and error corrections
A technical issue preventing background video previews was resolved. The commit removed a broken Vimeo video link from the website builder, preventing error messages and ensuring a smooth user experience when selecting background videos. This improves the usability of the website design tool.
Original PR description
Steps to reproduce: 1. Drop any snippet. 2. Click on the background video option. 3. Observe Traceback. The Vimeo video with ID `499761556` is no longer available, causing a traceback when opening the background video options. This commit removes the unavailable video from the preview list. task-6088772 Forward-Port-Of: odoo/odoo#264080 Forward-Port-Of: odoo/odoo#263555
A test for the Point of Sale receipt generation process failed due to a generic selector used to identify the shipping date. This update adds a specific class to the shipping date element, ensuring the test accurately reflects the receipt format across different localization settings. This resolves a technical issue that could have impacted receipt accuracy.
Original PR description
Issue: ====== - The test used the selector `.pos-receipt-order-data div` to retrieve the shipping date. - This selector is not specific and matches different elements depending on localization. Fix: ==== - Add a specific class `shipping-date` to the shipping date element and update the test to use `.pos-receipt-order-data .shipping-date` to avoid incorrect matches. Task-6183114 Error-241995 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262761
This update fixes a minor error in the Norwegian tax settings. The tax code 32's rate was incorrectly set to 11.0. This change ensures accurate tax calculations for Norwegian businesses using Odoo, aligning with official tax regulations. This was coordinated with a related Enterprise PR.
Original PR description
The tax rate(`amount`) for code 32 was mistakenly set to '11.0'. To properly align with the official Norwegian tax rates, it needs to be updated to '11.11'. Related Enterprise PR: https://github.com/odoo/enterprise/pull/110792 task-6033027 Forward-Port-Of: odoo/odoo#264221 Forward-Port-Of: odoo/odoo#258390
This update resolves an issue where Ctrl+A wouldn't select images with captions in the HTML editor. The fix ensures that the selection correctly targets the image itself, regardless of the surrounding caption structure, preventing a crash. This improves the user experience when working with images and captions.
Original PR description
#### Description of the issue this PR addresses: - When an image with caption is selected, it is wrapped in a `<figure>`, making `<figure>` the anchor node - `selectAll` was resolving the container using `[contenteditable]`, which keeps `<figure>` as the container even though it is `contenteditable=false` - This leads to `<figure>` being passed to `getDeepestEditablePosition`, which cannot resolve a valid `nodeLevelAncestor` and returns null, causing a traceback #### Desired behavior after PR is merged: - `selectAll` now targets the nearest `contenteditable=true` ancestor instead of any `[contenteditable]` #### Steps to reproduce: - Add image and enable caption - Select the image - Press Ctrl+A task-6174371 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261968
This update resolves a technical issue preventing the Journal Audit report from displaying correctly when the 'Load More Limit' is set to 1. The fix ensures accurate report generation by addressing a key error related to data formatting during report expansion.
Original PR description
Steps to reproduce: - Install `Accounting` module - Accounting > Configuration > Accounting Reports > Journal Report > Options > Set `Load More Limit` to 1 - Accounting > Review > Journal Audit >…
Steps to reproduce:
- Install `Accounting` module
- Accounting > Configuration > Accounting Reports > Journal Report > Options >
Set `Load More Limit` to 1
- Accounting > Review > Journal Audit > Expand Sales
Traceback: `KeyError: 'no_format'`
Cause:
This error occurs when we expand the lines. During the expansion, we [append] a `Load more...` pagination row inside the report lines. In that row, we pass empty [dictionaries] in`columns`, like: `columns': [{}, {}, {}, {}, {}, {}]`. and we have offset. So, after expanding, there are two lines, and the second one is the Load more line.
Because its [columns] contain empty dictionaries, the `no_format` key is not found, which results in a `KeyError`.
Solution:
We are passing a `None` value if `no_format` is not present in the line's columns.
[append]: https://github.com/odoo/enterprise/blob/34c60542d87366d50484c21bc0576bdc59517c5e/account_reports/models/account_report.py#L5765
[dictionaries]: https://github.com/odoo/enterprise/blob/34c60542d87366d50484c21bc0576bdc59517c5e/account_reports/models/account_report.py#L5867-L5878
[columns]: https://github.com/odoo/enterprise/blob/34c60542d87366d50484c21bc0576bdc59517c5e/account_reports/models/account_journal_report.py#L158
opw-6125082This update fixes a limitation in how Odoo handles attachments uploaded through cron jobs. Previously, a specific setting prevented multiple attachments from being uploaded in a single job. Now, allowing `--limit-time-real=0` or `--limit-time-real-cron=0` enables the upload of multiple attachments, improving efficiency for automated processes.
Original PR description
make the `limit_time_real > 0` when --limit-time-real-cron=0 --limit-time-real=0 to allow multiple attachments to be uploaded in a single cron job. 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#264328
This update resolves an issue where users could create a circular dependency when attaching files to records, leading to errors. The fix prevents an attachment from being linked to itself in both the user interface and the backend, ensuring data integrity and stability.
Original PR description
Currently, users have the option to attach an ir.attachment to itself. This causes a recursion depth error when accessing attachments. This commit prevents this in the UI and the write. Firstly, the ir.attachment does not show itself in the dropdown when selecting the resource ID. Second, the write raises a UserError if attempting to write an ir.attachment with the same ID as the Resource ID. Steps to reproduce: 1. Create an attachment and save 2. Set the Resource Model `(res.model)` to "ir.attachment" 3. Select the same attachment in Resource ID `(res_id)` 4. Attempt to view attachments: `RecursionError: maximum recursion depth exceeded` opw-6206075 closes #263591 Forward-Port-Of: odoo/odoo#264439 Forward-Port-Of: odoo/odoo#263591
A test within the l10n_latam_check module failed due to a dependency on the l10n_ar localization module not being installed. This update ensures that the test runs correctly by requiring the l10n_ar module to be present, preventing a runtime error.
Original PR description
Steps to reproduce: 1- Install l10n_latam_check on a fresh database instance 2- Run the test `test_invoice_status_after_voided_check` Issue: `ValueError: External ID not found in the system: l10n_ar.dc_liq_uci_a` Why this happens: The test used a document type from the l10n_ar module, so running the test without it being installed caused an error. runbot-243341 Forward-Port-Of: odoo/odoo#262800
This update resolves a technical issue impacting invoice accuracy for Mexican VAT (SAT) compliance. Previously, invoices with many items could trigger validation errors due to rounding discrepancies when applying per-line discounts. This fix ensures invoices pass SAT validation and correctly calculate discounts, improving financial reporting.
Original PR description
…any lines Fix SAT validation errors CFDI40111 and CFDI40108 that occur when invoices with many lines contain a small negative line, causing per-line discounts to be hidden due to currency precision. opw-6187014 Forward-Port-Of: odoo/enterprise#117344 Forward-Port-Of: odoo/enterprise#117297
This update fixes an issue where completion and refusal emails for signatures were incorrectly sent using the signer's partner email instead of the designated email defined within the sign request. Now, emails are sent using the correct, validated email address, ensuring signers receive important notifications reliably. This improves communication and reduces potential errors.
Original PR description
Previously, completion and refusal emails were sent using the partner email directly, ignoring the computed email defined on the sign request item. The computed email includes validation rules and should be the main email for signer communication. This commit ensures that completion and refusal emails are sent using the computed signer email instead of the partner email. task-6148765 Forward-Port-Of: odoo/enterprise#114606
This update resolves a problem that occurred when creating consolidated invoices from multiple POS orders for the same customer. The fix ensures that all refund reason values are correctly collected and validated, preventing errors and maintaining data consistency. This improves the reliability of invoice generation for multi-order transactions.
Original PR description
When creating a consolidated POS invoice from multiple orders for the same customer, `_prepare_invoice_vals` is called on a multi-record set. Accessing `self.l10n_es_tbai_refund_reason` directly on such a set raised a ValueError because `fields.Selection.__get__` internally calls `ensure_one()`. Use `mapped()` to safely collect all distinct refund reason values across the recordset. Raise a UserError if orders have conflicting values, consistent with the existing TicketBAI validation pattern for mixed required/non-required orders. opw-6192225 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262967
This update fixes an issue where large tablets with touch screens incorrectly displayed the mobile toolbar instead of the desktop version. The change now considers screen size alongside touch capability, ensuring the correct toolbar is shown on all devices. This improves the user experience for tablet users.
Original PR description
Problem: On large tablets with touch capability and high resolution, the mobile toolbar is displayed instead of the desktop toolbar. Cause: The mobile toolbar condition relied on touch capability alone, without considering screen size. Devices with large screens but touch support were therefore incorrectly treated as mobile. Solution: Use `utils.isSmall()` to determine whether the device should display the mobile toolbar, ensuring screen resolution is taken into account. Steps to reproduce: - Open the editor on a large tablet. - Observe that the mobile toolbar is shown. - The desktop toolbar should be displayed instead. task-6106531 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259605
This update resolves an issue where changing a text tag (like from H2 to H1) didn't properly remove the previous heading style. The fix ensures that selected text now correctly loses its original heading formatting, improving the consistency and accuracy of text editing within the Odoo website.
Original PR description
Problem: When applying `h1` to part of a selection already inside an `h2`, the selected content still keeps the `class="h2"` style. Cause: `removeFormats` internally uses `formatSelection`, but in this case we only want to change the tag and not reformat the selection. This causes existing heading styles to remain applied. Solution: Use `removeFormat` instead, as it removes formatting without applying additional formatting to the selection. Steps to reproduce: - Go to Website and drop the "Text-Image" snippet. - Copy the text "Enhance Your Experience". - Paste the text into a new To-Do. - Select part of the pasted text. - Change it from "Header 2" to "Header 1 Display 1". - Observe that part of the text still keeps the "Header 2" style. task-6204505 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263810
3 changes
Resolved issues and error corrections
This update fixes a bug in the journal report that caused it to repeatedly load the same data when using the 'Load More' feature. The fix ensures that the report correctly handles pagination, displaying only the necessary data and improving performance for users. This change enhances the user experience and reduces loading times.
Original PR description
Steps to reproduce: - Install `Accounting` module - Accounting > Configuration > Accounting Reports > Journal Report > Options > Set `Load More Limit` to 1 - Accounting > Review > Journal Audit > Expand Sales > `Load more...` The "Load More" button in the journal report was repeatedly loading the same lines because the custom engine query was not applying the offset and limit parameters passed to the method. Solution: Applied pagination to the query by using the `_get_engine_query_tail` helper method from `account.report`, which correctly appends `OFFSET` and `LIMIT` clauses to the SQL query. opw-6193697, 6125082 Forward-Port-Of: odoo/enterprise#116367
This update optimizes PDF document generation by compressing files after merging, leading to significantly smaller file sizes. It also addresses a memory issue in the PDF processing, improving overall system performance, particularly with large documents. The change resulted in a 75% reduction in file size and a faster print time.
Original PR description
When merging pages with pypdf, the resulting content is uncompressed. A compression pass should be done right after to reduce the resulting file size. Additionally, this helps alleviate a memory leak in PyPDF2 where resources in the merged page are not properly released. Newer versions of pypdf (>=3.15.4) do not have this leak but still see benefits in the output file size. In practice the CPU overhead is negligible, and we actually see a speed increase in cases with high memory usage. Benchmark Printing 400 page annual report | |Print Time|Peak Memory|Output File| |------|----------|-----------|-----------| |Before|142s |3.6GB |103MB | |After |127s |0.4GB |5MB | opw-6148786 Forward-Port-Of: odoo/enterprise#117308 Forward-Port-Of: odoo/enterprise#115550
This update resolves a technical issue impacting invoice accuracy for Mexican VAT (SAT) compliance. Specifically, it corrects a rounding problem that caused discounts to be hidden on invoices with many items, leading to validation errors. This ensures invoices meet SAT requirements and avoid potential disruptions to financial reporting.
Original PR description
…any lines Fix SAT validation errors CFDI40111 and CFDI40108 that occur when invoices with many lines contain a small negative line, causing per-line discounts to be hidden due to currency precision. opw-6187014 Forward-Port-Of: odoo/enterprise#117344 Forward-Port-Of: odoo/enterprise#117297
9 changes
Resolved issues and error corrections
This update optimizes PDF report generation by compressing files after merging, reducing file sizes and improving performance. It also addresses a memory leak in the PDF processing, leading to faster report creation, especially with large documents. The change results in significantly smaller PDF files and faster print times.
Original PR description
When merging pages with pypdf, the resulting content is uncompressed. A compression pass should be done right after to reduce the resulting file size. Additionally, this helps alleviate a memory leak in PyPDF2 where resources in the merged page are not properly released. Newer versions of pypdf (>=3.15.4) do not have this leak but still see benefits in the output file size. In practice the CPU overhead is negligible, and we actually see a speed increase in cases with high memory usage. Benchmark Printing 400 page annual report | |Print Time|Peak Memory|Output File| |------|----------|-----------|-----------| |Before|142s |3.6GB |103MB | |After |127s |0.4GB |5MB | opw-6148786 Forward-Port-Of: odoo/odoo#264355 Forward-Port-Of: odoo/odoo#261879
This update optimizes PDF document generation by compressing files after merging, reducing their size significantly. It also addresses a memory issue in the PDF processing, leading to faster performance, especially with large documents. The result is smaller, more efficient PDF files.
Original PR description
When merging pages with pypdf, the resulting content is uncompressed. A compression pass should be done right after to reduce the resulting file size. Additionally, this helps alleviate a memory leak in PyPDF2 where resources in the merged page are not properly released. Newer versions of pypdf (>=3.15.4) do not have this leak but still see benefits in the output file size. In practice the CPU overhead is negligible, and we actually see a speed increase in cases with high memory usage. Benchmark Printing 400 page annual report | |Print Time|Peak Memory|Output File| |------|----------|-----------|-----------| |Before|142s |3.6GB |103MB | |After |127s |0.4GB |5MB | opw-6148786 Forward-Port-Of: odoo/enterprise#117254 Forward-Port-Of: odoo/enterprise#115550
A recent test for point-of-sale receipt generation was failing due to an overly broad selector used to identify the shipping date. This update added a specific class to the shipping date element, ensuring the test accurately reflects how the receipt is generated across different localization settings. This resolves a potential issue with receipt accuracy.
Original PR description
Issue: ====== - The test used the selector `.pos-receipt-order-data div` to retrieve the shipping date. - This selector is not specific and matches different elements depending on localization. Fix: ==== - Add a specific class `shipping-date` to the shipping date element and update the test to use `.pos-receipt-order-data .shipping-date` to avoid incorrect matches. Task-6183114 Error-241995 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262761
This update resolves an issue where the color picker wasn't available when editing website snippets with images containing shapes. The fix ensures that users can now customize the colors of these images directly within the website editor, improving design flexibility. This change impacts the website editing experience.
Original PR description
Steps to reproduce: 1. Go to the website and enter edit mode. 2. Drop `s_cta_mockups` or `s_closer_look` snippet. 3. Click on any image that has a shape. Issue: The color picker option is missing for images with shapes in these snippets. Reason: These snippet templates do not include the `shapeColors` dataset on the image elements. task-5880905 Forward-Port-Of: odoo/odoo#246249
The 'Load More' feature in the journal report was repeatedly loading the same data due to a technical issue. This update correctly implemented pagination, ensuring that the report only displays the necessary data based on the user's selection, improving performance and accuracy.
Original PR description
Steps to reproduce: - Install `Accounting` module - Accounting > Configuration > Accounting Reports > Journal Report > Options > Set `Load More Limit` to 1 - Accounting > Review > Journal Audit > Expand Sales > `Load more...` The "Load More" button in the journal report was repeatedly loading the same lines because the custom engine query was not applying the offset and limit parameters passed to the method. Solution: Applied pagination to the query by using the `_get_engine_query_tail` helper method from `account.report`, which correctly appends `OFFSET` and `LIMIT` clauses to the SQL query. opw-6193697, 6125082 Forward-Port-Of: odoo/enterprise#116367
This update fixes a limitation in how Odoo handles attachments uploaded through cron jobs. Previously, a single cron job could only upload one attachment at a time. Now, attachments can be uploaded in bulk, improving efficiency for automated processes. This change ensures smoother and faster uploads for scheduled tasks.
Original PR description
make the `limit_time_real > 0` when --limit-time-real-cron=0 --limit-time-real=0 to allow multiple attachments to be uploaded in a single cron job. 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#264328
This update resolves a technical issue causing malformed XML in the TestReports module. Previously, automatic cleanup handled this, but with newer software, the fix ensures accurate test reporting and prevents potential errors. This change improves the reliability of our testing processes.
Original PR description
This commit fixes a malformed HTML/XML tag in TestReports. Note: before libxml2 v2.14.0, this issue was automagically cleaned up, but not anymore. Note: backport of https://github.com/odoo/odoo/pull/258569 Forward-Port-Of: odoo/odoo#264330
This update resolves an issue where users could create attachments that pointed back to themselves, leading to errors. The fix prevents attachments from being linked to themselves in both the user interface and during data writing, ensuring data integrity and stability.
Original PR description
Currently, users have the option to attach an ir.attachment to itself. This causes a recursion depth error when accessing attachments. This commit prevents this in the UI and the write. Firstly, the ir.attachment does not show itself in the dropdown when selecting the resource ID. Second, the write raises a UserError if attempting to write an ir.attachment with the same ID as the Resource ID. Steps to reproduce: 1. Create an attachment and save 2. Set the Resource Model `(res.model)` to "ir.attachment" 3. Select the same attachment in Resource ID `(res_id)` 4. Attempt to view attachments: `RecursionError: maximum recursion depth exceeded` opw-6206075 closes #263591 Forward-Port-Of: odoo/odoo#264439 Forward-Port-Of: odoo/odoo#263591
This update resolves a technical issue impacting invoice accuracy for Mexican VAT (SAT) compliance. Specifically, it corrects rounding errors that occurred when invoices with many items had small negative line discounts, leading to validation failures. This ensures invoices meet SAT requirements and avoids potential payment processing problems.
Original PR description
…any lines Fix SAT validation errors CFDI40111 and CFDI40108 that occur when invoices with many lines contain a small negative line, causing per-line discounts to be hidden due to currency precision. opw-6187014 Forward-Port-Of: odoo/enterprise#117344 Forward-Port-Of: odoo/enterprise#117297
2 changes
Resolved issues and error corrections
This update resolves a technical issue impacting invoice accuracy for Mexican VAT (SAT) compliance. Specifically, it corrects rounding errors that occurred when invoices with many items had a small negative line, preventing per-line discounts from being correctly applied. This ensures invoices pass SAT validation and avoid potential financial discrepancies.
Original PR description
…any lines Fix SAT validation errors CFDI40111 and CFDI40108 that occur when invoices with many lines contain a small negative line, causing per-line discounts to be hidden due to currency precision. opw-6187014 Forward-Port-Of: odoo/enterprise#117297
The 'Load More' functionality in the journal report was repeatedly loading the same data due to a technical issue. This update correctly implements pagination, ensuring that only the necessary data is retrieved and displayed, improving report performance and accuracy. This resolves a bug impacting report loading times.
Original PR description
Steps to reproduce: - Install `Accounting` module - Accounting > Configuration > Accounting Reports > Journal Report > Options > Set `Load More Limit` to 1 - Accounting > Review > Journal Audit > Expand Sales > `Load more...` The "Load More" button in the journal report was repeatedly loading the same lines because the custom engine query was not applying the offset and limit parameters passed to the method. Solution: Applied pagination to the query by using the `_get_engine_query_tail` helper method from `account.report`, which correctly appends `OFFSET` and `LIMIT` clauses to the SQL query. opw-6193697, 6125082 Forward-Port-Of: odoo/enterprise#116367
4 changes
Resolved issues and error corrections
This update resolves an error that occurred when users set their fiscal year's end date to February 29th. The fix ensures reports accurately calculate dates, regardless of whether the fiscal year is a leap year or not. This prevents reporting issues related to incorrect date calculations.
Original PR description
**Steps to Reproduce:** 1. Install the Accounting module. 2. Go to Settings and set the fiscal year's last day to 29 February. 3. Accounting > Reporting > open any report. **Error:** `ValueError - day is out of range for month` **Cause:** At [1], a fixed year (2025) is used to compute the fiscal year end. However, 2025 is not a leap year, so creating a date with February 29 raises an error. **Fix:** Ensure that when the fiscal year’s last day is Feb 29, a leap year (2024) is used for the computation. For all other dates, the year remains unchanged (2025). As a result; - If the last day is February **28** (non-leap year) -> `fy_start` becomes **March 1** - If the last day is February **29** (leap year) -> `fy_start` also becomes **March 1** [1] - https://github.com/odoo/enterprise/blob/4fa1c0c13308bd8de06646543391f8cbcf28d05e/account_reports/models/account_report.py#L820 sentry-7438598965 Forward-Port-Of: odoo/enterprise#115400
This update prevents a critical error that occurred when creating quality checks from quality points. The issue arose when a product wasn't specified, causing a system error. This fix ensures quality checks can be created successfully under all circumstances, improving data integrity and usability.
Original PR description
When creating a quality check from a quality point, a traceback occurs if no product is set. Steps to reproduce the error: - Install ``quality_control`` module with demo data - Go to Quality > Quality Control > Control Points > Create a new Control point > Set Control per: Quantity, Partial Test: 99 > Save - Click on Quality Checks smart button > Click on New Traceback: ```py ValueError: Expected singleton: uom.uom() ``` https://github.com/odoo/enterprise/blob/4fa1c0c13308bd8de06646543391f8cbcf28d05e/quality_control/models/quality.py#L369 During creation of a quality check, ``product_id`` is not set. The compute method ``_compute_qty_to_test`` accesses ``product_id.uom_id``, which leads to the above traceback. sentry-7440188763 Forward-Port-Of: odoo/enterprise#115292
This update cleans up tests related to the recent restructuring of the POS stock functionality. Previously, tests were referencing outdated stock-related data, which has now been removed to align with the new `pos_stock` module. This ensures the tests accurately reflect the current system.
Original PR description
Issue: ====== - Some tests were still using stock-related fields and groups that were previously part of `pos`, but were moved to a new module `pos_stock` after the refactor. Fix: ===== - Remove references to these fields from the tests, as stock-related logic is now handled in `pos_stock` module. Task-6183114 Error-242928,243017,243059 Related Community PR: https://github.com/odoo/odoo/pull/262719 Forward-Port-Of: odoo/enterprise#116185
The 'Waiting for Me' filter in the Sign app was incorrectly fetching all documents instead of filtering those requiring the current user's signature. This update corrects a technical issue related to how the system processes filter criteria, ensuring the filter functions as intended and only displays relevant documents.
Original PR description
When applying the 'Waiting for me' filter in the Sign app, all documents are fetched instead of filtering out documents that do not need the current user's signature. Steps to reproduce: 1) Install…
When applying the 'Waiting for me' filter in the Sign app, all documents are fetched instead of filtering out documents that do not need the current user's signature.
Steps to reproduce:
1) Install sign with demo data
2) Open sign app and remove default filter
3) Add a filter Waiting for me
Observed Behavior:
All the documents are fetched.
Expected Behavior:
Documents should be filtered out to only show those where the current user is a signer.
Root Cause:
Since [commit](https://github.com/odoo/enterprise/pull/76079/changes/8b5048f63f91a38a710b611d17f5cf27fbd0a18a), The `_search_need_my_signature` method returned `NotImplemented` for any operator other than `in` at [1]. While the filter uses `=` at [2]. Following a recent ORM optimization with the mentioned commit, the operators are now standardized as shown
From:
`('need_my_signature', '=', True)]`
To:
`[('need_my_signature', 'in', [True])]`
This means the search method now receives the expected `in` operator. However, the return logic uses a `not in` condition when filtering documents waiting for signature.
As a result, instead of filtering documents, all documents are returned.
[1]- https://github.com/odoo/enterprise/blob/012b42c20b48e8e36298875e3291936e68e72375/sign/models/sign_request.py#L107-L108
[2]- https://github.com/odoo/enterprise/blob/012b42c20b48e8e36298875e3291936e68e72375/sign/views/sign_request_views.xml#L177
Fix:
Corrected the return domain logic to fetch the correct documents.
opw-6026935
Forward-Port-Of: odoo/enterprise#117049
Forward-Port-Of: odoo/enterprise#1137604 changes
Resolved issues and error corrections
This update resolves an issue where users with limited planning permissions couldn't copy planning slots to employees with flexible calendars. Now, users with planning manager rights can successfully copy slots, even when moving them to flexible resource calendars, without encountering access errors. This simplifies the planning process for users with restricted access.
Original PR description
**Purpose**: A user with planning manager rights but no access to employee and contract records should be able to copy and movea planning slot to an employee with a flexible resource_calendar without…
**Purpose**: A user with planning manager rights but no access to employee and contract records should be able to copy and movea planning slot to an employee with a flexible resource_calendar without getting an access rights error. **Before this commit:** When copying a planning slot, the system tries to compute the working hours over the period of the slot. This will raise an access rights error if the user doesn't have access to employee and contract records when the slot is moved to a flexible resource_calendar. **After this commit:** The user can copy a planning slot without access rights error with only planning manager rights, even if the slot is moved to a flexible resource_calendar. **Steps to reproduce:** 1.Install Planning and Planning Contract modules. 2.Create a user with only planning manager rights and no access to employee and contract records. 3.Copy a planning slot to an employee with a flexible resource_calendar. opw-6166557 Forward-Port-Of: odoo/enterprise#117180 Forward-Port-Of: odoo/enterprise#115953
This update fixes a bug in the journal report that caused it to repeatedly load the same data when using the 'Load More' feature. The fix ensures that the report correctly handles pagination, displaying only the necessary amount of data and improving performance for users.
Original PR description
Steps to reproduce: - Install `Accounting` module - Accounting > Configuration > Accounting Reports > Journal Report > Options > Set `Load More Limit` to 1 - Accounting > Review > Journal Audit > Expand Sales > `Load more...` The "Load More" button in the journal report was repeatedly loading the same lines because the custom engine query was not applying the offset and limit parameters passed to the method. Solution: Applied pagination to the query by using the `_get_engine_query_tail` helper method from `account.report`, which correctly appends `OFFSET` and `LIMIT` clauses to the SQL query. opw-6193697, 6125082 Forward-Port-Of: odoo/enterprise#116367
This update corrects a problem that caused invoices with many items to fail SAT validation (CFDI40111 and CFDI40108). The issue stemmed from currency precision calculations when applying discounts, particularly with small negative line amounts. This ensures invoices meet Mexican tax regulations and avoid errors.
Original PR description
…any lines Fix SAT validation errors CFDI40111 and CFDI40108 that occur when invoices with many lines contain a small negative line, causing per-line discounts to be hidden due to currency precision. opw-6187014 Forward-Port-Of: odoo/enterprise#117344 Forward-Port-Of: odoo/enterprise#117297
This update optimizes PDF generation by compressing files after merging, reducing their size and improving performance. It also addresses a memory leak issue in the PDF processing library, leading to faster processing, especially with large documents. The result is smaller, faster PDF exports.
Original PR description
When merging pages with pypdf, the resulting content is uncompressed. A compression pass should be done right after to reduce the resulting file size. Additionally, this helps alleviate a memory leak in PyPDF2 where resources in the merged page are not properly released. Newer versions of pypdf (>=3.15.4) do not have this leak but still see benefits in the output file size. In practice the CPU overhead is negligible, and we actually see a speed increase in cases with high memory usage. Benchmark Printing 400 page annual report | |Print Time|Peak Memory|Output File| |------|----------|-----------|-----------| |Before|142s |3.6GB |103MB | |After |127s |0.4GB |5MB | opw-6148786 Forward-Port-Of: odoo/enterprise#117308 Forward-Port-Of: odoo/enterprise#115550
1 change
Resolved issues and error corrections
This update corrects a technical issue preventing Danish EC Sales reports from exporting correctly to CSV. The column name was incorrectly set to 'LIST' instead of the required 'LISTE', causing file rejection by tax authorities. This change aligns with official documentation and ensures compliance.
Original PR description
### Issue: When exporting the Danish EC Sales List to CSV, the column name is `LIST` instead of `LISTE` According to the official documentation: https://info.skat.dk/data.aspx?oid=392&chk=217608 The correct value is `LISTE`, with a fixed length of 5 characters This cause rejection of the file This was already fixed in 19.0 when the two modules were merged: https://www.odoo.com/odoo/unassigned-tasks/4826286 ### Cause: The value `LIST` is hardcoded in the export https://github.com/odoo/enterprise/blob/b9e4fc1ba08db22dafd10f62a7d9159f963dc949/l10n_dk_reports/models/account_sales_report.py#L104-L107 ### Steps to reproduce: - Install `l10n_dk_reports` - Switch to DK Company - Go to EC Sales List - Download the CSV in the dropdown menu The column name should be LISTE opw-6127427 Forward-Port-Of: odoo/enterprise#116554
1 change
Resolved issues and error corrections
This update fixes an error that prevented credit notes from being successfully submitted for invoices sent to jofatora. The issue stemmed from a mismatch in customer information between the credit note and the original invoice. This ensures proper invoice processing and submission.
Original PR description
…t note and original invoice
**STEP TO REPRODUCE**
1. Create an invoice and send it to jofatora.
2. Create a credit note for the invoice, send it to jofatora.
3. Sending the credit note will fail with the following error: `Request failed: {"EINV_RESULTS":{"status":"ERROR","INFO":[],"WARNINGS":[],"ERRORS":[{"type":"ERROR","status":"ERROR","EINV_CODE":"invoice-persist","EINV_CATEGORY":"Invoice","EINV_MESSAGE":"invoice: Credit invoice buyer info does not match the original invoice"}]},"EINV_STATUS":"NOT_SUBMITTED","EINV_SINGED_INVOICE":null,"EINV_QR":null,"EINV_NUM":null,"EINV_INV_UUID":null}`
**CAUSE**
In `account_edi_xml_ubl_21_jo.py` if the document is a credit note (`is_refund`), we fill the customer party with some default value. However, the documentation states that the credit note customer party should have the exact same values as the original invoice.
opw-6183573