Monday, July 29, 2024
40 changes · saas-17.1
Resolved issues and error corrections
This fix updates a Point of Sale test so it uses a more unique ZIP code when identifying a customer record. It prevents test failures caused by matching the wrong customer, helping keep automated quality checks reliable.
Original PR description
The test was failing because it tried to check the ZIP code of the partner. That was because the ZIP in the test was 99999, and another partner has a tax ID that contains 99999. The test was checking the first partner displayed on the list, and it was not the one with the ZIP but the one with the tax ID. This commit makes the ZIP code of the partner more long and unique to avoid this kind of issue. Runbot error: 72516, 72515, 72513
Miscellaneous changes
v2.3.0 of Owl added the .translate modifier to props, allowing them to be translated. This commit updates the script that generates the .pot files (the list of source terms to translate) in order to take into account props with the .translate modifier. *: website Task-3980675 Forward-Port-Of: odoo/odoo#174726 Forward-Port-Of: odoo/odoo#174697
Original PR description
v2.3.0 of Owl added the .translate modifier to props, allowing them to be translated. This commit updates the script that generates the .pot files (the list of source terms to translate) in order to take into account props with the .translate modifier. *: website Task-3980675 Forward-Port-Of: odoo/odoo#174726 Forward-Port-Of: odoo/odoo#174697
task-no Forward-Port-Of: odoo/odoo#174789 Forward-Port-Of: odoo/odoo#174617
Original PR description
task-no Forward-Port-Of: odoo/odoo#174789 Forward-Port-Of: odoo/odoo#174617
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
Issue ----- Events displayed on website are not correctly indexed by Google. This results in events not being displayed in the "Rich Results" format and simply as links in Google searches. Cause ----- The start date is a required field for proper indexation and is missing from the registration page of the event. Fix ----- Add information in Microdata format. opw-3993758 Forward-Port-Of: odoo/odoo#174232 Forward-Port-Of: odoo/odoo#172104
Original PR description
Issue ----- Events displayed on website are not correctly indexed by Google. This results in events not being displayed in the "Rich Results" format and simply as links in Google searches. Cause ----- The start date is a required field for proper indexation and is missing from the registration page of the event. Fix ----- Add information in Microdata format. opw-3993758 Forward-Port-Of: odoo/odoo#174232 Forward-Port-Of: odoo/odoo#172104
Current behavior: When a combo product is on the order and the user change the fiscal position, the prices of the lines of the combo change to get there original prices rather than the price of the combo Steps to reproduce: - Install "Point of Sale" app - Enable "Flexible Taxes" in the shop settings and allow 2 fiscal positions - Start a session, select one of the fp click on a combo product - Change the fp, the prices of the orderlines are now the prices of the products themselves and n
Original PR description
Current behavior: When a combo product is on the order and the user change the fiscal position, the prices of the lines of the combo change to get there original prices rather than the price of the combo Steps to reproduce: - Install "Point of Sale" app - Enable "Flexible Taxes" in the shop settings and allow 2 fiscal positions - Start a session, select one of the fp click on a combo product - Change the fp, the prices of the orderlines are now the prices of the products themselves and not the prices of the combo Cause: After changing the fp, the quantity of al the orderlines are reset Solution: After changing the fp, call the function which update the pricelist which update all the prices correctly opw-4027186 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173770
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
version - 16.0 Steps: -Install rental app. -Activate the date picker from the web-editor. -Add the start date and end date from that. -Select some attribute of the product. Issue: -When any user adds the start date and end date from the date picker and after that, the user adds the other attribute(filter) of the product, that s> Cause: -The selected rental period (start and end dates) is not persisted when the page refreshes or updates due to attribute selection. Fix: Get
Original PR description
version - 16.0 Steps: -Install rental app. -Activate the date picker from the web-editor. -Add the start date and end date from that. -Select some attribute of the product. Issue: -When any user adds the start date and end date from the date picker and after that, the user adds the other attribute(filter) of the product, that s> Cause: -The selected rental period (start and end dates) is not persisted when the page refreshes or updates due to attribute selection. Fix: Get the value of 'start_date' and 'end_date'. Update the hidden input fields for 'start_date' and 'end_date' with the values before applying the attribute changes. opw-3774060 Forward-Port-Of: odoo/odoo#174610 Forward-Port-Of: odoo/odoo#165068
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
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
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
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
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
### 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
**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
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
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
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
Currently when importing an order from sale to pos, if the price was set manually, changing the partner associated with the order will set back the price to the original product sale price. Steps to reproduce: ------------------- * Make a new quotation in **sales** * Change the unit price of a product * Confirm quotation * Open the pos shop session * Import the newly created quotation to be settled * Change the partner > Observation: The price set manually changes to the product sale
Original PR description
Currently when importing an order from sale to pos, if the price was set manually, changing the partner associated with the order will set back the price to the original product sale price. Steps to…
Currently when importing an order from sale to pos, if the price was set manually, changing the partner associated with the order will set back the price to the original product sale price. Steps to reproduce: ------------------- * Make a new quotation in **sales** * Change the unit price of a product * Confirm quotation * Open the pos shop session * Import the newly created quotation to be settled * Change the partner > Observation: The price set manually changes to the product sale price Why the fix: ------------ When changing the partner of a sale order we compute all the line that have to recompute their prices: https://github.com/odoo/odoo/blob/57f1b0bd502938a6d50244896e71df73705584b5/addons/point_of_sale/static/src/js/models.js#L2918-L2920 We see that when we settle an order, `price_manually_set` is set to false. In this example, if we set it to true it would solve the issue but we cannot use it, see with https://github.com/odoo/odoo/commit/70668ee3c3e2c1dd213903b44f4d36cc8ac9fa29 . Instead what we can do is to use `price_automatically_set` and set it to true. This does not undo the previously mentionned commit and fixes this current issue. This variable was created in https://github.com/odoo/odoo/commit/067299539116b55a449f022706c395dda2177829 opw-4001497 Forward-Port-Of: odoo/odoo#174580 Forward-Port-Of: odoo/odoo#172205
In this commit https://github.com/odoo/odoo/pull/157503/commits/98368c363bf4cb9604948a52196c6a61985dc34d we added the bank account (if present) next to the communication printed on the invoice. This commit apply the same logic to the "send and print" template task: 4048178 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172775
Original PR description
In this commit https://github.com/odoo/odoo/pull/157503/commits/98368c363bf4cb9604948a52196c6a61985dc34d we added the bank account (if present) next to the communication printed on the invoice. This commit apply the same logic to the "send and print" template task: 4048178 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172775
#### Commit 1 [FIX] sms, tools: prevent adding link references in sms This fix prevents the conversion of urls into reference footnotes in sent sms (adding characters and imparing readability) when coming from raw text (in opposition to html source). #### Commit 2 [FIX] mass_mailing_sms: fix characters count with (opt-out) links Also impacted: sms When adding opt-out link or any link in the text, the characters count was incorrect which made SMS campaigns more expensive than e
Original PR description
#### Commit 1 [FIX] sms, tools: prevent adding link references in sms This fix prevents the conversion of urls into reference footnotes in sent sms (adding characters and imparing readability) when…
#### Commit 1 [FIX] sms, tools: prevent adding link references in sms This fix prevents the conversion of urls into reference footnotes in sent sms (adding characters and imparing readability) when coming from raw text (in opposition to html source). #### Commit 2 [FIX] mass_mailing_sms: fix characters count with (opt-out) links Also impacted: sms When adding opt-out link or any link in the text, the characters count was incorrect which made SMS campaigns more expensive than expected when added characters meant more SMS to send for the message. #### Commit 3 [FIX] sms: fix disappearing sms counts To reproduce: 1. On a contact form view, click the `SMS` to send an SMS to a customer. 2. Enter some characters in the body textarea 3. Click outside the textarea At this point the count disappears and does not return on re-entering either. This solves it. (We keep jquery to keep this short and simple, as it will be obsolete with OWL in more recent versions anyway). Task-3502174 Forward-Port-Of: odoo/odoo#173285 Forward-Port-Of: odoo/odoo#140102
**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
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
This PR bugfix an error: "Error: Finalized Order cannot be modified" during a pos session. Steps to reproduce: 1. Install `pos_loyalty` module 2. Use any loyalty program (in video I used a gift card) on a pos order 3. Paid order but stay on "ReceiptScreen" 4. Click on "Orders" ("TicketButton") 5. Click on "New Order" 6. Click again on "Orders" and select paid order in status "Receipt" 7. "Error: Finalized Order cannot be modified" is shown Video of steps: https://www.loom.com/sha
Original PR description
This PR bugfix an error: "Error: Finalized Order cannot be modified" during a pos session.
Steps to reproduce:
1. Install `pos_loyalty` module
2. Use any loyalty program (in video I used a gift card) on a pos order
3. Paid order but stay on "ReceiptScreen"
4. Click on "Orders" ("TicketButton")
5. Click on "New Order"
6. Click again on "Orders" and select paid order in status "Receipt"
7. "Error: Finalized Order cannot be modified" is shown
Video of steps: https://www.loom.com/share/6ea8c86ebd994ce0958f42b6eb12c5db
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#170288
Forward-Port-Of: odoo/odoo#168142Before 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
### 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
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
This PR replaces https://github.com/odoo/enterprise/pull/55511 Forward-Port-Of: odoo/enterprise#56146
Original PR description
This PR replaces https://github.com/odoo/enterprise/pull/55511 Forward-Port-Of: odoo/enterprise#56146
task-3373525 Forward-Port-Of: odoo/enterprise#45062
Original PR description
task-3373525 Forward-Port-Of: odoo/enterprise#45062
Manual Fowardport latam task 1097 Forward-Port-Of: https://github.com/odoo/enterprise/pull/48754 Forward-Port-Of: https://github.com/odoo/enterprise/pull/47967 Forward-Port-Of: odoo/enterprise#52999
Original PR description
Manual Fowardport latam task 1097 Forward-Port-Of: https://github.com/odoo/enterprise/pull/48754 Forward-Port-Of: https://github.com/odoo/enterprise/pull/47967 Forward-Port-Of: odoo/enterprise#52999
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
version - 16.0 Steps: -Install rental app. -Activate the date picker from the web-editor. -Add the start date and end date from that. -Select some attribute of the product. Issue: -When any user adds the start date and end date from the date picker and after that, the user adds the other attribute(filter) of the product, that selected rental period gets cleared automatically. Cause: -The selected rental period (start and end dates) is not persisted when the page refreshes or upda
Original PR description
version - 16.0 Steps: -Install rental app. -Activate the date picker from the web-editor. -Add the start date and end date from that. -Select some attribute of the product. Issue: -When any user adds the start date and end date from the date picker and after that, the user adds the other attribute(filter) of the product, that selected rental period gets cleared automatically. Cause: -The selected rental period (start and end dates) is not persisted when the page refreshes or updates due to attribute selection. -The input fields for the rental period are not updated properly, causing the dates to be reset. Fix: Extend the '_onChangeAttribute' method to read the start_date and end_date parameters from the URL. Update the hidden input fields for 'start_date' and 'end_date' with the values before applying the attribute changes. opw-3774060 Forward-Port-Of: odoo/enterprise#67415 Forward-Port-Of: odoo/enterprise#64962
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
Before this commit, the 'no content' message was showing in the entire display, taking the employee panel account. Now, it is fixed, the message just stay at the disabled workorders, and when the screen is less than md, the message is hidded. Previous PR: https://github.com/odoo/enterprise/pull/62997 ### Before  ### After  ### After  task: 3794286 Forward-Port-Of: odoo/enterprise#64435
We notice that get_today_call_activities is a very frequent call that spend a lot of time runing sql queries. during 1h30 it was called 20515 times for an average of 719ms of sql times on odoo.com database. It was cause by _format_call_activities which can be called with many hundreds of activities before this commit for each activity _mail_get_partners and mail_partner_format were called once per activity. It take 581s for all the internal user of odoo.com database after this comm
Original PR description
We notice that get_today_call_activities is a very frequent call that spend a lot of time runing sql queries. during 1h30 it was called 20515 times for an average of 719ms of sql times on odoo.com database. It was cause by _format_call_activities which can be called with many hundreds of activities before this commit for each activity _mail_get_partners and mail_partner_format were called once per activity. It take 581s for all the internal user of odoo.com database after this commit the method _mail_get_partners and mail_partner_format are called for an entire batch as it's intended. The same computation for internal user takes now 84s Forward-Port-Of: odoo/enterprise#67289
When having multiple companies selected and that their tax id are not the same, then we put a banner on top of the tax report to warn the user that the companies selected don't have the same tax id. task: 3909005 Forward-Port-Of: odoo/enterprise#63275
Original PR description
When having multiple companies selected and that their tax id are not the same, then we put a banner on top of the tax report to warn the user that the companies selected don't have the same tax id. task: 3909005 Forward-Port-Of: odoo/enterprise#63275
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
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#66806- 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