Wednesday, November 13, 2024
25 changes · saas-17.2
Miscellaneous changes
This reverts commit 4d548d2240c85eebe004595cd65e0fbb6a76a39b. To reproduce the issue: 1. Create a customer payment and post it 2. Create a customer batch payment 3. Asociate that payment to the batch and validate it 4. Reset payment to draft ====> A constraint on the batch is triggered. In 17.4, we solved it by removing that check from the constraint, since the same check was done at batch validation: 3e307ec2fa5191fcc657316a125dae208975f82b . In lower versions, the validation does not
Original PR description
This reverts commit 4d548d2240c85eebe004595cd65e0fbb6a76a39b. To reproduce the issue: 1. Create a customer payment and post it 2. Create a customer batch payment 3. Asociate that payment to the batch and validate it 4. Reset payment to draft ====> A constraint on the batch is triggered. In 17.4, we solved it by removing that check from the constraint, since the same check was done at batch validation: 3e307ec2fa5191fcc657316a125dae208975f82b . In lower versions, the validation does not do that, so we can't apply the same fix. Since the dependency issue can only be annoying in case of customizations, we make the choice to live with it for old versions. Forward-Port-Of: odoo/enterprise#73495
Steps to reproduce: - Install Attendances - New employee > New Contract > Set a wage - Set 'Work Entry Source' to 'Attendances' - Payroll app > New Payslip > Compute Sheet - Salary Computation tab > Basic salary = contract Wage Steps to check salary configurator: - Install Salary Configurator and Recruitment - Recruitment > Any Job Position > New Application - Generate Offer > Pick template > Configure your package - Under 'Net Salary' click Details The basic salary should be 0 as
Original PR description
Steps to reproduce: - Install Attendances - New employee > New Contract > Set a wage - Set 'Work Entry Source' to 'Attendances' - Payroll app > New Payslip > Compute Sheet - Salary Computation tab >…
Steps to reproduce: - Install Attendances - New employee > New Contract > Set a wage - Set 'Work Entry Source' to 'Attendances' - Payroll app > New Payslip > Compute Sheet - Salary Computation tab > Basic salary = contract Wage Steps to check salary configurator: - Install Salary Configurator and Recruitment - Recruitment > Any Job Position > New Application - Generate Offer > Pick template > Configure your package - Under 'Net Salary' click Details The basic salary should be 0 as no work hours have been recorded, note that this is different from having leaves recorded we're talking about a case where no records are available to compute the payslip basic salary. We might still want to generate a payslip in such cases to account for the flat allowances / deductions the employee might have on their contract's salary structure. We can't just set it to 0 though: This workaround is needed because the salary configurator also uses salary computation, where we do want to get the monthly wage (Since the contract is still provisional we don't have worked hours, but we still want it to be reflective of the position's monthly wage). In the case of an active employee however, paying a basic wage when no hours have been worked does not make sense so it should invariably be 0. This could also be relevant with other work entry sources than attendances but a contract based on worked entries automatically generates worked hours according to the schedule so it is more difficult to reach. opw-4266880 Forward-Port-Of: odoo/enterprise#73469
StockMove.date does not represent the Scheduled date when the move is Done, but the date it was validated. Hence, if the move was validated outside the period it was made for, it will be accounted for in the future period. To reproduce, you can: - Create a subscription with a start_date in the past, so that today's date is in the SECOND period: Ex: Today = "2024-11-01" * Recurring plan: Monthly * Start Date: "2024-10-01" - Trigger the cron to invoice & deliver the FIRST period ("2
Original PR description
StockMove.date does not represent the Scheduled date when the move is Done, but the date it was validated. Hence, if the move was validated outside the period it was made for, it will be accounted…
StockMove.date does not represent the Scheduled date when the move is Done, but the date it was validated. Hence, if the move was validated outside the period it was made for, it will be accounted for in the future period.
To reproduce, you can:
- Create a subscription with a start_date in the past, so that today's date is in the SECOND period: Ex: Today = "2024-11-01"
* Recurring plan: Monthly
* Start Date: "2024-10-01"
- Trigger the cron to invoice & deliver the FIRST period ("2024-10-01" -> "2024-10-31").
- Validate the first period picking => "Scheduled Date" becomes the done date: "2024-11-01"
- Trigger the cron to invoice & deliver the SECOND period ("2024-11-01" -> "2024-11-30"). => Second period picking is NOT generated, because the first period picking was interpreted as belonging to the second period.
---
Test result before fix:
```
2024-11-07 13:44:54,695 34298 ERROR oes_17_test_sss odoo.addons.sale_subscription_stock.tests.test_sale_subscription_stock_order: FAIL: TestSubscriptionStockOnOrder.test_picking_done_in_another_period
Traceback (most recent call last):
File "/home/odoo/projects/odoo-src/multiverse/src/17.0/enterprise/sale_subscription_stock/tests/test_sale_subscription_stock_order.py", line 543, in test_picking_done_in_another_period
self.assertTrue(bool(second_picking))
AssertionError: False is not true
```
OPW-4280155
Forward-Port-Of: odoo/enterprise#73484opw-4160838 Community: https://github.com/odoo/odoo/pull/184555 Forward-Port-Of: odoo/enterprise#72501
Original PR description
opw-4160838 Community: https://github.com/odoo/odoo/pull/184555 Forward-Port-Of: odoo/enterprise#72501
TO REPRODUCE =========== 1. Create an appointment with users A and B 2. ...using 'no picture' and 'user then time' 3. go to front end 4. pick a date D both users have slots in 5. go to next month 6. change user in the dropdown (or change TZ) 7. slots appear for day D in previous month ISSUE ===== When selecting an other resource or user in the dropdown in resource_time mode, even if the selected one has no available slot for the current month, slots will appear in the slot list, c
Original PR description
TO REPRODUCE =========== 1. Create an appointment with users A and B 2. ...using 'no picture' and 'user then time' 3. go to front end 4. pick a date D both users have slots in 5. go to next month 6.…
TO REPRODUCE =========== 1. Create an appointment with users A and B 2. ...using 'no picture' and 'user then time' 3. go to front end 4. pick a date D both users have slots in 5. go to next month 6. change user in the dropdown (or change TZ) 7. slots appear for day D in previous month ISSUE ===== When selecting an other resource or user in the dropdown in resource_time mode, even if the selected one has no available slot for the current month, slots will appear in the slot list, corresponding to the first availability overall. This leads to a very strange mismatch between the calendar dates and the slots. The user may select a slot and book for a month they do not currently see on the calendar. SOLUTION ======== Now, we will select the previously selected date if it is in the current month and has slots. Otherwise we select the first day with slots in the currently displayed month (NOT overall). This way, the day is selected and displayed as so in the calendar. The slots match that day. If no availability exist for the current month, we do not click on any day, and show no slots. Task-4169513 Forward-Port-Of: odoo/enterprise#71460
Before this commit: The logo is not updated when users change the icon or image and click the confirm button. The updated logo appears after refreshing the page. After this commit: When users change the icon or image and click the confirm button, the logo is now updated Task-4219545 Forward-Port-Of: odoo/enterprise#71512
Original PR description
Before this commit: The logo is not updated when users change the icon or image and click the confirm button. The updated logo appears after refreshing the page. After this commit: When users change the icon or image and click the confirm button, the logo is now updated Task-4219545 Forward-Port-Of: odoo/enterprise#71512
This reverts commit fd46e62809544702193e636ec388103eea11f788. Task-4314619 Forward-Port-Of: odoo/enterprise#73506
Original PR description
This reverts commit fd46e62809544702193e636ec388103eea11f788. Task-4314619 Forward-Port-Of: odoo/enterprise#73506
Steps to reproduce ================== - Go to documents - Switch to the list view - Select a record - Resize a column => The selection is lost Solution ======== Ignore clicks in the header opw-4203375 Forward-Port-Of: odoo/enterprise#71774
Original PR description
Steps to reproduce ================== - Go to documents - Switch to the list view - Select a record - Resize a column => The selection is lost Solution ======== Ignore clicks in the header opw-4203375 Forward-Port-Of: odoo/enterprise#71774
This PR removes the tags added to the TDS sales taxes. Due to tags on sales taxes, all the TDS entries from customer invoices are reported in TDS reports which does not need to be reported. task-4314045 Forward-Port-Of: odoo/odoo#186746
Original PR description
This PR removes the tags added to the TDS sales taxes. Due to tags on sales taxes, all the TDS entries from customer invoices are reported in TDS reports which does not need to be reported. task-4314045 Forward-Port-Of: odoo/odoo#186746
This improves the wording for the "missing journal" error, matching #185054 Because the original PR needs to be stopped at 16.0, this part will be able to be forward-ported --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186669 Forward-Port-Of: odoo/odoo#186138
Original PR description
This improves the wording for the "missing journal" error, matching #185054 Because the original PR needs to be stopped at 16.0, this part will be able to be forward-ported --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186669 Forward-Port-Of: odoo/odoo#186138
Steps to reproduce ================== - Use a mobile device - Enable analytic accounting - Go to Expenses - Open a record - Click on the analytic field - Search more on the project - Click on the search input => The popup closes Cause of the issue ================== There is a resize handler that closes the popup. When the keyboard appears, the window is resized to reserve space for it Solution ======== Dont close the popup when we are using a mobile OS opw-4174514
Original PR description
Steps to reproduce ================== - Use a mobile device - Enable analytic accounting - Go to Expenses - Open a record - Click on the analytic field - Search more on the project - Click on the search input => The popup closes Cause of the issue ================== There is a resize handler that closes the popup. When the keyboard appears, the window is resized to reserve space for it Solution ======== Dont close the popup when we are using a mobile OS opw-4174514 Forward-Port-Of: odoo/odoo#186606
This commit adds the capture parameter to events listeners in useDropzone utility function to make it work correctly in Documents App where the events weren't intercepted because of `stopPropagation()` call in others listeners. Task-4314619 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186651
Original PR description
This commit adds the capture parameter to events listeners in useDropzone utility function to make it work correctly in Documents App where the events weren't intercepted because of `stopPropagation()` call in others listeners. Task-4314619 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186651
Before this commit, the welcome page was using "Guest" as the default name, regardless of what the name was. Forward-Port-Of: odoo/odoo#186759
Original PR description
Before this commit, the welcome page was using "Guest" as the default name, regardless of what the name was. Forward-Port-Of: odoo/odoo#186759
When an error is thrown sufficiently early in the webclient's "boot" process, sometimes the error handlers might not be ready *enough* eg: the dialog service has not been loaded yet. In those cases, the way to handle the error is to log it as an an error (console.log) along with some kind of hint as to why it has not been handled in a user-friendly manner. Before this commit, the original error appeared twice: one because of our logs, the second because of the browser's default behavior.
Original PR description
When an error is thrown sufficiently early in the webclient's "boot" process, sometimes the error handlers might not be ready *enough* eg: the dialog service has not been loaded yet. In those cases, the way to handle the error is to log it as an an error (console.log) along with some kind of hint as to why it has not been handled in a user-friendly manner. Before this commit, the original error appeared twice: one because of our logs, the second because of the browser's default behavior. After this commit, we prevnt the browser to apply its behavior. 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#186566
Before this commit: When a user creates multiple scheduled activities and clicks the "Close" button the newly created activities are not updated in the activity view. After this commit: When a user creates multiple scheduled activities and clicks the "Close" button, the newly created activities should update and visible in the activity view. Task-4057815 Forward-Port-Of: odoo/odoo#186615 Forward-Port-Of: odoo/odoo#180304
Original PR description
Before this commit: When a user creates multiple scheduled activities and clicks the "Close" button the newly created activities are not updated in the activity view. After this commit: When a user creates multiple scheduled activities and clicks the "Close" button, the newly created activities should update and visible in the activity view. Task-4057815 Forward-Port-Of: odoo/odoo#186615 Forward-Port-Of: odoo/odoo#180304
In large database, the compute of the field l10n_it_payment_method and l10n_it_document_type can raise a timeout. Step to reproduce: - On a large database (tested with +10M account.move), try to install the module l10n_it_edi_ndd - The installation will raise a timeout New behavior: The fields l10n_it_payment_method and l10n_it_document_type will no longer be computed during module installation. This will avoid the timeout. opw-4273165 Forward-Port-Of: odoo/odoo#185266
Original PR description
In large database, the compute of the field l10n_it_payment_method and l10n_it_document_type can raise a timeout. Step to reproduce: - On a large database (tested with +10M account.move), try to install the module l10n_it_edi_ndd - The installation will raise a timeout New behavior: The fields l10n_it_payment_method and l10n_it_document_type will no longer be computed during module installation. This will avoid the timeout. opw-4273165 Forward-Port-Of: odoo/odoo#185266
Control panel breadcrumb tooltips aren't translated. This is because the tooltip is defined with a t-att-*, and dynamic attributes are never translatable. This commit redefines the tooltip in a different way that allows translation. opw-4160838 Community: https://github.com/odoo/enterprise/pull/72501 Forward-Port-Of: odoo/odoo#184555
Original PR description
Control panel breadcrumb tooltips aren't translated. This is because the tooltip is defined with a t-att-*, and dynamic attributes are never translatable. This commit redefines the tooltip in a different way that allows translation. opw-4160838 Community: https://github.com/odoo/enterprise/pull/72501 Forward-Port-Of: odoo/odoo#184555
**Steps to reproduce:** - Go to events > Configuration > settings > Enable "Use Event Barcode" - Then go to events > Select any event - Click on the gear icon > Print > Badge example **The issue originates from the "sample id" used for printing the badge example. Since it lacks single quotes, the system interprets it as an integer rather than a string, resulting in a traceback error during the printing process.** opw-4253212 Forward-Port-Of: odoo/odoo#186243
Original PR description
**Steps to reproduce:** - Go to events > Configuration > settings > Enable "Use Event Barcode" - Then go to events > Select any event - Click on the gear icon > Print > Badge example **The issue originates from the "sample id" used for printing the badge example. Since it lacks single quotes, the system interprets it as an integer rather than a string, resulting in a traceback error during the printing process.** opw-4253212 Forward-Port-Of: odoo/odoo#186243
rendererProps was not called on the component. This causes issues when assigning a variable on `this` and referencing it later. See: https://github.com/odoo/owl/commit/df59ec49aefce2e0913fdc1792d42b9680fb28b6 https://github.com/odoo/odoo/commit/f76955a5615cf7950c014c4f7a64d8f3aeafdda0 Forward-Port-Of: odoo/odoo#186970 Forward-Port-Of: odoo/odoo#186814
Original PR description
rendererProps was not called on the component. This causes issues when assigning a variable on `this` and referencing it later. See: https://github.com/odoo/owl/commit/df59ec49aefce2e0913fdc1792d42b9680fb28b6 https://github.com/odoo/odoo/commit/f76955a5615cf7950c014c4f7a64d8f3aeafdda0 Forward-Port-Of: odoo/odoo#186970 Forward-Port-Of: odoo/odoo#186814
Here is record is something like this ```py (Pdb) 0.3/0.1 2.9999999999999996 ``` after taking quotient becoming 2 ```py 0.3 ``` and after taking quotent it 3 ```py AssertionError: Lists differ: [[142[468 chars]63, '2'], [14264, '0.3'], [14265, '-37'], [142[12784 chars]-5']] != [[142[468 chars]63, '3'], [14264, '0.3'], [14265, '-37'], [142[12784 chars]-5']] First differing element 27: [14263, '2'] [14263, '3'] ``` For resolving this Idea is to backport this fix https://github
Original PR description
Here is record is something like this ```py (Pdb) 0.3/0.1 2.9999999999999996 ``` after taking quotient becoming 2 ```py 0.3 ``` and after taking quotent it 3 ```py AssertionError: Lists differ: [[142[468 chars]63, '2'], [14264, '0.3'], [14265, '-37'], [142[12784 chars]-5']] != [[142[468 chars]63, '3'], [14264, '0.3'], [14265, '-37'], [142[12784 chars]-5']] First differing element 27: [14263, '2'] [14263, '3'] ``` For resolving this Idea is to backport this fix https://github.com/odoo/odoo/pull/182265 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186912 Forward-Port-Of: odoo/odoo#186758
Gift cards would have a description in the original language of the creator and could never be changed. Adds the description field to the form view of the loyalty rewards even for gift cards and ewallet programs. opw-4177262 Forward-Port-Of: odoo/odoo#180509
Original PR description
Gift cards would have a description in the original language of the creator and could never be changed. Adds the description field to the form view of the loyalty rewards even for gift cards and ewallet programs. opw-4177262 Forward-Port-Of: odoo/odoo#180509
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#186755
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 Forward-Port-Of: odoo/odoo#186755
mrp: fix 2 state concerns correctly track production fields avoid recursion error --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185092
Original PR description
mrp: fix 2 state concerns correctly track production fields avoid recursion error --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185092
The aim of this commit is to prevent traceback when mapping local and eu taxes to oss taxes. Before the commit: If the company chart template to use resolves to a CoA coming from a module not installed, it will crash when trying to resolve the xml_id for that specific localization. After the commit: If the l10n module isn't installed, it won't try to reference any tax tag as the tax report line wouldn't be there anyway Note: 1) This case is unlikely as if the customer has a vat n
Original PR description
The aim of this commit is to prevent traceback when mapping local and eu taxes to oss taxes. Before the commit: If the company chart template to use resolves to a CoA coming from a module not installed, it will crash when trying to resolve the xml_id for that specific localization. After the commit: If the l10n module isn't installed, it won't try to reference any tax tag as the tax report line wouldn't be there anyway Note: 1) This case is unlikely as if the customer has a vat number for a specific country, it means they have a tax report to fill and thus must have installed the related localization either as main CoA or as a foreing fiscal position. 2) This was spotted through a runbot single l10n build error. Nevertheless, it is something that is possible and thus should be working smoothly. runbot-100532 Forward-Port-Of: odoo/odoo#186942
Steps to reproduce: [point_of_sale] - activate "Generate a code on ticket" option in PoS settings. - have a PoS session in GMT-6 and create an order after 6pm local time. - go to /pos/ticket, enter the order information and the date that appears on the ticket - ** No sale order found ** Cause The `date_order` of the sale order is stored in UTC while the date displayed on the ticket is in local time. Change This commit makes the search domain bigger to account for orders made in diff
Original PR description
Steps to reproduce: [point_of_sale] - activate "Generate a code on ticket" option in PoS settings. - have a PoS session in GMT-6 and create an order after 6pm local time. - go to /pos/ticket, enter the order information and the date that appears on the ticket - ** No sale order found ** Cause The `date_order` of the sale order is stored in UTC while the date displayed on the ticket is in local time. Change This commit makes the search domain bigger to account for orders made in different timezones. opw-4311152 Forward-Port-Of: odoo/odoo#186770