Tuesday, June 3, 2025
38 changes · saas-18.2
Enhancements to existing features
The PEPPOL endpoint check now updates partner information only when the result has changed. This avoids needless background updates when users open the invoice sending wizard, helping reduce system noise and potential performance overhead.
Original PR description
When checking for PEPPOL partner endpoint, only update the value if it changed since the last check. This avoid triggering an unnecessary write on res.partner each time a user open the invoice sending wizard. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This update fixes how custom report components are registered so localized accounting reports load the right elements consistently. It reduces the chance of errors during upgrades or forward-porting, especially for Luxembourg annual tax reporting and other localization reports.
Original PR description
The last section of l10n_lu_reports's annual tax report makes use of a custom component. Due to the changes introduced in https://github.com/odoo/enterprise/commit/b4e146e34561f9d0411fcfa4cc9faf9b66dcffb0, the component registration was made on the wrong module. This "module" parameter of registerCustomComponent is too error prone, and will create errors in forward-ports; let's get rid of it, and simply make sure we use unique class names on components (by prefixing them L10nXX in localizations).
Miscellaneous changes
Steps to reproduce: - When the planning module is not installed and we click on employee avatar - This leads to a traceback, especially when the related employee data is available only in hr.employee.public or hr.employee. Cause: - The avatar card component was using a hardcoded model instead of dynamically using props.record.model. Although a custom get_avatar_card_data method was introduced to centralize data logic, it was not implemented on all relevant models (hr.employee,
Original PR description
Steps to reproduce: - When the planning module is not installed and we click on employee avatar - This leads to a traceback, especially when the related employee data is available only in…
Steps to reproduce: - When the planning module is not installed and we click on employee avatar - This leads to a traceback, especially when the related employee data is available only in hr.employee.public or hr.employee. Cause: - The avatar card component was using a hardcoded model instead of dynamically using props.record.model. Although a custom get_avatar_card_data method was introduced to centralize data logic, it was not implemented on all relevant models (hr.employee, hr.employee.public), which caused traceback in certain setups. Solution: - Replaced the hardcoded model with props.record.model to dynamically resolve the model. - Added the get_avatar_card_data method to hr.employee.base to ensure compatibility. Ensured the logic works correctly even when the planning module is not installed. Follow-up to: - Commit : https://github.com/odoo/odoo/pull/187171 https://github.com/odoo/enterprise/pull/75121 - prevent component destruction which moved avatar card data fetching into a parent method to avoid lifecycle issues. Related task-4210513 task - 4777570 Forward-Port-Of: odoo/odoo#210206 Forward-Port-Of: odoo/odoo#210027
### Before this commit: The `IBAN number` in the PDF footer is currently broken and displayed across multiple lines.  ### After this commit: Fix it by updating the CSS classes to ensure proper alignment and a cleaner UI layout.  > Task-4822070 --- I confirm I have signed the CLA and read the PR guidelines a
Original PR description
### Before this commit: The `IBAN number` in the PDF footer is currently broken and displayed across multiple lines.  ### After this commit: Fix it by updating the CSS classes to ensure proper alignment and a cleaner UI layout.  > Task-4822070 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212144
In this commit: =============== - We use session.test_mode instead of relying on a timeout while testing the carousel in all self-ordering modes in test_self_order_pos_landing_page_carousel Runbot error: 226322 Forward-Port-Of: odoo/odoo#212371
Original PR description
In this commit: =============== - We use session.test_mode instead of relying on a timeout while testing the carousel in all self-ordering modes in test_self_order_pos_landing_page_carousel Runbot error: 226322 Forward-Port-Of: odoo/odoo#212371
**Steps to reproduce :** 1) Install Accounting and enable Analytic Accounting from the configuration. 2) Create an analytic plan under Accounting > Configuration > Analytic Plans. 3) Add a line with domain set to miscellaneous, applicability as mandatory and a prefix 4) Create an analytic account using the smart button on the plan. 5) Create an asset record in one company in a multi-company setup. 6) Switch to another company and try to access the asset created in the first company.
Original PR description
**Steps to reproduce :** 1) Install Accounting and enable Analytic Accounting from the configuration. 2) Create an analytic plan under Accounting > Configuration > Analytic Plans. 3) Add a line with…
**Steps to reproduce :** 1) Install Accounting and enable Analytic Accounting from the configuration. 2) Create an analytic plan under Accounting > Configuration > Analytic Plans. 3) Add a line with domain set to miscellaneous, applicability as mandatory and a prefix 4) Create an analytic account using the smart button on the plan. 5) Create an asset record in one company in a multi-company setup. 6) Switch to another company and try to access the asset created in the first company. **Issue:** A traceback occurs ``` AttributeError: 'bool' object has no attribute 'startswith' ``` **Cause:** - When switching companies, all the chart of accounts records code for the previous company, will set as False. - When accessing an asset record expects a account code to call .startswith(), but it fails when code is False. This leads to the above traceback. https://github.com/odoo/odoo/blob/5a321b2327e36f3250b33c669bdb8bb344ab4cbd/addons/account/models/account_analytic_plan.py#L64-L67 **Solution:** - Add a check to ensure that the account’s code exists before attempting to call .startswith(). This makes the code more robust across multi-company environments. opw-4745633 Forward-Port-Of: odoo/odoo#210741
Before this commit: --------------------- - Internal notes of order were printed on the customer receipt. After this commit: ----------------------------- - Internal notes are no longer printed; only customer notes appear on the receipt. Task:4789682 Related PR - https://github.com/odoo/enterprise/pull/85740 Forward-Port-Of: odoo/odoo#209640
Original PR description
Before this commit: --------------------- - Internal notes of order were printed on the customer receipt. After this commit: ----------------------------- - Internal notes are no longer printed; only customer notes appear on the receipt. Task:4789682 Related PR - https://github.com/odoo/enterprise/pull/85740 Forward-Port-Of: odoo/odoo#209640
**Steps to reproduce:** - Install Accounting and l10n_es_edi_facturae - Switch to a Spanish company (e.g. ES Company) - Create or edit a Spanish customer and set "Facturae" as eInvoice format - Create an invoice: * Customer: [the Spanish customer] * Product: [any] * Customer Reference: [anything] - Confirm the invoice - Generate Facturae edi file via "Send & Print" button - Check the generated XML **Issue:** When submitting the XML to FACe service, the XML is rejected with th
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_es_edi_facturae - Switch to a Spanish company (e.g. ES Company) - Create or edit a Spanish customer and set "Facturae" as eInvoice format -…
**Steps to reproduce:** - Install Accounting and l10n_es_edi_facturae - Switch to a Spanish company (e.g. ES Company) - Create or edit a Spanish customer and set "Facturae" as eInvoice format - Create an invoice: * Customer: [the Spanish customer] * Product: [any] * Customer Reference: [anything] - Confirm the invoice - Generate Facturae edi file via "Send & Print" button - Check the generated XML **Issue:** When submitting the XML to FACe service, the XML is rejected with the following error: "Element 'ReceiverContractReference': This element is not expected. Expected is one of ( FileDate, SequenceNumber, DeliveryNotesReferences, ItemDescription )." It is caused by "ReceiverContractReference" being set after "FileReference" in the invoice line section. Apparently, the order defined in the documentation should be respected. "ReceiverContractReference" should be set before "ReceiverTransactionReference". The issue has been introduced by this other fix: https://github.com/odoo/odoo/commit/ac1af565161d70d57f51d579d0530eb7766c0c76 opw-4579987 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#211177
Steps to Reproduce: - Open the Planning app. - Click on the avatar of a resource. - Refresh the page, then click on the avatar of a resource again. Issue: - A traceback error occurs when clicking on the avatar after a page refresh, likely due to component destruction or incomplete loading. Solution: - Consolidated multiple RPC calls into a single method in the parent component to avoid issues with component destruction during super.onWillStart. - Modified onWillStart to ensur
Original PR description
Steps to Reproduce: - Open the Planning app. - Click on the avatar of a resource. - Refresh the page, then click on the avatar of a resource again. Issue: - A traceback error occurs when clicking on the avatar after a page refresh, likely due to component destruction or incomplete loading. Solution: - Consolidated multiple RPC calls into a single method in the parent component to avoid issues with component destruction during super.onWillStart. - Modified onWillStart to ensure hr_access data is fetched without risking lifecycle conflicts. task-4210513 Forward-Port-Of: odoo/odoo#206899 Forward-Port-Of: odoo/odoo#187171
The sudo function allowed the current user to fetch data (stage IDs) which were used to browse. The user does not have access to this data; therefore, an access error message is triggered task-4194357 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192345
Original PR description
The sudo function allowed the current user to fetch data (stage IDs) which were used to browse. The user does not have access to this data; therefore, an access error message is triggered task-4194357 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192345
**Steps to reproduce:** 1. Initialize a new database with `odoo -d langdb --stop -i base --load-language=es_AR` **Result:** ``` 2025-01-03 11:41:28,054 54 INFO langdb odoo.modules.loading: loading base/data/res_bank.xml 2025-01-03 11:41:28,057 54 INFO langdb odoo.modules.loading: loading base/data/res.lang.csv 2025-01-03 11:41:28,076 54 INFO langdb odoo.modules.loading: loading base/data/res_lang_data.xml 2025-01-03 11:41:28,091 54 ERROR langdb odoo.sql_db: bad query: b' UPDATE "res
Original PR description
**Steps to reproduce:** 1. Initialize a new database with `odoo -d langdb --stop -i base --load-language=es_AR` **Result:** ``` 2025-01-03 11:41:28,054 54 INFO langdb odoo.modules.loading: loading…
**Steps to reproduce:**
1. Initialize a new database with `odoo -d langdb --stop -i base --load-language=es_AR`
**Result:**
```
2025-01-03 11:41:28,054 54 INFO langdb odoo.modules.loading: loading base/data/res_bank.xml
2025-01-03 11:41:28,057 54 INFO langdb odoo.modules.loading: loading base/data/res.lang.csv
2025-01-03 11:41:28,076 54 INFO langdb odoo.modules.loading: loading base/data/res_lang_data.xml
2025-01-03 11:41:28,091 54 ERROR langdb odoo.sql_db: bad query: b' UPDATE "res_lang"\n
SET "url_code" = "__tmp"."url_code"::VARCHAR, "write_date" = "__tmp"."write_date"::timestamp, "write_uid" = "__tmp"."write_uid"::int4\n
FROM (VALUES (68, \'es\', \'2025-01-03T11:41:26.517428\'::timestamp, 1)) AS "__tmp"("id", "url_code", "write_date", "write_uid")\n
WHERE "res_lang"."id" = "__tmp"."id"\n'
ERROR: duplicate key value violates unique constraint "res_lang_url_code_uniq"
DETAIL: Key (url_code)=(es) already exists.
```
**Explanation:**
When initializing a new database with a specific language, the language is activated on `install_lang`, and since it's the only active language of the "es_*" family, its url_code is set to the short version. [^1]
By the time the url_code switch in `res_lang_data.xml` is executed, the `base.lang_es` language is no longer the one with "es" as url_code. It's actually the recently activated es_AR language.
**Solution:**
We must perform the `url_code` switch before calling `install_lang`
[^1]: https://github.com/odoo/odoo/blob/c042e1ba/odoo/addons/base/models/res_lang.py#L339-L356
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#192344[FIX] account: customer's default invoice template as only attachment Currently, when the user define an invoice template other than the standard 'account.account_invoices', both the standard report and the one defined by the user are attached to the mail when he hits the Send & Print. We want the template chosen by the user to be the one sent & printed. The fix is to remove the default accounting action report from the dynamic attachments : before, we were just removing the default a
Original PR description
[FIX] account: customer's default invoice template as only attachment Currently, when the user define an invoice template other than the standard 'account.account_invoices', both the standard report…
[FIX] account: customer's default invoice template as only attachment Currently, when the user define an invoice template other than the standard 'account.account_invoices', both the standard report and the one defined by the user are attached to the mail when he hits the Send & Print. We want the template chosen by the user to be the one sent & printed. The fix is to remove the default accounting action report from the dynamic attachments : before, we were just removing the default action report used for the current move. But e.g. if the partner had a default report set in the field invoice_template_pdf_report_id, the default report for the move was this one, and so we weren't removing the accounting default one. This was causing the duplicate placeholder because the default accounting report placeholder is already processed in another method. Also, we remove the configuration that sets the 'account.account_invoices' report as a default dynamic attachment. Task-4681142 Runbot : https://runbot.odoo.com/runbot/bundle/18-0-invoice-report-per-partner-roto-361127 Forward-Port-Of: odoo/odoo#205121
The function `_get_consumed_leaves`, that was in the hr_employee model is used in a compute method of the hr_employee_base model. This was causing some issues as the inhertiance is from hr_employee_base to hr_employee. This commit fixes the issue by moving the function to hr_employee_base. Also, a function in `hr_org_chart` was not taking care that an employee can be public or not, which lead to model inconsistencies errors. task-4742768 Forward-Port-Of: odoo/odoo#211787 Forward-Port-Of:
Original PR description
The function `_get_consumed_leaves`, that was in the hr_employee model is used in a compute method of the hr_employee_base model. This was causing some issues as the inhertiance is from hr_employee_base to hr_employee. This commit fixes the issue by moving the function to hr_employee_base. Also, a function in `hr_org_chart` was not taking care that an employee can be public or not, which lead to model inconsistencies errors. task-4742768 Forward-Port-Of: odoo/odoo#211787 Forward-Port-Of: odoo/odoo#207026
- Avoid traceback when using name-based preset without module `pos_restaurant` installed. - Since we cannot change the name of a floating order in POS, move floating order name logic to `pos_restaurant` to prevent errors when using presets with `identification = name` in POS without the `pos_restaurant` module installed. - Adapt tests so in `point_of_sale` we test preset with `identification = address` (delivery) and in `pos_restaurant` we test preset with `identification = name` (take out).
Original PR description
- Avoid traceback when using name-based preset without module `pos_restaurant` installed. - Since we cannot change the name of a floating order in POS, move floating order name logic to `pos_restaurant` to prevent errors when using presets with `identification = name` in POS without the `pos_restaurant` module installed. - Adapt tests so in `point_of_sale` we test preset with `identification = address` (delivery) and in `pos_restaurant` we test preset with `identification = name` (take out). Steps to reproduce: - Install `point_of_sale` (without `pos_restaurant`). - Enable presets in settings and create a preset with `identification = name`. - Open a session in POS and create a new order. - Select the preset in the order. - => Traceback occurs. task-id: 4794324 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210053
### Current behavior before PR: - The popover's editing mode was determined by whether the link had an `href` attribute. ### Desired behavior after PR is merged: - Introduced _`LinkPopoverState`_ to control the editing mode instead of relying on `href`. task-4241464 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204928
Original PR description
### Current behavior before PR: - The popover's editing mode was determined by whether the link had an `href` attribute. ### Desired behavior after PR is merged: - Introduced _`LinkPopoverState`_ to control the editing mode instead of relying on `href`. task-4241464 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204928
Installing PoS will change some values on existing operations types. To reproduce the issue 1. Install stock 2. Operations Types, edit Delivery: - Change the barcode 3. Install point_of_sale Error: the barcode of Delivery is reset When installing PoS, it will execute a generic method that creates and updates all operation types: https://github.com/odoo/odoo/blob/0bc90e7d74bd0792b9af7464256ba8770d894a25/addons/point_of_sale/data/point_of_sale_data.xml#L4 https://github.com/odoo
Original PR description
Installing PoS will change some values on existing operations types. To reproduce the issue 1. Install stock 2. Operations Types, edit Delivery: - Change the barcode 3. Install point_of_sale Error:…
Installing PoS will change some values on existing operations types. To reproduce the issue 1. Install stock 2. Operations Types, edit Delivery: - Change the barcode 3. Install point_of_sale Error: the barcode of Delivery is reset When installing PoS, it will execute a generic method that creates and updates all operation types: https://github.com/odoo/odoo/blob/0bc90e7d74bd0792b9af7464256ba8770d894a25/addons/point_of_sale/data/point_of_sale_data.xml#L4 https://github.com/odoo/odoo/blob/14e9a698e333c3d6d2f7830353c34311de9ecb2c/addons/point_of_sale/models/stock_warehouse.py#L45-L50 https://github.com/odoo/odoo/blob/03478253c166238442d2f81f095de9fbcdfb265f/addons/stock/models/stock_warehouse.py#L350-L356 Thanks to this, the PoS operation type will be created. However, as said in its docstring, the method will also update the existing operation types. For instance, for Delivery: https://github.com/odoo/odoo/blob/03478253c166238442d2f81f095de9fbcdfb265f/addons/stock/models/stock_warehouse.py#L1003-L1006 Its barcode and default source location will be reset. The update will also reset the sequence prefix. As said by the method name in PoS (`_create_missing_pos_picking_types`), the idea here is just to create missing PoS types. Similar issue with repair: the operations types of the user-created wh will be reset. OPW-4668505 Forward-Port-Of: odoo/odoo#210308
Description of the issue/feature this PR addresses: `_generate_price_difference_vals` is about 200 Ioc long. Current behavior before PR: if we want to extend this method there is little choice but copy paste everything. Desired behavior after PR is merged: it's possible to extend one of the new method instead --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205585
Original PR description
Description of the issue/feature this PR addresses: `_generate_price_difference_vals` is about 200 Ioc long. Current behavior before PR: if we want to extend this method there is little choice but copy paste everything. Desired behavior after PR is merged: it's possible to extend one of the new method instead --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205585
[FIX] website: update sitemap lastmod on website page view changes Before this commit, since the introduction of the website page model at commit [1], the lastmod for pages indicated in the sitemap was not entirely accurate: it only considered *page record* changes, not their internal *view changes*. Steps to reproduce: - Create a new website page and publish it - Go to /sitemap.xml, see the page is mentioned with correct lastmod - Wait for one day ** - Update the page URL - Go to
Original PR description
[FIX] website: update sitemap lastmod on website page view changes Before this commit, since the introduction of the website page model at commit [1], the lastmod for pages indicated in the sitemap…
[FIX] website: update sitemap lastmod on website page view changes
Before this commit, since the introduction of the website page model at
commit [1], the lastmod for pages indicated in the sitemap was not
entirely accurate: it only considered *page record* changes, not their
internal *view changes*.
Steps to reproduce:
- Create a new website page and publish it
- Go to /sitemap.xml, see the page is mentioned with correct lastmod
- Wait for one day **
- Update the page URL
- Go to /sitemap.xml, see the lastmod was updated
- Wait for one day **
- Update the page content
- Go to /sitemap.xml
=> The lastmod was unchanged
**: the lastmod does not show the hours. You will need to update the
write_date manually in your database to test this. Also, when
visiting the sitemap, you need to first delete the cached version
in the backend (Debug -> Settings -> Technical -> Attachments).
[1]: https://github.com/odoo/odoo/commit/4ecbacaf59576a22ff45615a5aa5c67244e4fb93
Forward-Port-Of: odoo/odoo#212055
Forward-Port-Of: odoo/odoo#211749Problem --------- Currently, when generating the XML to send to NAV, the XML currency rate is computed using an MMSE estimator. This leads to approximation error itself leading to a slight difference from the rate applied and given by the MNB of Hungary for that day. This is noticed by the NAV upon submiting the invoice who returns an error. Objective --------- Make it so that the rate returned by the HU bank is used during the XML generation. Solution --------- Instead of computing
Original PR description
Problem --------- Currently, when generating the XML to send to NAV, the XML currency rate is computed using an MMSE estimator. This leads to approximation error itself leading to a slight difference from the rate applied and given by the MNB of Hungary for that day. This is noticed by the NAV upon submiting the invoice who returns an error. Objective --------- Make it so that the rate returned by the HU bank is used during the XML generation. Solution --------- Instead of computing a MMSE estimator, we get the conversion rate stored in the database at the time of the invoice. task-4707316 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209553
### 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#211899 Forward-Port-Of: odoo/odoo#192876
Requested by @cima-odoo Forward-Port-Of: odoo/odoo#211848
Original PR description
Requested by @cima-odoo Forward-Port-Of: odoo/odoo#211848
Added FI and LT, and updated extra terms for others. Related to https://github.com/odoo/enterprise/pull/86440 Forward-Port-Of: odoo/odoo#211753 Forward-Port-Of: odoo/odoo#211714
Original PR description
Added FI and LT, and updated extra terms for others. Related to https://github.com/odoo/enterprise/pull/86440 Forward-Port-Of: odoo/odoo#211753 Forward-Port-Of: odoo/odoo#211714
Before this commit, sale_order information were used in some payment form but only website_sale_order was available. This would cause issue in overrides. task 4808806 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212531
Original PR description
Before this commit, sale_order information were used in some payment form but only website_sale_order was available. This would cause issue in overrides. task 4808806 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212531
Forward-Port-Of: odoo/odoo#212188
Original PR description
Forward-Port-Of: odoo/odoo#212188
**Current behavior:** COGS dashboard items in a project's profitability report do not open any details when clicked on. **Expected behavior:** This should open a detailed view for an invoice linked via the analytic account on the project. **Steps to reproduce:** 1. Create a service product that generates a project on sale, on the project template set a specific analytic account 2. Create another product with real time valuation and assign the COGS account on the product category's ex
Original PR description
**Current behavior:** COGS dashboard items in a project's profitability report do not open any details when clicked on. **Expected behavior:** This should open a detailed view for an invoice linked…
**Current behavior:** COGS dashboard items in a project's profitability report do not open any details when clicked on. **Expected behavior:** This should open a detailed view for an invoice linked via the analytic account on the project. **Steps to reproduce:** 1. Create a service product that generates a project on sale, on the project template set a specific analytic account 2. Create another product with real time valuation and assign the COGS account on the product category's expense account 3. Sell some of the service product and the auto val product in the same order, deliver it -> generate invoice & post it 4. In the project's settings, open the profitability report and click on the `Cost of Goods Sold` dashboard item **Cause of the issue:** There is no action set up to return for this section, as it was just added in: 0fbc592 **Fix:** Add an action to return the account move line records with COGS display type for the invoice record in question (in the request's `res_id`). opw-4813885 Forward-Port-Of: odoo/odoo#212547
Before this commit, 'queryX' functions in Hoot would supposedly cleanup internal global variables on error thrown by the helpers. However, this only took into account the errors explicitly thrown, and NOT those that were thrown by other methods/native code, such as invalid native query selectors. This commit introduces a new internal method to "guard" exposed 'queryX' helpers, to properly cleanup internal variables on any error. --- I confirm I have signed the CLA and read the PR guidelin
Original PR description
Before this commit, 'queryX' functions in Hoot would supposedly cleanup internal global variables on error thrown by the helpers. However, this only took into account the errors explicitly thrown, and NOT those that were thrown by other methods/native code, such as invalid native query selectors. This commit introduces a new internal method to "guard" exposed 'queryX' helpers, to properly cleanup internal variables on any error. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212650
The aim of this commit is to prevent the file generated to be rejected by the administration. Before this commit: As there weren't any mapping for those country code, the field `f2112_buitenlandspostnummer` wouldn't be set in the xml. After this commit: The field is correctly set task-none Forward-Port-Of: odoo/enterprise#86886
Original PR description
The aim of this commit is to prevent the file generated to be rejected by the administration. Before this commit: As there weren't any mapping for those country code, the field `f2112_buitenlandspostnummer` wouldn't be set in the xml. After this commit: The field is correctly set task-none Forward-Port-Of: odoo/enterprise#86886
Related to https://github.com/odoo/odoo/pull/211714 Forward-Port-Of: odoo/enterprise#86467 Forward-Port-Of: odoo/enterprise#86440
Original PR description
Related to https://github.com/odoo/odoo/pull/211714 Forward-Port-Of: odoo/enterprise#86467 Forward-Port-Of: odoo/enterprise#86440
When selecting an attribute value in the Rental Search snippet, the generated URL incorrectly uses the `attrib` parameter. However, the `/shop` route expects the parameter to be named `attribute_value`. As a result, the filter is not applied, and the search results are not correctly filtered. This fix ensures consistency between the snippet and the `/shop` route by replacing `attrib` with `attribute_value`, so the attribute filter works as expected. The change improves the user experience
Original PR description
When selecting an attribute value in the Rental Search snippet, the generated URL incorrectly uses the `attrib` parameter. However, the `/shop` route expects the parameter to be named `attribute_value`. As a result, the filter is not applied, and the search results are not correctly filtered. This fix ensures consistency between the snippet and the `/shop` route by replacing `attrib` with `attribute_value`, so the attribute filter works as expected. The change improves the user experience by ensuring that search filters behave consistently across the website. Steps to reproduce: - Add the "Rental Search" snippet to a website page. - Configure it by selecting an attribute value. - Observe the resulting URL using `attrib`, which fails to filter results on the `/shop` page. Forward-Port-Of: odoo/enterprise#86792
Fix the possibility to enter an empty document name when editing a file or folder name from the side panel. If the name is empty, a danger notification should be displayed and the previous name should be restored. Task-4794447 Forward-Port-Of: odoo/enterprise#85500
Original PR description
Fix the possibility to enter an empty document name when editing a file or folder name from the side panel. If the name is empty, a danger notification should be displayed and the previous name should be restored. Task-4794447 Forward-Port-Of: odoo/enterprise#85500
Currently, An Error occurs on removing the **Date To** or **Date From** value from a payslip's period. **Steps to Reproduce** 1) Install **l10n_id_hr_payroll module**. 2) Create a new **Pay-Slip**. 3) Remove **Date** from **Period** **Error:** `AttributeError: 'bool' object has no attribute 'month'` **Root Cause:** The `_compute_l10n_id_include_pkp_ptkp` method at [1] assumes that `date_to` and `contract_id.date_end` are always set and valid. If either of them is missing (False), a
Original PR description
Currently, An Error occurs on removing the **Date To** or **Date From** value from a payslip's period. **Steps to Reproduce** 1) Install **l10n_id_hr_payroll module**. 2) Create a new **Pay-Slip**.…
Currently, An Error occurs on removing the **Date To** or **Date From** value from a payslip's period. **Steps to Reproduce** 1) Install **l10n_id_hr_payroll module**. 2) Create a new **Pay-Slip**. 3) Remove **Date** from **Period** **Error:** `AttributeError: 'bool' object has no attribute 'month'` **Root Cause:** The `_compute_l10n_id_include_pkp_ptkp` method at [1] assumes that `date_to` and `contract_id.date_end` are always set and valid. If either of them is missing (False), accessing `.month` or `.year` causes an error. [1] - https://github.com/odoo/enterprise/blob/34aa0ffb82c1bd7c90b4cb161ea515f2cad8e65f/l10n_id_hr_payroll/models/hr_payslip.py#L87 **Solution:** This commit prevents the computation from failing when `slip.date_to` and `slip.contract_id.date_end` fields are unset by adding a conditional check to ensure that both fields are valid date objects before accessing their `.month` and `.year` attributes. sentry-6608982173 Forward-Port-Of: odoo/enterprise#85701
Steps to Reproduce: - Open the Planning app. - Click on the avatar of a resource. - Refresh the page, then click on the avatar of a resource again. Issue: - A traceback error occurs when clicking on the avatar after a page refresh, likely due to component destruction or incomplete loading. Solution: - Consolidated multiple RPC calls into a single method in the parent component to avoid issues with component destruction during `super.onWillStart`. - Modified `onWillStart` to ensure `h
Original PR description
Steps to Reproduce: - Open the Planning app. - Click on the avatar of a resource. - Refresh the page, then click on the avatar of a resource again. Issue: - A traceback error occurs when clicking on the avatar after a page refresh, likely due to component destruction or incomplete loading. Solution: - Consolidated multiple RPC calls into a single method in the parent component to avoid issues with component destruction during `super.onWillStart`. - Modified `onWillStart` to ensure `hr_access` data is fetched without risking lifecycle conflicts. task-4210513 Forward-Port-Of: odoo/enterprise#83837 Forward-Port-Of: odoo/enterprise#75121
The current implementation to handle the rate for multi-currency entries in CAMT creates problems when fetching the source rate from the file: the source rate can be taken from the SrcCcy or the TrgtCcy node, which should be compared with the source currency and target currency respectively. It is not done that way and is too restrictive (when the SrcCcy is found, it is always compared to the target currency, which leads to an incorrect transaction amount). Moreover, when the currency convers
Original PR description
The current implementation to handle the rate for multi-currency entries in CAMT creates problems when fetching the source rate from the file: the source rate can be taken from the SrcCcy or the TrgtCcy node, which should be compared with the source currency and target currency respectively. It is not done that way and is too restrictive (when the SrcCcy is found, it is always compared to the target currency, which leads to an incorrect transaction amount). Moreover, when the currency conversion introduces a exchange loss/gain, it is put back on the largest transaction of the entry. Backport of https://github.com/odoo/enterprise/pull/76828 and https://github.com/odoo/enterprise/pull/42763 opw-4672283 Forward-Port-Of: odoo/enterprise#84775 Forward-Port-Of: odoo/enterprise#83131
Before this commit, when the user creates more than one fsm project, the default fsm project selected once a fsm task is created if the one with the lowest sequence and lowest id which could be confusing for the user since the default order displayed in the list view of projects is `sequence, name, id`. This commit makes sure the default fsm project fetched is the first one displayed in the list view of projects. opw-4791468 Forward-Port-Of: odoo/enterprise#86554
Original PR description
Before this commit, when the user creates more than one fsm project, the default fsm project selected once a fsm task is created if the one with the lowest sequence and lowest id which could be confusing for the user since the default order displayed in the list view of projects is `sequence, name, id`. This commit makes sure the default fsm project fetched is the first one displayed in the list view of projects. opw-4791468 Forward-Port-Of: odoo/enterprise#86554
In this commit: --------------- - Corrected the label from `Is Alchoholic` to `is Alcoholic`. task- 4826438 Forward-Port-Of: odoo/enterprise#86587
Original PR description
In this commit: --------------- - Corrected the label from `Is Alchoholic` to `is Alcoholic`. task- 4826438 Forward-Port-Of: odoo/enterprise#86587
Before this commit: ------------------ - The preparation ticket displayed DUPLICATA on every print, regardless of whether it was a reprint or not. After this commit: -------------------- - DUPLICATA is now printed only when the preparation ticket is a reprint, avoiding confusion during regular printing. Task: 4789682 Related PR - https://github.com/odoo/odoo/pull/209640 Forward-Port-Of: odoo/enterprise#85740
Original PR description
Before this commit: ------------------ - The preparation ticket displayed DUPLICATA on every print, regardless of whether it was a reprint or not. After this commit: -------------------- - DUPLICATA is now printed only when the preparation ticket is a reprint, avoiding confusion during regular printing. Task: 4789682 Related PR - https://github.com/odoo/odoo/pull/209640 Forward-Port-Of: odoo/enterprise#85740
Currently, sending an invoice can raise an error if the **Electronic Invoice Type** is not set on the invoice. **Steps to Reproduce:** - Install the `l10n_co_dian` module. - Change the default company to **CO Company**. - Create and confirm a customer invoice, but leave the **Electronic Invoice Type** unset. - Send the invoice. **Error:** `AttributeError - 'bool' object has no attribute 'rjust'` Here, an issue occurs because the system attempts to call `rjust()` on the field `l10n_
Original PR description
Currently, sending an invoice can raise an error if the **Electronic Invoice Type** is not set on the invoice. **Steps to Reproduce:** - Install the `l10n_co_dian` module. - Change the default company to **CO Company**. - Create and confirm a customer invoice, but leave the **Electronic Invoice Type** unset. - Send the invoice. **Error:** `AttributeError - 'bool' object has no attribute 'rjust'` Here, an issue occurs because the system attempts to call `rjust()` on the field `l10n_co_edi_type` without ensuring it is a string. When the field is `False`, it results in an Attribute error. - [1] This commit ensures the right access to `rjust()` only when `l10n_co_edi_type` is a valid string, preventing the error. [1] - https://github.com/odoo/enterprise/blob/8d7a13822e9fd480a6e279ff93e29834a6668536/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L974-L975 Sentry - 6622171121 Forward-Port-Of: odoo/enterprise#86211
…tion_reg_payslip_lines This argument causes several issues and do not make sense as there is already a default_partner_id. For example, you click on payslip lines from the contact Abigail Peterson, and it filters everything with a search on partner_id = 1, which doesn't make sense. It also causes issues if the partner with id 1 doesn't exists. opw-4516239 Forward-Port-Of: odoo/enterprise#78287
Original PR description
…tion_reg_payslip_lines This argument causes several issues and do not make sense as there is already a default_partner_id. For example, you click on payslip lines from the contact Abigail Peterson, and it filters everything with a search on partner_id = 1, which doesn't make sense. It also causes issues if the partner with id 1 doesn't exists. opw-4516239 Forward-Port-Of: odoo/enterprise#78287