Friday, March 13, 2026
184 changes
10 changes
Enhancements to existing features
This update enhances the statement line dropdown by visually highlighting matching move lines with the same amount and currency. This provides users with quicker identification of related transactions, streamlining reconciliation processes. The change also includes an optional display setting for this feature.
Original PR description
This will add a new colored bubble on the dropdown of a statement line when there is a move line that has the same amount currency or amount. task-5493859 Forward-Port-Of: odoo/enterprise#104896
Resolved issues and error corrections
This update corrects a visual issue where empty options were being saved and displayed in dropdown selectors within the BuilderList. The change ensures that empty selections are no longer persisted, improving the user experience and data consistency. This was caused by a previous code adjustment.
Original PR description
**Description of the problem** Before this commit, the user could entry empty many2one options in a form, and these would be saved and displayed in the website as empty entries in a dropdown…
**Description of the problem** Before this commit, the user could entry empty many2one options in a form, and these would be saved and displayed in the website as empty entries in a dropdown selector. **How to reproduce the problem** 1. Drop a form 2. Add a "Selection" field (many2one) 3. Clear the text in one of the options in "Option List" 4. Save 5. The empty option is not removed, and shows up in the dropdown selector **Why the problem happens** Commit [1] introduced some changes to the action `SetFormCustomFieldValueListAction`, as a result, empty many2one options are not dropped anymore on apply. **Solution** The solution is applied on `BuilderList` (not only forms), as required by the task. `BuilderList.handleValueChange` now drops empty text fields before commiting changes, unless this violates `props.forbidLastItemRemoval`. The form action `setFormCustomFieldValueList` is changed such that the last entry is never removed even if its text is empty (unless `props.forbidLastItemRemoval` is false). task-5925171 [1]: https://github.com/odoo/odoo/commit/cb8469e9fe73f5c10b4e49d3462e0b23df2a047d Forward-Port-Of: odoo/odoo#249546
28 changes
New functionality added to Odoo
This update adds support for obtaining currency rates directly from the National Bank of Georgia (NBG). This is required to comply with Georgian tax regulations, ensuring all transactions are accurately translated into the local currency (GEL) using official exchange rates.
Original PR description
This commit adds the National Bank of Georgia (NBG) as a supported service provider for automatic currency rate updates. Purpose: To comply with the Georgian Tax Code (Article 73), taxable transactions must be translated into the national currency (GEL) using the official exchange rate defined by the NBG for the transaction day. Functionality: -Enables fetching official exchange rates directly from NBG. -Automatically handles rates defined for different quantities (e.g, rates quoted per 100 units instead of 1 unit). task-5894623 Forward-Port-Of: odoo/enterprise#107375
2 changes
Resolved issues and error corrections
This update prevents an infinite loop in the system's credit note processing. Previously, the system incorrectly polled for credit notes, leading to unnecessary checks. The fix restricts the polling process to only invoices, ensuring efficiency and stability.
Original PR description
Claimed credit notes (DTE 61) were being polled indefinitely by the _l10n_cl_ask_claim_status cron. The SII endpoint listarEventosHistDoc does not support DTE 61 and always returns codResp 3 "Tipo de…
12 changes
Enhancements to existing features
This update aligns Odoo's Peppol EAS field selections with the latest Peppol codelist version 9.5. This ensures Odoo continues to meet regulatory requirements for electronic invoicing and simplifies compliance with Peppol standards. The change was made to reflect official updates from the Peppol organization.
Original PR description
A new version of codelist (v9.5) has been released. This commit aligns the Peppol EAS field selection with the Peppol codelist v9.5 See the changelog here : https://docs.peppol.eu/edelivery/codelists/changelog.html Updates applied according to the official v9.5 changes. task-5461213 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243990
3 changes
Resolved issues and error corrections
This update ensures Odoo complies with new NACHA regulations regarding payment descriptions. Starting March 2026, all payroll payments must include 'PAYROLL' in the Company Entry Description field to avoid potential payment issues. This change ensures continued smooth and compliant payroll processing.
Original PR description
Starting March 20, 2026, NACHA requires the Company Entry Description field to contain "PAYROLL" for paying wages, salaries, or compensation [1]. [1] https://www.nacha.org/rules/risk-management-topics-company-entry-descriptions task-5981941 Forward-Port-Of: odoo/enterprise#109460
19 changes
Enhancements to existing features
This update enhances the accuracy of Hong Kong payroll reports by rounding currency values to avoid potential errors when reporting to the IRD. The change ensures correct HKD reporting by using a more precise rounding method before converting to an integer, addressing a minor but important issue. Additionally, the rental system has been updated to fully support all officially recognized IRD rental benefit types.
3 changes
Resolved issues and error corrections
This update fixes a bug that prevented users from removing external members with edit access from spreadsheets after archiving. The fix ensures these warnings are displayed correctly, improving spreadsheet management and reducing potential confusion for users. It resolves three specific warnings related to access rights.
Original PR description
Problem: A bug occurs when an internal user with "Edit" rights to a spreadsheet is archived. Upon archiving, the user transitions to an external user, a state where "Edit" rights are strictly…
6 changes
Resolved issues and error corrections
This fix addresses an issue where portal users could access and potentially modify draft sales quotations after receiving a message. The change prevents sending draft quotations to customers, ensuring that orders remain in their intended draft state. This resolves a potential risk of unauthorized modifications to sales orders.
Original PR description
Issue: --- Draft quotation can be accessed by portal user if a message is sent to portal user. They can sign and pay the quotation. Steps to reproduce: --- 1- Create a SO with portal user as partner. Don't confirm it. 2- Using chatter, send a message to the partner. 3- Open the email. You can access the quotation using portal user which is not expected. Cause: --- After #124486, portal users can accept or pay the draft sale orders if they can access the quote. Fix: --- We can prevent sending quotation to customers when the order is in draft state. opw-5969465
1 change
Resolved issues and error corrections
This update resolves an issue where long tax amounts on invoices were causing display problems. The change ensures that tax totals are accurately and clearly presented, regardless of the numerical value, improving invoice readability and accuracy for users. This addresses a minor display issue impacting invoice reporting.
Original PR description
This commit aims to: Fix Display issue when the amount is long. task-5162891
This update corrects a minor syntax error in the PWA service's CSS selector, which was preventing the application from correctly registering during installation. This fix ensures that the PWA installation process works reliably, resolving a potential issue that could have disrupted the user experience. The change targets a known problem in versions 18.0 and 19.0.
Original PR description
Description of the issue/feature this PR addresses:
Fixes a typo in the manifest selector used by the PWA service.
document.querySelector("link[rel=manifest") was missing the closing ], making the selector invalid.
Current behavior before PR:
Calling getManifest() could throw a DOMException due to an invalid CSS selector, preventing manifest retrieval and potentially breaking PWA install flow.
Desired behavior after PR is merged:
getManifest() correctly queries link[rel=manifest], retrieves the manifest URL, and keeps the existing manifest-fetch behavior intact (including test coverage already present in pwa_service.test.js).
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#251376This update corrects a recent issue where quotation documents with lines having a zero subtotal amount were being discarded during upload. The fix ensures that all lines, including those with zero subtotal, are correctly processed, maintaining accurate quotation data. This resolves a regression introduced in a previous update.
Original PR description
Versions: --- Reproducible on 18.0+ Fix targets 16.0 to keep the code consistent across versions Issue: --- Due to this issue, a line with zero subtotal amount will be discarded in quotation document…
Versions: --- Reproducible on 18.0+ Fix targets 16.0 to keep the code consistent across versions Issue: --- Due to this issue, a line with zero subtotal amount will be discarded in quotation document upload. Steps to reproduce: --- 1- In sale app, upload a quotation document without line amount. (You could use the one attached in the ticket) 2- As you see, lines are discarded. Cause: --- This regression is introduced in https://github.com/odoo/odoo/pull/245862, to prevent lines with zero amount in accounting. The https://github.com/odoo/odoo/pull/245862 targets 16.0. However, the `sale_edi_ubl` is introduced on 18.0. Fix: --- Instead of `_retrieve_line_vals` (`_import_fill_invoice_line_values` on 16.0) returning `None` when `price_subtotal` is not present, it can keep returning `dict` with an extra key `price_subtotal`, and filter out unwanted line in `_retrieve_invoice_line_vals` itself. opw-5977735 Forward-Port-Of: odoo/odoo#253149 Forward-Port-Of: odoo/odoo#251463
This update fixes a bug that prevented users from seeing subtasks within the Kanban mobile view of tasks. The issue stemmed from a missing configuration element, now resolved. This enhancement improves task management visibility for mobile users.
Original PR description
Example of steps: - Install `industry_fsm` - Create a task with a subtask - Enable mobile view with devtools - Open a task - Navigate to sub-tasks tab - Traceback ``` TypeError: undefined is not an object (evaluating 'ctx['record'].parent_id.raw_value') ``` parent_id was missing from "view_task_kanban" opw-5981990 Forward-Port-Of: odoo/odoo#253623
A bug preventing users from copying their two-factor authentication secret via the portal has been resolved. The update corrected a technical issue related to how the 'Copy' button's functionality was implemented, ensuring users can now reliably access and copy their security codes.
Original PR description
__Problem__ Since odoo/odoo@e3da5f1 the onclick listener set on `copyButton` is lost because we give the HTML of the body as argument at the dialog creation. __Steps to reproduce__ 1. Go to `/my/security` 2. Click on "Enable two-factor authentication" 3. Confirm password 4. Click on "Cannot scan it?" 5. The "Copy" button doesn't work __Fix__ - Inherit from `InputConfirmationDialog` to add a listener to the button. - At the same time, remove the remaining jQuery dependency in this part of the code Forward-Port-Of: odoo/odoo#253314 Forward-Port-Of: odoo/odoo#251429
This update resolves a technical issue preventing correct receipt generation in the l10n_sa_pos module. The fix corrects an incorrect override condition, ensuring receipts are now generated accurately. This improves the user experience for South African POS customers.
Original PR description
With the commit moving receipt template to the backend, an override on the l10n_sa receipt was wrongly modified. This commit fixes the issue by changing the override condition to the correct one. runbot-error: 239134 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where contacts without names or email addresses in Odoo's chatter interface were displaying as 'Unnamed'. Now, when a contact lacks this information, the system will automatically show their display name instead, providing a more user-friendly experience. This ensures all contacts are correctly identified within conversations.
Original PR description
Steps to reproduce =============== 1. Create a contact of type invoice address without name and email. 2. Go to any app with chatter. 3. Add this user to the recipient ----> Only the blue tick will be visible (recipient name will be empty) After this commit, we will use the display_name as a fallback to show in the chatter. Forward-Port-Of: odoo/odoo#241830 Forward-Port-Of: odoo/odoo#213545
This update fixes a bug preventing customers from seeing their available payment methods within the customer portal. The issue stemmed from an incorrect configuration that was overlooked. The fix ensures all payment methods are correctly displayed, improving the customer experience and streamlining the payment process.
Original PR description
Versions: --- saas-19.1+ Issue -- Payment methods are not shown in portal page. Cause: --- In #212880 two issues were overlooked: 1. The payment portal entry ID is `payment_methods_portal_entry`, but the `should_show_portal_card` override was using the wrong external ID: `portal_payment_orders`. 2. The payment card should have `is_config_card=True`, which was missed. Because of this, the superclass implementation (which checks `is_config_card`) returns False and hides the card. Setting `is_config_card=True` would normally fix the issue, but it would require updating views for already existing databases. To avoid this, the override is adjusted to not `&` with the parent implementation. In master we can restore the `&` superclass. This change should have no negative impact since the issue only affects versions saas-19.1, saas-19.2 and there should be no custom overrides in saas versions. opw-6013786 Forward-Port-Of: odoo/odoo#253085
This update fixes an issue where 'sandwich leave' calculations involving company-specific public holidays were inaccurate. The fix ensures that all date calculations are properly localized to the company's timezone, guaranteeing the correct leave duration is determined. This improves the reliability of leave requests and reporting.
Original PR description
Steps to Reproduce: 1. Install the `l10n_in_hr_holidays` module. 2. Enable the "sandwich leave" option for the time off type. 3. Create public holidays that last the entire day, for example from 00:00 to 23:59. 4. Create a leave around the public holiday 5. Duration should be 3 days instead of 1 Cause: When creating a dictionary for company-specific public holidays, the dates from and to are not converted to the company's timezone when calculating the days between public holidays. Fix: To resolve this, the first step is to localize the `date_from` and `date_to` to the company's timezone before counting the days between the public holidays. Task-6012992 Forward-Port-Of: odoo/odoo#253489 Forward-Port-Of: odoo/odoo#252466
Enhancements to existing features
This update enhances the statement line dropdown by adding colored bubbles to highlight matching move lines with the same amount and currency. This provides users with quicker visual cues for related transactions, streamlining reconciliation processes. The feature also includes an optional display setting for increased flexibility.
Original PR description
This will add a new colored bubble on the dropdown of a statement line when there is a move line that has the same amount currency or amount. task-5493859 Forward-Port-Of: odoo/enterprise#104896
Resolved issues and error corrections
During migration, the `l10n_pl` end-migrate script was loading for every company using the `pl` chart template, including child companies. However, account codes must be [unique](https://github.com/odoo/odoo/blob/18.0/addons/account/models/account_account.py#L1033) across parent and child companies. Since the chart is already loaded for the root company, reloading it for child companies cause duplicate account code errors during migration. To prevent this, restrict chart loading to root
Original PR description
During migration, the `l10n_pl` end-migrate script was loading for every company using the `pl` chart template, including child companies. However, account codes must be…
During migration, the `l10n_pl` end-migrate script was loading
for every company using the `pl` chart template, including child companies.
However, account codes must be [unique](https://github.com/odoo/odoo/blob/18.0/addons/account/models/account_account.py#L1033) across parent and child companies.
Since the chart is already loaded for the root company, reloading it for child companies cause duplicate account code errors during migration.
To prevent this, restrict chart loading to root companies only, which is consistent with how account code uniqueness is enforced.
**Steps to reproduce:**
1. Create a database in 17.0
2. Install `account_accountant` and `l10n_pl`
3. Create a child (branch) for the company using the `pl` chart template
4. Migrate the database to 18.0
5. Migration fails with duplicate account code validation errors
**Traceback**
```py
Traceback (most recent call last):
File "/home/odoo/odoo18/community/odoo/service/server.py", line 1366, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "<decorator-gen-13>", line 2, in new
File "/home/odoo/odoo18/community/odoo/tools/func.py", line 97, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/odoo18/community/odoo/modules/registry.py", line 129, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/odoo/odoo18/community/odoo/modules/loading.py", line 523, in load_modules
migrations.migrate_module(package, 'end')
File "/home/odoo/odoo18/community/odoo/modules/migration.py", line 222, in migrate_module
exec_script(self.cr, installed_version, pyfile, pkg.name, stage, stageformat[stage] % version)
File "/home/odoo/odoo18/community/odoo/modules/migration.py", line 259, in exec_script
mod.migrate(cr, installed_version)
File "/home/odoo/odoo18/community/addons/l10n_pl/migrations/2.1/end-migrate.py", line 8, in migrate
Template._load_data({'account.account': Template._get_account_account('pl')})
File "/home/odoo/odoo18/upgrade/migrations/account/0.0.0/pre-ensure-deferred-accounts.py", line 36, in _load_data
return super()._load_data(data, *args, **kwargs)
File "/home/odoo/odoo18/community/addons/account/models/chart_template.py", line 677, in _load_data
created_records[model] = self.with_context(lang='en_US').env[model]._load_records(all_records_vals, ignore_duplicates=ignore_duplicates)
File "/home/odoo/odoo18/community/odoo/models.py", line 5531, in _load_records
records = self._load_records_create([data['values'] for data in to_create])
File "/home/odoo/odoo18/community/odoo/models.py", line 5435, in _load_records_create
records = self.create(vals_list)
File "<decorator-gen-196>", line 2, in create
File "/home/odoo/odoo18/community/odoo/api.py", line 498, in _model_create_multi
return create(self, arg)
File "/home/odoo/odoo18/community/addons/account/models/account_account.py", line 987, in create
records._ensure_code_is_unique()
File "/home/odoo/odoo18/community/addons/account/models/account_account.py", line 1064, in _ensure_code_is_unique
raise ValidationError(
odoo.exceptions.ValidationError: Account codes must be unique. You can't create accounts with these duplicate codes: 01.000.100, 01.000.200, 01.000.400, 01.000.900, 02.000.100, 02.000.200, 02.000.300, 02.000.900, 03.000.100, 03.000.200, 03.000.300, 03.000.400, 03.000.500, 03.000.600, 03.000.700, 03.000.800, 03.000.900, 03.050.100, 03.050.200, 03.050.300, 03.050.900, 07.010.200, 07.010.300, 07.010.400, 07.010.500, 07.010.600, 07.020.100, 07.020.200, 07.020.300, 07.030.100, 07.030.200, 08.000.100, 08.000.200, 08.000.300, 08.000.400, 08.000.500, 10.000.100, 10.000.200, 10.000.900, 13.000.100, 13.000.200, 13.000.900, 14.000.100, 14.000.200, 14.000.900, 14.050.100, 20.000.100, 20.000.200, 20.000.300, 21.000.100, 22.000.100, 22.010.100, 22.010.200, 22.010.300, 22.020.100, 22.020.200, 22.020.300, 22.030.100, 22.030.200, 22.030.300, 22.030.400, 22.030.500, 22.030.600, 23.000.100, 23.000.200, 23.000.900, 24.010.100, 24.010.200, 24.020.100, 24.020.200, 24.030.100, 24.030.200, 24.030.300, 24.030.400, 24.050.100, 24.090.100, 24.090.200, 24.090.300, 24.090.900, 28.000.100, 29.000.100, 29.010.100, 29.020.100, 30.000.100, 30.000.200, 30.000.300, 30.000.400, 30.000.500, 30.000.600, 30.000.700, 30.000.800, 30.000.900, 31.010.100, 31.060.100, 31.090.100, 33.000.100, 33.000.200, 33.000.300, 33.000.400, 33.000.500, 33.000.600, 34.010.100, 34.020.100, 34.020.200, 34.020.300, 34.020.400, 34.060.100, 34.070.100, 39.000.100, 40.000.100, 40.010.100, 40.010.200, 40.010.300, 40.010.400, 40.010.900, 40.020.100, 40.020.200, 40.020.300, 40.020.400, 40.020.500, 40.020.600, 40.020.700, 40.020.900, 40.030.100, 40.030.200, 40.030.300, 40.030.400, 40.030.500, 40.030.600, 40.030.700, 40.030.800, 40.030.900, 40.040.100, 40.040.200, 40.050.100, 40.050.200, 40.050.300, 40.050.900, 40.090.100, 49.000.100, 49.000.200, 49.000.300, 49.000.400, 50.000.100, 50.000.200, 50.010.100, 50.010.200, 52.010.100, 52.070.100, 53.000.100, 53.000.200, 55.000.100, 55.000.200, 58.000.100, 60.000.100, 60.010.100, 60.020.100, 62.000.100, 62.010.100, 64.000.100, 64.010.100, 65.000.100, 65.010.100, 70.000.100, 70.000.200, 70.000.300, 70.000.400, 70.010.100, 70.010.200, 70.010.300, 70.010.400, 73.000.100, 73.000.200, 73.000.300, 73.000.400, 73.010.100, 73.010.200, 73.010.300, 73.010.400, 74.000.100, 74.000.200, 74.000.300, 74.010.100, 74.010.200, 74.010.300, 75.000.100, 75.000.200, 75.000.300, 75.000.400, 75.000.500, 75.000.600, 75.000.700, 75.000.900, 75.010.100, 75.010.200, 75.010.300, 75.010.400, 75.010.500, 75.010.900, 76.000.100, 76.000.200, 76.000.300, 76.000.400, 76.000.900, 76.010.100, 76.010.200, 76.010.300, 76.010.900, 79.000.100, 79.000.200, 79.000.300, 79.000.400, 79.000.500, 80.000.100, 80.000.200, 80.000.300, 80.000.400, 81.010.100, 81.020.100, 81.030.100, 81.040.100, 82.000.100, 83.000.100, 83.000.200, 83.010.000, 83.010.100, 83.010.200, 84.010.000, 84.020.100, 84.020.200, 85.010.100, 85.020.100, 85.020.200, 85.020.300, 86.000.100, 87.000.100, 87.000.900
```
**Fix:**
- Load `account.account` records only for root companies during When the chart template loads for `pl` localization.
opw-5932421
upg-3895331
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#250654This update resolves an issue where the font size in the HTML editor toolbar would disappear when navigating within a document. The fix ensures that the editor's state, including font size settings, is preserved across toolbar redraws and DOM movements. This improves the user experience and prevents data loss during document editing.
Original PR description
Since [1], the font size in editor's toolbar is a `button` that contains an `iframe`. An `input` is put within this `iframe` so that when it is focused, the selection in the edited document is not lost. Unfortunately, when an `iframe` is moved in the DOM, it is restarted. In this case, the `iframe` has no source, so it becomes empty, and the content that was added into it `onMounted` is lost. This commit solves this by listening to every `load` events on the `iframe` instead of only the initial one. Steps to reproduce: - Go to a "To Do" note - Create a table with `/table` - Press Enter to confirm the 3x3 size - Select the last two cells of the first column - Move the mouse upwards to the next cell => The font size disappeared [1]: https://github.com/odoo/odoo/commit/a468de9d1099931d8f553c8569359996e7b694f2 task-6003539 Forward-Port-Of: odoo/odoo#252013
This update corrects a previous issue where quotation documents with lines having a zero subtotal amount were being discarded during upload. The fix ensures that all lines, including those with zero subtotal, are now correctly processed, maintaining accurate quotation data. This resolves a compatibility problem introduced in a recent update.
Original PR description
Versions: --- Reproducible on 18.0+ Fix targets 16.0 to keep the code consistent across versions Issue: --- Due to this issue, a line with zero subtotal amount will be discarded in quotation document…
Versions: --- Reproducible on 18.0+ Fix targets 16.0 to keep the code consistent across versions Issue: --- Due to this issue, a line with zero subtotal amount will be discarded in quotation document upload. Steps to reproduce: --- 1- In sale app, upload a quotation document without line amount. (You could use the one attached in the ticket) 2- As you see, lines are discarded. Cause: --- This regression is introduced in https://github.com/odoo/odoo/pull/245862, to prevent lines with zero amount in accounting. The https://github.com/odoo/odoo/pull/245862 targets 16.0. However, the `sale_edi_ubl` is introduced on 18.0. Fix: --- Instead of `_retrieve_line_vals` (`_import_fill_invoice_line_values` on 16.0) returning `None` when `price_subtotal` is not present, it can keep returning `dict` with an extra key `price_subtotal`, and filter out unwanted line in `_retrieve_invoice_line_vals` itself. opw-5977735 Forward-Port-Of: odoo/odoo#253149 Forward-Port-Of: odoo/odoo#251463
This update ensures that session rotation is correctly disabled when a WebSocket connection closes, specifically on the `/websocket/on_closed` route. Previously, this route wasn't accounted for, potentially leading to session issues. This change enhances stability and reliability of the Odoo WebSocket functionality.
Original PR description
In [1], session rotation was disabled for websocket routes. However, the `/websocket/on_closed` route was forgotten. This commit ensures session rotation is also disabled for this route. [1]: https://github.com/odoo/odoo/pull/250826 opw-5445323 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#253615
This update copies translations from the previous Odoo 19.0 release into the current 19.1 version. The process focuses on direct module matches, ensuring consistency across the enterprise platform. A key aspect is the absence of context checks during this copy, which may require further review and adjustments to the Uzbek translations.
Original PR description
Copying translations from 19.0, only direct module matches. I.e. Missing translations were not filled in + moved terms were not matched across modules (i.e. no translation context to ensure correctness)
A recent test was failing because the system wasn't loading all necessary partner data due to a limit on the number of users loaded. This fix increases the loading limit to guarantee the correct partner information is available, preventing reporting issues. This ensures accurate data display in key reports.
Original PR description
In the test, test_pos_settle_due_with_rounding, the partner that we want to check was sometimes not loaded in the frontend due to the default limit of 100 users loaded. Those users are loaded by priority of number of orders and then name. In the test, no order has been made before so we only check the alphabetical order of the names and the partner we want to check is not always in the first 100. In the fix, we change the limits to a very big number to be sure that the partner is loaded. runbot-error: 241039
This update resolves a technical issue related to the format of XML files used for processing payments in Sweden. Specifically, a test file was updated to correctly utilize the `<BICFI>` node, ensuring compliance with Swedish banking standards. This ensures accurate payment processing and avoids potential disruptions.
Original PR description
In Sweden, pain.001.001.09 XML files should use `<BICFI>` node, not `<BIC>`. This commit fix an XML test file to use BICFI. runbot-241221 Forward-Port-Of: odoo/enterprise#109930
A warning message was appearing unexpectedly when adjusting the B1 field in French tax reports. This issue stemmed from an outdated reference within the report's calculations. This fix removes the problematic reference, ensuring accurate reporting and eliminating the warning message for French users.
Original PR description
Steps to reproduce: 1- Install Accounting and l10n_fr and switch to French company 2- Go to [Settings > Accounting] and make sure fiscal localization is set to France 3. Go to [Accounting > Reporting > Tax return] and change the Report to Tax Report (FR) 4. Make an adjustment to the B1 field Description of issue: Warning message displayed where the text does not mention B1 Expected behavior: No warning message should be displayed when editing B1 Why this happens: 'box_B1' is used in the the expression total comparison when it should not be opw-5960001 Forward-Port-Of: odoo/enterprise#110169
This update fixes an issue where selecting an office on the Jobs page would remove the previously applied country filter. The fix ensures that country filters remain active and accurate when users select offices, improving the user experience for job searches. This change was made to ensure consistent and reliable filtering functionality.
Original PR description
Steps to reproduce: =================== 1. Navigate to the Jobs page. 2. Filter a specific country 3. Select all offices -> The country filter will be removed Cause: ====== the "All Offices" link inside job_filter_by_offices, the href uses 'all_countries=1' if is_remote else current_country_path but current_country_path is not defined anywhere Solution: ========= Switch to current_country_param Note: ===== The fix will be adapted in later versions opw-5947819 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252909 Forward-Port-Of: odoo/odoo#252477
This update resolves a visual bug where icons within the HTML editor weren't correctly styled with padding. The fix ensures icons are consistently formatted upon page load, improving the editor's appearance and functionality. This was caused by a timing issue in how the editor processed elements.
Original PR description
Problem: When content is added to the editor, icons are not surrounded by `feff`s. Cause: The selector used to pad elements with `feff`s relies on `o-paragraph`, which is added during normalization. However, `BaseContainerPlugin.normalize_handlers` runs last, so when `FeffPlugin.normalize_handlers` executes, it cannot find icons through `selectors_for_feff_providers` because the expected paragraph-related parent is not yet in place. Solution: Execute `FeffPlugin.normalize_handlers` immediately after `BaseContainerPlugin.normalize_handlers`, ensuring the DOM structure is ready before attempting to add surrounding `feff`s. Steps to reproduce: - Add an icon. - Reload the page. - Do not make any changes (so normalization is not triggered again). - Inspect the icon and observe that it does not have surrounding `feff`s. task-5960097 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250855
A small technical issue preventing the PWA (Progressive Web App) from correctly installing Odoo was resolved. The fix corrected a syntax error in the PWA's CSS selector, which was causing installation problems. This ensures a smoother and more reliable PWA installation experience for users.
Original PR description
Description of the issue/feature this PR addresses:
Fixes a typo in the manifest selector used by the PWA service.
document.querySelector("link[rel=manifest") was missing the closing ], making the selector invalid.
Current behavior before PR:
Calling getManifest() could throw a DOMException due to an invalid CSS selector, preventing manifest retrieval and potentially breaking PWA install flow.
Desired behavior after PR is merged:
getManifest() correctly queries link[rel=manifest], retrieves the manifest URL, and keeps the existing manifest-fetch behavior intact (including test coverage already present in pwa_service.test.js).
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#251376This update resolves an issue where users without HR officer permissions would encounter an error when trying to open the user form. The change removes unnecessary PIN information from the main user view, streamlining access for authorized personnel while retaining the data in employee records and preferences.
Original PR description
If a person having rights to edit users is not HR officer, he gets a traceback when he tries to open the user form. As the information of PIN is not really related to the user, we left it on the employee and the "Preference" view, but remove it from the main user view --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where archived employee versions were incorrectly appearing in pay run reports. The fix ensures that only active employees are included in pay run calculations, preventing inaccurate payroll processing. This improves data accuracy and reliability.
Original PR description
Steps to reproduce: 1. Create an employee with a contract for this month 2. Archive the employee (but not the version) 3. Create a pay run 4. The employee's version will appear in the list Cause: The domain takes versions for archived employees. Fix: Add active_employee in the domain. Task: 6022437 Forward-Port-Of: odoo/enterprise#110204 Forward-Port-Of: odoo/enterprise#110073
This update prevents an infinite loop in the system's credit note processing. Previously, credit notes were incorrectly polled, causing delays. The fix restricts the polling process to only invoices, ensuring efficient claim status updates.
Original PR description
Claimed credit notes (DTE 61) were being polled indefinitely by the _l10n_cl_ask_claim_status cron. The SII endpoint listarEventosHistDoc does not support DTE 61 and always returns codResp 3 "Tipo de…
Claimed credit notes (DTE 61) were being polled indefinitely by the _l10n_cl_ask_claim_status cron. The SII endpoint listarEventosHistDoc does not support DTE 61 and always returns codResp 3 "Tipo de documento no corresponde". Since the response never contains event data, l10n_cl_claim is never set, the record permanently matches the cron domain, and polling repeats every 4 hours forever. Root cause: the cron domain included out_refund move types, but the SII endpoint used to fetch claim events does not support credit note document types. There is no point querying the SII for claim details on credit notes through this endpoint. Fix: restrict the cron domain to out_invoice only Before: claimed credit notes matched the cron domain, _get_dte_claim was called on every run, SII returned codResp 3, l10n_cl_claim stayed False, record never exited the domain. After: credit notes are excluded from the cron domain entirely and are never polled, stopping the infinite loop. opw-5933833 Forward-Port-Of: odoo/enterprise#109995
When a bill import fails, Odoo now displays a clearer message in the chat indicating an error occurred and attaching the original XML file. This prevents confusion for users who might otherwise be unsure why an empty bill was created.
Original PR description
When a bill import (including Peppol) fails, an empty bill is created with the XML attached in the chatter, which can be confusing for users. This commit adds a clearer chatter message indicating that an error occurred and that the incoming XML is attached. task-5932172 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250586
This update fixes a problem where temporary files used during report generation weren't being properly deleted after tests, leading to potential clutter. The change uses a safer method for creating temporary files, ensuring they are always cleaned up, minimizing storage usage and improving system stability. This resolves a minor technical issue with no direct impact on users.
Original PR description
Investigated after finding `/tmp/report.*` left over after running tests. #186547 left some temporal holes in the cleanup which are apparently sufficient to not correctly clean the files in some cases? Swap with `NamedTemporaryFile(delete_on_close=False)`. Forward-Port-Of: odoo/odoo#253053
This update resolves an issue where users without write access to product templates couldn't print labels. The fix adjusts how access rights are checked, now permitting label printing for users with read-only permissions. This ensures all users can utilize the product label printing functionality.
Original PR description
## Issue Users who do not have the "write" right access on `product.template` cannot print product labels. ## Steps to reproduce 1. Install *Sales* (`sale_management`) 2. In Settings > User &…
## Issue Users who do not have the "write" right access on `product.template` cannot print product labels. ## Steps to reproduce 1. Install *Sales* (`sale_management`) 2. In Settings > User & Companies > Users, make sure Marc Demo does not have any write access on `product.template` 3. Log in as Marc Demo 4. In Sales > Products > Products, open a product and click *Print Labels* from the cogwheel menu 5. **An Access Error is shown, saying that the operation is allowed for the `Products/Create` group.** ## Cause [This commit](https://github.com/odoo/odoo/commit/95ace0a694eaf83329b50e6b89f774f0c59fec5e) removed Products-related rights from the `base.group_user`. This made a difference in terms of access rights, as the `IrActionServe.run` method checks for the "write" access by calling `_can_execute_action_on_records`: https://github.com/odoo/odoo/blob/d15685304f479541879fabd55ea1cae4252a2a90/odoo/addons/base/models/ir_actions.py#L1230-L1239 When a `group_ids` field is added to the action, this check is no longer performed. opw-5914988 Forward-Port-Of: odoo/odoo#248672
A bug was preventing users from successfully deleting files within the HTML editor. This update corrects a technical issue related to how the HTML editor's removal functionality interacts with editable elements. The fix ensures that files can now be properly removed using the backspace key.
Original PR description
Steps to reproduce: =================== 1- Go to website & add a file using /file or /upload file 2- Click on the file box and press backspace -> Nothing happens. Cause: ====== After this commit [1], `is_node_editable_predicates` was added to prevent color from being applied to the file box so when removing the file box, The delete plugin's removeNode checks `isNodeEditable(node)` which returns false for the file box and thus prevents it from being removed. Solution: ========= a non-editable node that sits inside an editable parent should still be removable so now : node is not removable if !isNodeEditable(node) & its parent is also not contentEditable [1]: https://github.com/odoo/odoo/pull/226927/changes/7f4eedd76c833f3a162070563f3982a1fbdb77c7 opw-5995236 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252764
This update fixes an issue where `equity_unaffected` accounts were incorrectly using 'historical' currency rates. By reordering the CASE statement, the system now accurately applies the correct rate conversion, ensuring more precise reporting of equity values. This improves the reliability of financial reports.
Original PR description
Due to the order of the CASE statement, `equity_unaffected` accounts used 'historical' rate_type Change the order of the CASE statement. no-task Forward-Port-Of: odoo/enterprise#110112
This update addresses an issue where the Odoo upgrade process was unintentionally growing a database mapping, leading to potential performance problems. The fix ensures custom models are correctly handled during upgrades, preventing unnecessary data duplication and improving overall system stability. This change focuses on internal system improvements.
Original PR description
During upgrades we observed an uncontrolled growth of the mappings `field_depends` and `field_depends_context` in the registry. The Field instances that serve as keys are duplicated for custom models. This comes from the fact that custom models are completely reloaded during registry setup, even incremental setup. To avoid duplication we consider custom models to be re-setup, which they actually are.
Co-authored-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Xavier Dollé (xdo) <xdo@odoo.com>
Forward-Port-Of: odoo/odoo#253377This update fixes a bug in how the system calculates scrap quantities. Previously, if a product lacked a related BOM, the calculation would stop prematurely, leading to inaccurate scrap amounts. Now, all products in a recordset are correctly processed, ensuring accurate scrap quantity reporting.
Original PR description
### Description of the issue/feature this PR addresses: The `_compute_scrap_qty` method in **mrp/models/stock_scrap.py** exits early with return when a record has no BOM, preventing the computation of `scrap_qty` for remaining records in the recordset. ### Current behavior before PR: When iterating over a multi-record recordset, if any record lacks a `bom_id`, the method does return `super(...)._compute_scrap_qty()`, which exits the entire loop. Records after that one are never computed and keep the default value of 1. ### Desired behavior after PR is merged: Records without a `bom_id` delegate to `super()._compute_scrap_qty()` and the loop continues (continue) to the next record, ensuring all records in the recordset are properly computed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253368 Forward-Port-Of: odoo/odoo#252149
This update resolves an issue where users without HR access were blocked from accessing PoS settings when an incorrect employee was automatically assigned. The fix ensures that only employees from the same company as the PoS configuration are used, preventing access errors and improving usability.
Original PR description
When writing to a PoS config, it will automatically set an `advanced_employee_ids` if none is set. But it will take any employee that is part of `point_of_sale.group_pos_manager`. If the employee…
When writing to a PoS config, it will automatically set an `advanced_employee_ids` if none is set. But it will take any employee that is part of `point_of_sale.group_pos_manager`. If the employee selected is not part of the same company as the PoS config, and the current user doesn't have HR employee access it will trigger an ir.rule that block the user from opening the settings. Steps to reproduce: ------------------- * Create a new company * Create a new user that only have access to this company and no HR access * Create a PoS in the new company * Login as the new user * Try to open the settings > Observation: You will get an access error because the employee set in `advanced_employee_ids` is from the other company Why the fix: ------------ We make sure that when automatically setting the advanced_employee_ids we filter out the ones that are not from the correct company. If no employee exist that satisfies the requirements, we take a user from the `group_pos_manager` and create an employee for him. opw-5885417 Forward-Port-Of: odoo/odoo#252402
This update corrects a bug that prevented the creation of 'Cash Supplement' cash moves in German POS systems. The original system incorrectly capitalized the type, causing an error with the Fiskaly accounting software. Now, the correct casing is maintained, ensuring proper cash move processing.
Original PR description
When creating a cash move of type "Cash Supplement", the type sent was "Zuschussecht" instead of "ZuschussEcht", which caused is not an allowed type. Steps to reproduce: ------------------- * Setup a PoS with a TSS for a German localization * Start a session and open the cash control popup * Create a cash move of type "Cash Supplement" * Close the session > Observation: You get an error from Fiskaly that the type is not allowed Why the fix: ------------ When doing `.capitalize()` on a string it would make the first letter uppercase and the rest lowercase. In this case "ZuschussEcht" would become "Zuschussecht", which is not the correct type expected by Fiskaly We now keep the original casing for all the type. opw-5462364 Forward-Port-Of: odoo/enterprise#109235
This update simplifies how users manage icons within accordions. Previously, users could switch icons by clicking, which wasn't an efficient editing method. This change removes the inline icon editing option, streamlining the process and improving usability.
Original PR description
In the accordion snippet option, the user can set the icons as custom to choose them. He can do so in the sidebar with the options "Active / Inactive Icons", or by double clicking on them. Since clicking on the icon open / close the accordion item, switching from one icon to the other, it is not a practical way to edit them that way. It was decided to remove the possibility to edit the icon inline. task-5885917 Forward-Port-Of: odoo/odoo#246937
This update fixes an issue where loyalty discounts weren't applied to sales orders using foreign currencies when the order total was below a certain threshold. The change ensures that the correct currency is used to calculate discountable amounts, resolving a bug that prevented discounts from being applied in these scenarios. This improves the accuracy of loyalty program rewards.
Original PR description
When the company currency rounds on unit and we try to apply a reward on a sale order that uses another currency and that has a total of less than 0.5, no reward is applied Steps to reproduce: 1.…
When the company currency rounds on unit and we try to apply a reward on a sale order that uses another currency and that has a total of less than 0.5, no reward is applied Steps to reproduce: 1. Install Sales app and l10n_cl and loyalty module 2. Switch to CL Company 3. Go to Sales > Products > Discount & Loyalty 4. Create a new program and change the rule's minimum purchase to 0.00 5. Go to Sales and create a new quotation for customer Acme Corporation and add any product 6. Change the sale order line unit price to 0.4 and click on Reward 7. No discount is applied Problem: The company currency is used to compute the discountable amount but when this currency rounds on unit, any amount that is less than 0.5 will be considered as zero so no discount will be applied. This is because the `compute_all` method is called without specifying the currency, so we fallback on the company currency. Solution: Pass the order currency when computing the discountable amount opw-5946975 Forward-Port-Of: odoo/odoo#252756 Forward-Port-Of: odoo/odoo#250153
Claimed credit notes (DTE 61) were being polled indefinitely by the _l10n_cl_ask_claim_status cron. The SII endpoint listarEventosHistDoc does not support DTE 61 and always returns codResp 3 "Tipo de documento no corresponde". Since the response never contains event data, l10n_cl_claim is never set, the record permanently matches the cron domain, and polling repeats every 4 hours forever. Root cause: the cron domain included out_refund move types, but the SII endpoint used to fetch claim events does not support credit note document types. There is no point querying the SII for claim details on credit notes through this endpoint. Fix: restrict the cron domain to out_invoice only Before: claimed credit notes matched the cron domain, _get_dte_claim was called on every run, SII returned codResp 3, l10n_cl_claim stayed False, record never exited the domain. After: credit notes are excluded from the cron domain entirely and are never polled, stopping the infinite loop. opw-5933833 Forward-Port-Of: odoo/enterprise#109995
This update fixes an issue where timesheet descriptions were not consistently grouped after edits within the grid view. The fix ensures that new timesheet lines created from updated values retain the original description, maintaining accurate reporting and organization of timesheet data. This improves the usability and reliability of the timesheet feature.
Original PR description
To reproduce: ============= - on timesheet group by Project > Task > Description - on a line with a description, update a 0:00 cell to an other value - refresh or change view to list and back to grid - a new line with description '/' is created with the updated value Problem: ======== when creating the new timesheet it's by default given the name '/' which for the grid view is not in same group as the original line with the description. Solution: ========= when creating the new timesheet, we give it the same description as the original line. opw-5909249 Forward-Port-Of: odoo/enterprise#108894
Resolved issues and error corrections
This update resolves a technical problem that prevented users from correctly filtering job postings within the website's HR recruitment module. The issue stemmed from an unsupported comparison operator ('==') when dealing with recordsets in the filters. This fix ensures the job filter functionality works as intended for all users.
Original PR description
When `selection` is a recordset, `==` is an unsupported operand type
This update enhances the 'My Team' filter in Live Chat reports to accurately reflect the team members of the current user and their direct managers. Previously, the filter was limited to department-based reporting, now it provides a more comprehensive view of team members, improving reporting accuracy and team management insights.
Original PR description
Replace the department-based domain with a hierarchy-based domain in livechat reports. The new filter includes the current user's records and the records of employees whose manager is the current user. task-6030147 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a test issue where simultaneous data synchronization within the Point of Sale (POS) tax module caused errors. The fix ensures that backend processes complete before the test continues, improving test reliability and stability. This enhances the overall quality of the POS tax functionality.
Original PR description
In the test test_pos_avatax_flow, two calls are made to get_order_tax_details almost simultaneously, which causes the second call to raise an error due to both call trying to sync the same order at the same time. This commit fixes the test by waiting for the backend calls to be done before proceeding with the test next steps. runbot-error: 238871, 238872
This update resolves an issue where upload widgets within dropdown menus on small screens wouldn't function correctly. The fix ensures that clicking the dropdown item doesn't immediately close it, allowing the widget action to complete successfully. This improves usability for users accessing Odoo on mobile devices.
Original PR description
## Issue: On small screens, when an upload widget is placed inside a dropdown (e.g., Upload Bill from a Purchase Order), the action does not work Clicking the dropdown item closes the dropdown immediately, which prevents the widget action from completing ## Cause: Widget actions require an accessible anchor element to function properly. However, dropdown items automatically close the dropdown on click As a result, the widget is triggered but immediately detached from the DOM before its action can fully execute ## Steps to reproduce: - Install `purchase_stock` (to have the Upload Bill widget available) - Create and confirm a Purchase Order (the Receive button must be available) - Reduce the browser width until the action buttons collapse into the three-dots menu - Click Upload Bill and try to upload a document opw-5918379
This update prevents an infinite loop in the system's credit note processing. Previously, credit notes were incorrectly polled, leading to unnecessary checks. The fix restricts the polling process to only invoices, ensuring efficiency and stability.
Original PR description
Claimed credit notes (DTE 61) were being polled indefinitely by the _l10n_cl_ask_claim_status cron. The SII endpoint listarEventosHistDoc does not support DTE 61 and always returns codResp 3 "Tipo de…
Claimed credit notes (DTE 61) were being polled indefinitely by the _l10n_cl_ask_claim_status cron. The SII endpoint listarEventosHistDoc does not support DTE 61 and always returns codResp 3 "Tipo de documento no corresponde". Since the response never contains event data, l10n_cl_claim is never set, the record permanently matches the cron domain, and polling repeats every 4 hours forever. Root cause: the cron domain included out_refund move types, but the SII endpoint used to fetch claim events does not support credit note document types. There is no point querying the SII for claim details on credit notes through this endpoint. Fix: restrict the cron domain to out_invoice only Before: claimed credit notes matched the cron domain, _get_dte_claim was called on every run, SII returned codResp 3, l10n_cl_claim stayed False, record never exited the domain. After: credit notes are excluded from the cron domain entirely and are never polled, stopping the infinite loop. opw-5933833 Forward-Port-Of: odoo/enterprise#109995
This update fixes an issue where resending invoices to MER would overwrite existing addendums, even if the invoice hadn't been sent. The change ensures that existing addendums are updated instead of replaced, streamlining the resend process and preventing data loss. This improves invoice processing reliability.
Original PR description
Issue: when resending an invoice already sent to MER, the existing addendum is overwritten even when the invoice is not sent to MER. Solution: updating values on the existing addendum rather than creating a new one, if it already exists. task-none --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253281
This update resolves a minor issue where the helpdesk tour would intermittently fail due to timing problems when creating new tickets. The fix ensures the tour waits for the kanban view to fully load before attempting to click the 'New' button, improving overall tour reliability. This prevents the tour from incorrectly targeting elements on the page.
Original PR description
This PR fixes a flickering failure in the `helpdesk_tour` ### Problem In the kanban view, the tour occasionally tried to click the "New" (quick create) button before the view's internal structure was fully painted. This caused the tour to click a wrong element. ### Solution Updated the step trigger to include a selector for the kanban group (`.o_kanban_group`). By requiring the presence of the group container, we ensure that: 1. The page content has actually loaded. 2. The specific "New" button within the kanban context is visible and ready. **Runbot ID: 223081**
This update resolves an issue where clicking on 'reply' links within Odoo mailboxes didn't function correctly. The change ensures that clicking on a reply link now automatically jumps to the original message thread, improving the user experience and streamlining communication workflows. This fix enhances the usability of the mail functionality.
Original PR description
Before this change, clicking on a `message in reply` in mailboxes had no effect. The expected behavior is for it to jump to the message in its origin thread. To fix it, this commit ensures that `useMessageHighlight` hook receives the correct thread which in this case is the origin thread of the message in reply. task-5343804 Forward-Port-Of: odoo/odoo#253589 Forward-Port-Of: odoo/odoo#253334
This update resolves an issue that prevented users from copying spreadsheets within Odoo. The fix corrects a technical error that disabled the copy button, ensuring users can now seamlessly duplicate spreadsheets as needed. This improves usability and efficiency for spreadsheet-based workflows.
Original PR description
Fix error which disabled the copy button. 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
A bug preventing users from copying spreadsheets has been resolved. This update corrects a technical error that disabled the copy button, ensuring seamless spreadsheet functionality for all users. This fix improves the user experience and prevents data loss.
Original PR description
Fix error which disabled the copy button.
This update fixes an issue where timesheet descriptions were not consistently grouped after edits within the grid view. The fix ensures that when a timesheet line is updated, a new line with the same description is created, maintaining accurate grouping and reporting. This improves data clarity and accuracy for timesheet management.
Original PR description
To reproduce: ============= - on timesheet group by Project > Task > Description - on a line with a description, update a 0:00 cell to an other value - refresh or change view to list and back to grid - a new line with description '/' is created with the updated value Problem: ======== when creating the new timesheet it's by default given the name '/' which for the grid view is not in same group as the original line with the description. Solution: ========= when creating the new timesheet, we give it the same description as the original line. opw-5909249 Forward-Port-Of: odoo/enterprise#108894
This update prevents an infinite loop in the system's claim status polling process for credit notes (DTE 61). The fix restricts the polling domain to only invoices, addressing a technical issue where the system incorrectly processed credit notes through the SII endpoint. This ensures efficient system performance and accurate claim status reporting.
Original PR description
Claimed credit notes (DTE 61) were being polled indefinitely by the _l10n_cl_ask_claim_status cron. The SII endpoint listarEventosHistDoc does not support DTE 61 and always returns codResp 3 "Tipo de…
Claimed credit notes (DTE 61) were being polled indefinitely by the _l10n_cl_ask_claim_status cron. The SII endpoint listarEventosHistDoc does not support DTE 61 and always returns codResp 3 "Tipo de documento no corresponde". Since the response never contains event data, l10n_cl_claim is never set, the record permanently matches the cron domain, and polling repeats every 4 hours forever. Root cause: the cron domain included out_refund move types, but the SII endpoint used to fetch claim events does not support credit note document types. There is no point querying the SII for claim details on credit notes through this endpoint. Fix: restrict the cron domain to out_invoice only Before: claimed credit notes matched the cron domain, _get_dte_claim was called on every run, SII returned codResp 3, l10n_cl_claim stayed False, record never exited the domain. After: credit notes are excluded from the cron domain entirely and are never polled, stopping the infinite loop. opw-5933833 Forward-Port-Of: odoo/enterprise#109995
This update resolves an issue where timesheet descriptions were being duplicated when updating timesheet entries. Specifically, when a time entry was modified, a new, incorrect description was created. The fix ensures that the new timesheet entry retains the original description, maintaining data accuracy and consistency within the timesheet view.
Original PR description
To reproduce: ============= - on timesheet group by Project > Task > Description - on a line with a description, update a 0:00 cell to an other value - refresh or change view to list and back to grid - a new line with description '/' is created with the updated value Problem: ======== when creating the new timesheet it's by default given the name '/' which for the grid view is not in same group as the original line with the description. Solution: ========= when creating the new timesheet, we give it the same description as the original line. opw-5909249 Forward-Port-Of: odoo/enterprise#108894
This update simplifies the naming of joint committees within the Odoo Enterprise system. By removing redundant prefixes and moving data to a CSV file, the system is now more efficient and easier to maintain. This change improves data clarity and reduces complexity.
Original PR description
Almost all joint committees start with the same ""(Sub-)(Sub-)Joint Committee for (the)". This is unnecessary as the field is already called Joint Committee. This removes those unnecessary prefixes and also move the data to a csv for concise code. Task: 6025737
This update streamlines the Live Chat experience by reorganizing form views and standardizing the associated copy. The changes group related actions together for easier access and improve the overall clarity of the Live Chat interface. This enhancement aims to make Live Chat more intuitive and efficient for users.
Original PR description
community PR: https://github.com/odoo/odoo/pull/253027 This commit improves the form views related to Live Chat by: 1. Reordering the action buttons to group chat related actions together. 2. Harmonizing the Live Chat copywriting. task-6018898
Resolved issues and error corrections
This update corrects a technical issue in the timesheet grid that prevented proper task state resets. Adding a missing 'super()' call ensures the parent method executes correctly, maintaining the integrity of timesheet data. This resolves a minor bug impacting timesheet accuracy.
Original PR description
The `_onchange_project_id` override was missing a `super()` call, which prevented the parent method (responsible for resetting the task state) from executing. This commit adds the missing super call. task-4210148
This update resolves an issue preventing users from successfully exporting new modules through the Odoo Studio tour. The change removes a problematic flag and adds a wait step to ensure the home menu is fully loaded, guaranteeing a smoother and more reliable experience for users.
Original PR description
This commit marks the 'can_export_new_module' tour as stable by removing the 'undeterministicTour_doNotCopy' flag. A new step has been added to wait for the home menu to be fully loaded before proceeding to open Studio.
This update corrects a visual problem with the appointment form grid, ensuring that all appointment details are displayed correctly. The change prevents a broken layout that was impacting user experience when viewing appointment records. This ensures consistent and accurate appointment data display.
Original PR description
opw-6036938
This update corrects a bug where copying product records after creation didn't function correctly due to a context key. Previously, tests were incorrectly passing, masking a fundamental problem. The fix ensures tests accurately reflect product creation behavior, improving overall system reliability.
Original PR description
Copy of `product.product` records wasn't working as expected when called on records returned by a `create` call, as they had a context key disabling product creation. Since this is now fixed (see counterpart PR), some enterprise tests were failing as they wrongly assumed the copy worked as expected, previously making some assertions succeed regardless of the absence of a product.
This update ensures all Odoo reports consistently include the 'has_sublines' key in their results. Previously, some reports lacked this key, causing confusion for developers and potential issues with report functionality. This change improves the reliability and predictability of our reporting engine.
Original PR description
Some reports doesn't return the has_sublines key in their results which can be confusing for developers and can be a source of issues. This PR ensures that it's not the case anymore. task-id: 4896816
A recent update caused crashes when creating and saving YouTube posts in Odoo. This fix removes outdated references to a 'name' attribute within the social_youtube module, resolving the issue. The change ensures stable post creation without impacting core functionality.
Original PR description
Bug: Following recent changes introduced in saas-19.2, creating and saving a YouTube post causes the flow to crash. Cause: A refactoring in the social module removed the `utm.source.mixin` dependency from the `social_post` model. This consequently removed the `name` attribute from the model. However, `social_youtube` still expected this attribute to exist, triggering the crash. Solution: Remove all references to the `name` attribute within the `social_youtube` module. We opted not to reintroduce the attribute on the model because it did not add significant functionality and has been superseded by other attributes. Forward-Port-Of: odoo/enterprise#109203
This update fixes an issue where customers could inadvertently set subscription start dates to 'false,' leading to incorrect invoicing. The change prevents users from removing the start date, ensuring subscriptions are properly billed and tracked. This maintains accurate subscription records and prevents revenue discrepancies.
Original PR description
**Issue** Some customers were removing the `start_date` of subscriptions, leading to the subscription being considered free on the next invoicing. While there are legitimate use cases to edit the `start_date` of a running subscription, it should probably not be removed. opw-5325303 Forward-Port-Of: odoo/enterprise#104925
This update resolves an error that prevented the generation of customer statement reports. The issue stemmed from a missing domain variable, causing a type error. The fix ensures the domain is always provided, guaranteeing correct report output and preventing failed email previews and PDF generation.
Original PR description
**Steps to reproduce:** * Install the **l10n_my_reports** module. * Go to `Accounting > Reporting > Partner Ledger`. * Change report to `Customer Statement`. * Add data in the report and click Send. * In the email template, set the `dynamic reports` as `statement of accounts` under the options tab. * Click Preview. **Observed behavior:** * Error: `TypeError: Domain() invalid argument type for domain: None` * Email preview fails and PDF cannot be generated. **Cause:** * The `statement_account_document` template uses `filtered_domain(domain)` but the domain variable was not being passed to the template context by the `_get_report_values` method, resulting in None being passed to `filtered_domain()`. **Fix:** * Ensure domain is always present in the report context, defaulting to an empty list when not provided. * Added safe handling for missing data and context parameters. opw-5880385 Forward-Port-Of: odoo/enterprise#107400
This update fixes a potential issue with Instagram polls by ensuring the system only requests the poll's ID after it's successfully published. Previously, attempting to retrieve the ID prematurely could cause errors. The changes include updated tests to simulate the Instagram API's behavior and prevent future problems, ensuring poll data is reliably fetched.
Original PR description
Follow-up to 06256aa02cb92378933edd638259dd725a2d04c1 The Instagram API returns an error if the `ig_id` field is requested while the container is still processing. This commit splits the container status check into two steps: 1. Poll for `status_code` only to determine the current state. 2. If the status is `PUBLISHED`, perform a second request to fetch the `ig_id`. Updated the test mocks to simulate this restriction, ensuring that requesting `ig_id` on a non-published container results in a 400 error to prevent future regressions. opw-5081325 Forward-Port-Of: odoo/enterprise#110094
This update fixes a technical issue preventing HR modules from properly customizing VoIP contact information. The change ensures VoIP data aligns with how it's stored in the system, maintaining consistency and allowing for future flexibility in how VoIP interacts with other business processes. This improves the reliability of VoIP data across the enterprise.
Original PR description
`_store_voip_fields` was directly adding `"im_status"` to the stored partner fields. This bypassed `_store_im_status_fields`, so module overrides (notably HR-related ones) could not extend/adjust the IM status payload. Use `_store_im_status_fields(res)` from `_store_voip_fields` instead of hardcoding `"im_status"`. Also align the VoIP mock server `res.partner` contact payload with the real store payload by including the same contact fields and IM status data (`partner_share`, `im_status`, `im_status_access_token`, etc.). This keeps VoIP aligned with the extensibility contract and keeps tests on the same data shape as runtime. [H>A] Forward-Port-Of: odoo/enterprise#110070
A minor bug fix has been implemented to ensure the correct field for account numbers is being used in the account_online_payment module. This prevented a technical error and ensures data is processed accurately. The change improves system stability.
Original PR description
Due to an oversight during https://github.com/odoo/enterprise/pull/109070, the old field `sanitized_acc_number` was used instead of the new one `sanitized_account_number` This causes a traceback. No task ID Forward-Port-Of: odoo/enterprise#110266
This update corrects a calculation error in the HRA (House Rent Allowance) rules for Indian employees. The change ensures that HRA percentages are accurately applied, aligning with standard India payroll practices. This update improves the consistency and accuracy of employee compensation calculations.
Original PR description
… fields - compute HRAMN from categories['BASIC'] with result_rate = l10n_in_hra_percentage * 100 - add python condition to skip the rule when HRA percentage is zero - keeps ind_emp behavior consistent with regular India payroll rules task-5964270 Forward-Port-Of: odoo/enterprise#108507
Code cleanup and technical improvements
This update simplifies how data is grouped within key Enterprise modules like Knowledge, Gantt, and Studio. The team has switched to using the standard JavaScript `Object.groupBy` method, aligning with recent changes in the core Odoo system. This improves efficiency and reduces potential future maintenance challenges.
Original PR description
**This PR:** Migrates Enterprise call sites to the native **`Object.groupBy`** API, following its removal from core. ### Key Changes * **Migration:** Updated call sites in Knowledge, Gantt, and Studio. * **Refactor:** Converted string criteria to callbacks and removed unused imports. **Task-5477775**
This update standardizes the naming of resources within several Odoo website plugins. Specifically, a naming inconsistency was corrected to improve code organization and maintainability. This change ensures a more consistent and manageable codebase for future development.
Original PR description
*: website_appointment, website_sale_renting This commit renames `so_content_addition_selector` to `so_content_addition_selectors` to enforce the use of coherent naming among plugin resources. Community PR: https://github.com/odoo/odoo/pull/247166 task-5363816
This update prepares our Odoo templates for OWL3 by adding the `.this` syntax to template variables. This is necessary because OWL3 requires template variables to explicitly target component variables, ensuring compatibility with the new rendering context. This change impacts several spreadsheet-related modules to ensure a smooth transition.
Original PR description
*documents_spreadsheet,hr_contract_salary,project_enterprise, sale_timesheet_enterprise,spreadsheet_dashboard_edition, spreadsheet_edition,spreadsheet_sale_management, test_spreadsheet_edition,timesheet_grid In preparation for OWL3, where template variables will need to use `.this` to target component variables, we add `.this` to template variables that are targetting the component. Script PR: odoo/odoo#247965 task: OWL3 prep - add this. to template variables
This update prepares our Point of Sale system for OWL3, a new version of Odoo. It modifies template variables to use `.this`, which is now required to correctly target component variables. This ensures the POS system functions correctly with the updated Odoo version.
Original PR description
In preparation for OWL3, where template variables will need to use `.this` to target component variables, we add `.this` to template variables that are targetting the component. Community PR: https://github.com/odoo/odoo/pull/253046 Script PR: odoo/odoo#247965 task: OWL3 prep - add this. to template variables
Problem: A bug occurs when an internal user with "Edit" rights to a spreadsheet is archived. Upon archiving, the user transitions to an external user, a state where "Edit" rights are strictly prohibited. However, due to a validation error in the access rights wizard, users were unable to fix this. Cause: The validation logic in `documents_sharing.py` performed checks after any action was taken. If an illegal configuration was detected, it set a flag to hide the Save button. Because the check did not distinguish between adding an illegal rule and deleting one, users were blocked from removing the very records causing the validation failure. Solution: The validation checks have been updated to account for the operation- type (addition or deletion). This ensures that while new illegal rules are still blocked, existing illegal rules can be successfully removed to restore the system to a valid state. A test was also added to prevent this problem form happening in the future. This PR applies uses the solution to fix the state of 3 warnings, ensuring they are only displayed when actually relevant. Specifically, it covers: - The warning triggered when removing external users with edit access in `documents_spreadsheets`. - The `has_warning_no_access` warning in documents. - The `has_warning_link_with_more_rights` warning. task-5902391
This update resolves an issue where removing an EPD line in bank reconciliation incorrectly removed associated tax lines. Now, only the EPD line and its corresponding tax line are properly removed, ensuring accurate reconciliation reporting. This improves the reliability of bank statement processing.
Original PR description
When removing an EPD line in the bank rec widget, if the invoice line added to the statement line contained a tax, the invoice line was removed aswell. Now, only the EPD line and its tax line are removed. no-task
This update fixes an issue where fields at the bottom of the barcode editing page were hidden behind buttons. The fix allows users to scroll through the fields, ensuring all data entry options are visible regardless of button display. This enhances usability for barcode operations.
Original PR description
# How to reproduce - Set the barcode of a product - Go to Barcode > Operations > (Select any operation) > New - Click on the cog in the top right and type in the barcode you set for the product - Apply and then edit the item you added - Add options to the page (like Expiration Date) or increase the browser's zoom until the list of fields take the whole page # The problem The fields at the bottom of the page are hidden behind the buttons at the bottom # Why The controls at the bottom are positioned absolutely and with a high z-index, so they hide anything behind them. The form css class fixes this issue by adding a margin-bottom roughly the size of the controls. But this fix does not take into account the fact that the controls can grow in size when the DELETE button is displayed opw-5907564
This update fixes a labeling issue in the invoice payment widget for Indian companies using the l10n_in_withholding module. Previously, TDS entries incorrectly displayed 'Paid on' instead of 'TDS on,' causing confusion. This change ensures accurate labeling for tax withholdings, improving clarity and compliance.
Original PR description
### Issue before this commit: When generating a TDS entry for an Indian company, the payment widget on the invoice incorrectly displays the label "Paid on" instead of "TDS on," failing to distinguish…
### Issue before this commit: When generating a TDS entry for an Indian company, the payment widget on the invoice incorrectly displays the label "Paid on" instead of "TDS on," failing to distinguish tax withholdings from standard payments. ### Steps to reproduce the issue: 1. Install l10n_in and switch to IN company 2. Go to settings and activate TDS and TCS 3. Create an invoice setting a certain price and confirm it 4. Click on the 'TDS entry' button 5. Set a random TDS tax and the base amount equal the one of the invoice 6. Confirm it and see there is the label "Paid on" and not "TDS on" ### Cause of the issue: The invoice payments widget determines the label displayed for each reconciled entry based on predefined flags. However, entries created for TDS withholding were not explicitly identified in the widget data. As a result, these entries were treated as regular payments and the label "Paid on" was displayed instead of a more appropriate label indicating that the entry corresponds to a TDS withholding transaction. ### Reason to introduce the fix: The label "Paid on" is conceptually incorrect for TDS transactions because no actual payment or cash outflow has occurred since TDS is a tax withholding rather than a monetary settlement. Using "Paid on" creates confusion for the user, as it implies a transfer of funds that does not exist in this context. opw-5952700 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a technical issue preventing the correct generation of Luxembourg's SAFT reports when dealing with multi-currency transactions. The fix ensures the necessary currency information is included in the report template, allowing accurate reporting for vendors and compliance.
Original PR description
Steps to reproduce 1/ setup a LU company. The default company currency will be EUR. 2/ create a vendor bill in another currecy (e.g. USD) 3/ take note of the bill date and accounting date (ideally set them in the past, like 1 month) 4/ generate the FAIA report for the period containing the created bill => error while rendering the qweb template The core of the error is when rendering the l10n_lu saft template. Sales invoices and purchase invoices reuse the standard `account_saft.tax_information` report, which expects to find `currency_code` in the object's fields. This commit explicitly re-adds it when creating the document's tax summary. opw-5216057 Forward-Port-Of: odoo/enterprise#106902
This update resolves an issue where GS1 barcode filtering in the stock module would fail due to an incorrect date interpretation. The fix prevents validation errors from blocking product filtering, ensuring internal transfers are correctly processed based on barcode data. This improves the reliability of barcode-based product selection.
Original PR description
Steps to reproduce: - Activate the GS1 nomenclature - Create a product "P1" with the barcode: 15099590225865 - Create an internal transfer with one unit of P1 - Go to Barcode > Operations > Internal…
Steps to reproduce: - Activate the GS1 nomenclature - Create a product "P1" with the barcode: 15099590225865 - Create an internal transfer with one unit of P1 - Go to Barcode > Operations > Internal Transfers - Scan the barcode: 15099590225865 to filter transfers by this product barcode Problem: An validation error is raised: A ValidationError is raised: "A GS1 barcode nomenclature pattern was matched. However, the barcode failed to be converted to a valid date." Explanation: GS1 barcodes must follow a strict nomenclature based on well-defined rules. For example, a GS1 product barcode should start with the Application Identifier 01 followed by 14 digits. The GS1 parser processes the barcode rule by rule and applies the first matching rule. In this case, the barcode 15099590483921 is interpreted as a date because it starts with "15", which corresponds to a GS1 Application Identifier for a date. As a result, the parser attempts to convert the first six digits into a date and raises a ValidationError. Solution: Catch the ValidationError raised during GS1 date parsing in filter_on_barcode and explicitly reset parsed_results to False, allowing the normal filter on product resolution logic to continue. This prevents GS1 parsing errors from blocking valid barcodes and ensures that product is correctly filtered opw-5929064
This update fixes an issue where timesheet descriptions were not consistently updating when values were changed within the grid view. The fix ensures that new timesheet lines created after a value update retain the original description, maintaining accurate reporting. This improves data integrity and user experience.
Original PR description
To reproduce: ============= - on timesheet group by Project > Task > Description - on a line with a description, update a 0:00 cell to an other value - refresh or change view to list and back to grid - a new line with description '/' is created with the updated value Problem: ======== when creating the new timesheet it's by default given the name '/' which for the grid view is not in same group as the original line with the description. Solution: ========= when creating the new timesheet, we give it the same description as the original line. opw-5909249 Forward-Port-Of: odoo/enterprise#108894
This update resolves a problem where account move references were sometimes missing when the l10n_jo_edi_pos module was installed. The fix ensures that the 'ref' field in account moves created from POS orders is correctly populated, regardless of the country setting. This prevents errors and ensures proper accounting processing.
Original PR description
Before this commit, an override of _prepare_invoice_vals in l10n_jo_edi_pos was setting the ref field of the created account move to l10n_jo_edi_pos_return_reason, which was False when the country was not Jordan. This was causing the ref to be unset for every move created from a pos order when the module was installed but the field l10n_jo_edi_pos_return_reason was not set. This is now fixed by taking the value of the field if set, else take the original value. runbot-error: 241014 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update copies translations from the previous Odoo 19.0 release to the 19.1 SaaS version. The translations were focused on direct module matches, but didn't account for context across modules, potentially leading to inconsistencies. This ensures a consistent user experience across all Odoo 19.1 modules.
Original PR description
Copying translations from 19.0, only direct module matches. I.e. Missing translations were not filled in + moved terms were not matched across modules (i.e. no translation context to ensure correctness) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr