Wednesday, July 24, 2024
38 changes · saas-17.4
Enhancements to existing features
The point of sale mobile interface has been tightened up to make customer cards easier to scan and closing register details better aligned. These small layout improvements help staff work more comfortably on mobile devices during customer selection and end-of-day closing.
Original PR description
- remove dead space between customers' cards - In Closing Register, align the 'Payment Method' header with the 'Expected' header task-4035873
Resolved issues and error corrections
This fixes an issue that could prevent community Point of Sale product forms from loading because they referenced a scanner field that only exists in the enterprise edition. The change helps keep the community edition stable and avoids blocking users from accessing product details in Point of Sale.
Original PR description
Runbot error: 71442 The error "Missing widget: productScanner for field of type char" is raised in community builds. This is linked to the fact that the widget is called in community but declared in enterprise. Enterprise PR: odoo/enterprise#66721 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Before this PR, to filter modules that a module set required, the addon name was searched within the list of allowed addons *stringified and joined* with a simple call to "includes", which means that a partial match with an addon's name would allow the module to be started. This has been fixed by checking that the full addon's name appears in the list of allowed addons. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174
Original PR description
Before this PR, to filter modules that a module set required, the addon name was searched within the list of allowed addons *stringified and joined* with a simple call to "includes", which means that a partial match with an addon's name would allow the module to be started. This has been fixed by checking that the full addon's name appears in the list of allowed addons. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174426
This fixes how purchase and purchase agreement totals are calculated in the company currency. It improves reliability of displayed totals by using the right dependencies and removing redundant currency conversion logic.
Original PR description
Followup to 202af7c12a768005df3bd97f595ead0a4c4c02b9 - Some depend values were wrong - New fields should have been separate computes for cleaner code + avoiding trying to change their values when their field dependencies don't have any changes - Also, remove the obsolete repeat currency conversions from bugfix 5618236ce217406931885a80b3f764eb25369d66 since the newer `price_total_cc` makes it unnecessary, but didn't remove the logic at the time of adding the new field. Followup to task: 3151579 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The sales tests now make sure discount functionality is enabled before checking discount behavior. This prevents false test failures and helps keep sales-related quality checks reliable after a recent validation change.
Original PR description
After commit 73b80be7649746f739fbd924c94a0410d6660659, a check was added if discount was enabled before applying it some tests were failing, because the setting was not enabled So now we make sure the setting is enabled before running the tests --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents community builds from failing when product barcode lookup views reference an enterprise-only scanner widget. The scanner widget usage is now kept in the enterprise override, improving build stability without changing business workflows.
Original PR description
Runbot error: 71442 The error "Missing widget: productScanner for field of type char" is raised in community builds. This is linked to the fact that the widget is called in community but declared in enterprise. We thus move its usage to the enterprise view override. Community PR: odoo/odoo#173283
A project time-off test now sets the expected timezone before running. This makes automated checks consistent across environments and helps prevent false failures unrelated to product behavior.
Original PR description
This PR fixes a test that was relying on the user being in a certain timezone. This timezone is now set before the test. Task-4038158
Some fields related to Italian invoicing are included in XML but missing from the invoice PDF. Added these fields to report_invoice for users to have more visibility for what's included in the XML submitted to Sdl. Task [link](https://www.odoo.com/odoo/project.task/3794551) task-3794551 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168447
Original PR description
Some fields related to Italian invoicing are included in XML but missing from the invoice PDF. Added these fields to report_invoice for users to have more visibility for what's included in the XML submitted to Sdl. Task [link](https://www.odoo.com/odoo/project.task/3794551) task-3794551 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168447
Before this commit, validating an order in the PoS restaurant module with a customer note attached would result in a KeyError. This issue occurred because the customer note was incorrectly processed in the note history, leading to unexpected behavior. Enterprise PR: https://github.com/odoo/enterprise/pull/67210 opw-4059220 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174249
Original PR description
Before this commit, validating an order in the PoS restaurant module with a customer note attached would result in a KeyError. This issue occurred because the customer note was incorrectly processed in the note history, leading to unexpected behavior. Enterprise PR: https://github.com/odoo/enterprise/pull/67210 opw-4059220 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174249
[IMP] l10n_cz: Fill accounting date with 'taxable_supply_date' In CZ, they need to use the taxable supply date as accounting date and rely on it when we are calculating the currency rate 1- Set default value for 'taxable_supply_date' as the invoice date and allow the user to modify it. Also, fill the accounting date but using the taxable supply date as reference in place of invoice date. 2- Use taxable_supply_date/accounting date to compute the currency rate task-id#3983749 enterpr
Original PR description
[IMP] l10n_cz: Fill accounting date with 'taxable_supply_date' In CZ, they need to use the taxable supply date as accounting date and rely on it when we are calculating the currency rate 1- Set default value for 'taxable_supply_date' as the invoice date and allow the user to modify it. Also, fill the accounting date but using the taxable supply date as reference in place of invoice date. 2- Use taxable_supply_date/accounting date to compute the currency rate task-id#3983749 enterprise-pr: https://github.com/odoo/enterprise/pull/67149 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168933
Description of the issue/feature this PR addresses: This PR fixes the incorrect styling applied by the css when reporting the client_order_ref field. Current behavior before PR:  Desired behavior after PR is merged:  --- I confirm I have signed the CLA and read the PR guidelines at ww
Original PR description
Description of the issue/feature this PR addresses: This PR fixes the incorrect styling applied by the css when reporting the client_order_ref field. 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#172741 Forward-Port-Of: odoo/odoo#172366
[REV] project: set default value of analytic plan in the project config setting This reverts commit https://github.com/odoo/odoo/commit/a2c51c6ad9ae80e6d4edc5de96811edd56df7a7c because the `analytic.project_plan` should not be altered since that field is used to find the column auto-generated in `account.analytic.line` model by `analytic.plan`. opw-4051817 Forward-Port-Of: odoo/odoo#174259
Original PR description
[REV] project: set default value of analytic plan in the project config setting This reverts commit https://github.com/odoo/odoo/commit/a2c51c6ad9ae80e6d4edc5de96811edd56df7a7c because the `analytic.project_plan` should not be altered since that field is used to find the column auto-generated in `account.analytic.line` model by `analytic.plan`. opw-4051817 Forward-Port-Of: odoo/odoo#174259
This commit adds the missing neutralization necessary for the l10n_ro_efactura module introduced in [1] The purpose of the standard neutralization framework is to allow us to create database copies that will not interact with external systems in ways that could impact the production database (or if it is not possible to prevent the interactions, make sure that they are benign or won't result in actual changes), or impact the customers of the operator of the production database. This is mainly
Original PR description
This commit adds the missing neutralization necessary for the l10n_ro_efactura module introduced in [1] The purpose of the standard neutralization framework is to allow us to create database copies that will not interact with external systems in ways that could impact the production database (or if it is not possible to prevent the interactions, make sure that they are benign or won't result in actual changes), or impact the customers of the operator of the production database. This is mainly useful to allow safe support investigation on database duplicates. [1] https://github.com/odoo/odoo/pull/144061 Forward-Port-Of: odoo/odoo#174013
Specification: In the daterange widget, if the second date field is required and left empty, the field should be marked as invalid and be colored red. Expected behavior: if the second field is empty so that fields should be highlighted in red. Task-3786540 Forward-Port-Of: odoo/odoo#162000
Original PR description
Specification: In the daterange widget, if the second date field is required and left empty, the field should be marked as invalid and be colored red. Expected behavior: if the second field is empty so that fields should be highlighted in red. Task-3786540 Forward-Port-Of: odoo/odoo#162000
Current behavior: After settling the payment of an order, the order remains in the orders list Steps to reproduce: - Install "Point of Sale" and "Sales" apps - Start a shop session, select an order and proceed to the payment - Go back to the orders list and see the paid order still there Note: Forward the test of https://github.com/odoo/odoo/pull/171609 opw-4019204 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/
Original PR description
Current behavior: After settling the payment of an order, the order remains in the orders list Steps to reproduce: - Install "Point of Sale" and "Sales" apps - Start a shop session, select an order and proceed to the payment - Go back to the orders list and see the paid order still there Note: Forward the test of https://github.com/odoo/odoo/pull/171609 opw-4019204 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173723 Forward-Port-Of: odoo/odoo#173103
Versions: --------- - 16.0 Steps to reproduce: ------------------- - go to the planning calendar. - hover over a record in the sidebar of the calendar, and then - click on "Shifts" in the calendar entries. Issue: ------ 1. the size of the popover enlarges when the content of the field is large, and the child element does not inherit the width of its parent elements. 2. The size of the popover becomes larger when hovering over the calendar filter tooltip. Cause: ------ Th
Original PR description
Versions: --------- - 16.0 Steps to reproduce: ------------------- - go to the planning calendar. - hover over a record in the sidebar of the calendar, and then - click on "Shifts" in the calendar entries. Issue: ------ 1. the size of the popover enlarges when the content of the field is large, and the child element does not inherit the width of its parent elements. 2. The size of the popover becomes larger when hovering over the calendar filter tooltip. Cause: ------ The popover title is taking up the full 100% width. Additionally, the popover title and body expand in response to the content of the fields, causing the popover size to become larger. Solution: --------- Setting a maximum width and enabling text truncation will make it appear more visually appealing. Additionally, set a maximum width of 25% and enable text truncation." **task-3446307** Forward-Port-Of: odoo/odoo#173203 Forward-Port-Of: odoo/odoo#138336
Summary ----- In the method load in models.py, when there is an error when we try to create a recordset with at least 2 records, we try to create each record separately. Only the errors caught by creating these single records are displayed which is confusing. Steps to Reproduce ----- 1. In Accounting > Configuration > Accounting > Chart of Accounts, create an account with the type "Off-Balanced Sheet" 2. On the same page, import a Chart of Account (import journal items
Original PR description
Summary ----- In the method load in models.py, when there is an error when we try to create a recordset with at least 2 records, we try to create each record separately. Only the errors caught by…
Summary
-----
In the method load in models.py, when there is an error when we try to create a recordset with at least 2 records, we try to create each record separately.
Only the errors caught by creating these single records are displayed which is confusing.
Steps to Reproduce
-----
1. In Accounting > Configuration > Accounting > Chart of
Accounts, create an account with the type "Off-Balanced Sheet"
2. On the same page, import a Chart of Account (import journal
items) by uploading a file which contains the following lines
(example available on the ticket):
[
['move_id','account_id','balance' 'journal_id','date'],
[<move_name>,<account_code_1>,1,<journal_name>,2021-01-01],
[<move_name>,<account_code_2>,-1,<journal_name>,2021-01-01]
]
such that:
- move_name cannot exist
account_code_1 is the code of the created account at
first step
account_code_2 is not the code of an account with the
type "Off-Balanced Sheet"
- journal_name is the name of an existing journal
3. Test or import the uploaded file and see the error which does
not mention the "Off-Balanced Sheet" account.
Cause
-----
If a journal entry contains a line with an "Off
Balanced Sheet" account, then all the other lines must have an account with the same type.
So when we try to load the lines of the uploaded file, it raises a UserError which is caught (which is not added to the list 'messages'). Then we try to create the lines one by one which and that raises an error too because the balance is not null.
Only these errors are added to the list 'messages' which contains the displayed error messages.
Fix
-----
Add the first error to 'message', and ensure that the next errors are not already in 'messages'.
opw-3945687
Forward-Port-Of: odoo/odoo#169083**Current behavior before PR:** When initiating searches quickly in discuss channels or chatter, overlapping requests can occur before previous searches finish. This race condition leads to errors and causes issues with destructuring properties like count, loadMore, and messages.( see: [Discuss](https://www.awesomescreenshot.com/video/29801496?key=44057f8e37a2f394f20e8fc790f80537)) **Desired behavior after PR is merged:** This commit updates the `useMessageSearch` hook to handle sim
Original PR description
**Current behavior before PR:** When initiating searches quickly in discuss channels or chatter, overlapping requests can occur before previous searches finish. This race condition leads to errors and causes issues with destructuring properties like count, loadMore, and messages.( see: [Discuss](https://www.awesomescreenshot.com/video/29801496?key=44057f8e37a2f394f20e8fc790f80537)) **Desired behavior after PR is merged:** This commit updates the `useMessageSearch` hook to handle simultaneous requests more robustly by checking that search results are defined before processing them. This prevents errors and improves stability during rapid searches. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174174
- Changed pos_display background to follow odoo 17's default one, updated all colors/logo to fit, - Moved error message to console as it's almost never relevant to users, - Added hostname on top of the page. Task: 3947355 Forward-Port-Of: odoo/odoo#174169
Original PR description
- Changed pos_display background to follow odoo 17's default one, updated all colors/logo to fit, - Moved error message to console as it's almost never relevant to users, - Added hostname on top of the page. Task: 3947355 Forward-Port-Of: odoo/odoo#174169
Pre-authorized debit payments in Canada are using Automated Clearing Settlement System (ACSS), which our current integration does not support. opw-4012861 Forward-Port-Of: odoo/odoo#173587
Original PR description
Pre-authorized debit payments in Canada are using Automated Clearing Settlement System (ACSS), which our current integration does not support. opw-4012861 Forward-Port-Of: odoo/odoo#173587
Before this commit : In Draft Invoice/bill if we change fiscal position then it's not updating tax and account in existing lines. After this commit : In the Draft Invoice/bill if we change in fiscal position then it will update the tax and account in existing lines. Task - 3619055 Forward-Port-Of: odoo/odoo#153172
Original PR description
Before this commit : In Draft Invoice/bill if we change fiscal position then it's not updating tax and account in existing lines. After this commit : In the Draft Invoice/bill if we change in fiscal position then it will update the tax and account in existing lines. Task - 3619055 Forward-Port-Of: odoo/odoo#153172
[FIX] web_editor: won't place font element between if else nodes Previously when we updated color on multiple selected nodes, </font> tag would get inserted between qweb if and else tags. This caused qweb processor to crash. After this change we don't insert font on the "t" elements. [Reproduce] - Install account - Open Email Template called "Invoice: Sending" - Change color of all of its content - Open preview opw-3912434 Forward-Port-Of: odoo/odoo#173703 Forward-Port-Of: odoo
Original PR description
[FIX] web_editor: won't place font element between if else nodes Previously when we updated color on multiple selected nodes, </font> tag would get inserted between qweb if and else tags. This caused qweb processor to crash. After this change we don't insert font on the "t" elements. [Reproduce] - Install account - Open Email Template called "Invoice: Sending" - Change color of all of its content - Open preview opw-3912434 Forward-Port-Of: odoo/odoo#173703 Forward-Port-Of: odoo/odoo#169678
Allow customization to retrieve the user used to authenticate by adding the user attribute. opw-4059147 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174208
Original PR description
Allow customization to retrieve the user used to authenticate by adding the user attribute. opw-4059147 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174208
**Steps:** - Create a new Discount and loyalty program. - Keep the program type as Buy X Get Y / any other program - In the rewards pop-up, leave the 'description on the product' empty and click on 'save & close'. - Try to save the loyalty program. Validation error appears. **Cause:** - This occurs because the description is used to set the name of the discount product, but if it's empty, the write method will not get the proper values hence resulting in error. **Fix:** - Raise user
Original PR description
**Steps:** - Create a new Discount and loyalty program. - Keep the program type as Buy X Get Y / any other program - In the rewards pop-up, leave the 'description on the product' empty and click on 'save & close'. - Try to save the loyalty program. Validation error appears. **Cause:** - This occurs because the description is used to set the name of the discount product, but if it's empty, the write method will not get the proper values hence resulting in error. **Fix:** - Raise user error if the description field is set to empty. **Affected Version:** 16.0 - saas~17.4 **opw**-4032798 Forward-Port-Of: odoo/odoo#173789
In the mail composer, the title of the modal changes to "Odoo" when the user clicks on the "Save Template" button. This commit will ensure that the modal will keep the title "Compose email" after the user clicks on the button. Steps to reproduce the issue: 1. Open a lead from the CRM module 2. Open the mail composer from the chatter 3. In the composer, click on the "Save Template" button 4. Give a name for the new template => The modal title changes from "Compose Email" to "Odoo" TO
Original PR description
In the mail composer, the title of the modal changes to "Odoo" when the user clicks on the "Save Template" button. This commit will ensure that the modal will keep the title "Compose email" after the…
In the mail composer, the title of the modal changes to "Odoo" when the user clicks on the "Save Template" button. This commit will ensure that the modal will keep the title "Compose email" after the user clicks on the button. Steps to reproduce the issue: 1. Open a lead from the CRM module 2. Open the mail composer from the chatter 3. In the composer, click on the "Save Template" button 4. Give a name for the new template => The modal title changes from "Compose Email" to "Odoo" TO BE: The modal title should display "Compose Email" after creating the template. After creating the template, the system re-opens the composer by executing a dynamic action. This action does not specify any title. As a result, the modal fallbacks to the default title "Odoo" after executing the action. To fix the issue, we will simply set a name to the dynamic action. task-3748652 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173135 Forward-Port-Of: odoo/odoo#172765
In the POS Restaurant module, there was an issue where an order could be missed in the backend if a draft order, opened by a cashier on one device, was paid for on another device. Subsequently, if the cashier added more products to the order and completed the payment, the receipt would be printed, but the backend would fail to record the updated order. This fix ensures that an updated order with the same reference is captured in the backend if its content has changed, preventing data loss and en
Original PR description
In the POS Restaurant module, there was an issue where an order could be missed in the backend if a draft order, opened by a cashier on one device, was paid for on another device. Subsequently, if the cashier added more products to the order and completed the payment, the receipt would be printed, but the backend would fail to record the updated order. This fix ensures that an updated order with the same reference is captured in the backend if its content has changed, preventing data loss and ensuring consistency across devices. opw-4067875 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174200
Steps: - Create group tax (20%) and add two tax in it (10% each) with Tax included true. - Create product with 100 price and and set that 20% tax on it. - Create coupon program with 90 amount on order and generate coupon. - Create SO and add SOL with that product now apply coupon on that SO. Issue: - Amount computation is wrong for coupon value which is greater then that product's tax_excluded(80) and it is only applying 80 instead of 90 because we were not properly computing amount
Original PR description
Steps: - Create group tax (20%) and add two tax in it (10% each) with Tax included true. - Create product with 100 price and and set that 20% tax on it. - Create coupon program with 90 amount on order and generate coupon. - Create SO and add SOL with that product now apply coupon on that SO. Issue: - Amount computation is wrong for coupon value which is greater then that product's tax_excluded(80) and it is only applying 80 instead of 90 because we were not properly computing amount of child taxed. Cause: - Discountable was not properly computed in commit [1]. it was not taking child tax values into account. Fix: - Add condition to properly check discountable values and take child tax amount into consideration. [1] https://github.com/odoo/odoo/commit/443097b4db29a4909bb0d0c44040140f08d1e433 opw-4033803 Forward-Port-Of: odoo/odoo#174196 Forward-Port-Of: odoo/odoo#173659
Description of the issue/feature this PR addresses: - In v17.0, the default value of 'analytic plan' (analytic_plan_id) has not been set in setting. - Analytic plan has config_parameter is set as "[analytic.analytic_plan_projects](https://github.com/odoo/odoo/blob/758ced91f8cb220a003a49b01e047b507f8509d7/addons/project/models/res_config_settings.py#L18-L22)" However, the default key was set different "[account.plan_projects](https://github.com/odoo/odoo/blob/758ced91f8cb220a003a49b01e047b507
Original PR description
Description of the issue/feature this PR addresses: - In v17.0, the default value of 'analytic plan' (analytic_plan_id) has not been set in setting. - Analytic plan has config_parameter is set as…
Description of the issue/feature this PR addresses: - In v17.0, the default value of 'analytic plan' (analytic_plan_id) has not been set in setting. - Analytic plan has config_parameter is set as "[analytic.analytic_plan_projects](https://github.com/odoo/odoo/blob/758ced91f8cb220a003a49b01e047b507f8509d7/addons/project/models/res_config_settings.py#L18-L22)" However, the default key was set different "[account.plan_projects](https://github.com/odoo/odoo/blob/758ced91f8cb220a003a49b01e047b507f8509d7/addons/analytic/data/analytic_data.xml#L13)" - And during the migration from v16.0 to v17.0, the default key generated in v16.0 is [removed](https://github.com/odoo/upgrade/blob/20faf7ba48595c61fc028ba1b4cf278d2c44e3cc/migrations/analytic/saas~16.5.1.1/pre-migrate.py#L10-L18) in saas~16.5 and new key will be set which this only "account.plan_projects" . - Because of the incorrect key value of 'analytic plan'(analytic_plan_id) is null. **Steps to reproduce:** - Install project module. - Go to Setting > Projects > got to Analytics section in that Analytic Plan. - Default analytic plan value is not there. **Solution:** - Set the correct key `analytic.project_plan` for the 'analytic_plan_id' field. **Current behavior in 16.0 :**  **Current behavior in 17.0 before pr:**  **Desired behavior after PR is merged:**  task-3941668 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173087 Forward-Port-Of: odoo/odoo#172123
Before this commit, validating an order in the PoS restaurant module with a customer note attached would result in a KeyError. This issue occurred because the customer note was incorrectly processed in the note history, leading to unexpected behavior. Community PR: https://github.com/odoo/odoo/pull/174249 opw-4059220 Forward-Port-Of: odoo/enterprise#67210
Original PR description
Before this commit, validating an order in the PoS restaurant module with a customer note attached would result in a KeyError. This issue occurred because the customer note was incorrectly processed in the note history, leading to unexpected behavior. Community PR: https://github.com/odoo/odoo/pull/174249 opw-4059220 Forward-Port-Of: odoo/enterprise#67210
[IMP] l10n_cz_reports: Adapt cz test on taxable date CZ is going to rely on taxable_supply_date and not the invoice date So, We need to adapt the tests on the new behavior task-id#3983749 odoo-pr: https://github.com/odoo/odoo/pull/168933 Forward-Port-Of: odoo/enterprise#67149
Original PR description
[IMP] l10n_cz_reports: Adapt cz test on taxable date CZ is going to rely on taxable_supply_date and not the invoice date So, We need to adapt the tests on the new behavior task-id#3983749 odoo-pr: https://github.com/odoo/odoo/pull/168933 Forward-Port-Of: odoo/enterprise#67149
Before this commit, after we drag a sign item out of bounds, it would disappear until we refresh the page. This was happening because we were hiding the item at drag start, then it would only get re-rendered after dropping it inside the page. Thus, if we dragged the item out of bounds instead of inside the page, the item would never get re-rendered. After this commit, the sign item can be dragged anywhere, even out-of-bounds. It works properly because now when the item is dragged out-of-bound
Original PR description
Before this commit, after we drag a sign item out of bounds, it would disappear until we refresh the page. This was happening because we were hiding the item at drag start, then it would only get re-rendered after dropping it inside the page. Thus, if we dragged the item out of bounds instead of inside the page, the item would never get re-rendered. After this commit, the sign item can be dragged anywhere, even out-of-bounds. It works properly because now when the item is dragged out-of-bounds, we make the item visible again even though the the invalid operation is discarded. task-4037888 Forward-Port-Of: odoo/enterprise#66155
Update legacy tests importing mail/test_utils.js to use HOOT instead of Qunit. Task-3818666 Forward-Port-Of: odoo/enterprise#66751
Original PR description
Update legacy tests importing mail/test_utils.js to use HOOT instead of Qunit. Task-3818666 Forward-Port-Of: odoo/enterprise#66751
### **Steps to reproduce:** - install Timesheets module. - Go to To Validate. - Click on All Timesheets. ### **Issue:** - The notification message is not displaying when clicking on validate in pivot and kanban views ### **Solution:** - The problem seems to be from a mismatch in parameters when triggering the validation action. PR-https://github.com/odoo/enterprise/pull/44455 task-3925639 Forward-Port-Of: odoo/enterprise#67020 Forward-Port-Of: odoo/enterprise#62945
Original PR description
### **Steps to reproduce:** - install Timesheets module. - Go to To Validate. - Click on All Timesheets. ### **Issue:** - The notification message is not displaying when clicking on validate in pivot and kanban views ### **Solution:** - The problem seems to be from a mismatch in parameters when triggering the validation action. PR-https://github.com/odoo/enterprise/pull/44455 task-3925639 Forward-Port-Of: odoo/enterprise#67020 Forward-Port-Of: odoo/enterprise#62945
Previously, we added support for self-withholding taxes, which do not need to be reported in the XML file. Hence, tax lines that contain a tax with a code ZZ (for customer invoices)/ ZZ, 07 (for vendor bills) are filtered out. However, when we compute the total amounts these are not filtered out, leading to a discrepancy in sums. We should filter out such tax lines when computing totals as well. See other commit: https://github.com/odoo/enterprise/commit/af8f364cc1f09cc1f9159b326a7f59
Original PR description
Previously, we added support for self-withholding taxes, which do not need to be reported in the XML file. Hence, tax lines that contain a tax with a code ZZ (for customer invoices)/ ZZ, 07 (for vendor bills) are filtered out. However, when we compute the total amounts these are not filtered out, leading to a discrepancy in sums. We should filter out such tax lines when computing totals as well. See other commit: https://github.com/odoo/enterprise/commit/af8f364cc1f09cc1f9159b326a7f59c6524380be opw-3958518 Forward-Port-Of: odoo/enterprise#67100 Forward-Port-Of: odoo/enterprise#66918
Before this commit: For multi-label shipment tracking references are stored in field carrier_tracking_ref as "1Zxxxxxxxxxxxxxxxx+1Zxxxxxxxxxxxxxxxx+..." When cancelling the shipment, the ShipmentIdentificationNumber is the tracking reference of first package. carrier_tracking_ref is being sent as ShipmentIdentificationNumber with all the tracking references. resulting in error 'Shipment not found'. After this commit: Only the tracking reference for the first package is sent as
Original PR description
Before this commit: For multi-label shipment tracking references are stored in field carrier_tracking_ref as "1Zxxxxxxxxxxxxxxxx+1Zxxxxxxxxxxxxxxxx+..." When cancelling the shipment, the ShipmentIdentificationNumber is the tracking reference of first package. carrier_tracking_ref is being sent as ShipmentIdentificationNumber with all the tracking references. resulting in error 'Shipment not found'. After this commit: Only the tracking reference for the first package is sent as ShipmentIdentificationNumber in cancel request. Reference ups documentation: https://developer.ups.com/api/reference?loc=en_US#operation/Shipment Methods > Shipment Methods > Void Shipment opw-3974794 Forward-Port-Of: odoo/enterprise#67158
Step to reproduce: 1. Install Accounting and l10n_dk 2. View the balance sheet in comparison to last year and check the current profit & loss 3. create a bill reversal for 2023 and confirm it 4. View the balance sheet and observe how the 2024 adds the 2023 total into its total Expected behavior: The PnL from the previous year should not be added to the total of that report line. Solution: Add the missing `date_scope` field on the formula to make sure it only considers the PnL f
Original PR description
Step to reproduce: 1. Install Accounting and l10n_dk 2. View the balance sheet in comparison to last year and check the current profit & loss 3. create a bill reversal for 2023 and confirm it 4. View the balance sheet and observe how the 2024 adds the 2023 total into its total Expected behavior: The PnL from the previous year should not be added to the total of that report line. Solution: Add the missing `date_scope` field on the formula to make sure it only considers the PnL from the start of the fiscal year, therefore getting the current year's PnL opw-3957488 Forward-Port-Of: odoo/enterprise#66883
Steps to reproduce: - Projects > Field Service > New - Pick a customer but no assignee - Products > Add any product - Back to task > Sale order > Other info tab What happens: No salesperson is set. Expected behavior: salesperson is the first assignee on the task if any, current user if not (first assignee as in the first listed on the task, which sorts them alphabetically). opw-4026074 opw-4015184 (duplicate) Forward-Port-Of: odoo/enterprise#67184 Forward-Port-Of: odoo/enterprise#6
Original PR description
Steps to reproduce: - Projects > Field Service > New - Pick a customer but no assignee - Products > Add any product - Back to task > Sale order > Other info tab What happens: No salesperson is set. Expected behavior: salesperson is the first assignee on the task if any, current user if not (first assignee as in the first listed on the task, which sorts them alphabetically). opw-4026074 opw-4015184 (duplicate) Forward-Port-Of: odoo/enterprise#67184 Forward-Port-Of: odoo/enterprise#66404
This traceback occurs when the user changes the `resource` of an existing The `planning slots` record has a `repeat` enabled. To reproduce this issue: 1) Install `planning_contract` 2) Open the planning module in `year` mode 3) Change the `resource` of any existing slot with `repeat` enabled record 4) Now run the corn job (`generate next recurring shifts`) to produce the issue for instance Error:- ``` ValueError: Expected singleton: hr.employee(2, 8) File "odoo/tools/safe
Original PR description
This traceback occurs when the user changes the `resource` of an existing The `planning slots` record has a `repeat` enabled. To reproduce this issue: 1) Install `planning_contract` 2) Open the…
This traceback occurs when the user changes the `resource` of an existing
The `planning slots` record has a `repeat` enabled.
To reproduce this issue:
1) Install `planning_contract`
2) Open the planning module in `year` mode
3) Change the `resource` of any existing slot with `repeat` enabled record
4) Now run the corn job (`generate next recurring shifts`)
to produce the issue for instance
Error:-
```
ValueError: Expected singleton: hr.employee(2, 8)
File "odoo/tools/safe_eval.py", line 390, in safe_eval
return unsafe_eval(c, globals_dict, locals_dict)
File "ir.actions.server(344,)", line 1, in <module>
File "home/odoo/src/enterprise/saas-17.2/planning/models/planning_recurrency.py", line 71, in _cron_schedule_next
recurrencies._repeat_slot(now + delta)
File "home/odoo/src/enterprise/saas-17.2/planning/models/planning_recurrency.py", line 89, in _repeat_slot
misc_recurrence_stop = recurrency._get_misc_recurrence_stop()
File "home/odoo/src/enterprise/saas-17.2/planning_contract/models/planning_recurrency.py", line 15, in _get_misc_recurrence_stop
('employee_id', '=', self.slot_ids.resource_id.employee_id.id),
File "odoo/fields.py", line 5183, in __get__
raise ValueError("Expected singleton: %s" % record)
ValueError: <class 'ValueError'>: "Expected singleton: hr.employee(2, 8)" while evaluating
'model._cron_schedule_next()'
File "odoo/addons/base/models/ir_cron.py", line 388, in _callback
self.env['ir.actions.server'].browse(server_action_id).run()
File "home/odoo/src/custom/trial/saas_trial/models/sentry.py", line 33, in run
res = super().run()
File "odoo/addons/base/models/ir_actions.py", line 971, in run
res = runner(run_self, eval_context=eval_context)
File "odoo/addons/base/models/ir_actions.py", line 801, in _run_action_code_multi
safe_eval(self.code.strip(), eval_context, mode="exec", nocopy=True, filename=str(self)) # nocopy allows to return 'action'
File "odoo/tools/safe_eval.py", line 404, in safe_eval
raise ValueError('%s: "%s" while evaluating\n%r' % (ustr(type(e)), ustr(e), expr))
```
When the user changes the slot resource, the corn job runs based on recurrence.
Each recurrence may have multiple recordsets of slots which might have multiple resources.
But in the commit[1] a search query was used in which `id` is used instead of ids.
which leads to the traceback from [2].
Commit[1]: https://github.com/odoo/enterprise/pull/64845/commits/ff4cb88199349ac7507f7e526aeb3ed21c114c96
[2]
https://github.com/odoo/enterprise/blob/40711df5a635a9d2fd690ca53b271f0e7890cdb6/planning_contract/models/planning_recurrency.py#L15
After applying this commit, it will resolve this issue by using ids instead of id
sentry-5608817801
Forward-Port-Of: odoo/enterprise#66812