Tuesday, May 27, 2025
33 changes · 18.0
Enhancements to existing features
When users create a new account move, the cursor now starts in the next editable field instead of the displayed name field. This helps prevent accidental changes to document numbering or sequence information during data entry.
Original PR description
made the default focus to be the next editable field in the form view when people create a new account move the cursor focus on the desplayed name so people tend to mess up the sequence so we changed the focus to the next editable field to not mess up the sequence task-4558713 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
Resolved issues and error corrections
Point of Sale session reports now correctly show counted amounts when bank payments include refunds or other negative transactions. This prevents mismatched payment totals and gives businesses more reliable end-of-session reporting.
Original PR description
Before this commit, if a session included negative bank payments resulting in a negative total, the session report displayed incorrect counted amounts and mismatched values for the bank payment method. opw-4714251 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Versions -------- - 17.0+ Steps ----- 1. Create a new internal user with some administrator rights; 2. set notification preference to "Handle in Odoo"; 3. save changes; 4. switch user type to portal. Issue ----- Validation Error: The user cannot have more than one user types. Cause ----- In the write method of `UsersImplied`, a check happens on whether a user was demoted, by saving the internal users before `super().write`, and comparing it to the internal users after `super(
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Create a new internal user with some administrator rights; 2. set notification preference to "Handle in Odoo"; 3. save changes; 4. switch user type to portal.…
Versions -------- - 17.0+ Steps ----- 1. Create a new internal user with some administrator rights; 2. set notification preference to "Handle in Odoo"; 3. save changes; 4. switch user type to portal. Issue ----- Validation Error: The user cannot have more than one user types. Cause ----- In the write method of `UsersImplied`, a check happens on whether a user was demoted, by saving the internal users before `super().write`, and comparing it to the internal users after `super().write`[^1]. [^1]: https://github.com/odoo/odoo/blob/6ba1106aecf71886b7df3b7943089fa72a6c506c/odoo/addons/base/models/res_users.py#L1455-L1457 This was working fine until commit 141852dc6613c introduced the `_inverse_notification_type` method[^4]. It adds or removes the `mail.group_mail_notification_type_inbox` group from users when the `notification_type` gets changed. [^4]: https://github.com/odoo/odoo/blob/6ba1106aecf71886b7df3b7943089fa72a6c506c/addons/mail/models/res_users.py#L54-L58 In our first call to `UsersImplied.write`, we store the user as an internal user and call `super().write`. This unlinks `base.group_user`, links `base.group_portal` and sets `notification_type` to `email`. Before returning from `super().write`, the `_inverse_notification_type` method gets triggered to unlink the inbox group, which will lead to a recursive call to `UsersImplied.write`. The recursive call no longer registers the user as internal or being demoted, hence it will re-add `base.group_user` as an implied group[^2] of its still present administrator group, leading to the `api.constrains` violation in `_check_one_user_type`[^3], as we already have the `base.group_portal` group. [^2]: https://github.com/odoo/odoo/blob/6ba1106aecf71886b7df3b7943089fa72a6c506c/odoo/addons/base/models/res_users.py#L1466-L1469 [^3]: https://github.com/odoo/odoo/blob/6ba1106aecf71886b7df3b7943089fa72a6c506c/odoo/addons/base/models/res_users.py#L589-L599 Solution -------- Add a context value when calling `super().write`. If this value is present in the current call, this indicates we are in a recursive write, and can return without adding/removing implied groups, as these will get handled later by the base call. opw-4676929 Forward-Port-Of: odoo/odoo#207961
This fix prevents pivot report exports from crashing when a numeric field is used in the row grouping. Business users can now download CSV or Excel exports from affected reports reliably, including reports such as Sales Analysis.
Original PR description
Steps to reproduce: - Go to any Report (Ex: Sale Analysis) - Switch to the pivot view - Add on y-column any **int** field - Download as csv Tracebrack is thrown, because the controller tries to concat int to str in the csv generated file. opw-4762807 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
Invoice PDFs now handle unusually long tax group names without pushing the total amount off the page. This keeps invoice totals readable and avoids layout problems when printing or sharing invoices.
Original PR description
**Issue** When the tax group name is too long, it pushes the total amount off the page in the invoice PDF, making the amount unreadable. **Steps to Reproduce** 1. Install the Accounting module. 2. Go to Taxes. 3. Select a tax and open Advanced Options. 4. Set a very long name for the tax group. 5. Go to Accounting > Customers > Invoices. 6. Create and confirm an invoice using the tax with the long group name. 7. Print the invoice PDF and observe the layout issue. **Root Cause** The text-nowrap CSS class prevents the tax group name from wrapping, causing it to expand the table cell width and push the amount outside the page boundary. **Fix** Remove the text-nowrap class and apply a maximum width to the <td> element, allowing the tax group name to wrap or truncate properly without overlapping or pushing the total amount off the page. Opw-4795941 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Calendar popovers now display each task property with its own label instead of reusing the general container label. This makes custom property information clearer and consistent with how standard fields are shown.
Original PR description
Backport of 18affd81cbdd321e428b729602f91dc06988929f Steps: ------ * Add properties (displayed on card) to a task of a project * Open the card view of the task in the calendar view of the project Previously, the calendar popover displayed property field values using the label of the container field. This commit updates the behavior to display each property field with its respective label, ensuring consistency with the appearance of standard fields. opw-4767059 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes an issue in the homeworking calendar where changing the time format could trigger an error when moving between calendar views in debug mode. This makes calendar navigation more reliable for users who adjust time display settings.
Original PR description
**Issue**:
an error is thrown in debug mode when switching between calendar views ("year", "week", etc.) after changing the time format.
**Steps to reproduce:**
- ensure hr_homeworking_calendar is installed
- activate debug mode
- Calendar > change the time format
opw-4684831The Point of Sale mobile screen now keeps the search dropdown visible above the orders list. This fixes an issue that made searching orders difficult or unusable on smaller screens.
Original PR description
The search field dropdown was being rendered behind the orders list in mobile view, making it unusable. This commit adds a higher z-index to the search field dropdown to ensure it's rendered above the orders list. opw-4654710 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users can now add a Pricer Sales Pricelist while creating a product variant before it has been saved. This prevents an error that interrupted product setup and improves the reliability of the product form workflow.
Original PR description
An error occurs when a user attempts to set the **Pricer Sales Pricelist** on a product variant that has not yet been saved. **Steps to reproduce:** - Install the `pos_pricer` module. - Open the form view of **Product Variants**. - Without saving the record, try to add a **Pricer Sales Pricelist**. - Observe the error. **Error:** `KeyError: False` **Cause:** When the product variant is unsaved, `product.id` is `False`, leading to a `KeyError` at [1], because `False` is not a valid key in the result of method `_compute_price_rule()`. [1] - https://github.com/odoo/odoo/blob/d352cfcfe0fe8c161392f3c39ea3e64b7c98bd69/addons/product/models/product_pricelist.py#L140 This commit ensures that users can add a 'Pricer Sales Pricelist' to a product variant, even before saving it. Sentry - 6598605111
Website editors can now delete all text from a button, save the page, and still edit that button later. This prevents buttons such as “Apply Now!” on job pages from becoming inaccessible after content cleanup.
Original PR description
Problem: When the "Apply Now!" button text is deleted (e.g., on `/jobs/experienced-developer-4`), it becomes uneditable after saving. Cause: When all text is deleted, a zero-width space (ZWS) is…
Problem: When the "Apply Now!" button text is deleted (e.g., on `/jobs/experienced-developer-4`), it becomes uneditable after saving. Cause: When all text is deleted, a zero-width space (ZWS) is inserted with the `data-oe-zws-empty-inline` attribute. This is removed during the save process. Since the button has `data-oe-field="arch"` and becomes empty, it is excluded from editable areas in `_getContentEditableAreas`, making it uneditable after reload. This worked in 17.0 due to inherited `display: block` from a floated parent, which added a `<br>` in empty blocks. Solution: Preserve the ZWS for inline empty elements with `data-oe-field="arch"`, ensuring the element remains editable after save. Steps to reproduce: 1. Navigate to `/jobs/experienced-developer-4`. 2. Open the web editor. 3. Delete the text inside the "Apply Now!" button. 4. Save the page. 5. Reopen the web editor. → The button is no longer editable. opw-4737255 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue in the HTML editor where pressing Tab inside a table header cell could cause an error. Users can now navigate tables with header cells more reliably without interrupting their editing work.
Original PR description
Problem: `shiftCursorToTableCell` is not considering being inside `th` which causes traceback as `currentTd` will be null. Solution: Include `th` in the selector alongside `td` to ensure proper detection and navigation. Steps to reproduce: - Copy and paste in the editor any table that has `th`. - Put selection inside a `th` element. - Press "TAB". → Traceback occurs. opw-4808751 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Document tags can now display the custom tooltip text set by users instead of always showing the tag name. This makes tag details clearer when hovering over tags in document views and avoids misleading or incomplete hover text.
Original PR description
Before this commit --- The tooltip shown on hover over document tags was always the tag name. This ignored the "Tooltip" field available on document tags. (The tooltip was not fetched.) After this commit --- We fetch and display the custom tooltip defined in the "Tooltip" field of the tag. Reproduce --- - install documents - add "Tooltip" string to a TAG in Documents/Configuration/Tags - open documents kanban view and over onto the TAG - BUG: tag name is apearing on hover (instead of tooltip string) opw-4567814 A sibling https://github.com/odoo/enterprise/pull/79496 updating xml and utilizing this change
This fix makes list column width handling more reliable, especially for right-to-left layouts and custom integrations that may not pass newer options. It helps prevent display issues or errors in list views while preserving compatibility for existing custom code.
Original PR description
This commit is a followup of [1]. It does two things: 1) it fixes the "rtl" check that was forwardported from 16.0, where the callback was defined in the renderer and for which `this` was…
This commit is a followup of [1]. It does two things: 1) it fixes the "rtl" check that was forwardported from 16.0, where the callback was defined in the renderer and for which `this` was unambiguously the renderer. As of 18.0, the code was moved to an hook, so using `this.isRTL` worked, but kind of by chance. This commit removes the ambiguity and makes the code a bit more robust. 2) using the newly added parameters `options` in `listViewWidths` callbacks looked harmless. Indeed, it causes no issue in standard odoo. However, as reported in [2], there is a world where `options` is undefined. I couldn't really find how, as it works fine even with the suggested culprit [3]. So this commit simply adds a fallback, which makes sense in stable in case there would be custom code calling those `listViewWidths` functions without options. In master though, we expect from people to adapt their code with respect to this change. [1] https://github.com/odoo/odoo/pull/210584 [2] https://github.com/odoo/odoo/issues/211243 [3] https://github.com/OCA/web/tree/18.0/web_remember_tree_column_width closes #211243 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
Updates internal test data so tax group receivable and payable accounts follow the latest accounting validation rules. This helps ensure accounting, tax report, localization, and subscription tests continue to reflect compliant account setup without changing customer-facing functionality.
Original PR description
In the related community commit, we added a constraint that requires the Tax Receivable and Tax Payable accounts on tax groups to be a Receivable or Payable account, be reconcilable and set to Non Trade. In this commit we adapt the current tests that use accounts on tax groups to have their accounts comply to the new constraint. [task-3763030](https://www.odoo.com/odoo/project.task/3763030) Related to https://github.com/odoo/odoo/pull/201249
This fix prevents an error in Mexican electronic invoicing for Point of Sale when a cashier selects a company contact on the payment screen. Orders are now only marked for invoicing once the required customer information is complete, reducing checkout interruptions.
Original PR description
Before this commit, selecting a contact of type "company" on the payment screen would result in the following error: `TypeError: Cannot read properties of undefined (reading 'name')` This occurred because selecting a company contact automatically set the order to be invoiced, even if the required fields were not filled in. To prevent this error, the process now checks that all necessary fields are completed before setting the order to invoice. opw-4773831
Document tags now display the custom tooltip text configured for them when users hover over a tag, instead of always showing the tag name. This makes tag guidance clearer for users and ensures the existing Tooltip field works as intended across document-related views.
Original PR description
[FIX] documents: display tag tooltip on hover when possible Before this commit, the tooltip shown on hover over document tags was always the tag name. This ignored the "Tooltip" field available on document tags. After this commit, the system correctly fetches and displays the custom tooltip defined in the "Tooltip" field of the tag. Reproduce --- - install documents - add "Tooltip" string to a TAG in Documents/Configuration/Tags - open documents kanban view and over onto the TAG - BUG: tag name is apearing on hover (instead of tooltip string) opw-4567814 # (older) sibling PR: https://github.com/odoo/odoo/pull/210147
*: l10n_cl, l10n_nz, sale_expense --- Description of the issue this commit addresses: [This PR](https://github.com/odoo/odoo/pull/211150) has brought our attention to some files that were in the codebase but not included in their module's manifest. Therefore they are useless as is and can either be deleted or need to be put in the manifest. --- Desired behavior after this commit is merged: Unused useless files have been removed from the codebase. Unused useful files have been
Original PR description
*: l10n_cl, l10n_nz, sale_expense --- Description of the issue this commit addresses: [This PR](https://github.com/odoo/odoo/pull/211150) has brought our attention to some files that were in the codebase but not included in their module's manifest. Therefore they are useless as is and can either be deleted or need to be put in the manifest. --- Desired behavior after this commit is merged: Unused useless files have been removed from the codebase. Unused useful files have been added to their module's manifest. --- task-4822341 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#211762 Forward-Port-Of: odoo/odoo#211609
Encountered an issue where `_name_search` would crash if a search term couldn’t be converted to all expected field types — specifically when using a string like "1971-01-01" that gets interpreted as a date, but also hits a float field in the comodel. This happened when searching currencies by exchange rates, which involve both a date field (`name`) and a float field (`rate`) in `res.currency.rate`. The original implementation only caught `ValueError` during type conversion, but in my case it
Original PR description
Encountered an issue where `_name_search` would crash if a search term couldn’t be converted to all expected field types — specifically when using a string like "1971-01-01" that gets interpreted as a date, but also hits a float field in the comodel. This happened when searching currencies by exchange rates, which involve both a date field (`name`) and a float field (`rate`) in `res.currency.rate`. The original implementation only caught `ValueError` during type conversion, but in my case it was raising a `TypeError` when attempting to convert a `datetime.date` to a float. To fix this, I expanded the exception handling to also catch `TypeError`, ensuring `_name_search` gracefully skips over fields where conversion is invalid. This aligns with the intended behavior described in the original fix — to silently ignore incompatible fields instead of failing. Failing in Distro Build , python version >=3.10 raises a `TypeError` build_error-110207 Forward-Port-Of: odoo/odoo#210551
Problem: For a gift card with 0 points which have its price changed a popup error is displayed saying the gift card has already been sold Steps to reproduce: - Install "point_of_sale" app and "pos_loyalty" module - Select "Scan existing cards" in the promotions settings - Generate a gift card with a value of 0.00 $ and copy its code - Start a shop session - Select the gift card product and enter the code - Change the price of the gift card (must be an integer < 10) - Proceed to the pa
Original PR description
Problem: For a gift card with 0 points which have its price changed a popup error is displayed saying the gift card has already been sold Steps to reproduce: - Install "point_of_sale" app and…
Problem: For a gift card with 0 points which have its price changed a popup error is displayed saying the gift card has already been sold Steps to reproduce: - Install "point_of_sale" app and "pos_loyalty" module - Select "Scan existing cards" in the promotions settings - Generate a gift card with a value of 0.00 $ and copy its code - Start a shop session - Select the gift card product and enter the code - Change the price of the gift card (must be an integer < 10) - Proceed to the payment - See the popup error Cause: As the gift card has no points, `couponPointChanges` stays empty. But when the price is modified, `couponPointChanges` is updated but has no giftCardId so the error is triggered (see `validateOrder` in PaymentScreen.js). There is no issue if the price is > 10 or is not an integer because `_updatePrograms` is called after each click on the numpad and `changesPerProgram` gets the values of `couponPointChanges` which are the saved in `oldChanges` which is modified by getting the values of `pointsAdded` which has `giftCardId` so `couponPointChanges` get the `giftCardId` opw-3909019 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175232 Forward-Port-Of: odoo/odoo#174538
### Description of the issue/feature this PR addresses: When an event is synced with an external calendar (Google/ Microsoft), the external calendar is responsible for sending reminders, and Odoo should not send any additional reminders. However, the current implementation does not properly handle this, with the default crone job running daily sending email reminders up to one day late. ### Current behavior before PR: Although the current implementation ensures the crone is not t
Original PR description
### Description of the issue/feature this PR addresses: When an event is synced with an external calendar (Google/ Microsoft), the external calendar is responsible for sending reminders, and Odoo…
### Description of the issue/feature this PR addresses: When an event is synced with an external calendar (Google/ Microsoft), the external calendar is responsible for sending reminders, and Odoo should not send any additional reminders. However, the current implementation does not properly handle this, with the default crone job running daily sending email reminders up to one day late. ### Current behavior before PR: Although the current implementation ensures the crone is not triggered for alarms of external-calendars-synced events, the default crone job that is running daily is going all over the events with reminders need to be sent and send them up to one day late. ### Desired behavior after PR is merged: When the crone goes to trigger the _send_reminder method, it will check first if the events are synced or not, and if synced then no reminders will be sent from odoo's side. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr task-id: 4316693 Forward-Port-Of: odoo/odoo#211121 Forward-Port-Of: odoo/odoo#192876
Description of the issue/feature this PR addresses: The method action_add_from_catalog in purchase_stock replaces the product's kanban view with a purchase-specific one. This method directly replaces the first view in the list, which could be wrong if another module changes the default view of the catalog. This commit updates the method to replace only the kanban view, ensuring that other view types are preserved correctly. --- I confirm I have signed the CLA and read the PR guidelines
Original PR description
Description of the issue/feature this PR addresses: The method action_add_from_catalog in purchase_stock replaces the product's kanban view with a purchase-specific one. This method directly replaces the first view in the list, which could be wrong if another module changes the default view of the catalog. This commit updates the method to replace only the kanban view, ensuring that other view types are preserved correctly. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182918 Forward-Port-Of: odoo/odoo#175438
When an iframe is removed from the DOM, it is unloaded, which can cause errors in some cases (e.g. fetch/loadJs). This has not been a significant issue for the web client since it is designed with the assumption that users either keep the browser tab open or close it at some point. However, on the website, there are some iframes (e.g. when editing the website) and unloading these iframes appears to cause tracebacks to be logged in the console and a dialog is quickly display to the end user.
Original PR description
When an iframe is removed from the DOM, it is unloaded, which can cause errors in some cases (e.g. fetch/loadJs). This has not been a significant issue for the web client since it is designed with…
When an iframe is removed from the DOM, it is unloaded, which can cause errors in some cases (e.g. fetch/loadJs).
This has not been a significant issue for the web client since it is designed with the assumption that users either keep the browser tab open or close it at some point. However, on the website, there are some iframes (e.g. when editing the website) and unloading these iframes appears to cause tracebacks to be logged in the console and a dialog is quickly display to the end user.
According to the Fetch specification, the user agent may terminate an ongoing fetch if that termination cannot be observed through script. In our case, however, the fetch cannot be terminated because the termination can be observed through the promise and a TypeError is thrown[1].
Here a sample to reproduce the errors with firefox on github:
```js
window.onbeforeunload = () => console.log("beforeunload");
fetch("https://github.com/").then(() => console.log("fetch"));
window.location = "https://github.com/";
```
Should log inside the Firefox console:
```log
beforeunload
Uncaught (in promise) TypeError: NetworkError when attempting to fetch resource.
```
Another errors can occur when we unload a page, if we manipulate the DOM when it's unload a DOMException can be trowed[2], we also handle these case inside this commit.
This commit prevents displaying these errors on dialog inside Odoo.
task-4457865
[1]: https://fetch.spec.whatwg.org/#http-network-fetch
[2]: https://webidl.spec.whatwg.org/#dom-domexception-abort_err
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#210854
Forward-Port-Of: odoo/odoo#210786Before this change, all quotations and orders were loaded into the same view in the POS frontend. This caused severe performance issues and even complete unresponsiveness when a large number of records were present. This commit introduces proper pagination for this view, limiting the number of displayed records to 80 per page to avoid bloating frontend memory and speeding up the fetch. ** Benchmarks:** | num records | before | after | |-------------|---------------------
Original PR description
Before this change, all quotations and orders were loaded into the same view in the POS frontend. This caused severe performance issues and even complete unresponsiveness when a large number of records were present. This commit introduces proper pagination for this view, limiting the number of displayed records to 80 per page to avoid bloating frontend memory and speeding up the fetch. ** Benchmarks:** | num records | before | after | |-------------|---------------------|-----------| | 17,000+ | frontend unresponsive | < 500ms | opw-4728862 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209038
Issue: In Odoo, it is impossible to generate an NLCIUS document for a partner with a valid Peppol endpoint using their Netherlands VAT (schemeID=9944) instead of a Dutch KVK/OIN identification number (schemeID=0106/0190). The latter is required for the PartyLegalEntity section of the document, but shares fields with the Peppol endpoint values, thus the two are incompatible. Solution: When the Peppol endpoint is not set to KVK/OIN, the number is instead taken from the generic res_partner.co
Original PR description
Issue: In Odoo, it is impossible to generate an NLCIUS document for a partner with a valid Peppol endpoint using their Netherlands VAT (schemeID=9944) instead of a Dutch KVK/OIN identification number (schemeID=0106/0190). The latter is required for the PartyLegalEntity section of the document, but shares fields with the Peppol endpoint values, thus the two are incompatible. Solution: When the Peppol endpoint is not set to KVK/OIN, the number is instead taken from the generic res_partner.company_registration field which is used for similar purposes for other locales, and the length of the number is used to determine the type. Addresses ticket-4624350 task-4624366 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209875
All instances of "_t" in emoji shortcodes were incorrectly replaced with "_lt" (e.g., "christmas_tree" became "christmas_ltree"). This commit restores the proper spelling. Forward-Port-Of: odoo/odoo#211741
Original PR description
All instances of "_t" in emoji shortcodes were incorrectly replaced with "_lt" (e.g., "christmas_tree" became "christmas_ltree"). This commit restores the proper spelling. Forward-Port-Of: odoo/odoo#211741
*: account_sepa_direct_debit, l10n_ec --- Description of the issue this commit addresses: [This PR](odoo#211150) has brought our attention to some files that were in the codebase but not included in their module's manifest. Therefore they are useless as is and can either be deleted or need to be put in the manifest. --- Desired behavior after this commit is merged: Unused useless files have been removed from the codebase. Unused useful files have been added to their module's m
Original PR description
*: account_sepa_direct_debit, l10n_ec --- Description of the issue this commit addresses: [This PR](odoo#211150) has brought our attention to some files that were in the codebase but not included in their module's manifest. Therefore they are useless as is and can either be deleted or need to be put in the manifest. --- Desired behavior after this commit is merged: Unused useless files have been removed from the codebase. Unused useful files have been added to their module's manifest. --- task-4822341 Forward-Port-Of: odoo/enterprise#86471 Forward-Port-Of: odoo/enterprise#86397
…de for payslip display We increase the size of the external CH code to not impact payslip display Forward-Port-Of: odoo/enterprise#86299
Original PR description
…de for payslip display We increase the size of the external CH code to not impact payslip display Forward-Port-Of: odoo/enterprise#86299
**Issue:** In a swiss company, when a user clicks on "Prepare Data" for a salary certificate rectification, an error occurs. **Steps to reproduce:** - make sure l10n_ch_hr_payroll_elm_transmission is installed and you're in a swiss company - Payroll > Transmission > Salary Certificate Rectification - create a new declaration and fill the form with a newly created previous declaration - click on "Prepare Data" A traceback is raised opw-4687938 Forward-Port-Of: odoo/enterprise#832
Original PR description
**Issue:** In a swiss company, when a user clicks on "Prepare Data" for a salary certificate rectification, an error occurs. **Steps to reproduce:** - make sure l10n_ch_hr_payroll_elm_transmission is installed and you're in a swiss company - Payroll > Transmission > Salary Certificate Rectification - create a new declaration and fill the form with a newly created previous declaration - click on "Prepare Data" A traceback is raised opw-4687938 Forward-Port-Of: odoo/enterprise#83261
…Inter-Company sync ### Steps to reproduce: - With Company B in the settings Enable Inter-Company Transactions > Synchronize Sales and Purchase Order - Sales > Configurations > Sales Teams, Archive all sales team - With COMP A create a sales team with a set company_id: COMP A - With COMP A create and confirm a PO with COMP B as customer #### > Invalid operation: while generating the SO, the sales team belongs to COMP A and the SO to COMP B. ### Cause of the issue: The `team_i
Original PR description
…Inter-Company sync ### Steps to reproduce: - With Company B in the settings Enable Inter-Company Transactions > Synchronize Sales and Purchase Order - Sales > Configurations > Sales Teams, Archive…
…Inter-Company sync ### Steps to reproduce: - With Company B in the settings Enable Inter-Company Transactions > Synchronize Sales and Purchase Order - Sales > Configurations > Sales Teams, Archive all sales team - With COMP A create a sales team with a set company_id: COMP A - With COMP A create and confirm a PO with COMP B as customer #### > Invalid operation: while generating the SO, the sales team belongs to COMP A and the SO to COMP B. ### Cause of the issue: The `team_id` field of the `sale.order` model is a stored pre-computed and company checked field. As such, when the SO is created and even if no sales team is provided to the create vals: https://github.com/odoo/enterprise/blob/c61ce5a8e46e706bfb2025d4c9c79a39598e8827/sale_purchase_inter_company_rules/models/purchase_order.py#L70 a default sales team will be computed and set on the SO based on the "allowed_company_ids" (including both COMP A and COMP B): https://github.com/odoo/odoo/blob/1fa8678a33ab35195005d1b65b5eecb1d089fe56/addons/sale/models/sale_order.py#L453-L460 https://github.com/odoo/odoo/blob/1fa8678a33ab35195005d1b65b5eecb1d089fe56/addons/sales_team/models/crm_team.py#L81-L88 While the domain checks that the sales team is either not tight to a company or belong to comp B, since no such teams were found, we fallback the invalid sales team of COMP A. The invalid operation is then raised during the `_check_company` of the created record. opw-4627851 Forward-Port-Of: odoo/enterprise#85545 Forward-Port-Of: odoo/enterprise#83487
Versions -------- - 17.0+ Steps ----- 1. Go to Automation Rules; 2. create a new automation; 3. set model to `product.pricing`; 4. in one of the filters, check the record(s) that fit in the domain. Issue ----- > EvalError: Can not evaluate python expression: (bool(parent.product_variant_count < 2)) > Error: Name 'parent' is not defined Cause ----- `parent` is not defined because the `product_variant_ids` field in the view does not have a parent field to evaluate. Solution
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Go to Automation Rules; 2. create a new automation; 3. set model to `product.pricing`; 4. in one of the filters, check the record(s) that fit in the domain. Issue ----- > EvalError: Can not evaluate python expression: (bool(parent.product_variant_count < 2)) > Error: Name 'parent' is not defined Cause ----- `parent` is not defined because the `product_variant_ids` field in the view does not have a parent field to evaluate. Solution -------- Remove the `parent` checks. opw-4788215 Forward-Port-Of: odoo/enterprise#86384
Currently the SEPA mandate auto validation is done when the payment ref of the statement line is the same as the name of the payment transaction and that the partner id matches between SEPA mandate and statement line. Issue is that some flows (at least the bank synchronization handled through `account_online_synchronization` and odoofin) do not set the partner id on the bank statement line (until reconciliation) but provide it first through the `partner_name` field. To ensure those flows w
Original PR description
Currently the SEPA mandate auto validation is done when the payment ref of the statement line is the same as the name of the payment transaction and that the partner id matches between SEPA mandate and statement line. Issue is that some flows (at least the bank synchronization handled through `account_online_synchronization` and odoofin) do not set the partner id on the bank statement line (until reconciliation) but provide it first through the `partner_name` field. To ensure those flows work fine with SEPA, we should also match transactions and statement lines whose partners names match when there is no partner_id set on the bank statement line. opw-4536189 Forward-Port-Of: odoo/enterprise#85965
This enhancement introduces support for customer statements in the Indian localization of the accounting package. The update includes an automatic installation of the customer statement module, which essentially exports the partner ledger. Task link: https://www.odoo.com/web#model=project.task&id=3774149 task-3774149 Forward-Port-Of: odoo/enterprise#76412 Forward-Port-Of: odoo/enterprise#57781
Original PR description
This enhancement introduces support for customer statements in the Indian localization of the accounting package. The update includes an automatic installation of the customer statement module, which essentially exports the partner ledger. Task link: https://www.odoo.com/web#model=project.task&id=3774149 task-3774149 Forward-Port-Of: odoo/enterprise#76412 Forward-Port-Of: odoo/enterprise#57781
This enhancement introduces support for customer statements in the Indian localization of the accounting package. The update includes an automatic installation of the customer statement module, which essentially exports the partner ledger. Task link: https://www.odoo.com/web#model=project.task&id=3774149 task-3774149 Forward-Port-Of: odoo/enterprise#66529 Forward-Port-Of: odoo/enterprise#57781
Original PR description
This enhancement introduces support for customer statements in the Indian localization of the accounting package. The update includes an automatic installation of the customer statement module, which essentially exports the partner ledger. Task link: https://www.odoo.com/web#model=project.task&id=3774149 task-3774149 Forward-Port-Of: odoo/enterprise#66529 Forward-Port-Of: odoo/enterprise#57781