Friday, June 6, 2025
40 changes · saas-18.3
Enhancements to existing features
The manufacturing barcode test tour was adjusted to match a new product naming convention introduced elsewhere. This keeps automated checks aligned with the latest naming format and helps prevent false test failures.
Original PR description
The tour is adapted to follow new naming convention introduced in the community PR. Task [4745662](https://www.odoo.com/odoo/project/966/tasks/4745662) odoo/odoo#207217
Resolved issues and error corrections
Chat windows now have a stronger shadow so conversations stand out better from the page content behind them. This makes messages easier to read and reduces visual confusion when chat overlaps other information.
Original PR description
Before this commit, when there was some content under chat windows, this was hard to read chat window conversations and content below. This happens because the chat windows lack visual separation from the content below: everything looked flat. There was a slight `.shadow-sm` on chat window but it barely contributed to separation with background. This commit fixes it by using stronger `.shadow` instead. Before  After 
Miscellaneous changes
Versions -------- - 18.0+ Steps ----- 1. Install `website_sale_loyalty` without demo data; 2. configure taxes to be included in the price; 2. run `test_apply_coupon_with_multiple_rewards`. Issue ----- Test fails. Cause ----- The test compares the product's list price to the order subtotal. With `price_include` set to `True`, the product's `list_price` does include taxes, making the comparison invalid. Solution -------- Explicitly set `taxes_id` to `False` on products crea
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Install `website_sale_loyalty` without demo data; 2. configure taxes to be included in the price; 2. run `test_apply_coupon_with_multiple_rewards`. Issue ----- Test fails. Cause ----- The test compares the product's list price to the order subtotal. With `price_include` set to `True`, the product's `list_price` does include taxes, making the comparison invalid. Solution -------- Explicitly set `taxes_id` to `False` on products created for the test. Also ensure the pricelist & partner don't change in the test. runbot-223362 Forward-Port-Of: odoo/odoo#212424 Forward-Port-Of: odoo/odoo#211694
The website module now handles malformed website domain names more safely instead of letting them stop an upgrade. This reduces upgrade failures caused by invalid domain settings and helps affected customers complete migrations more reliably.
Original PR description
It's possible that the `hostname` obtained from `website_domain` is invalid, for instance: ``` website_domain='https://.com' hostname='.com' ``` Attempt to encode it with `idna` will raise an error: `UnicodeError: encoding with 'idna' codec failed (UnicodeError: label empty or too long)` There's a few upgrades to 18.3 failing due to this: [Traceback Group](https://upgrade.odoo.com/odoo/action-178/2029) Tested with [upg-2847175](https://upgrade.odoo.com/odoo/action-150/2847175)
Bank statement lines now correctly match a customer or vendor even when the same partner has multiple linked bank accounts with the same account number. This prevents valid matches from being missed during bank reconciliation, reducing manual correction work.
Original PR description
There was a corner case where a single partner should match a statement line but would not. The case was when the statement line account number matches multiple accounts that are linked to the same active partner. This commit fixes this issue by relying on the number of partners instead of the number of banks while matching. task-4826477
The EC Sales List warning now more accurately identifies truly duplicated VAT numbers. This prevents businesses from seeing unnecessary duplicate VAT alerts when a customer has both invoices and refunds in the same reporting period.
Original PR description
Fixed the computation of `is_vat_duplicated` to avoid false positive in case of partners having both invoices and refunds in the selected period.
Point of Sale IoT auto-configuration now prefers USB-connected receipt printers over network printers when assigning a printer. This helps improve receipt printing reliability during POS setup by choosing the more dependable connection type first.
Original PR description
Currently when auto-configuring IoT with pos printers we take the first available receipt printer we assign to PoS we chose. However if the printer is usb-connected it should take priority over network printers for the reliability reasons. task-4853231
Opening the return kanban now applies its expanded group setting only to that specific return view. This prevents unrelated kanban views from being unintentionally changed, keeping other workflows consistent for users.
Original PR description
Before when we would open the return kanban, it would set for every other kanban the variable MAX_NUMBER_OPENED_GROUPS to max integer. This is not what we want, we only weant to restrict that to the Return Kanban Model only not every relational model.
Portal users will no longer see the Invite button when sharing Knowledge articles. This prevents them from triggering an access error for an action they are not allowed to use, improving the sharing experience.
Original PR description
Currently, the "Invite" button is visible to portal users. When a portal user clicks this button, the system attempts to open a wizard using the `knowledge.invite` model. However, because portal users lack access rights to this model, the system raises an "Access Error". Steps to reproduce: 1. Log in as a portal user 2. Open an article 3. Click on the "Share" button 4. Click on the "Invite" button => Traceback: Access Error on the model `knowledge.invite` To fix the issue, we will simply hide the "Invite" button for the portal user as it was the case before the permission panel refactoring. See: odoo/enterprise#76261 Task-4636494
Steps to reproduce: 1. Create an invoice. 2. Register a payment in the 'pending' state. 3. Cancel the invoice. 4. Confirm the payment (set payment state to 'done'). 5. Run the post_process cron job and check the logs. → Error occurs during reconciliation due to the cancelled invoice. Issue: cancelled invoices were being considered during the reconciliation process, leading to errors. Solution: This fix ensures that only posted invoices are considered during the reconciliation
Original PR description
Steps to reproduce: 1. Create an invoice. 2. Register a payment in the 'pending' state. 3. Cancel the invoice. 4. Confirm the payment (set payment state to 'done'). 5. Run the post_process cron job and check the logs. → Error occurs during reconciliation due to the cancelled invoice. Issue: cancelled invoices were being considered during the reconciliation process, leading to errors. Solution: This fix ensures that only posted invoices are considered during the reconciliation process, thereby preventing such issues. Forward-Port-Of: odoo/odoo#211036
Versions -------- - 18.0+ Steps ----- 1. Enable Demo express checkout; 2. pay with Demo Express checkout in eCommerce. Issue ----- Validation error: No delivery method is available. Cause ----- Commit bf8d08cd22b5 changed the express checkout delivery method RPC API. Instead of an array, `availableCarriers` is now an object with a `delivery_methods` attribute. Because it checks the length of an object, which is `undefined`, Demo express checkout incorrectly believes no deliv
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Enable Demo express checkout; 2. pay with Demo Express checkout in eCommerce. Issue ----- Validation error: No delivery method is available. Cause ----- Commit bf8d08cd22b5 changed the express checkout delivery method RPC API. Instead of an array, `availableCarriers` is now an object with a `delivery_methods` attribute. Because it checks the length of an object, which is `undefined`, Demo express checkout incorrectly believes no delivery methods are available. Solution -------- Check the length of `delivery_methods` instead of `availableCarriers`. Forward-Port-Of: odoo/odoo#213240
When changing the website view of the events from grid to list, we are losing the "Sold out, Unpublished, etc" information that was displayed on the card. This is due to loading the event calendar date widget before the rest of the elements which is provoking them to not properly load. opw-4597647 ## Before:  ## After: ![image](https://github.com/user-attachments/assets/c02aca35-c2c6-4c43-90
Original PR description
When changing the website view of the events from grid to list, we are losing the "Sold out, Unpublished, etc" information that was displayed on the card. This is due to loading the event calendar date widget before the rest of the elements which is provoking them to not properly load. opw-4597647 ## Before:  ## After:  Forward-Port-Of: odoo/odoo#199830
Before this commit, when a Many field has a One inverse, assigning on the many field in a specific index lead to a crash. The crash was fixed by https://github.com/odoo/odoo/pull/212963 But the resulting relations were still incorrect: the old record still was linked in the relation, and the new record was not properly linked in the inverse field. This was happening due to similar typo in the inner code of JS models: deletion and addition of respectively old and new records were done with
Original PR description
Before this commit, when a Many field has a One inverse, assigning on the many field in a specific index lead to a crash. The crash was fixed by https://github.com/odoo/odoo/pull/212963 But the…
Before this commit, when a Many field has a One inverse, assigning on the many field in a specific index lead to a crash. The crash was fixed by https://github.com/odoo/odoo/pull/212963 But the resulting relations were still incorrect: the old record still was linked in the relation, and the new record was not properly linked in the inverse field. This was happening due to similar typo in the inner code of JS models: deletion and addition of respectively old and new records were done with respectively `recordList.delete(recordList)` and `recordList.add(recordList)`. The error comes from passing `recordList` instead of `recordList._.owner`, i.e. the old/new records. The typo comes from `RecordUses` that also have methods `add` and `delete` and have `recordList` as 1st param. FYI, `RecordUses` is used for very-low level internal links of record being used by other records. Semantically this is like a relational field but the shape differs for improved computational complexity. Forward-Port-Of: odoo/odoo#213203
Steps to reproduce =================== 1. Open a record with chatter, and open the full composer. 2. Add a custom subject and add a body. 3. Schedule message to send in the future. 4. Click on send now from chatter. => Subject is not propagated to the mail After this commit ================= This commit propagate subject to mail. Task-4845440 Forward-Port-Of: odoo/odoo#213188 Forward-Port-Of: odoo/odoo#213093
Original PR description
Steps to reproduce =================== 1. Open a record with chatter, and open the full composer. 2. Add a custom subject and add a body. 3. Schedule message to send in the future. 4. Click on send now from chatter. => Subject is not propagated to the mail After this commit ================= This commit propagate subject to mail. Task-4845440 Forward-Port-Of: odoo/odoo#213188 Forward-Port-Of: odoo/odoo#213093
Previously, e-waybills generated through IRN did not include dispatch details (`DispDtls`) and export shipping details (`ExpShipDtls`) in the JSON payload. In this commit: ---- - Added `DispDtls` to include dispatch location details (name, address, city, PIN, state TIN) from the shipping-from partner. - Added `ExpShipDtls` to include shipping destination details (address, city, PIN, state TIN) from the shipping-to partner. - The `ExpShipDtls` (export shipping details) is included
Original PR description
Previously, e-waybills generated through IRN did not include dispatch details (`DispDtls`) and export shipping details (`ExpShipDtls`) in the JSON payload. In this commit: ---- - Added `DispDtls` to include dispatch location details (name, address, city, PIN, state TIN) from the shipping-from partner. - Added `ExpShipDtls` to include shipping destination details (address, city, PIN, state TIN) from the shipping-to partner. - The `ExpShipDtls` (export shipping details) is included only for overseas transactions. > `DispDtls`: the company from which the goods are dispatched > `ExpShipDtls`: the entity to which the goods are shipped to ---- Refer: https://einv-apisandbox.nic.in/version1.03/ewaybill-generation-irn.html#JSONSchema Forward-Port-Of: odoo/odoo#213132 Forward-Port-Of: odoo/odoo#209869
This is clearer. It also avoids some noisy messages in runbot. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213016 Forward-Port-Of: odoo/odoo#212037
Original PR description
This is clearer. It also avoids some noisy messages in runbot. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213016 Forward-Port-Of: odoo/odoo#212037
Commit [1] added the use of the portal user in test_01_donation. Its forward-port at [2] was adapted so that it works without demo data, and more, as it became the new default in that version. But [1] still made our test fail in some custom non-demo runbot builds. This commit fixes that by backporting the relevant parts of [2]. [1]: https://github.com/odoo/odoo/commit/4229a3f68e17f05b75bd13347589497682575bd0 [2]: https://github.com/odoo/odoo/commit/c4418cdbf82627fa7c0dc43087de790d61c01208
Original PR description
Commit [1] added the use of the portal user in test_01_donation. Its forward-port at [2] was adapted so that it works without demo data, and more, as it became the new default in that version. But [1] still made our test fail in some custom non-demo runbot builds. This commit fixes that by backporting the relevant parts of [2]. [1]: https://github.com/odoo/odoo/commit/4229a3f68e17f05b75bd13347589497682575bd0 [2]: https://github.com/odoo/odoo/commit/c4418cdbf82627fa7c0dc43087de790d61c01208 runbot-223118 Forward-Port-Of: odoo/odoo#213265 Forward-Port-Of: odoo/odoo#213198
*: l10n_ar_pos, l10n_pe_pos, portal, website_sale Issue 1: ========== Steps: ----------- - Install point_of_sale. - Open a PoS Register. - Process an order until the receipt screen. - Scan the QR for self-invoicing. Issue: ----------- - A traceback occurs when trying to access a value from a `null` reference. Cause: ----------- - The `o_portal_details` class was included in the rendered template, even when the country selection was unavailable. FIX: ---------- - Removed
Original PR description
*: l10n_ar_pos, l10n_pe_pos, portal, website_sale Issue 1: ========== Steps: ----------- - Install point_of_sale. - Open a PoS Register. - Process an order until the receipt screen. - Scan the QR for…
*: l10n_ar_pos, l10n_pe_pos, portal, website_sale
Issue 1:
==========
Steps:
-----------
- Install point_of_sale.
- Open a PoS Register.
- Process an order until the receipt screen.
- Scan the QR for self-invoicing.
Issue:
-----------
- A traceback occurs when trying to access a value from a `null` reference.
Cause:
-----------
- The `o_portal_details` class was included in the rendered template, even when the country selection was unavailable.
FIX:
----------
- Removed the unrelated o_portal_details class from the template to prevent the error.
Issue 2:
==========
Steps:
----------
- Install point_of_sale.
- Open a PoS Register.
- Process an order until the receipt screen.
- Scan the QR for self-invoicing with public user.
- Attempt to generate an invoice for a country where state selection is required for the invoice.
Issue:
----------
- The invoice is not generated due to missing state selection.
Cause:
----------
- The state selection field was not available, even when required for invoicing.
FIX:
----------
- Ensured the state field is displayed when required based on the selected country.
- Applied `address_autoformat` and `o_customer_address_fill` classes to dynamically update the field based on country selection.
- Changed authentication for the `/my/address/country_info/<model("res.country"):country>` route from `user` to `publi`c to allow public users to retrieve country-specific address formats.
task-4649241
Related PR:
- Enterprise: https://github.com/odoo/enterprise/pull/81639
Forward-Port-Of: odoo/odoo#201995Problem: When trying to align a separator to the left or right in the email editor using `ms-auto` or `me-auto`, it remains centered instead of aligning as intended. Cause: A global `margin: auto` rule was applied to all `hr` elements, overriding the directional margin utilities (`ms-auto`, `me-auto`), preventing correct alignment. Solution: Restrict `margin: auto` to only apply on `hr` elements that do *not* have `ms-auto` or `me-auto` classes. This preserves default centering while al
Original PR description
Problem: When trying to align a separator to the left or right in the email editor using `ms-auto` or `me-auto`, it remains centered instead of aligning as intended. Cause: A global `margin: auto` rule was applied to all `hr` elements, overriding the directional margin utilities (`ms-auto`, `me-auto`), preventing correct alignment. Solution: Restrict `margin: auto` to only apply on `hr` elements that do *not* have `ms-auto` or `me-auto` classes. This preserves default centering while allowing explicit left or right alignment. Steps to reproduce: - Open Email Marketing and add a "Separator" to an email. - Try to align the separator to the left or right. → The separator remains centered instead of aligning properly. opw-4805194 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212496
…again) When a partner was set on account.move.line but not on its related account.move, reconciliation would break upon changing the parent_id of a partner. This wasn't expected. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213176
Original PR description
…again) When a partner was set on account.move.line but not on its related account.move, reconciliation would break upon changing the parent_id of a partner. This wasn't expected. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213176
Forward-Port-Of: odoo/odoo#212951
Original PR description
Forward-Port-Of: odoo/odoo#212951
Before this PR, the Generic Tax Report had always been considered as the only report necessary to handle the US taxes. The problem is that, if a company needs to submit tax reports in multiple countries (because it has a VAT number in them; what we call multivat in the Odoo jargon), the Generic Tax Report would then show the taxes from every company, not only the US ones, hence becoming a bit messy. In 18.3+, this also causes issues with the tax returns, which need to know the country they belon
Original PR description
Before this PR, the Generic Tax Report had always been considered as the only report necessary to handle the US taxes. The problem is that, if a company needs to submit tax reports in multiple countries (because it has a VAT number in them; what we call multivat in the Odoo jargon), the Generic Tax Report would then show the taxes from every company, not only the US ones, hence becoming a bit messy. In 18.3+, this also causes issues with the tax returns, which need to know the country they belong to in order to properly set the tax lock date. We solve that by introducing a new US tax report. It does the same as the Generic Tax Report, but shows only the US taxes. Forward-Port-Of: odoo/odoo#213044 Forward-Port-Of: odoo/odoo#212146
Description of the issue/feature this PR addresses: Issue: if only one line is edited/added and it's account is not of type off-balance, the check will fail to raise the warning Steps to reproduce the error: 1. Create entry 2. Account move line 1 with account off balance 3. Account move line 2 with account off balance 4. Save move 5. Edit line 2, change the account to an asset type account. 6. Save move. The system does not give a warning. Current behavior before PR: Desired beha
Original PR description
Description of the issue/feature this PR addresses: Issue: if only one line is edited/added and it's account is not of type off-balance, the check will fail to raise the warning Steps to reproduce the error: 1. Create entry 2. Account move line 1 with account off balance 3. Account move line 2 with account off balance 4. Save move 5. Edit line 2, change the account to an asset type account. 6. Save move. The system does not give a warning. 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#213046 Forward-Port-Of: odoo/odoo#211811
Currently, an exception is generated when the system tries to find the product category for the newly added `product_flour` if all categories have been deleted manually before loading demo data. Steps to reproduce: 1. Install the `point_of_sale` module without demo data. 2. Navigate to Inventory -> Configuration -> Categories. 3. Delete food categories. 4. Navigate to Point of Sale -> load sample of bakery 5. An error occurs. Error: ``` ParseError while parsing /home/odoo/src/odo
Original PR description
Currently, an exception is generated when the system tries to find the product category for the newly added `product_flour` if all categories have been deleted manually before loading demo data. Steps to reproduce: 1. Install the `point_of_sale` module without demo data. 2. Navigate to Inventory -> Configuration -> Categories. 3. Delete food categories. 4. Navigate to Point of Sale -> load sample of bakery 5. An error occurs. Error: ``` ParseError while parsing /home/odoo/src/odoo/saas-18.2/addons/product/data/product_demo.xml:30, somewhere inside ``` This issue occurs because `product_flour` also references a missing product category. As with previous products, this change ensures a fallback to avoid failure when no categories exist. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212062
**Patch description:** - This commit addresses a perf issue in the `_compute_previous_order` compute of the `pos.order` model, which is particularly noticeable during db upgrade from `v17.0` to `v18.0` because field `previous_order_id` got introduced in `v18.0` or when installing the `l10n_fr_pos_cert` module on an existing db with many POS orders in `v18.0`. - In both cases, the compute method is triggered for all `pos.order` records to assign the `previous_order_id`, causing significant de
Original PR description
**Patch description:** - This commit addresses a perf issue in the `_compute_previous_order` compute of the `pos.order` model, which is particularly noticeable during db upgrade from `v17.0` to…
**Patch description:** - This commit addresses a perf issue in the `_compute_previous_order` compute of the `pos.order` model, which is particularly noticeable during db upgrade from `v17.0` to `v18.0` because field `previous_order_id` got introduced in `v18.0` or when installing the `l10n_fr_pos_cert` module on an existing db with many POS orders in `v18.0`. - In both cases, the compute method is triggered for all `pos.order` records to assign the `previous_order_id`, causing significant delay due to per-record lookups. **Example from a real DB with ~113k orders:** ```sql apan_2840187=> select count(*) from pos_order; count -------- 113342 (1 row) ``` **Observation:** - Before the fix (compute took nearly 50 minutes): ```py 2025-05-29 06:31:12,587 28 INFO apan_2840187_18.0 odoo.modules.registry: module l10n_fr_pos_cert: creating or updating database tables 2025-05-29 06:31:12,799 28 INFO apan_2840187_18.0 odoo.models: Prepare computation of pos.order.previous_order_id 2025-05-29 07:17:37,855 28 INFO apan_2840187_18.0 odoo.modules.loading: loading l10n_fr_pos_cert/views/pos_views.xml ``` - After the fix (completed within 1 min): ```py 2025-05-30 06:56:59,510 24 INFO apan_2840187_18.0 odoo.modules.registry: module l10n_fr_pos_cert: creating or updating database tables 2025-05-30 06:56:59,584 24 INFO apan_2840187_18.0 odoo.models: Prepare computation of pos.order.previous_order_id 2025-05-30 06:57:12,531 24 INFO apan_2840187_18.0 odoo.modules.loading: loading l10n_fr_pos_cert/views/pos_views.xml ``` **Note:** The issue reported in the OPW was not originally about perf, but it was clearly exposed during the upgrade of the mentioned db. opw-4812874 upg-2840187 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212626 Forward-Port-Of: odoo/odoo#212339
Ensure correct editability of Bill To, Bill From, Ship To, and Ship From fields based on stock and accounting moves. - For accounting moves: - Always allow editing of Ship To and Ship From - Keep Bill To and Bill From readonly - For stock moves: - Incoming: Bill From and Ship To are editable - Outgoing: Bill To and Ship From are editable task-4680493 Forward-Port-Of: odoo/odoo#204240
Original PR description
Ensure correct editability of Bill To, Bill From, Ship To, and Ship From fields based on stock and accounting moves. - For accounting moves: - Always allow editing of Ship To and Ship From - Keep Bill To and Bill From readonly - For stock moves: - Incoming: Bill From and Ship To are editable - Outgoing: Bill To and Ship From are editable task-4680493 Forward-Port-Of: odoo/odoo#204240
**ORIGINAL Issue:** When an email with an attachment was sent to a project alias (configured to create tasks and documents in a specific project), and the target project's Documents folder was explicitly owned by a company (`Company2`) distinct from the current system company (`Company1`), the alias creation process for the resulting documents would fail. The error message indicated a domain mismatch: "We could not create alias Inactive Alias because domain company1.com belongs to company
Original PR description
**ORIGINAL Issue:** When an email with an attachment was sent to a project alias (configured to create tasks and documents in a specific project), and the target project's Documents folder was…
**ORIGINAL Issue:** When an email with an attachment was sent to a project alias (configured to create tasks and documents in a specific project), and the target project's Documents folder was explicitly owned by a company (`Company2`) distinct from the current system company (`Company1`), the alias creation process for the resulting documents would fail. The error message indicated a domain mismatch: "We could not create alias Inactive Alias because domain company1.com belongs to company YourCompany while the owner document belongs to company Company2." **Changes in 18.1 FW** This commit adapts the existing mail alias company test to the `documents_hr_recruitment` module context for saas-18.1. Previously, the test targeted `documents_project`, but changes in saas-18.1 indicate that sending an email to a project alias no longer creates documents via the `document.mixin` in the same way. **Changes in 18.3 FW** Since Odoo 18.3, inactive aliases are not created anymore for binary attachments But the fix introduced with this commit still makes sense in case of custom message processing that creates folders for example For now we usurp this test by mocking the method to fit our needs TODO: when a proper testing module exists in the future for documents.mixin, this can be recycled as need The core bug remains: ensuring that when a document is created via an incoming email alias, and it targets a folder explicitly owned by a specific company (in a multi-company setup), the created document and its associated alias correctly inherit that folder's company, preventing alias domain mismatch errors. **Proposed Solution and Justification:** The chosen solution centralizes the `company_id` assignment for new documents within the `_get_document_vals` method of the `documents.mixin.DocumentMixin` abstract model. This method is the primary entry point for determining default values when any model inheriting `DocumentMixin` creates a linked `documents.document` record. The fix ensures that when `document_vals` are prepared, the `company_id` of the new document is explicitly pulled from the `company_id` of its designated `folder` (retrieved via `_get_document_folder()`). **Steps to reproduce (multi-company in 18.1 with documents_hr_recruitment):** 1. **Install Modules:** `hr_recruitment` and `documents` are installed. 2. **Create Company-Owned Folder:** A Documents folder (`hr-company2`) is created and explicitly owned by Company 2. 3. **Configure HR Recruitment Workspace:** In Documents settings, the recruitment workspace is configured to use the `hr-company2` folder. This is done by setting `documents_recruitment_settings` and `recruitment_folder_id` on `res.company` for Company B. 4. **Create Job Posting:** A new job posting is created in `hr_recruitment` (owned by Company 2) with an email alias. 5. **Simulate Incoming Email:** An email with an attachment is sent to this job posting's alias. 6. **Error**: mail alias during document creation fails because of miss-matched companies opw-4727873 X-original-commit: https://github.com/odoo/enterprise/commit/17f18d2f48b95b53f977c974d321dcb1c4f33d56
In this commit: ========== - We will display the provider's order ID in the order receipt header. Before this commit: ----------  After this commit: ----------  task-4840924 Forward-Port-Of: odoo/enterprise#87128 Forward-Port-Of: odoo/enterprise#86790
Original PR description
In this commit: ========== - We will display the provider's order ID in the order receipt header. Before this commit: ----------  After this commit: ----------  task-4840924 Forward-Port-Of: odoo/enterprise#87128 Forward-Port-Of: odoo/enterprise#86790
Upgrading from 16 to 17 causes issues with demo data. It happens when the main company has no chart template, because it won't find the correct `account.journal` for the moves (and `account.account` for the lines). To reproduce: - initialize an Odoo 16.0 database with `account_accountant` and NO demo data. (There will be no country_id set on the default company, so the `post_install` hook in `account` won't install `l10n_generic_coa`) - install demo data (the `post_install` hook in `accoun
Original PR description
Upgrading from 16 to 17 causes issues with demo data. It happens when the main company has no chart template, because it won't find the correct `account.journal` for the moves (and `account.account` for the lines). To reproduce: - initialize an Odoo 16.0 database with `account_accountant` and NO demo data. (There will be no country_id set on the default company, so the `post_install` hook in `account` won't install `l10n_generic_coa`) - install demo data (the `post_install` hook in `account` is then not fired, still no `l10n_generic_coa`) - upgrade to Odoo 17.0 By creating the demo data in Python instead of the XML, we can put the condition to avoid creating the move if we do not have a chart template on the company. Community PR: odoo/odoo#200420 opw-4781045 Forward-Port-Of: odoo/enterprise#86341 Forward-Port-Of: odoo/enterprise#80812
Previously, the `referral_state` was not reset when reprocessing an applicant, which could lead to inconsistencies in the referral tracking. This commit ensures that the `referral_state` is explicitly set to `'progress'` when the applicant is reset, maintaining proper state management in the referral process. opw-4523156 Forward-Port-Of: odoo/enterprise#86077 Forward-Port-Of: odoo/enterprise#79767
Original PR description
Previously, the `referral_state` was not reset when reprocessing an applicant, which could lead to inconsistencies in the referral tracking. This commit ensures that the `referral_state` is explicitly set to `'progress'` when the applicant is reset, maintaining proper state management in the referral process. opw-4523156 Forward-Port-Of: odoo/enterprise#86077 Forward-Port-Of: odoo/enterprise#79767
Before this commit, validating an order from the mobile menu caused an error because the 'name' field was removed from the order in the process_order method of self order. Since the 'pos_reference' field exists and is correct to use (unlike 'name', which may be '/'), the code has been updated to use 'pos_reference' instead. opw-4758288 Forward-Port-Of: odoo/enterprise#85266
Original PR description
Before this commit, validating an order from the mobile menu caused an error because the 'name' field was removed from the order in the process_order method of self order. Since the 'pos_reference' field exists and is correct to use (unlike 'name', which may be '/'), the code has been updated to use 'pos_reference' instead. opw-4758288 Forward-Port-Of: odoo/enterprise#85266
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 Forward-Port-Of: odoo/en
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 Forward-Port-Of: odoo/enterprise#86512 Forward-Port-Of: odoo/enterprise#85123
### Issue: When trying to upload the video for a Youtube post, we are getting a traceback with "UncaughtPromiseError > TypeError", caused by not having the `youtube_video_category_id` field properly loaded, at the time where we are trying to evaluate `_preprocessReferenceChanges` we try to access the type of the field as `this.fields[fieldName].type === "reference"` where `fieldName` is `youtube_video_category_id`, but the field is not loaded yet (this.fields[fieldName] is undefined), so we get
Original PR description
### Issue: When trying to upload the video for a Youtube post, we are getting a traceback with "UncaughtPromiseError > TypeError", caused by not having the `youtube_video_category_id` field properly loaded, at the time where we are trying to evaluate `_preprocessReferenceChanges` we try to access the type of the field as `this.fields[fieldName].type === "reference"` where `fieldName` is `youtube_video_category_id`, but the field is not loaded yet (this.fields[fieldName] is undefined), so we get an error. ### Solution: This commit adds this field as a field dependecy for the `YoutubeUploadField` widget, so that it is loaded when we try to access it. opw-4646432 Forward-Port-Of: odoo/enterprise#83571
Runbot error: https://runbot.odoo.com/odoo/error/160977 This commit fixes the tour by moving the steps related to the contract management in the python part of the test. Also fixes the formatting of the tour file. Forward-Port-Of: odoo/enterprise#86106 Forward-Port-Of: odoo/enterprise#83686
Original PR description
Runbot error: https://runbot.odoo.com/odoo/error/160977 This commit fixes the tour by moving the steps related to the contract management in the python part of the test. Also fixes the formatting of the tour file. Forward-Port-Of: odoo/enterprise#86106 Forward-Port-Of: odoo/enterprise#83686
The `MoveArticleDialog` component uses the display name to indicate which article will be moved. However, this field is not loaded on the record object, resulting in an undefined value. As a result, the modal incorrectly displays the article as untitled. Steps to reproduce the issue: 1. Open an article in Knowledge 2. Make sure that the article has a title 3. Click on the "Move To" option from the kebab menu => The modal says "Move the untitled article under:" TO BE: The modal should
Original PR description
The `MoveArticleDialog` component uses the display name to indicate which article will be moved. However, this field is not loaded on the record object, resulting in an undefined value. As a result, the modal incorrectly displays the article as untitled. Steps to reproduce the issue: 1. Open an article in Knowledge 2. Make sure that the article has a title 3. Click on the "Move To" option from the kebab menu => The modal says "Move the untitled article under:" TO BE: The modal should say: "Move <display_name> under:" To fix the issue, we will add the `display_name` field to the field dependencies of the `KnowledgeTopbar` component. Task-4636494 Forward-Port-Of: odoo/enterprise#87026 Forward-Port-Of: odoo/enterprise#86059
Before this commit the opening balance in the iras audit export was always at 0. This was caused because it would call _query_values which was not returning the initial balances. The fix was to instead call _get_initial_balance_values. With this we could finally get the opening balances. task-4826744 Forward-Port-Of: odoo/enterprise#86907 Forward-Port-Of: odoo/enterprise#86600
Original PR description
Before this commit the opening balance in the iras audit export was always at 0. This was caused because it would call _query_values which was not returning the initial balances. The fix was to instead call _get_initial_balance_values. With this we could finally get the opening balances. task-4826744 Forward-Port-Of: odoo/enterprise#86907 Forward-Port-Of: odoo/enterprise#86600
In this commit: - We are replacing the XPath class `o_portal_details` to `o_customer_address_fill` according to changes in the related community PR. task-4649241 Related PR: - Community: https://github.com/odoo/odoo/pull/201995 Forward-Port-Of: odoo/enterprise#81639
Original PR description
In this commit: - We are replacing the XPath class `o_portal_details` to `o_customer_address_fill` according to changes in the related community PR. task-4649241 Related PR: - Community: https://github.com/odoo/odoo/pull/201995 Forward-Port-Of: odoo/enterprise#81639
**PROBLEM** When confirming an invoice, the payment policy of the invoice was overridden by the payment policy assigned to the partner, and the user had to reselect the correct policy. **STEP TO REPRODUCE** 1. On a fresh database, install the l10n_mx_edi module. 2. Select the "ZAPATERIA URTADO ÑERI" as your company (demo mexican company). 3. Set a payment policy on a client. 4. Create an invoice with this client, and set the payment policy equal to a different policy than the client. 5.
Original PR description
**PROBLEM** When confirming an invoice, the payment policy of the invoice was overridden by the payment policy assigned to the partner, and the user had to reselect the correct policy. **STEP TO…
**PROBLEM** When confirming an invoice, the payment policy of the invoice was overridden by the payment policy assigned to the partner, and the user had to reselect the correct policy. **STEP TO REPRODUCE** 1. On a fresh database, install the l10n_mx_edi module. 2. Select the "ZAPATERIA URTADO ÑERI" as your company (demo mexican company). 3. Set a payment policy on a client. 4. Create an invoice with this client, and set the payment policy equal to a different policy than the client. 5. Confirm the invoice, the payment policy field will take the value of the client policy, overriding what we set in the invoice. **CAUSE** https://github.com/odoo/enterprise/blob/3f42e4322dbd684d9431a172c11a369090b21c0c/l10n_mx_edi/models/account_move.py#L615-L620 The payment policy compute method is incorrect, we should select the partner policy as a last resort to avoid overriding what the user chose. **FIX** Reorder the fallback: If the invoice is a refund, payment policy should be PUE. Else, if the user set a payment policy in the invoice form, we should keep it. Finally, if the partner has a payment policy, select it. opw-4820139 Forward-Port-Of: odoo/enterprise#86918
Before this PR, the Generic Tax Report had always been considered as the only report necessary to handle the US taxes. The problem is that, if a company needs to submit tax reports in multiple countries (because it has a VAT number in them; what we call multivat in the Odoo jargon), the Generic Tax Report would then show the taxes from every company, not only the US ones, hence becoming a bit messy. In 18.3+, this also causes issues with the tax returns, which need to know the country they belon
Original PR description
Before this PR, the Generic Tax Report had always been considered as the only report necessary to handle the US taxes. The problem is that, if a company needs to submit tax reports in multiple countries (because it has a VAT number in them; what we call multivat in the Odoo jargon), the Generic Tax Report would then show the taxes from every company, not only the US ones, hence becoming a bit messy. In 18.3+, this also causes issues with the tax returns, which need to know the country they belong to in order to properly set the tax lock date. We solve that by introducing a new US tax report. It does the same as the Generic Tax Report, but shows only the US taxes. Forward-Port-Of: odoo/enterprise#87045 Forward-Port-Of: odoo/enterprise#86638
Currently, if there is an error while generation print reports the use of the IoT will return the generic error `Failed to send to printer' which does not lead to understand there is a hidden issue to begin with. Steps to reproduce: ------------------- 1. Set up the iot and like the product labels report to a zebra printer 2. Modify the view of the product labels (`label_product_product_view`) to ensure there is an error during rendering (mistype a field name) 3. Go to a product and print
Original PR description
Currently, if there is an error while generation print reports the use of the IoT will return the generic error `Failed to send to printer' which does not lead to understand there is a hidden issue…
Currently, if there is an error while generation print reports the use of the IoT will return the generic error `Failed to send to printer' which does not lead to understand there is a hidden issue to begin with. Steps to reproduce: ------------------- 1. Set up the iot and like the product labels report to a zebra printer 2. Modify the view of the product labels (`label_product_product_view`) to ensure there is an error during rendering (mistype a field name) 3. Go to a product and print labels > Observation: Notification: Failed to send to printer Why the fix: ------------ In the example given an error occurs when trying to render the label here: https://github.com/odoo/enterprise/blob/968bf16c65a67791efd5fb94f5c95eaf09a47107/iot/static/src/iot_report_action.js#L50-L57 Technically the error makes it so that we fall into this catch block https://github.com/odoo/enterprise/blob/968bf16c65a67791efd5fb94f5c95eaf09a47107/iot/static/src/iot_report_action.js#L81-L88 We will now make a distinction between the RPC error and generic iot related error. If any error occur while making the RPC call we will now show the traceback. This should help anyone debugging. opw-4571350 Forward-Port-Of: odoo/enterprise#84589