Navigate
Branch
Monday, July 29, 2024
66 changes
31 changes
Resolved issues and error corrections
Fixed an issue where opening certain partner links in a new browser tab could show the record the user was already viewing instead of the intended linked partner. This ensures duplicate Tax ID links and similar record links take users to the correct destination, reducing confusion and navigation errors.
Original PR description
Currently, links created with the `Many2OneField` component won't work properly if opened in a new tab. ### Steps to reproduce * create two partners with the same Tax ID * each partner should display a link to the other partner, indicating a duplicate Tax ID. * open one of those links in a new tab When the link is opened in a new tab, it displays the record you were originally viewing instead of the intended partner. opw-4050312
This update fixes several issues affecting everyday Odoo workflows, including loyalty orders, vendor bill purchase order selection, email sender handling, manufacturing work orders, and localized accounting reports. It improves reliability and compliance behavior across point of sale, purchasing, email, manufacturing, and country-specific accounting features.
Original PR description
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
Miscellaneous changes
To replicate the issue: 1. Go to Accounting app 2. Click on the Accounting menu => Journal Entries 3. Click the button Upload 4. After selecting a file, an error is raise, saying that "The journal in which to upload the invoice is not specified." Cause: In the view for Journal Entries, there isn't a particular journal associated with it, so there is no definition the journal in which the document should be uploaded. Before 17.0, the document was uploaded to a default journal. Without a d
Original PR description
To replicate the issue: 1. Go to Accounting app 2. Click on the Accounting menu => Journal Entries 3. Click the button Upload 4. After selecting a file, an error is raise, saying that "The journal in…
To replicate the issue: 1. Go to Accounting app 2. Click on the Accounting menu => Journal Entries 3. Click the button Upload 4. After selecting a file, an error is raise, saying that "The journal in which to upload the invoice is not specified." Cause: In the view for Journal Entries, there isn't a particular journal associated with it, so there is no definition the journal in which the document should be uploaded. Before 17.0, the document was uploaded to a default journal. Without a default journal, the error is raised. This renders the button useless in this view, as it will always raise an error after the user has selected a file to upload. Fix: The button should not be shown in the Journal Entries view (through Accounting => Journal Entries). But if the user is in a specific journal (for example, navigating from Accounting Dashboard => Miscellaneous Operations), the button should be shown. To do so, the account move list and kanban controllers in bills_upload check if the default move type is 'entry', and if so, whether there is an active id in the context. This allows differentiating between the specific journals or the general Journal Entries view. opw-4029227 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174669 Forward-Port-Of: odoo/odoo#174561
### Steps to reproduce: - Enable Multi-step routes - Create a storable product P - Change the on hand quantity to 10 - Create and confirm a delivery order for 4 units of the product - Go back to the product form, click the "On hand" smart button - Select the quant line > Actions > duplicate ### Issues: The reserved quantity was copied but this reserved quantity does not match any move reservation. In addition, since you can not have a quant for a product twice in the same location
Original PR description
### Steps to reproduce: - Enable Multi-step routes - Create a storable product P - Change the on hand quantity to 10 - Create and confirm a delivery order for 4 units of the product - Go back to the…
### Steps to reproduce: - Enable Multi-step routes - Create a storable product P - Change the on hand quantity to 10 - Create and confirm a delivery order for 4 units of the product - Go back to the product form, click the "On hand" smart button - Select the quant line > Actions > duplicate ### Issues: The reserved quantity was copied but this reserved quantity does not match any move reservation. In addition, since you can not have a quant for a product twice in the same location (unless the product is tracked and the lot_ids are different), the two lines will be merged. However, since you can not modify the reserved quantity directly, you will not be able to update it back and you will not be able to correct the forecast by deleting your duplicated line since it does not exist anymore. #### Note: The stock.quant duplication was introduced in 17.0 because of commit 3192051 which enabled the copy action in the list view. Prior to that it was in my knowledge not possible to copy quants from the UI. ### Fix: We introduce a root attribute `duplicate="0"` on the tree view. We also add the other root attributes `duplicate="0"` added by the commit 9f2949d in saas-17.3 to prior versions where they are also needed. opw-4035690 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172376
### Steps to reproduce: - Start with an empty DB - Install account_accountant - Open settings - Search "Default Accounts" - Clear Outstanding receipts - Save - Go to Apps: Install stock #### > traceback ### Cause of the issue: The "_setup_utility_bank_accounts" method is called during the installation of the stock module. In this call, data about non-existing fields of the "account.account" model are added to the `account_data` dictionary, namely : `prefix` and `code_digits`: htt
Original PR description
### Steps to reproduce: - Start with an empty DB - Install account_accountant - Open settings - Search "Default Accounts" - Clear Outstanding receipts - Save - Go to Apps: Install stock #### >…
### Steps to reproduce: - Start with an empty DB - Install account_accountant - Open settings - Search "Default Accounts" - Clear Outstanding receipts - Save - Go to Apps: Install stock #### > traceback ### Cause of the issue: The "_setup_utility_bank_accounts" method is called during the installation of the stock module. In this call, data about non-existing fields of the "account.account" model are added to the `account_data` dictionary, namely : `prefix` and `code_digits`: https://github.com/odoo/odoo/blob/e80ff1c285ce633a75ce0de5a7cb8d3dcecd301f/addons/account/models/chart_template.py#L702-L708 Since the "Outstanding receipts" account was removed from the settings of the company, it is not removed from the `account_data` here: https://github.com/odoo/odoo/blob/e80ff1c285ce633a75ce0de5a7cb8d3dcecd301f/addons/account/models/chart_template.py#L749-L751 and the datas of these records will be loaded: https://github.com/odoo/odoo/blob/e80ff1c285ce633a75ce0de5a7cb8d3dcecd301f/addons/account/models/chart_template.py#L756-L761 If the records were to be created, it would not be problematic because these datas are popped and used by the override of the `create` method of the `account.account` model: https://github.com/odoo/odoo/blob/e80ff1c285ce633a75ce0de5a7cb8d3dcecd301f/addons/account/models/account_account.py#L701 However, in our case, the record linked to that xml_id already exists and is added to the list of the records to update. A `write` call will then be launched to update the non-existing `account.account` fields leading to the traceback: https://github.com/odoo/odoo/blob/96d98792bb34772e7acc228dd093c56f2f18b483/odoo/models.py#L5045-L5046 opw-4007561 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170580
before this commit, wrong invisible conditions were added using attrs, which is already removed after this commit, valid invisible conditions are added --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172034
Original PR description
before this commit, wrong invisible conditions were added using attrs, which is already removed after this commit, valid invisible conditions are added --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172034
Before this commit, no API version was given to StripeJS. This could lead to discrepancies between the APIs. Now, the API version used will be the same client-side and server-side. Forward-Port-Of: odoo/odoo#174713 Forward-Port-Of: odoo/odoo#169786
Original PR description
Before this commit, no API version was given to StripeJS. This could lead to discrepancies between the APIs. Now, the API version used will be the same client-side and server-side. Forward-Port-Of: odoo/odoo#174713 Forward-Port-Of: odoo/odoo#169786
[FIX] website_profile: reorder conditions accessing users profile Before we were checking for karma requirenment even if for unpublished websites now we don't. [Reproduce] - Install website_forum - Set karma to 100 for a website - Open a profile page on a forum, unselect "Public Profile" - BUG: Opening a profile page as another user render msg: "Not have enough karma to view other users's profile" Instead of a message about profile beeing private opw-3972165 Forward-Port
Original PR description
[FIX] website_profile: reorder conditions accessing users profile Before we were checking for karma requirenment even if for unpublished websites now we don't. [Reproduce] - Install website_forum - Set karma to 100 for a website - Open a profile page on a forum, unselect "Public Profile" - BUG: Opening a profile page as another user render msg: "Not have enough karma to view other users's profile" Instead of a message about profile beeing private opw-3972165 Forward-Port-Of: odoo/odoo#170784
Before this commit, when resetting the Google Calendar account in Odoo, some events and recurrences were disappearing from Odoo when they shouldn't have. This was happening because we weren't removing the 'google_id' information from deleted recurrences or even unlinking events incorrectly on the Odoo side. In addition, synchronizing only “new” or “all existing” events was not being handled correctly because the “need_sync” field should change according to the “sync_policy” selected. Followin
Original PR description
Before this commit, when resetting the Google Calendar account in Odoo, some events and recurrences were disappearing from Odoo when they shouldn't have. This was happening because we weren't removing the 'google_id' information from deleted recurrences or even unlinking events incorrectly on the Odoo side. In addition, synchronizing only “new” or “all existing” events was not being handled correctly because the “need_sync” field should change according to the “sync_policy” selected. Following this commit, we correctly removed the 'google_id' from the recurrences when deleting them and now correctly consider the 'sync_policy' of synchronizing only 'new' or 'all existing' events by updating the 'need_sync' status of all existing synchronized events. task-3731683 Forward-Port-Of: odoo/odoo#167299
Problem --- The `sequence` field of product attributes has no default, This causes ordering bugs in the frontend when using handles. Steps --- * go to product attributes list view * move the last element to the top (to ensure a full reordering) * create a new product attribute *PA* > go back to the list view * => it appears at the bottom of the list * => its sequence appears to be 0 to the frontend but is actually NULL * move it one place up * => *PA* and the item after it
Original PR description
Problem --- The `sequence` field of product attributes has no default, This causes ordering bugs in the frontend when using handles. Steps --- * go to product attributes list view * move the last…
Problem --- The `sequence` field of product attributes has no default, This causes ordering bugs in the frontend when using handles. Steps --- * go to product attributes list view * move the last element to the top (to ensure a full reordering) * create a new product attribute *PA* > go back to the list view * => it appears at the bottom of the list * => its sequence appears to be 0 to the frontend but is actually NULL * move it one place up * => *PA* and the item after it now have the sequence numbers 0, 1 * refresh * => the two last items move to the top, crisscrossing with the previous 2 first items which also have sequence 0, 1 Cause --- The frontend always assume click-and-drag sortable lists are already sorted, but this assumption is wrong when we have a record with a NULL `sequence`, because it will appears at the end of the ORDERBY SQL query but be converted to 0 frontend-side. opw-3937263 Forward-Port-Of: odoo/odoo#174582 Forward-Port-Of: odoo/odoo#174397
Before this commit, the "discount amount" was not displayed as a monetary field in the sales report. Additionally, the discount amount calculation was limited to discounts applied within the entire session included in the report period. This meant that partial reports within a single session failed to include any discounts. opw-4061831 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174341
Original PR description
Before this commit, the "discount amount" was not displayed as a monetary field in the sales report. Additionally, the discount amount calculation was limited to discounts applied within the entire session included in the report period. This meant that partial reports within a single session failed to include any discounts. opw-4061831 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174341
Before this commit, search results for chats and channels on mobile show up in uppercase. This happens because of the class `text-uppercase` on a parent element. This commit fixes the issue by removing said class on the parent element. Before:  After:  Forward-Port-Of: odoo/odoo#174268 Forward-Port-Of: odo
Original PR description
Before this commit, search results for chats and channels on mobile show up in uppercase. This happens because of the class `text-uppercase` on a parent element. This commit fixes the issue by removing said class on the parent element. Before:  After:  Forward-Port-Of: odoo/odoo#174268 Forward-Port-Of: odoo/odoo#174224
**Version**: 16 **Description of the issue/feature this PR addresses**: A customer payment with journal of type "Cash" and Incoming payment method "New Third Party Checks" is marked as "Not in Wallet" if prior to confirming the payment it was saved with a different journal and other payment method, such as a journal of type "Bank" and the payment method "Manual". **Video showing how to replicate the bug**: https://drive.google.com/file/d/1hHntOd5sYz-I3sbrBZmUxlh66FYt_eTR/view **Steps
Original PR description
**Version**: 16 **Description of the issue/feature this PR addresses**: A customer payment with journal of type "Cash" and Incoming payment method "New Third Party Checks" is marked as "Not in…
**Version**: 16 **Description of the issue/feature this PR addresses**: A customer payment with journal of type "Cash" and Incoming payment method "New Third Party Checks" is marked as "Not in Wallet" if prior to confirming the payment it was saved with a different journal and other payment method, such as a journal of type "Bank" and the payment method "Manual". **Video showing how to replicate the bug**: https://drive.google.com/file/d/1hHntOd5sYz-I3sbrBZmUxlh66FYt_eTR/view **Steps to reproduce**: 1) Log in with admin on runbot odoo enterprise 16 instance and install l10n_latam_check (Third Party and Deferred/Electronic Checks Management) module. 2) Go to "Accounting / Configuration /Accounting / Journals and create a new journal of type "Cash" and add incoming payment method "New Third Party Checks".  3) Create a new customer payment with journal "Bank" and payment method "Manual" and save.  4) Change journal to the same journal created on step 2, change payment method to "New Third Party Checks" and confirm.  **Current behavior before PR**: A customer payment with journal of type "Cash" and Incoming payment method "New Third Party Checks" is marked as "Not in Wallet" if prior to confirming the payment it was saved with a different journal and other payment method, such as a journal of type "Bank" and the payment method "Manual". **Desired behavior after PR is merged**: A customer payment with journal of type "Cash" and Incoming payment method "New Third Party Checks" is "On hand" if prior to confirming the payment it was saved with a different journal and other payment method, such as a journal of type "Bank" and the payment method "Manual". Ticket Adhoc side: 76561 Task Latam side: 1229 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172652
**Description of the issue/feature this PR addresses:** based on the fact that `PCVIII1` + `PCVIII2` are just independent subcategories which must be also available in `PCVIII3` or `PCVIII4` and therefore are the base for the sum of `PCVIII` which should not have an independent tag in the future anyway **Current behavior before PR:** Incomplete information based on these tags in the current and changed balance sheet **Desired behavior after PR is merged:** Having a proper and complete p
Original PR description
**Description of the issue/feature this PR addresses:** based on the fact that `PCVIII1` + `PCVIII2` are just independent subcategories which must be also available in `PCVIII3` or `PCVIII4` and therefore are the base for the sum of `PCVIII` which should not have an independent tag in the future anyway **Current behavior before PR:** Incomplete information based on these tags in the current and changed balance sheet **Desired behavior after PR is merged:** Having a proper and complete picture of the current accounts available in the balance sheet Enterprise PR: https://github.com/odoo/enterprise/pull/64747 Info: @wt-io-it --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171410
### Steps to reproduce: - Create a storable product P using the manifacturing route - Create a BOM for that product with 2 lines: 1 x storable product COMP 1 using buy route and with a set vendor and a delivery lead time of 1 day 1 x storable product COMP 2 without any route or using the buy route without vendor - In the inventory tab of your storable product P, click on compute the "Days to prepare Manufacturing Order" from BoM ### Current Behavior: Since the second component is not
Original PR description
### Steps to reproduce: - Create a storable product P using the manifacturing route - Create a BOM for that product with 2 lines: 1 x storable product COMP 1 using buy route and with a set vendor and…
### Steps to reproduce: - Create a storable product P using the manifacturing route - Create a BOM for that product with 2 lines: 1 x storable product COMP 1 using buy route and with a set vendor and a delivery lead time of 1 day 1 x storable product COMP 2 without any route or using the buy route without vendor - In the inventory tab of your storable product P, click on compute the "Days to prepare Manufacturing Order" from BoM ### Current Behavior: Since the second component is not available, the final product is not available and the number of days to prepare the MO is set to 0 so that nothing happens: https://github.com/odoo/odoo/blob/2744217900c4eb985bd71919ef86614ab95c0fd0/addons/mrp/report/mrp_report_bom_structure.py#L680-L688 ### Expected behavior: A warning should be raised to notify the user that at least one of the component is not availabe. opw-3933989 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170871 Forward-Port-Of: odoo/odoo#167136
### Steps to reproduce: - Install Contacts app - Go to General Settings and add another language - Add a new contact to a parent. - Don't add a specific contact name - Assign a contact type (delivery address, invoice address, other address) - Go to the list or kanban view of the contacts and change the language - The type of the contact listed next to the parent name is not translated from English. ### Investigation: - When the contact name is not set, the `display_name`
Original PR description
### Steps to reproduce: - Install Contacts app - Go to General Settings and add another language - Add a new contact to a parent. - Don't add a specific contact name - Assign a contact type (delivery…
### Steps to reproduce:
- Install Contacts app
- Go to General Settings and add another language
- Add a new contact to a parent.
- Don't add a specific contact name
- Assign a contact type (delivery address, invoice address, other address)
- Go to the list or kanban view of the contacts and change the language
- The type of the contact listed next to the parent name is not translated from English.
### Investigation:
- When the contact name is not set, the `display_name` displayed in both kanban and list views is set by concatenating the parent name with the contact type.
- The line https://github.com/odoo/odoo/blob/03b7e17faef4075dbbb805bca4e7f40f7fbcc988/odoo/addons/base/models/res_partner.py#L345 in the function `_compute_display_name`, `with_context({})` in particular basically enforce to compute the name in english language regardless of the active language. That actually makes sense as the `display_name` field has `store=True` https://github.com/odoo/odoo/blob/03b7e17faef4075dbbb805bca4e7f40f7fbcc988/odoo/addons/base/models/res_partner.py#L199
### Solution:
- add a computed field that is not stored that gets recomputed on changing the language.
opw-3569171
Forward-Port-Of: odoo/odoo#150859
Forward-Port-Of: odoo/odoo#143514When the stock_move_line and stock_move have the same UoM everything works as expected. However, in the process of setting the done quantity from the move, to the move line, there are 2 places the wrong value is used in the compute, leading to misaligned data. This can, in a worst case, make a move with a quantity as done, and no supporting move lines. And no backorder created. Description of the issue/feature this PR addresses: This was raised in Odoo Ticket https://www.odoo.com/my
Original PR description
When the stock_move_line and stock_move have the same UoM everything works as expected. However, in the process of setting the done quantity from the move, to the move line, there are 2 places the wrong value is used in the compute, leading to misaligned data. This can, in a worst case, make a move with a quantity as done, and no supporting move lines. And no backorder created. Description of the issue/feature this PR addresses: This was raised in Odoo Ticket https://www.odoo.com/my/tasks/4033989 Current behavior before PR: Creates mismatched moves 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#172039
When splitting MO there's a bug which causes more items to be reserved than we have on hand. Steps to reproduce: - Create a product TEST - Create BoM of a product (e.g. COMP1) - Set quantity of COMP1 to X - Create MO of TEST with quantity set to X + 1 (or more) - Split the MO It will cause X + 1 COMP1's to be reserved even though we only have X COMP1's on hand. To fix this we need to create move lines before reserving. Task: 3962125 Forward-Port-Of: odoo/odoo#171241
Original PR description
When splitting MO there's a bug which causes more items to be reserved than we have on hand. Steps to reproduce: - Create a product TEST - Create BoM of a product (e.g. COMP1) - Set quantity of COMP1 to X - Create MO of TEST with quantity set to X + 1 (or more) - Split the MO It will cause X + 1 COMP1's to be reserved even though we only have X COMP1's on hand. To fix this we need to create move lines before reserving. Task: 3962125 Forward-Port-Of: odoo/odoo#171241
[IMP] point_of_sale: load company fiscal_country in the client The `account_fiscal_country_id` is required in the client to trigger l10n_* specific behaviour. task-3801234 [IMP] point_of_sale: add hook in onDoRefund Allows to add extra behaviour when clicking on the "Refund" button (when refunding a previous order). task-3801234 https://github.com/odoo/enterprise/pull/64761 Forward-Port-Of: odoo/odoo#173559 Forward-Port-Of: odoo/odoo#169597
Original PR description
[IMP] point_of_sale: load company fiscal_country in the client The `account_fiscal_country_id` is required in the client to trigger l10n_* specific behaviour. task-3801234 [IMP] point_of_sale: add hook in onDoRefund Allows to add extra behaviour when clicking on the "Refund" button (when refunding a previous order). task-3801234 https://github.com/odoo/enterprise/pull/64761 Forward-Port-Of: odoo/odoo#173559 Forward-Port-Of: odoo/odoo#169597
Current behavior before PR: When switching the checkbox direction from left to right and pressing tab, the checkbox would shift to the left while the text appeared on the right, and vice versa for RTL languages. Desired behavior after PR is merged: Commit [1] added the positioning of checklists in Right-to-Left (RTL) languages. Previously, only the direct child `li` elements of `ul` were styled because of the use of the child combinator selector (>), as the `dir` attribute was o
Original PR description
Current behavior before PR: When switching the checkbox direction from left to right and pressing tab, the checkbox would shift to the left while the text appeared on the right, and vice versa for RTL languages. Desired behavior after PR is merged: Commit [1] added the positioning of checklists in Right-to-Left (RTL) languages. Previously, only the direct child `li` elements of `ul` were styled because of the use of the child combinator selector (>), as the `dir` attribute was only applied to the outermost `ul` element. This commit ensures uniform styling across various languages, including RTL languages. [1]: https://github.com/odoo/odoo/commit/bb9c4b3892353901a2cf33bccf0d6324466fd1fa task-3828737 Forward-Port-Of: odoo/odoo#160909
Before this commit, the self test was failing because the user used to run the test didn't have the right access rights. This commit fixes the access rights for the user used to run the test. Rb error: 71576, 71757, 70420, 71598 Forward-Port-Of: odoo/odoo#173716 Forward-Port-Of: odoo/odoo#173601
Original PR description
Before this commit, the self test was failing because the user used to run the test didn't have the right access rights. This commit fixes the access rights for the user used to run the test. Rb error: 71576, 71757, 70420, 71598 Forward-Port-Of: odoo/odoo#173716 Forward-Port-Of: odoo/odoo#173601
People tend to install every new shiny release of Python but fail to realise that it usually takes a month or two before Odoo is made compatible with that shiny new version. In the meantime there is a surge of issues / tickets with bugs related to the new python version, wasting time of a lot of people (at least mine). Hardcode the officially maximum supported python version and emit a warning when the current python is more recent than that. We'll change the variable the next time we support
Original PR description
People tend to install every new shiny release of Python but fail to realise that it usually takes a month or two before Odoo is made compatible with that shiny new version. In the meantime there is a surge of issues / tickets with bugs related to the new python version, wasting time of a lot of people (at least mine). Hardcode the officially maximum supported python version and emit a warning when the current python is more recent than that. We'll change the variable the next time we support a new python version. Forward-Port-Of: odoo/odoo#174054 Forward-Port-Of: odoo/odoo#168911
### Steps to reproduce: - Install eCommerce and Loyalty module - Create a Discount that is applied using code - Generate coupon codes - Modify the balance of the codes to be more than 1 - Go to website and create an order - Proceed to checkout and apply one of the codes ### Current behavior before PR: The reward will be shown as claimable even after we already applied its code. This will lead that the user can be able to claim it more than once in the same order. This is happenin
Original PR description
### Steps to reproduce: - Install eCommerce and Loyalty module - Create a Discount that is applied using code - Generate coupon codes - Modify the balance of the codes to be more than 1 - Go to website and create an order - Proceed to checkout and apply one of the codes ### Current behavior before PR: The reward will be shown as claimable even after we already applied its code. This will lead that the user can be able to claim it more than once in the same order. This is happening becuase when getting the claimable rewards we are fetching the rewards that already got applied. https://github.com/odoo/odoo/blob/16.0/addons/sale_loyalty/models/sale_order.py#L655 ### Desired behavior after PR is merged: We are excluding the already-applied coupons on the order to avoid using them more than once in the same order. opw-4018909 Forward-Port-Of: odoo/odoo#173555
Because of https://github.com/odoo/odoo/pull/170616 we relaxed the constraint of needing a chained original refund invoice in the case it is imported. But that way, we allowed to post a credit note without the original invoice and that would give problems later in the flow as the XML rendering will give an error. 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
Original PR description
Because of https://github.com/odoo/odoo/pull/170616 we relaxed the constraint of needing a chained original refund invoice in the case it is imported. But that way, we allowed to post a credit note without the original invoice and that would give problems later in the flow as the XML rendering will give an error. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173948
**Current behavior before PR:** Issue detected where the new message separator disappears for Admin after Demo deletes message B which is last seen message. **Desired behavior after PR is merged:** Adjusted logic to correctly position the new message separator between messages A and C after message B is deleted by Demo. Task-3826567 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160456
Original PR description
**Current behavior before PR:** Issue detected where the new message separator disappears for Admin after Demo deletes message B which is last seen message. **Desired behavior after PR is merged:** Adjusted logic to correctly position the new message separator between messages A and C after message B is deleted by Demo. Task-3826567 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160456
Steps to reproduce: -Create a product. -Add an attribute with a long name. -Add a significant number of variants (around 15-20). -Create a SO with this product. Issue: The attribute name is not easily readable. Cause: The use of the w-lg-25 class sets a fixed width. Fix: Use col-lg-3 to ensure the width adjusts according to the grid system. Forward-Port-Of: odoo/odoo#173619
Original PR description
Steps to reproduce: -Create a product. -Add an attribute with a long name. -Add a significant number of variants (around 15-20). -Create a SO with this product. Issue: The attribute name is not easily readable. Cause: The use of the w-lg-25 class sets a fixed width. Fix: Use col-lg-3 to ensure the width adjusts according to the grid system. Forward-Port-Of: odoo/odoo#173619
Some valid URLs were not working before because since [1], we were only supporting 15-16 digits facebook page ID. We also wanted to give feedback to a user if their link did not work for some reason. [1]: https://github.com/odoo/odoo/commit/82c4393fd025f9ab50197c0d68d52f57eb55ded2 task-3995431 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174602 Forward-Port-Of: odoo/odoo#169928
Original PR description
Some valid URLs were not working before because since [1], we were only supporting 15-16 digits facebook page ID. We also wanted to give feedback to a user if their link did not work for some reason. [1]: https://github.com/odoo/odoo/commit/82c4393fd025f9ab50197c0d68d52f57eb55ded2 task-3995431 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174602 Forward-Port-Of: odoo/odoo#169928
63a80c14f62e2a96e0a5dc9b33d1cf8c9e7a4b9a added support for safe_eval in python 3.12. However this added RETURN_CONST in _SAFE_OPCODES instead of _CONST_OPCODES. This stopped const_eval from returning const values. closes #174045 Task-4067772 Forward-Port-Of: odoo/odoo#174707 Forward-Port-Of: odoo/odoo#174510
Original PR description
63a80c14f62e2a96e0a5dc9b33d1cf8c9e7a4b9a added support for safe_eval in python 3.12. However this added RETURN_CONST in _SAFE_OPCODES instead of _CONST_OPCODES. This stopped const_eval from returning const values. closes #174045 Task-4067772 Forward-Port-Of: odoo/odoo#174707 Forward-Port-Of: odoo/odoo#174510
The account_chart_template `_load` override was removed here, odoo/odoo#114164 (The update code has become a part of the template). It was reintroduced by mistake in this fw-port with rebase fast-forward: odoo/odoo#134348 Since it's dead code not even imported in the `__init__.py` file [(link)](https://github.com/odoo/odoo/blob/0ac43fa3cffce83e88accda435f3315600af558a/addons/l10n_it/models/__init__.py#L2) , it's totally safe to be removed. Forward-Port-Of: odoo/odoo#174153
Original PR description
The account_chart_template `_load` override was removed here, odoo/odoo#114164 (The update code has become a part of the template). It was reintroduced by mistake in this fw-port with rebase fast-forward: odoo/odoo#134348 Since it's dead code not even imported in the `__init__.py` file [(link)](https://github.com/odoo/odoo/blob/0ac43fa3cffce83e88accda435f3315600af558a/addons/l10n_it/models/__init__.py#L2) , it's totally safe to be removed. Forward-Port-Of: odoo/odoo#174153
When the user adds a Kenyan phone number, it is not correctly parsed by the phonenumbers library, resulting in a user error while sending a WhatsApp message to that number. Steps to produce: - Add a Kenyan phone number (e.g., '+254114627044'). - Try to send WhatsApp messages using this phone number. - This will throw an Invalid number error. Problem: when `phonenumbers` python library is used in odoo for parsing phone numbers, versions below `8.13.31` have problem with parsing some Ken
Original PR description
When the user adds a Kenyan phone number, it is not correctly parsed by the phonenumbers library, resulting in a user error while sending a WhatsApp message to that number. Steps to produce: - Add a Kenyan phone number (e.g., '+254114627044'). - Try to send WhatsApp messages using this phone number. - This will throw an Invalid number error. Problem: when `phonenumbers` python library is used in odoo for parsing phone numbers, versions below `8.13.31` have problem with parsing some Kenyian numbers because they aren't updated, therefore they can't identify prefix and throw an error. task-3994165 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174666 Forward-Port-Of: odoo/odoo#174568
### Steps to reproduce the issue: 1. Create a Sales Order 2. Create an Invoice with a Down Payment 3. Go to Sales>Reporting>Sales in Pivot View 4. Activate "Untaxed Amount To Invoice" or "Untaxed Amount Invoiced" in the Measures 5. Look for the Sales Order 6. The Down Payment is not calculated ### Explanation: In commit odoo/odoo@9aa52dd6418e5881adc2d96d15d062b55d6150c5, the Down Payment product was removed and Down Payment lines no longer have a `product_id`. In `sale.report`, mos
Original PR description
### Steps to reproduce the issue: 1. Create a Sales Order 2. Create an Invoice with a Down Payment 3. Go to Sales>Reporting>Sales in Pivot View 4. Activate "Untaxed Amount To Invoice" or "Untaxed Amount Invoiced" in the Measures 5. Look for the Sales Order 6. The Down Payment is not calculated ### Explanation: In commit odoo/odoo@9aa52dd6418e5881adc2d96d15d062b55d6150c5, the Down Payment product was removed and Down Payment lines no longer have a `product_id`. In `sale.report`, most values are only calculated if this field, `product_id`, has a value. This includes `untaxed_amount_to_invoice` and `untaxed_amount_invoiced`. ### Fix reasoning: `is_downpayment` field filters Down Payment lines, it can be used to add them in the calculation of selected columns in the report. opw-4033003 Forward-Port-Of: odoo/odoo#174486
26 changes
Enhancements to existing features
Restaurant table references now use a numeric table number instead of a free-text name across appointment, preparation display, and self-order preparation flows. This makes table identification more consistent for staff and customer-facing order preparation screens.
Original PR description
pos*: pos_restaurant_appointment, pos_restaurant_preparation_display, pos_self_order_preparation_display In this commit, we adapt the data model of the restaurant table. Its name becomes a table number: the field is changed from 'name::string' to 'table_number::integer'. Community PR: odoo/odoo#173108
Gantt views now handle end dates more consistently by avoiding rounding to the last second of the day. This improves scheduling accuracy in planning, field service, projects, and other Gantt-based workflows.
Original PR description
*web_gantt, planning, industry_fsm
Before this commit:
- The default value of the end time in Gantt view was 23:59:59.
After this commit:
- The end time in the Gantt view will now default to 00:00:00 with one day/hr
ahead.
- Introduced a new parameter `roundUpStop` in the `getColumnStartStop` function.
- When this parameter is set to true, the default time for the end date
will increment by 1ms.
- When set to false, the end time remain as it is.
Task-3871980The expense onboarding flow now lets users either try a sample receipt or upload their own receipt. This makes the setup experience more realistic, while ensuring uploads are only available when the customer has data extraction credits.
Original PR description
Before this commit, the expense onboarding wizard offered the user 4 sample receipts to choose from. Now, the user can choose either a sample receipt, or to upload their own receipt. However, in order to upload their own receipt, they need to have credit for data extraction. A depiction of the updated user journey could be found here: https://link.excalidraw.com/l/65VNwvy7c4X/3RaHoyA4PFQ task-3901510
Users can now open the full project or task form from Gantt and Calendar views using the expand button. This makes collaboration details such as the chatter accessible without leaving the planning workflow.
Original PR description
Currently, when user open a task or project in the calendar or Gantt view, they cannot access the chatter. With this commit, they can now access the form view through the expanded button. Task: 3837229
Indian payroll now supports sandwich leave calculations, where intervening weekends or public holidays can be counted when leave is taken on both sides. This helps businesses apply local leave policies more consistently and deduct the correct number of leave days from employee balances.
Original PR description
This commit, adds the Sandwich Leave Rule in Indian Localization. The sandwich leave rule will be applied if an Employee takes leave like in the scenario below. Scene 1: Friday (leave) -> Saturday -> Sunday -> Monday(Leave) 4 Leaves will be deducted from the Employee's leave balance. Scene 2: Tuesday(Leave) -> Wednesday(Public Holiday) -> Thursday (Leave) 3 Leaves will be deducted from the Employee's leave balance. task-3950973
The event form now places the social menu setting in a dedicated Sub-menu tab. This makes the event setup screen easier to navigate and helps users find related website menu options more quickly.
Original PR description
**Specifications:** Modify event form and move 'social_menu' field to 'Sub-menu' tab. **After this commit:** 'social_menu' field will be moved in the newly created 'Sub-menu' tab. Please refer the related community PR for better understanding. Task-4010675
Event website sub-pages can now keep their own SEO titles and descriptions instead of unintentionally sharing the same values. This helps event organizers tailor search visibility and social previews for pages like talks and exhibitors independently.
Original PR description
**How to reproduce:** - Create an event and activate the submenu - Open Talk Proposal page and set specific SEO discription and title - Open Exhibitors page and set another one **Specifications:** - They are currently synced. - All the sub-pages except 'Introduction' and 'Location' page are synced. - SEO data of all the pages should be different from one another. **After this PR:** SEO data for all sub-pages will be different. Task-3874050
Global invoices for Mexican POS sales now use the POS reference, making the related ticket numbers visible on the invoice. This helps businesses provide clearer records during government tax audits and makes it easier to match invoices with sold tickets.
Original PR description
When there is a tax audit from the government, its common to check global invoices as they declare which tickets were sold during a certain period. This is not possible because the global invoice does not contain ticket numbers, it contains references which are only visible from Odoo and can be an issue for checking. [Ticket](https://www.odoo.com/odoo/project/4216/tasks/4061845?cids=17)
Resolved issues and error corrections
Removing HMRC authentication credentials now affects the user selected by the administrator, not the currently logged-in user. This prevents accidental removal of another user's UK tax reporting credentials and makes multi-user credential management more reliable.
Original PR description
This commit fixes the following issue and also improves the way the code is handling write/clean hrmc tokens on user. In the write/clear functions, `user` argument is now mandatory so that we can do…
This commit fixes the following issue and also improves the way the code is handling write/clean hrmc tokens on user. In the write/clear functions, `user` argument is now mandatory so that we can do the operation on the selected user rather than the environment user. Issue: Step to reproduce: - install`l10n_uk_reports` - create 2 user or more - for each user, fill their hmrc token values - select a user different from the current environment user - remove their credential with the button "Remove Authentication Credentials" Current behavior: - The selected user's credential is not removed, but the environment user one got removed Expected behavior: - the selected user's credential should be the one that is removed, and the environment user should not be removed. Why it happens: - In `_clean_tokens` function, it clears the credential of the environment user by default. Solution: - change the signature of _clean_tokens function to have `user` required argument and clean that user's token instead of `env.user` opw-4041604
Australian payroll users now have a dedicated menu item to access termination payments. This restores easier access after a previous workflow change and keeps payroll forms less cluttered.
Original PR description
Termination flow was removed in a previous commit. https://github.com/odoo/enterprise/commit/9d21446069dfc794fcf7b0f7bb4ced90202cbd05 This commit adds a menu item for the Termination Payments to avoid too many actions on the form view.
Code cleanup and technical improvements
This change reorganizes how extra record details are prepared for Approvals, VoIP, and WhatsApp features. It reduces repeated technical handling behind the scenes, making future maintenance easier without changing the user experience.
Original PR description
\* = approvals, voip, whatsapp This allows to easily set extra values on records without having to repeat the model name or the id in many different places. Part of task-3605717 https://github.com/odoo/odoo/pull/174507
Miscellaneous changes
It turns out we've been sending the wrong value in the state field [1]. This hasn't caused issues for the majority of states, but some states reject invoices if they don't have the right code (e.g. Minas Gerais). opw-4076445 [1] The specification mentions state *code*: https://avataxbr-docs.avalarabrasil.com.br/#/Invoice%20Goods/sendInvoiceGoods Forward-Port-Of: odoo/enterprise#67476
Original PR description
It turns out we've been sending the wrong value in the state field [1]. This hasn't caused issues for the majority of states, but some states reject invoices if they don't have the right code (e.g. Minas Gerais). opw-4076445 [1] The specification mentions state *code*: https://avataxbr-docs.avalarabrasil.com.br/#/Invoice%20Goods/sendInvoiceGoods Forward-Port-Of: odoo/enterprise#67476
Steps to Reproduce: ----------- - Install sale planning. - Create a sale order with a plan product. - Navigate to the Planning app > Schedule > By Resource. - Click on a cell in the "Open Shifts" line. - Select a resource. - Save and close. - Check the shift resource. Issue: ---------- The shift is not being created in the open shift section based on the parameters selected by the user. Fix: ---------- When creating a shift from the open shift section, it
Original PR description
Steps to Reproduce: ----------- - Install sale planning. - Create a sale order with a plan product. - Navigate to the Planning app > Schedule > By Resource. - Click on a cell in the "Open Shifts" line. - Select a resource. - Save and close. - Check the shift resource. Issue: ---------- The shift is not being created in the open shift section based on the parameters selected by the user. Fix: ---------- When creating a shift from the open shift section, it should generate shifts according to the parameters selected by the user, such as resource, date, etc. task-3919549 Forward-Port-Of: odoo/enterprise#67248 Forward-Port-Of: odoo/enterprise#64203
Currently, if a user uses a sale order sequence that contains special characters like `/` (e.g. SO/2024/12/31/01), they do not see such a sale order in suggestions in bank reconciliation if the label doesn't match the name of the sale order exactly. That is, a label `SO/2024/12/31/01 test` would not much this sale order, but a label `SO2024123101 test` would much a sale order with a name `SO2024123101`. This is because we format tokens and filter out special characters and then compare them t
Original PR description
Currently, if a user uses a sale order sequence that contains special characters like `/` (e.g. SO/2024/12/31/01), they do not see such a sale order in suggestions in bank reconciliation if the label doesn't match the name of the sale order exactly. That is, a label `SO/2024/12/31/01 test` would not much this sale order, but a label `SO2024123101 test` would much a sale order with a name `SO2024123101`. This is because we format tokens and filter out special characters and then compare them to names. With this commit, we'll compare names and tokens that are formatted the same way. opw-3964898 Forward-Port-Of: odoo/enterprise#67471 Forward-Port-Of: odoo/enterprise#67176
We should not raise during the Send & Print. Otherwise, when sending a batch of invoices and one of them is raising errors, none will be sent. no task Forward-Port-Of: odoo/enterprise#66326
Original PR description
We should not raise during the Send & Print. Otherwise, when sending a batch of invoices and one of them is raising errors, none will be sent. no task Forward-Port-Of: odoo/enterprise#66326
Speed up the shop floor by drastically reducing the number of refresh calls. We try to avoid a refresh of data from the server as much as possible. If an update is still unavoidable, we try to only refresh the relevant MO. task-4048415 Forward-Port-Of: odoo/enterprise#66898
Original PR description
Speed up the shop floor by drastically reducing the number of refresh calls. We try to avoid a refresh of data from the server as much as possible. If an update is still unavoidable, we try to only refresh the relevant MO. task-4048415 Forward-Port-Of: odoo/enterprise#66898
In Peru, we don't prevent invoices with the same name from being created. Invoices with the same name, same document type and same company RUC will be reported to SUNAT with the same `edi_filename`. SUNAT rejects those invoices as duplicates, which is good. However, our fallback mechanism of retrieving the existing CDR for those invoices and marking the invoice as sent is not good in this situation. Indeed, the user should be notified that the invoice was rejected, prompting them to resequenc
Original PR description
In Peru, we don't prevent invoices with the same name from being created. Invoices with the same name, same document type and same company RUC will be reported to SUNAT with the same `edi_filename`. SUNAT rejects those invoices as duplicates, which is good. However, our fallback mechanism of retrieving the existing CDR for those invoices and marking the invoice as sent is not good in this situation. Indeed, the user should be notified that the invoice was rejected, prompting them to resequence their invoice. Instead, they get the impression that their invoice was correctly sent to SUNAT. To fix this, we don't try to retrieve an existing CDR if an invoice was rejected as duplicate, but there already exists an invoice with the same edi_filename that was sent to SUNAT. opw-3900393 Forward-Port-Of: odoo/enterprise#67161 Forward-Port-Of: odoo/enterprise#65520
Steps to reproduce: - Open the Profit & Loss report - Create a budget using the budget filter - Audit a cell of the report Issue: A traceback occurs, indicating a string or bytes-like object error. Cause: In the previous commit https://github.com/odoo/enterprise/commit/8f19af2335d4199a306d9db489cbac1db656a0cb, the markup of line IDs was modified to include dictionaries for groupby information. However, one 'groupby' was overlooked, causing a traceback due to the system expecting a
Original PR description
Steps to reproduce: - Open the Profit & Loss report - Create a budget using the budget filter - Audit a cell of the report Issue: A traceback occurs, indicating a string or bytes-like object error. Cause: In the previous commit https://github.com/odoo/enterprise/commit/8f19af2335d4199a306d9db489cbac1db656a0cb, the markup of line IDs was modified to include dictionaries for groupby information. However, one 'groupby' was overlooked, causing a traceback due to the system expecting a string instead of a dictionary. Fix: This commit corrects the missing 'groupby' case to handle dictionaries properly,preventing the traceback. Additional Changes: Updated a related comment to reflect the new markup handling for consistency. task-3791247 Forward-Port-Of: odoo/enterprise#67337
With this PR : ========================== - Previously, when producing the entire quantity of a product, new component lines were created, ignoring reserved components. - This change uses the reserved components instead of creating new ones. Task-id : 4012314 Forward-Port-Of: odoo/enterprise#65559
Original PR description
With this PR : ========================== - Previously, when producing the entire quantity of a product, new component lines were created, ignoring reserved components. - This change uses the reserved components instead of creating new ones. Task-id : 4012314 Forward-Port-Of: odoo/enterprise#65559
Before this fix, one couldn't move documents to the parents workspaces. This was due to a check on the 'active' class of the target's child elements and not only on his direct descendant. This commit fix this by adding ':scope > ' to the selector. Task-3999790 Forward-Port-Of: odoo/enterprise#65000
Original PR description
Before this fix, one couldn't move documents to the parents workspaces. This was due to a check on the 'active' class of the target's child elements and not only on his direct descendant. This commit fix this by adding ':scope > ' to the selector. Task-3999790 Forward-Port-Of: odoo/enterprise#65000
- Added missing pot/po files/translations for l10_cl_edi_pos - Converted website_sale file from es_CL => es_419 so the translations will show for other LATAM countries/langs - Added missing pot file + added missing terms/translations to website_sale module opw-4044338 Forward-Port-Of: odoo/enterprise#67429
Original PR description
- Added missing pot/po files/translations for l10_cl_edi_pos - Converted website_sale file from es_CL => es_419 so the translations will show for other LATAM countries/langs - Added missing pot file + added missing terms/translations to website_sale module opw-4044338 Forward-Port-Of: odoo/enterprise#67429
### Steps to reproduce: - Install hr_holidays_contract_gantt module - Create two employees one with a contract and another without - Create a time off for each employee - Check Time Off -> Overview ### Current behavior before PR: The employee who has a contract will have grey cells on weekend days that are coming after his contract start date but the ones before will be white. The employee who has no contract won't have any grey cells neither for his off days nor the weekend days.
Original PR description
### Steps to reproduce: - Install hr_holidays_contract_gantt module - Create two employees one with a contract and another without - Create a time off for each employee - Check Time Off -> Overview ### Current behavior before PR: The employee who has a contract will have grey cells on weekend days that are coming after his contract start date but the ones before will be white. The employee who has no contract won't have any grey cells neither for his off days nor the weekend days. ### Desired behavior after PR is merged: Both employees should show the grey cells in the gantt view whether they have contract or not because if so we fallback on the employee working hours and then company's working hours 'According to the PO' opw-3961873 Forward-Port-Of: odoo/enterprise#67432 Forward-Port-Of: odoo/enterprise#65470
When the customer tries to create an asset for multiple journal items from different companies, a traceback will appear. Steps to reproduce the error: - Create an invoice with Company A - Create an invoice with Company B - Go to Accounting > Journal Items > select both invoice > Create Asset Traceback: ``` ValueError: Expected singleton: res.company(1, 5) File "odoo/http.py", line 2248, in __call__ response = request._serve_db() File "odoo/http.py", line 1823, in _serve_db
Original PR description
When the customer tries to create an asset for multiple journal items from different companies, a traceback will appear. Steps to reproduce the error: - Create an invoice with Company A - Create an…
When the customer tries to create an asset for multiple journal items from
different companies, a traceback will appear.
Steps to reproduce the error:
- Create an invoice with Company A
- Create an invoice with Company B
- Go to Accounting > Journal Items > select both invoice > Create Asset
Traceback:
```
ValueError: Expected singleton: res.company(1, 5)
File "odoo/http.py", line 2248, in __call__
response = request._serve_db()
File "odoo/http.py", line 1823, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1843, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1821, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1828, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2053, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 220, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 756, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 42, in call_button
action = self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 34, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 458, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "home/odoo/src/enterprise/saas-17.2/account_asset/models/account_move.py", line 315, in turn_as_asset
'default_company_id': self.company_id.id,
File "odoo/fields.py", line 5183, in __get__
raise ValueError("Expected singleton: %s" % record)
```
https://github.com/odoo/enterprise/blob/9373f9bac47839e3314a7823e05d4ef61af0b3e3/account_asset/models/account_move.py#L345 Here, When the user creates an asset for multiple journal items from
different companies, Self has multiple 'company_id'.
So it will lead to the above traceback.
sentry-5613448397
Forward-Port-Of: odoo/enterprise#67417
Forward-Port-Of: odoo/enterprise#66806Problem --------- Currently, if you install l10n_xx and update some specific account codes (depending on the localization) and then try to install the corresponding l10n_xx_hr_payroll_account hr module, you are struck with an error that cancels the installation as some accounts are missing. 1. Install l10n_ae for example 2. Switch to AE company 3. Update the account with code 201002 to 701002 4. Install l10n_ae_hr_payroll_account -> Error occurs during the installation Objective ----
Original PR description
Problem --------- Currently, if you install l10n_xx and update some specific account codes (depending on the localization) and then try to install the corresponding l10n_xx_hr_payroll_account hr module, you are struck with an error that cancels the installation as some accounts are missing. 1. Install l10n_ae for example 2. Switch to AE company 3. Update the account with code 201002 to 701002 4. Install l10n_ae_hr_payroll_account -> Error occurs during the installation Objective --------- Be able to install the module even when the account is missing. Solution --------- Log a warning instead of raising an error. opw-3961798 Forward-Port-Of: odoo/enterprise#67345 Forward-Port-Of: odoo/enterprise#67241
Issue: =============== When a manufacturing order (MO) is created, the default components are automatically reserved and are made visible in the barcode module. However, even if these components are later unreserved, they will continue to be displayed in the barcode module. Resolution: ================ To address this issue, we've taken the step to avoid forcefully re-reserving the components when a component is unreserved. This resolves the persistent display of components in t
Original PR description
Issue: =============== When a manufacturing order (MO) is created, the default components are automatically reserved and are made visible in the barcode module. However, even if these components are…
Issue: =============== When a manufacturing order (MO) is created, the default components are automatically reserved and are made visible in the barcode module. However, even if these components are later unreserved, they will continue to be displayed in the barcode module. Resolution: ================ To address this issue, we've taken the step to avoid forcefully re-reserving the components when a component is unreserved. This resolves the persistent display of components in the barcode. Steps to Reproduce: ====================== 1. Create a manufacturing order (MO) and confirm it. 2. Navigate to the barcode module within the manufacturing order. 3. By default, the components are reserved, so they are visible in the barcode module. 4. Go to the form view of the MO in MRP and unreserve the components. 5. Check the barcode module again, and notice that the unreserved components are still visible. Expected Result: ================== After implementing the solution, When we opens the MO in the barcode module only reserved components should be visible. When a component is unreserved, it should no longer be visible in the barcode module for manufacturing order. task-3869731 Forward-Port-Of: odoo/enterprise#66679 Forward-Port-Of: odoo/enterprise#61827
Refs. commits message for steps to reproduce COMMIT 1: ---------------- Issue: ------ One attachment has been removed (not linked anymore to the move). Cause: ------ When switching the main attachment, the versioning is triggered; the new main attachment is set on the document and the previous is added to the history for versioning (and therefore also change the res fields to be linked to the document instead of the move). Solution: --------- When updating the attachm
Original PR description
Refs. commits message for steps to reproduce COMMIT 1: ---------------- Issue: ------ One attachment has been removed (not linked anymore to the move). Cause: ------ When switching the main…
Refs. commits message for steps to reproduce COMMIT 1: ---------------- Issue: ------ One attachment has been removed (not linked anymore to the move). Cause: ------ When switching the main attachment, the versioning is triggered; the new main attachment is set on the document and the previous is added to the history for versioning (and therefore also change the res fields to be linked to the document instead of the move). Solution: --------- When updating the attachment of a document that already have an attachment (normal versioning), we should remove the link between the current document attachment (not the new one) and the related model only if the related model has not a `message_main_attachment_id` field or if the current document attachment is different of the main attachment set on the related model. COMMIT 2: ---------------- Issue: ------ A second document is created. Cause: ------ The issue is when switching the second time the invoice main attachment, the current main attachment is in fact in the versioned attachments (`document.preview_attachment_ids`), and since we search only for document that have as attachment (`document.attachment_id`) the current invoice main attachment, we don't find it and create a new document. Solution: --------- Look also in the versioned attachments when searching for the invoice main attachment in case it has been versioned. opw-4028789 Forward-Port-Of: odoo/enterprise#67464 Forward-Port-Of: odoo/enterprise#66501
9 changes
Enhancements to existing features
This update improves the error messages shown to users in Argentina when the electronic billing service (AFIP) is temporarily unavailable. Instead of asking users to contact their Odoo provider for a service issue they cannot fix, the system now provides clear guidance to wait and retry, making the user experience more helpful and accurate.
Original PR description
Steps to reproduce: 1) Go to runbot Odoo 16 enterprise and install "l10n_ar_edi" module (Argentinean Electronic Invoicing). 2) Take position on Argentinian company (AR) (Responsable Inscripto) . 3)…
Steps to reproduce: 1) Go to runbot Odoo 16 enterprise and install "l10n_ar_edi" module (Argentinean Electronic Invoicing). 2) Take position on Argentinian company (AR) (Responsable Inscripto) . 3) Create customer electronic invoice and confirm. If there is a response with 503 error (HTTPError: 503 Server Error. Service Unavailable) while connecting to the webservice then it will be raised the error message and this text "Please report this error to your Odoo provider" (but this text is not suitable because the odoo provider can`t solve the error. The webservice is not available). Current behavior: If there is a response with 503 error (HTTPError: 503 Server Error. Service Unavailable) while connecting to the webservice when the user is trying to confirm an electronic customer invoice then it will be raised the error message and this text "Please report this error to your Odoo provider". Expected behavior: If there is a response with 503 error (HTTPError: 503 Server Error. Service Unavailable) while connecting to the webservice when the user is trying to confirm an electronic customer invoice then it will be raised the error message and this text 'The AFIP electronic billing webservice is not available. Wait a few minutes for it to reset and try to validate the action again.'. Task Adhoc: 37771 Forward-Port-Of: odoo/enterprise#59983
This update adds customer contact information to the receipt header for Chilean Point of Sale invoices (facturas). This change ensures compliance with Chilean tax and legal requirements for invoice documentation. Customers will now see complete contact details on their receipts.
Original PR description
In this commit, we had the partner information to the receipt header of the CL PoS when the order is a factura. This is needed in order to be compliant with the CL law. task-id: 3747828
This release includes several improvements and fixes across multiple Odoo Enterprise modules. Key updates include performance optimizations in the report editor, enhancements to salary attachment views, improvements to gantt view loading, fixes for sign document resizing, and new document layout options. These changes improve system performance, user experience, and functionality across accounting, HR, project management, and document signing features.
Resolved issues and error corrections
Fixed an issue where VAT Record Books exported from Spanish tax reports were displaying numbers as text instead of actual numbers. This fix allows users to perform calculations and operations directly on the exported spreadsheets, improving usability and reducing manual data conversion work.
Original PR description
With an ES Company Open Tax Report Select Report > Generic Tax Report Export "VAT Record Books" Issue: Numbers are exported as string, while the system should export as number, to let users execute operations on the resulting workbook opw-4029478
Users can now successfully move documents to parent workspaces. Previously, a technical issue prevented this action from working correctly. This fix resolves the underlying problem so users have full flexibility in organizing their documents across workspace hierarchies.
Original PR description
Before this fix, one couldn't move documents to the parents workspaces. This was due to a check on the 'active' class of the target's child elements and not only on his direct descendant. This commit fix this by adding ':scope > ' to the selector. Task-3999790 Forward-Port-Of: odoo/enterprise#65000
This fix resolves a problem where users couldn't navigate away from locked or read-only articles. When switching between articles, the system was attempting to rename read-only articles, which failed and prevented users from leaving. The fix prevents these unnecessary rename attempts for articles users don't have permission to edit.
Original PR description
This commit fixes an issue with locked/readonly empty articles. If a user opens an article which is locked/readonly for them, when switching articles the browser will try to update the article's name. This operation is of course not possible, but this leads to the user not able to leave said article. This is caused by the update method on the record which sets it as dirty so that it can be saved when possible. In order to fix, this when the user has no write access on the article or if it is locked, we return early so that the record doesn't set itself as dirty. task-4047722
Fixed a bug in the Follow-up Reports feature where the Save button would not work after changing the "Exclude from Follow-up" field. The field was automatically saving changes, leaving nothing for the Save button to process. This fix disables auto-save for this field, restoring normal save functionality and matching the behavior in other Odoo versions.
Original PR description
This bug is only present in v17.0.
### Steps to reproduce:
- Go in Accounting > Customers > Follow-up Reports
- Click on a customer
- Changing the "Exclude from Follow-up" field of a line
- The save button does not work anymore
### Cause:
The field "Exclude from Follow-up" is in autosave by default. So it is saved every time it is changed. When clicking on the save button there is nothing to save so nothing happens and the button stays there.
### Solution:
Add `options={'autosave': False}` in the field to prevent it from saving. This will create the same behavior as in all other versions.
This bug does not appear in 17.1 because a new condition called canSaveOnUpdate is added: https://github.com/odoo/odoo/blob/2db71d627fd2c9fc97d573df7993a953753bb8bd/addons/web/static/src/model/relational_model/record.js#L256
opw-4055350The GST Return Period filter has been updated to display both the current and previous month or quarter by default, instead of only showing the previous period. This change makes it easier for users to access and work with the most relevant GST return periods without having to manually adjust filters.
Original PR description
Before this **PR**: The default filter for the GST Return Period shows the previous month or quarter. After this **PR**: The default filter for the GST Return Period shows the current as well as the previous month or quarter. **task**-4014267
This fix corrects how state information is submitted in Brazilian electronic invoices. Previously, the system was sending state names instead of state codes, which caused some states like Minas Gerais to reject invoices. Now the correct state codes are sent according to the official specification, ensuring invoices are accepted by all Brazilian states.
Original PR description
It turns out we've been sending the wrong value in the state field [1]. This hasn't caused issues for the majority of states, but some states reject invoices if they don't have the right code (e.g. Minas Gerais). opw-4076445 [1] The specification mentions state *code*: https://avataxbr-docs.avalarabrasil.com.br/#/Invoice%20Goods/sendInvoiceGoods