Tuesday, November 21, 2023
13 changes · 17.0
Resolved issues and error corrections
Clicking outside a popover now closes it without cancelling pending edits, so changes made in property definition popovers are applied as expected. The calendar view keeps its special behavior to avoid accidentally opening a record creation dialog.
Original PR description
Since commit 3d218e1, clicking outside a popover closes the popover and performs a preventDefault on the event. As a consequence, changes made in the property definition popover are no longer applied…
Since commit 3d218e1, clicking outside
a popover closes the popover and performs a preventDefault on the event. As a consequence, changes made in the property definition popover are no longer applied when the popover is closed by clicking outside.
Problem:
The preventDefault has the consequence of cancelling the input change event allowing the change to be applied to the property definition when the popover is closed.
Solution:
Remove the preventDefault by default and only use it in the case of the calendar view, which is the only use case that wants to prevent the click event so as not to open a record creation dialog (see commit 3d218e1).
How to reproduce the PropertyField bug:
- Go to a form view with a properties field
- Click on the edit property button
- A popover opens so that you can edit the field definition
- Type a few characters in the label input
- Click outside the popover
Before this commit:
The value inserted in the popover is ignored
After this commit:
The value inserted in the popover is applied to the property.
It is not possible to write a test reproducing this native browser behaviour.
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-prThis update fixes a problem where Point of Sale orders could lead to a blank screen when the Saudi localization module was installed. It also corrects receipt display when no rounding is applied, helping cashiers complete sales and provide accurate receipts reliably.
Original PR description
Before this commit, validating an order with the l10n_sa_pos module installed resulted in a blank screen. Additionally, there was an issue with the display of receipts when no rounding was applied. opw-3594564 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes an issue where edits made in a properties popover could be lost when the user clicked elsewhere to close it. The change keeps those edits applied while preserving the calendar behavior that prevents accidental record creation.
Original PR description
Since commit 3d218e10f8911f14e87981a91f0345ca630e29d5, clicking outside a popover closes the popover and performs a preventDefault on the event. As a consequence, changes made in the property…
Since commit 3d218e10f8911f14e87981a91f0345ca630e29d5, clicking outside a popover closes the popover and performs a preventDefault on the event. As a consequence, changes made in the property definition popover are no longer applied when the popover is closed by clicking outside.
Problem:
The preventDefault has the consequence of cancelling the input change event allowing the change to be applied to the property definition when the popover is closed.
Solution:
Remove the preventDefault by default and only use it in the case of the calendar view, which is the only use case that wants to prevent the click event so as not to open a record creation dialog (see commit 3d218e10f8911f14e87981a91f0345ca630e29d5).
How to reproduce the PropertyField bug:
- Go to a form view with a properties field
- Click on the edit property button
- A popover opens so that you can edit the field definition
- Type a few characters in the label input
- Click outside the popover
Before this commit:
The value inserted in the popover is ignored
After this commit:
The value inserted in the popover is applied to the property.
It is not possible to write a test reproducing this native browser behaviour.
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-prThis fixes a problem where time off accrual allocations created with very old start dates could calculate the next accrual date incorrectly. As a result, employee leave balances should no longer show incorrect future balances or gain extra days when the scheduled accrual process runs.
Original PR description
To reproduce the bug: - create an accrual allocation with the seniority plan - set the start date way in the past like in 2000 - validate the allocation - go on the dashboard, the accrued amount should be broken when setting the balance on a future date - additional days accrued if the cron is run Fix: nextcall being unset upon creation by default, the allocation would consider the start of the second level as the nextcall if the allocation is created in the past. This commits sets nextcall to a correct value if the lastcall is set in the past upon creation. 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
This fixes an issue where newly created stock movements could be moved out of their initial status too early. Keeping them in the right state ensures related stock replenishment rules can run as expected, reducing the risk of missed warehouse operations.
Original PR description
**Description of the issue/feature this PR addresses:** The "New" stock moves should not recompute state, otherwise the stock pull rule will not triggered for the moves. This pr fix an issue: https://github.com/odoo/odoo/issues/142633 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Webhook-triggered automated actions now receive the request payload and handle record lookup more reliably. This prevents errors when webhooks are called with record details and lets teams use webhook data in their automated Python actions.
Original PR description
Adds the payload to the eval_context of the triggered automated action so that it can be used in the python code. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an error that could occur when using webhook URLs to trigger actions on existing records. It also ensures missing records show the expected warning instead of causing another error, with tests updated to cover the corrected behavior.
Original PR description
**Step to reproduce:** - Create a webhook on any models with any action - Enter the webhook url in your browser and add ?id=1&_model=your.model (make sure the record exists in the database) **Issue:** - You get an error **Cause:** In the webhook the record_getter default value is wrong. The env is not available in the eval_context of the webhook Also the id is not casted to integer - Additional fix, in case no record is found the args for the warning are not in a tuple and it raises an error instead of the expected warning - Fix the tests to verify the default record_getter and the cast of the id in integer --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The journal report was incorrectly displaying debit amounts instead of the move line name/label in the first column. This fix restores the correct display of move line names, ensuring users see the expected information when reviewing journal reports.
Original PR description
The label of the first move line of the journal report has been broken, and is now showing the debit. This fix will revert that mistake so that it shows the name as expected. Forward-Port-Of: odoo/enterprise#50882
Fixed two issues with the follow-up email system in Accounting. The reply-to field configured in follow-up templates is now properly used when sending emails, and users will now correctly receive follow-up emails when they are added as recipients. These fixes ensure that follow-up communications are delivered reliably with the correct reply-to address.
Original PR description
Accounting > Configuration > Follow-up Levels Open any followup level configuration, access the template configuration Under 'Email configuration' tab fill reply-to field Send a followup email using this followup level Issue: reply-to field is not filled This occurs because the system never use the field from the template. Accounting > Follow-up Reports Select a partner in need of action Click "Follow up", the send mail wizard will open Add as recepient the current user Send Issue: User will not receive the email This occurs because without the context key 'mail_notify_author' the mail subsystem will avoid sending the email to the author opw-3575447 Forward-Port-Of: odoo/enterprise#50902 Forward-Port-Of: odoo/enterprise#50621
Fixed an issue where the timer start button was not appearing in the timesheet list view when grouping filters were applied. The timer now displays correctly regardless of whether rows are grouped or collapsed, improving the user experience when managing timesheets with filters.
Original PR description
**Steps:** - Open Timesheet - You can see the row of timer with Start Button - Choose Grid View and apply a Group By filter - Now go to the List View **Issue:** - When ListView is selected, the row with the timer consisting of the Start Button is not displayed. **Cause:** - In the list view because of the closed rows, the display timer doesn't get the data due to which the timer is not visible. **Fix:** - Added a different condition to showTimer instead of depending on display_timer field value in view which only gives the desire result when there is no group-by or group-by has at-least one section opened. **Task**-3387850 Forward-Port-Of: odoo/enterprise#51097 Forward-Port-Of: odoo/enterprise#50884
Fixed an issue where consolidation comparison reports displayed multiple columns without showing their corresponding time periods, making it impossible to distinguish between them. The fix adds period dates to the column headers and comparison field labels so users can clearly identify which data belongs to which period.
Original PR description
Issue: ====== When you add comparaison in consolidation it will not show the period in the display name so we are not able to distinguish between them. Steps to reproduce the issue: ============================= - Install consolidation - Install demo data for consolidation - Go to consolidation app and click on consolidated balance in the first test chart - Click on comparison and select test chart - You will see 2 columns that you can't distinguish between them. Solution: ========== - Added `display_dates` in the display in the comparaison field and in the headers fields. Before: ======  After: ====  opw-3514517 Forward-Port-Of: odoo/enterprise#51092 Forward-Port-Of: odoo/enterprise#48667
A bug in the Belgian POS blackbox module prevented the numpad from working correctly on the product screen, making it impossible to apply discounts or perform other numeric input operations. This fix corrects the underlying code error so the numpad functions as intended.
Original PR description
Prior to this commit, the override made on the method _setValue in the product screen was including a call to the parent method without the correct arguments leading to no behaviour when clicking on the numpad in the product screen when the pos_blackbox_be module was installed (e.g. when trying to do a discount). This commit fixes this error.
Users can now successfully delete draft approvals that have attached documents. Previously, attempting to delete a draft approval with attachments would fail with an error. The fix ensures attachments are properly removed before the approval record is deleted.
Original PR description
There is a business check on attachment unlink that needs to access approval state. This is why the attachment needs to be unlinked before the approval itself. steps to reproduce: - create a draft approval and attach a document - delete the approval. before this commit: odoo.exceptions.MissingError: Record does not exist or has been deleted. (Record: approval.request(8,), User: 2) after this commit: approval is deleted opw-3558437 Forward-Port-Of: odoo/enterprise#51095 Forward-Port-Of: odoo/enterprise#49681