Daily updates from Odoo
Thursday, July 16, 2026
35 changes · saas-19.2
New functionality added to Odoo
This module adds extra functions on the point of sale for l10n_tw_edi_ecpay, passing values from pos order to invoice for creating Taiwan E-invoice task-5122414 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255980
Original PR description
This module adds extra functions on the point of sale for l10n_tw_edi_ecpay, passing values from pos order to invoice for creating Taiwan E-invoice task-5122414 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255980
Enhancements to existing features
Servers would return a 403 because we annoy them for downloading the WSDL/XSD at every call. opw-6237180 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#276345 Forward-Port-Of: odoo/odoo#267482
Original PR description
Servers would return a 403 because we annoy them for downloading the WSDL/XSD at every call. opw-6237180 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#276345 Forward-Port-Of: odoo/odoo#267482
While upgrading the database to v19.2, several Tags are missing from the tax grid - Tags following the `mod349[X]` pattern (e.g., A, T, I, etc.) missing in upgraded database - Without these tags, the accounting reports display 0 - Earlier, I created an [upgrade](https://github.com/odoo/upgrade/pull/10434/changes/6afa01302928d77591430ff6e2779b35d7c92126) script to handle this issue, but after discussing with the reviewer, I created a fix in the community <img width="1846" height="845" al
Original PR description
While upgrading the database to v19.2, several Tags are missing from the tax grid - Tags following the `mod349[X]` pattern (e.g., A, T, I, etc.) missing in upgraded database - Without these tags, the accounting reports display 0 - Earlier, I created an [upgrade](https://github.com/odoo/upgrade/pull/10434/changes/6afa01302928d77591430ff6e2779b35d7c92126) script to handle this issue, but after discussing with the reviewer, I created a fix in the community <img width="1846" height="845" alt="image" src="https://github.com/user-attachments/assets/618bf6fd-73df-4ad2-af35-17cc018d7cf4" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
Fixed an issue where product variants using cost-based pricelists showed an outdated on sale price after the product cost was changed. Prices now refresh immediately, helping sales teams and cashiers see accurate promotional pricing without needing another update.
Original PR description
When we create a product variant and have a pricelist which is based on the cost price, and change the cost price, the on_sale_price doesn't update correctly. It gets delayed by one update because the product._origin isn't getting updated with the new onchanged value. Steps to Reproduce: 1.Create a pricelist and add a line with "formula" price type, and based on "cost", 2.Create a product variant, and add the pricelist just created. 3.Change the "Cost". The "On Sale Price" updates based on the value before. To fix the issue, we need to update the product._origin for standard_price just like the lst_price before computing the on_sale_price opw-5947995 Forward-Port-Of: odoo/enterprise#120420 Forward-Port-Of: odoo/enterprise#119470
This fixes a payroll report issue where eco voucher information was missing from Belgian payslips. Employees and payroll teams will now see the expected eco voucher line on the report, improving accuracy and clarity.
Original PR description
Since changing Eco vouchers to property input, the eco vouchers line on the report does not appear, this commit fixes it by calling the correct method in the template task-6370164
This fixes an issue that could interrupt the signing interface when debug-related page comments were present. The change helps ensure sign items are selected correctly so users can continue preparing or signing documents without unexpected errors.
Original PR description
Use lastElementChild when retrieving the sign item from the target element. In debug mode, inherited templates may introduce HTML comments into the DOM. Since lastChild return a comment node, accessing classList on the returned node raises an error. Using lastElementChild ensures that the last HTML element is always retrieved, regardless of comment nodes in the DOM. Forward-Port-Of: odoo/enterprise#122106
The Indian GST reports now exclude imported services from GSTR-2B, matching current legal requirements. GSTR-3B reporting for imported goods and services has also been updated to use the latest required sections, helping businesses file more accurate tax reports.
Original PR description
As per the law, import of services is not required to be shown in GSTR-2B. Therefore, the related report lines are removed in this commit. Additionally, GSTR-3B reporting is now handled according to the updated section changes for import of goods and services. task-6330737 Forward-Port-Of: odoo/enterprise#124316 Forward-Port-Of: odoo/enterprise#121925
Fixed an issue where opening Studio from a project's task list added an incorrect extra ID to the URL. This also prevents errors when users go back in the browser or open the Studio URL directly, making Studio navigation more reliable.
Original PR description
Go on a project, then open its task list view Open studio with the menu item. At this point, studio is open but the url looks like: `/odoo/project/5/tasks/studio/5` the last `/5` is wrong ; this commit fixes this. Then, hit the browser's back button. There is an error because the active_id was not correctly set when leaving studio that way Try loading `/odoo/project/5/tasks/studio`, again, there is an error because the active_id is read from the wrong object Forward-Port-Of: odoo/enterprise#124412 Forward-Port-Of: odoo/enterprise#122405
Preparation tickets now load the required styling again after a recent receipt printing change, so kitchen and order tickets display as expected. The update also restores missing receipt details, including customer notes, and improves related point-of-sale receipt screens.
Original PR description
..., pos_restaurant, pos_self_order, pos_urban_piper --- During the refactor of the receipt printing system, some CSS classes were no longer loaded with preparation tickets. As a result, preparation tickets lost part of their original styling. To restore the expected rendering, ensure all required classes are properly loaded while keeping the loading minimal. Additionally, some receipt data were missing after the refactor and some UI elements could be improved. This commit restores the missing data and improves the overall UI. It also fixes an issue where customer notes were not printed on the receipt. Templates checked: * point_of_sale.pos_order_change_receipt * point_of_sale.pos_order_change_receipt_line --- Task: https://www.odoo.com/odoo/project/1737/tasks/6133403 Refacto: https://github.com/odoo/odoo/pull/244395
This fix ensures payroll rule parameter values stay consistent when reused by the system. It prevents one payroll calculation or process from unintentionally changing shared rule data, reducing the risk of hard-to-trace payroll issues.
Original PR description
Cached functions with `@ormcache` should not return immutable values, yet `_get_parameter_from_code()` could return dicts/sets/lists/etc. It could lead to very obscure bugs such as: ```python def…
Cached functions with `@ormcache` should not return immutable values, yet `_get_parameter_from_code()` could return dicts/sets/lists/etc.
It could lead to very obscure bugs such as:
```python
def some_innocent_code():
category_dict = self.env["hr.rule.parameter"]._get_parameter_from_code('l10n_be_work_entry_categories')
incapacity_codes = category_dict['partial_incapacity']
incapacity_codes |= category_dict['total_incapacity']
# ... then use incapacity_codes
def print_rule_param():
print(self.env["hr.rule.parameter"]._get_parameter_from_code('l10n_be_work_entry_categories')['partial_incapacity'])
print_rule_param() # OrderedSet(['LEAVE281'])
some_innocent_code()
print_rule_param() # OrderedSet(['LEAVE281', 'LEAVE264', 'LEAVE266', 'LEAVE217', 'LEAVE218', 'LEAVE219', 'MEDIC01'])
```
The solution was to either deepcopy the returned value each time, or to change all the rule parameters to their frozen equivalent. Since we don't have access to frozen objects in rule parameters's xml definitions, we opted for the deepcopy approach.
task-6329380
Forward-Port-Of: odoo/enterprise#124141
Forward-Port-Of: odoo/enterprise#123057Fixed an issue that could prevent German point-of-sale receipts from being downloaded or printed when Fiskaly certification data was present. This helps stores using German fiscal certification reliably access receipts from completed POS orders.
Original PR description
With fiskaly in production, when printing the pos receipt, it crashes because the tss values dictionnary is not correctly interacted with. To reproduce: install l10n_de_pos_cert create a DE shop activate fiskaly and the tss in the settings of the POS create an order in the POS and pay it go to the backend, open the pos order and download the receipt it will crash To reproduce without production credentials, you can not activate fiskaly and the tss but still create and pay the pos order. Then, you can change the pos.config to add the l10n_de_fiskaly_tss_id and change the pos.order to add the l10n_de_fiskaly_time_start. Then download the receipt. opw-6356628 Fixes https://github.com/odoo/enterprise/pull/115676
Opening Studio from the Working Files view no longer triggers an error. This makes the accounting reports workflow more reliable when customizing or reviewing these records.
Original PR description
Open Studio while on "Working Files" menu and view. Before this commit, the python raised an error becaude at some point `record[False]` (returning the current virtual record) was put in the return values of the onchange. After this commit, there is no error. runbot-error-941248 Forward-Port-Of: odoo/enterprise#124239
This fix prevents Chile-specific certificate serial number requirements from blocking certificate creation for companies using other Latin American localizations, such as Peru. Businesses with multiple localizations installed can now configure certificates without encountering an unnecessary missing field error.
Original PR description
With a l10n_pe company and having a l10n_cl company installed: - Try to create a certificate in the settings, there is a missing field error. The template certificate_certificate_view_form have a required subject_serial_number field in l10n_cl but it shouldn't in other latam localization. opw-6274126 Forward-Port-Of: odoo/enterprise#120211
Call recordings made from Apple mobile devices will no longer result in silent audio files. The VoIP recording settings were adjusted for Apple mobile browsers so recorded calls can be played back correctly.
Original PR description
Before this commit, recording a VoIP phone call from an Apple mobile device generated a silent audio file. This issue happened because the configured 8000 `audioBitsPerSecond` value was too low. Apple mobile browsers strictly respect this value, while other browsers ignore it and default to a higher bitrate to 128000. Increasing `audioBitsPerSecond` to 32000 on WebKit browsers fixes the issue on Apple mobile devices. How to reproduce: - Set up a DIDWW user. - Enable call recording. - Make a call. - Open the call and play the recording. opw-6046534 Forward-Port-Of: odoo/enterprise#117885
The Dutch reports module no longer shows an outdated website link in its module information. This avoids sending users to an unrelated external site and keeps the app details accurate.
Original PR description
The URL leads to a website that has nothing to do with what it used to be so it needs to be removed. Task-6360682 Forward-Port-Of: odoo/enterprise#124380 Forward-Port-Of: odoo/enterprise#123019
This fixes a configuration issue so the subtask button in project forecast task views points to the current subtask action. It helps keep task navigation reliable after related interface changes, with minimal impact for users.
Original PR description
Issue --- The inherited xpath still targets the old action-based subtask button Fix --- Update the inherited xpath to target action_open_subtasks. task-5966684 Forward-Port-Of: odoo/enterprise#123493 Forward-Port-Of: odoo/enterprise#123035
This fix ensures the field service sales task view correctly supports both older and newer versions of the subtask button. It prevents compatibility issues so users can continue accessing subtasks reliably after upgrades or forward ports.
Original PR description
Issue --- The inherited xpath only targets the new object-based subtask button, making it incompatible with versions where the action-based button is still present. Fix --- Update the inherited xpath to target both the action-based and object-based subtask buttons. Forward-Port-Of: odoo/enterprise#124249
The signing tool now uses PDF handling calls that work with the older PDF library version used on Python 3.10. This prevents automated build failures and helps keep document signing reliable across supported environments.
Original PR description
The flatten_pdf helper was written against the snake_case pypdf API (append_pages_from_reader, .pages, get_object), but that API does not exist on PyPDF2 1.26.0, the camelCase-only release still pinned on Python 3.10 in 19.0, so runbot builds on 3.10 failed with an AttributeError on 'BrandedFileWriter' object has no attribute 'append_pages_from_reader'. Switching to the camelCase spelling (appendPagesFromReader, getNumPages/getPage, getObject) fixes it. RunbotError: https://runbot.odoo.com/odoo/runbot.build.error/941405 Forward-Port-Of: odoo/enterprise#124482
Loading a certificate could raise an unhandled exception instead of failing gracefully. Clearing the content, uploading a bundle with a corrupted certificate block, or handling certificates with unsupported signature algorithms or malformed extensions all could end up in a traceback. Guard those paths to ensure loading errors are handled. opw-6370529 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I
Original PR description
Loading a certificate could raise an unhandled exception instead of failing gracefully. Clearing the content, uploading a bundle with a corrupted certificate block, or handling certificates with unsupported signature algorithms or malformed extensions all could end up in a traceback. Guard those paths to ensure loading errors are handled. opw-6370529 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#276193 Forward-Port-Of: odoo/odoo#275325
Previously: 1.`purchase_cdnur_regular` section was assigned to credit/debit notes of: - import of goods - import of services without RCM However: - import of goods should be handled through bill of supply - import of services without RCM is not possible Therefore, with this commit, such journal items are moved to `purchase_out_of_scope`. 2.`purcha
Original PR description
Previously:
1.`purchase_cdnur_regular` section was assigned to credit/debit notes of:
- import of goods
- import of services without RCM However:
- import of goods should be handled through bill of supply
- import of services without RCM is not possible Therefore, with this commit, such journal items are moved to `purchase_out_of_scope`.
2.`purchase_imp_services` section included import of services both with and
without RCM. Since import of services without RCM is not possible, those
journal items are now moved to `purchase_out_of_scope`.
3.Credit/debit notes of import of services with RCM were previously moved to
`purchase_out_of_scope`, which was incorrect. With this commit, they are now
correctly moved to `purchase_imp_services`.
task-6330737
Forward-Port-Of: odoo/odoo#276301
Forward-Port-Of: odoo/odoo#272453..., pos_restaurant, pos_self_order, pos_urban_piper --- During the refactor of the receipt printing system, some CSS classes were no longer loaded with preparation tickets. As a result, preparation tickets lost part of their original styling. To restore the expected rendering, ensure all required classes are properly loaded while keeping the loading minimal. Additionally, some receipt data were missing after the refactor and some UI elements could be improved. This commit restores t
Original PR description
..., pos_restaurant, pos_self_order, pos_urban_piper --- During the refactor of the receipt printing system, some CSS classes were no longer loaded with preparation tickets. As a result, preparation tickets lost part of their original styling. To restore the expected rendering, ensure all required classes are properly loaded while keeping the loading minimal. Additionally, some receipt data were missing after the refactor and some UI elements could be improved. This commit restores the missing data and improves the overall UI. It also fixes an issue where customer notes were not printed on the receipt. Templates checked: * point_of_sale.pos_order_change_receipt * point_of_sale.pos_order_change_receipt_line --- Task: https://www.odoo.com/odoo/project/1737/tasks/6133403 Refacto: https://github.com/odoo/odoo/pull/244395
CertificateAdapter presents a client certificate stored in the database instead of on disk when opening an HTTPS connection (used by the l10n_es EDI modules verifactu, sii and tbai). It loaded that certificate on the connection path of requests 2.31, but requests >= 2.32 changed that path (no longer calls get_connection()), so the step was skipped and the call crashed with: "TypeError: expected str, bytes or os.PathLike object, not certificate" Odoo pins requests 2.31.0 (max depending on Pyth
Original PR description
CertificateAdapter presents a client certificate stored in the database instead of on disk when opening an HTTPS connection (used by the l10n_es EDI modules verifactu, sii and tbai). It loaded that…
CertificateAdapter presents a client certificate stored in the database instead of on disk when opening an HTTPS connection (used by the l10n_es EDI modules verifactu, sii and tbai). It loaded that certificate on the connection path of requests 2.31, but requests >= 2.32 changed that path (no longer calls get_connection()), so the step was skipped and the call crashed with: "TypeError: expected str, bytes or os.PathLike object, not certificate" Odoo pins requests 2.31.0 (max depending on Python version), but online databases can use the version shipped by the OS (2.32.x on recent Ubuntu 26). Set the certificate up when the adapter is created instead of on that connection call. That step runs the same on every requests version, so the fix works both before and after 2.32. Steps to reproduce: - Spanish company with Veri*Factu and a certificate, on a server running requests >= 2.32 (saas-19.3 database for exemple on ubuntu 26) - Post a customer invoice and send it to Veri*Factu. => TypeError Reference: https://github.com/psf/requests/blob/f361ead047be5cb873174218582f7d8b9fcd9f49/HISTORY.md?plain=1#L146 Ticket [link](https://www.odoo.com/odoo/project.task/6366028) opw-6366028 Forward-Port-Of: odoo/odoo#275324
Issue: ---------------------------------------- When generating work entries with the CRON "Generate Missing Work Entries", the name of the work entries is always in English. Steps to reproduce: ---------------------------------------- - Create a new employee, setup a running contract for them - Run the schedule action "Generate Missing Work Entries" - In Payroll > Work Entries, search for the work entries of the new employee - Their name are in French Cause: ----------------------
Original PR description
Issue: ---------------------------------------- When generating work entries with the CRON "Generate Missing Work Entries", the name of the work entries is always in English. Steps to reproduce: ---------------------------------------- - Create a new employee, setup a running contract for them - Run the schedule action "Generate Missing Work Entries" - In Payroll > Work Entries, search for the work entries of the new employee - Their name are in French Cause: ---------------------------------------- When running the cron, `self.env.lang` is `False` so the text aren't translated. Solution: ---------------------------------------- In `_cron_generate_missing_work_entries()` we specify `self.env.user.lang` in the context. As `_cron_generate_missing_work_entries()` uses the root user to run, the language of the work entries will be the one specified on Odoobot. opw-6369109 Forward-Port-Of: odoo/odoo#275952
When creating an event in Odoo and syncing it to Outlook, the event appeared in the correct slot on Outlook's calendar grid, but its detail panel showed start/end times labelled as UTC, causing a mismatch between the user's wall-clock time and what was displayed in Microsoft Outlook. The sync now sends the event in the organizer's local timezone with a matching timezone label, so Outlook displays the same wall-clock time and timezone that was entered. task-6167258 Description of the issue/
Original PR description
When creating an event in Odoo and syncing it to Outlook, the event appeared in the correct slot on Outlook's calendar grid, but its detail panel showed start/end times labelled as UTC, causing a mismatch between the user's wall-clock time and what was displayed in Microsoft Outlook. The sync now sends the event in the organizer's local timezone with a matching timezone label, so Outlook displays the same wall-clock time and timezone that was entered. task-6167258 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#276556 Forward-Port-Of: odoo/odoo#262488
Click Working Files menu, then open studio. Before this commit there was an error, because the accounting code tried to check access rights on an new record (no id) After this commit there is no crash. runbot-error-941248 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#276269
Original PR description
Click Working Files menu, then open studio. Before this commit there was an error, because the accounting code tried to check access rights on an new record (no id) After this commit there is no crash. runbot-error-941248 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#276269
### Steps to reproduce: - Open the Todo app - In the editor, insert the following content: `<p>a</p><div class="oe_unbreakable"><br></div><p>b</p>` - Double-click the empty unbreakable node - Open the color picker and hover over a color - Toolbar and color picker get closed ### Root cause: - Hovering a color in an empty unbreakable node replaces the `<br>` with a `<font data-oe-zws-empty-inline>` containing a ZWS (`\u200b`). This triggers a selectionchange where `isToolbarVisible()`
Original PR description
### Steps to reproduce: - Open the Todo app - In the editor, insert the following content: `<p>a</p><div class="oe_unbreakable"><br></div><p>b</p>` - Double-click the empty unbreakable node - Open…
### Steps to reproduce: - Open the Todo app - In the editor, insert the following content: `<p>a</p><div class="oe_unbreakable"><br></div><p>b</p>` - Double-click the empty unbreakable node - Open the color picker and hover over a color - Toolbar and color picker get closed ### Root cause: - Hovering a color in an empty unbreakable node replaces the `<br>` with a `<font data-oe-zws-empty-inline>` containing a ZWS (`\u200b`). This triggers a selectionchange where `isToolbarVisible()` finds no `<br>` and no visible text, returns false, and closes the toolbar — which reverts the preview, reopens the toolbar, and causes a flicker loop. ### Solution: - Instead of calling `fillEmpty()` (which inserts a ZWS placeholder) on empty blocks containing `<br>` preserve the `<br>` element by appending it directly inside the `<font>` tag which keeps toolbar open. task-6312933 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#271507
**PROBLEM** `_cron_migrate_local_to_cloud_storage()` is used to migrate attachment to a cloud storage. It delete the attachment from the database, rendering it innacessible from the server-side. The problem is it can delete attachment used in business logic. **STEP TO REPRODUCE** 1. Install and configure cloud_storage + a provider (e.g. cloud_storage_google) and cloud_storage_migration. 2. Install l10n_mx_edi and stamp a customer invoice. The CFDI XML is stored as an ir.attachment that:
Original PR description
**PROBLEM** `_cron_migrate_local_to_cloud_storage()` is used to migrate attachment to a cloud storage. It delete the attachment from the database, rendering it innacessible from the server-side. The…
**PROBLEM** `_cron_migrate_local_to_cloud_storage()` is used to migrate attachment to a cloud storage. It delete the attachment from the database, rendering it innacessible from the server-side. The problem is it can delete attachment used in business logic. **STEP TO REPRODUCE** 1. Install and configure cloud_storage + a provider (e.g. cloud_storage_google) and cloud_storage_migration. 2. Install l10n_mx_edi and stamp a customer invoice. The CFDI XML is stored as an ir.attachment that: - is referenced by a business Many2one l10n_mx_edi.document.attachment_id (copied into account.move.l10n_mx_edi_cfdi_attachment_id), - has res_field = NULL (record attachment, not a field binary), - is posted to the chatter → it has a row in message_attachment_rel. 3. Add account.move to cloud_storage_migration_message_models and set a low enough cloud_storage_min_file_size. 4. Run the cron _cron_migrate_local_to_cloud_storage. 5. Open the invoice and trigger any recompute of the EDI chain (e.g. Update Payments, a reconciliation, or re-stamping). **FIX** Filters out attachment linked to a model listed by the already existing function `_get_cloud_storage_unsupported_models()` opw-6347198 Forward-Port-Of: odoo/odoo#275945
## Steps to reproduce: - Install sale_timesheet - Create a timesheet with a Sale order item linked to it - Change the sale order item on that timesheet - Change the project linked to the timesheet to a non-billable project - Notice the sale order item still linked to the timesheet ## Cause: When computing the so_line we filter out the records that has is_so_line_edited as true, so when changing the SOL before changing the project we don't reset so_line field when setting a non-bill
Original PR description
## Steps to reproduce: - Install sale_timesheet - Create a timesheet with a Sale order item linked to it - Change the sale order item on that timesheet - Change the project linked to the timesheet to a non-billable project - Notice the sale order item still linked to the timesheet ## Cause: When computing the so_line we filter out the records that has is_so_line_edited as true, so when changing the SOL before changing the project we don't reset so_line field when setting a non-billable project. ## Fix: We reset the is_so_line_edited field to false when changing the project to a non-billable one. opw-6311549 Forward-Port-Of: odoo/odoo#276386 Forward-Port-Of: odoo/odoo#275919
Before this commit, when making a test print from the POS backend, the following issues would occur: - Very slow response - Missing cut, and extra 'A' character is printed This commit fixes both these issues. The slow response is avoided by not performing the network tests when they aren't used in the printed receipt. The cut issue is solved by appending a newline character to the message. task-6391141 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/s
Original PR description
Before this commit, when making a test print from the POS backend, the following issues would occur: - Very slow response - Missing cut, and extra 'A' character is printed This commit fixes both these issues. The slow response is avoided by not performing the network tests when they aren't used in the printed receipt. The cut issue is solved by appending a newline character to the message. task-6391141 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#276524
Steps to Reproduce --- - Create a normal parent task with one normal sub-task and one template sub-task. - Open the parent task form view and observe the Sub-tasks stat button count and notebook tab, check the subtask view as well. - Create a template parent task with one normal sub-task and one template sub-task, then repeat the same checks. Issue --- - Task templates are handled like regular subtasks in the subtask count, notebook, and subtask view, without taking the parent task t
Original PR description
Steps to Reproduce --- - Create a normal parent task with one normal sub-task and one template sub-task. - Open the parent task form view and observe the Sub-tasks stat button count and notebook tab,…
Steps to Reproduce --- - Create a normal parent task with one normal sub-task and one template sub-task. - Open the parent task form view and observe the Sub-tasks stat button count and notebook tab, check the subtask view as well. - Create a template parent task with one normal sub-task and one template sub-task, then repeat the same checks. Issue --- - Task templates are handled like regular subtasks in the subtask count, notebook, and subtask view, without taking the parent task type into account. Current Behaviour --- - For a normal parent task, both the normal sub-task and the template sub-task are counted and shown in the opened subtask view and notebook. - For a template parent task, the same filtering is applied, even though template subtasks should remain accessible in that context. Expected Behaviour --- - For a normal parent task, only real sub-tasks should be counted and shown in the subtask view and notebook, and on the project kanban card. - For a template parent task, template subtasks should remain available in the subtask view and notebook according to the parent template context. - In the project kanban card, tasks must not be counted when their parent task is a template, even if the child task itself is not a template. Fix --- - Apply template-aware filtering to subtask counting,project kanban task count and subtask view behavior, depending on whether the parent task is a normal task or a template task. task-5966684 Forward-Port-Of: odoo/odoo#275002 Forward-Port-Of: odoo/odoo#252403
Currently, if a discount program has a max discount, this value is not taken into account when computing the amount left to discount. Steps to reproduce: ------------------- * Create a loyalty program, it needs a reward as such: 100% discount on product A, maximum discount 100 * Create a discount code program, it needs a reward as such: 15% discount on product A * Open pos, make an order, add product A, change its price to 1000 * In this order: * Add the loyalty program reward (100%)
Original PR description
Currently, if a discount program has a max discount, this value is not taken into account when computing the amount left to discount. Steps to reproduce: ------------------- * Create a loyalty…
Currently, if a discount program has a max discount, this value is not taken into account when computing the amount left to discount. Steps to reproduce: ------------------- * Create a loyalty program, it needs a reward as such: 100% discount on product A, maximum discount 100 * Create a discount code program, it needs a reward as such: 15% discount on product A * Open pos, make an order, add product A, change its price to 1000 * In this order: * Add the loyalty program reward (100%) > Only 100$ discount since it's the max * Add the discount code reward > Nothing happens, no reward line added, no message saying the code didn't applied Why the fix: ------------ When we compute the amount left to discount `getDiscountable` when we try to apply the last reward we have `discount = 1` as the loyalty reward line is set up to a 100% discount. This ends up leaving `remainingAmountPerLine[line.uuid]` to be 0. The current state of the code does not take into account the maximum discount which, if triggered, means we still have something remaining to discount. We introduce this discount in a straightforward way for the moment. We simply compare the theoretical discount `remainingAmountPerLine[line.uuid] * discount` to the max. This is a simple version intended to make this work. In the future we could imagine taking all the lines the discount applies to and compute the proportion that is applied to the specific line. This approach was already discussed in the past for fixed amount discounts and was not implemented as it would make the code more complex (and unreadable) than needed. We're assuming the same approach applies here. We make it work first and see if there's ever a need to complexify it. opw-6129625 Forward-Port-Of: odoo/odoo#262499
When Google sends a recurrence with UNTIL in UTC (UNTIL=...Z), users in timezones behind UTC can get one extra occurrence on the boundary day. Google's UNTIL represents the last allowed start in UTC, but that UTC date fell into the previous local day. Because Odoo was comparing event start times as naive local datetimes against a cutoff derived from the wrong date, the boundary occurrence passed the check and was created. Steps to reproduce: 1. Set the user's timezone to a UTC-negative offse
Original PR description
When Google sends a recurrence with UNTIL in UTC (UNTIL=...Z), users in timezones behind UTC can get one extra occurrence on the boundary day. Google's UNTIL represents the last allowed start in UTC,…
When Google sends a recurrence with UNTIL in UTC (UNTIL=...Z), users in timezones behind UTC can get one extra occurrence on the boundary day. Google's UNTIL represents the last allowed start in UTC, but that UTC date fell into the previous local day. Because Odoo was comparing event start times as naive local datetimes against a cutoff derived from the wrong date, the boundary occurrence passed the check and was created. Steps to reproduce: 1. Set the user's timezone to a UTC-negative offset (e.g. America/Argentina/Buenos_Aires, UTC-3). 2. In Google Calendar, create a weekly recurring event (e.g. every Thursday at 12:00 local). 3. Edit the series with "This and following events" so the old series ends with UNTIL set to 02:59:59 UTC of the next day (= 23:59:59 local of the last valid occurrence day). 4. Sync with Odoo -> an extra event is created on the day after the last valid Thursday, which does not exist in Google Calendar. opw-6024835 Forward-Port-Of: odoo/odoo#274593 Forward-Port-Of: odoo/odoo#265297
Description of the issue/feature this PR addresses: Current behavior before PR: meeting.rrule is stored as a full dateutil rrule string, e.g.: "DTSTART:20250218T113209\nRRULE:FREQ=YEARLY;COUNT=720" Passing the full multi-line string as a single RRULE property value causes vobject to emit two RRULE lines, where the first one ("RRULE:DTSTART:...") has no FREQ. This is not standard-compliant and is rejected by calendar clients (e.g. Thunderbird: "invalid frequency null"). Desired behavior af
Original PR description
Description of the issue/feature this PR addresses:
Current behavior before PR: meeting.rrule is stored as a full dateutil rrule string, e.g.: "DTSTART:20250218T113209\nRRULE:FREQ=YEARLY;COUNT=720"
Passing the full multi-line string as a single RRULE property value causes vobject to emit two RRULE lines, where the first one ("RRULE:DTSTART:...") has no FREQ. This is not standard-compliant and is rejected by calendar clients (e.g. Thunderbird: "invalid frequency null").
Desired behavior after PR is merged: Only a single RRULE line is generated.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#274490**Steps to reproduce:** - create storable avco product - set the cost to 10 - set an onhand quantity of 100 in WH/stock - create another warehouse (if you don't already have another one) - create an internal transfer from WH/Stock to WH2 - open the 'stock' view - click on inventory at date - confirm **Current behavior:** the total value is 11.000 **Expected behavior:** total value should be 10.000 **Cause of the issue:** To compute the total_value of the product, _co
Original PR description
**Steps to reproduce:** - create storable avco product - set the cost to 10 - set an onhand quantity of 100 in WH/stock - create another warehouse (if you don't already have another one) - create an…
**Steps to reproduce:** - create storable avco product - set the cost to 10 - set an onhand quantity of 100 in WH/stock - create another warehouse (if you don't already have another one) - create an internal transfer from WH/Stock to WH2 - open the 'stock' view - click on inventory at date - confirm **Current behavior:** the total value is 11.000 **Expected behavior:** total value should be 10.000 **Cause of the issue:** To compute the total_value of the product, _compute_value calls _run_average_batch https://github.com/odoo/odoo/blob/68f258e99f42693131a5309b3606c3b95f93d824/addons/stock_account/models/product.py#L260 Inside run_average_batch we need the qty_available at the time of last manual value (which is when we set the cost to 10 manually) in order to value all this quantity at the value of the manual value. https://github.com/odoo/odoo/blob/68f258e99f42693131a5309b3606c3b95f93d824/addons/stock_account/models/product.py#L435 This qty should be 0 cause we had no onhand quantity when we set the cost to 10. But it's actually going to be 10, here is why : Inside _compute_quantities_dict, because we're asking for a quantity in the past, the computation is current quantity - quantities that went in between the date in the past and now + quantities that went out between the date in the past and now. https://github.com/odoo/odoo/blob/154b49ec6be6230989ee4eb420e7f83b681ff520/addons/stock/models/product.py#L255 So we should have : 100 - 100 (moves_in_res_past) + 0 (moves_out_res_past) = 0 because we have 100 now and between the date we're asking for (the time of the manual value) and now there is one move in (when we set a quantity of 100) and no move out. But moves_out_res_past will actually be 10 for our product instead of 0. That's because in the read_group, our internal move will be considered as a move out and be taken into account https://github.com/odoo/odoo/blob/60cf607d7148ebe389cc8513aa3b82e156cd4400/addons/stock/models/product.py#L233-L234 That's because: When we called _run_average_batch from _compute_value, we called it on 'products_to_value', which is based on 'products', which was computed calling with_valuation_context() https://github.com/odoo/odoo/blob/60cf607d7148ebe389cc8513aa3b82e156cd4400/addons/stock_account/models/product.py#L206 which passes the valued internal location in the context https://github.com/odoo/odoo/blob/60cf607d7148ebe389cc8513aa3b82e156cd4400/addons/stock_account/models/product.py#L366-L370 As wh2 is not internal (it's a view) it's not included in the locations from the context. strict is also set to True Therefore at the beginning of compute_quantities_dict, when we call _get_domain_location to compute domain_move_out_loc (on which domain_move_out_done will be based), https://github.com/odoo/odoo/blob/60cf607d7148ebe389cc8513aa3b82e156cd4400/addons/stock/models/product.py#L165 inside _get_domain_location, because a location is given in the context that's the one we're going to use. https://github.com/odoo/odoo/blob/60cf607d7148ebe389cc8513aa3b82e156cd4400/addons/stock/models/product.py#L365 and because strict is in the context, dest_location_domain_out will be "location_dest_id not in [the list of valued location which does not include wh2]". https://github.com/odoo/odoo/blob/7e95d32d669a7ee7c50b5e665697cb577be0af93/addons/stock/models/product.py#L402-L405 And back in compute_quantities_dict(), domain_move_out_loc will be "location_id in [the list of valued location] and location_dest_id not in [the list of valued location]". Our internal move will therefore be considered as an out move and taken into account in the computation mentioned above. Which explains why quantity will be 10 inside run_average_batch and why the computation of total_value is wrong **fix:** in 19.0 the fix is in the xml to take less risk with regards to stable policy, however starting from 19.1 the fix will be in python opw-6321636 Forward-Port-Of: odoo/odoo#275384 Forward-Port-Of: odoo/odoo#273388
Miscellaneous changes
Fix field name typo. @qrtl QT6381 Forward-Port-Of: odoo/odoo#276119
Original PR description
Fix field name typo. @qrtl QT6381 Forward-Port-Of: odoo/odoo#276119