Daily updates from Odoo
Navigate
Branch
Monday, June 10, 2024
56 changes
18 changes
Resolved issues and error corrections
Invoice tax totals now apply rounding consistently when calculating untaxed amounts with price-included fixed and percentage taxes. This prevents small one-cent discrepancies on displayed invoice totals, improving accuracy for accounting documents.
Original PR description
Suppose 2 lines of 21.53 having: t1: fixed tax of 1, incl in price, include base amount t2: 21% price included tax The price_subtotal is computed as 21.53 / 1.21 - 1 = 16.79. So the untaxed amount of the invoice is 16.79 * 2 = 33.58. However, 33.59 is displayed on the invoice tax_totals. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix cleans up the chatter recipient area so the checkbox, “To” label, and suggested recipients appear in the right order and alignment. It makes the messaging interface easier to read and use, especially when no recipient has been selected yet.
Original PR description
1. alignment of the checkbox and the "To" text; 2. when there is no recipient, the suggested recipient list should be displayed after the "To" text; 3. give a ps-1 class to the recipient text; before:  after:   --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
**Steps:** Go to Sales > Products > Products Move to the tab of attributes and variants Create a new attribute with display type as multi-checkbox Add only one value for the attribute created Click on the website stat button **Issue:** When multi-checkbox has single value, it is not displayed on website **Cause:** Attributes selection is hidden if there is only one value available and it's not a custom value **Fix:** Disabling the feature of hiding attributes with single value wh
Original PR description
**Steps:** Go to Sales > Products > Products Move to the tab of attributes and variants Create a new attribute with display type as multi-checkbox Add only one value for the attribute created Click on the website stat button **Issue:** When multi-checkbox has single value, it is not displayed on website **Cause:** Attributes selection is hidden if there is only one value available and it's not a custom value **Fix:** Disabling the feature of hiding attributes with single value when display type is multi-checkbox **Affected Version:** 17.0 ~ master **Task**-3753005 Forward-Port-Of: odoo/odoo#157243
Before this commit, when a product had multiple categories, it was shown in all its categories in the x/z reports. This commit changes the feature so that the product is only shown in one category (first in sequence). task-id: 3973199 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168171
Original PR description
Before this commit, when a product had multiple categories, it was shown in all its categories in the x/z reports. This commit changes the feature so that the product is only shown in one category (first in sequence). task-id: 3973199 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168171
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166788
Original PR description
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166788
This commit updates the logic to enable the modification of quantities for combo products in the cart. Task ID: 3872513 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167215 Forward-Port-Of: odoo/odoo#166695
Original PR description
This commit updates the logic to enable the modification of quantities for combo products in the cart. Task ID: 3872513 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167215 Forward-Port-Of: odoo/odoo#166695
Ukranian translation doesn't seem to be pulled from Transifex for some reason. This commit adds in the missing translation. Task-3956036 Enterprise: https://github.com/odoo/enterprise/pull/64106
Original PR description
Ukranian translation doesn't seem to be pulled from Transifex for some reason. This commit adds in the missing translation. Task-3956036 Enterprise: https://github.com/odoo/enterprise/pull/64106
Current behavior: --- Expiry dates are computed from today's date and expiration time, it should be based on scheduled date. Steps to reproduce: --- 1. Go to Inventory 2. Go to Configuration > Operations Types 3. Click on Receipts 4. Check "Show Detailed Operations" box 5. Check "Pre-fill Detailed Operations" box 6. Go back to Inventory > Products 7. Create a new product 8. Go to the Inventory tab 9. At Tracking, put "By lots" 10. Check "Expiration date" Box 11. At "Expiration D
Original PR description
Current behavior: --- Expiry dates are computed from today's date and expiration time, it should be based on scheduled date. Steps to reproduce: --- 1. Go to Inventory 2. Go to Configuration > Operations Types 3. Click on Receipts 4. Check "Show Detailed Operations" box 5. Check "Pre-fill Detailed Operations" box 6. Go back to Inventory > Products 7. Create a new product 8. Go to the Inventory tab 9. At Tracking, put "By lots" 10. Check "Expiration date" Box 11. At "Expiration Date" input 10 12. Go back to Inventory > Receipts 13. Make a new receipt 14. At "Scheduled Date" input a new date 15. At "Add a line" add the product 16. Expiration date is today + 10 17. It should be new date + 10 Fix: --- Replaced today with scheduled_date opw-3813132 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167834 Forward-Port-Of: odoo/odoo#164179
### Steps to reproduce: - Create a storable product with a vendor (in the pruchase tab) - Create a buy reordering rule with that vendor for that product - Select the reordering rule line and snooze it for one day - Create a sale order for #### > the snoozed reordering rule is triggered ### Cause of the issue: The `snoozed_untill` field of the orderpoint is not taken into account by the `_trigger_scheduler` to determine which auto-trigger orderpoint should be applied: https://gith
Original PR description
### Steps to reproduce: - Create a storable product with a vendor (in the pruchase tab) - Create a buy reordering rule with that vendor for that product - Select the reordering rule line and snooze it for one day - Create a sale order for #### > the snoozed reordering rule is triggered ### Cause of the issue: The `snoozed_untill` field of the orderpoint is not taken into account by the `_trigger_scheduler` to determine which auto-trigger orderpoint should be applied: https://github.com/odoo/odoo/blob/4f43eb2e69224c9cb271b6e2ca7533d929333985/addons/stock/models/stock_move.py#L2132-L2138 opw-3901613 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168201 Forward-Port-Of: odoo/odoo#165567
Issue: ====== Colorpicker disappears randomly when the selection is in the end column of the table. Steps to reptoduce the issue: ============================= - Go to notes - Add a table - Fill the first cell of the last column until the end - Select some content of the end of the text (we need the toolbar to have some part ouside the editable) - Try to change the color of the text/background - The toolbar disapears - You may need to do this multiple times to get the issue and
Original PR description
Issue: ====== Colorpicker disappears randomly when the selection is in the end column of the table. Steps to reptoduce the issue: ============================= - Go to notes - Add a table - Fill the…
Issue: ====== Colorpicker disappears randomly when the selection is in the end column of the table. Steps to reptoduce the issue: ============================= - Go to notes - Add a table - Fill the first cell of the last column until the end - Select some content of the end of the text (we need the toolbar to have some part ouside the editable) - Try to change the color of the text/background - The toolbar disapears - You may need to do this multiple times to get the issue and make sure to go to the toolbar by sliding the cursor over the visible right edge of the table first Origin of the issue: ==================== The right edge of the table is at the end of the editable so passing by it will trigger `_onMouseMove` which will detect that we are hovering on the td border of the table so it will add the class `o_col_resize` or `o_row_resize` to the editable. In `_updateToolbar` we check if we have one of those mentioned classes we don't show the toolbar so we hide it. That's why when hovering on a color in the colorpicker it will disappear. Note: The issue isn't always reproduceable because if we go so fast or so slow the hovering may not get detected or even get detected and then removed. Solution: ========= When we leave the editable, we toggle the resizeing classes if we are not in resizing state. opw-3950584 Forward-Port-Of: odoo/odoo#167480
go to Point of sales -> choose menu a pos -> view order -> choose order has state 'New' -> chooose '(update)' -> server error  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167302
Original PR description
go to Point of sales -> choose menu a pos -> view order -> choose order has state 'New' -> chooose '(update)' -> server error  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167302
A fix's term was changing during the fw-port, but it's pot file was not re-exported to match. Therefore, re-export so that it translates properly. Also note that apparently some records are re-named in Enterprise version and were exported into the pot file (wiping the community names). This commit attempted to re-add those COM names, but this conflicts with the CI to check that a model translation does not have more than 1 term (e.g. can't have different names for the same record). The
Original PR description
A fix's term was changing during the fw-port, but it's pot file was not re-exported to match. Therefore, re-export so that it translates properly. Also note that apparently some records are re-named in Enterprise version and were exported into the pot file (wiping the community names). This commit attempted to re-add those COM names, but this conflicts with the CI to check that a model translation does not have more than 1 term (e.g. can't have different names for the same record). Therefore we leave the already exported enterprise terms. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168165 Forward-Port-Of: odoo/odoo#167745
**Steps to reproduce:** (!!! Spanish EDI credentials required !!!) - Install l10n_es_edi_sii - Switch to a Spanish company (e.g. ES Company) - Configure Spanish Localization - Create an invoice - Process it by the ES E-invoicing service - Once processed, an electronic document containing the response of the E-invoicing service is created (i.e. jsondump.json) **Issue:** When sending the invoice via "SEND & PRINT" button, the "jsondump.json" file is added in the attachments. opw-37209
Original PR description
**Steps to reproduce:** (!!! Spanish EDI credentials required !!!) - Install l10n_es_edi_sii - Switch to a Spanish company (e.g. ES Company) - Configure Spanish Localization - Create an invoice - Process it by the ES E-invoicing service - Once processed, an electronic document containing the response of the E-invoicing service is created (i.e. jsondump.json) **Issue:** When sending the invoice via "SEND & PRINT" button, the "jsondump.json" file is added in the attachments. opw-3720984 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167950
Currently, no language was passed to the HR Attendance Kiosk, so it would default to English. This change passes the language of the company partner to the kiosk mode in order to allow companies having the portal in their own language. task-3976591 Forward-Port-Of: odoo/odoo#168343
Original PR description
Currently, no language was passed to the HR Attendance Kiosk, so it would default to English. This change passes the language of the company partner to the kiosk mode in order to allow companies having the portal in their own language. task-3976591 Forward-Port-Of: odoo/odoo#168343
Steps to reproduce: - insert a pivot in a spreadsheet - create a From/To global filter - leave the filter values empty - click on the Share button => boom because of `cell.value.toString()` `cannot read toString of undefined` opw-3971278 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168147
Original PR description
Steps to reproduce: - insert a pivot in a spreadsheet - create a From/To global filter - leave the filter values empty - click on the Share button => boom because of `cell.value.toString()` `cannot read toString of undefined` opw-3971278 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168147
**Current behavior before PR:** if a partner is a member of any channel (eg, whatsapp channel) it will be displayed in the command palette even if he does not have any associated user.which will cause issues as you can not chat with partner who do not have any dedicated user. **Desired behavior after PR is merged:** partners with no dedicated users will not be displayed in the command palette to chat with when you enter @. Task-3815150 --- I confirm I have signed the CLA and rea
Original PR description
**Current behavior before PR:** if a partner is a member of any channel (eg, whatsapp channel) it will be displayed in the command palette even if he does not have any associated user.which will cause issues as you can not chat with partner who do not have any dedicated user. **Desired behavior after PR is merged:** partners with no dedicated users will not be displayed in the command palette to chat with when you enter @. Task-3815150 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166220 Forward-Port-Of: odoo/odoo#159239
Tour 'shop_buy_product' checks the correctness of manipulating products and their quantities in the cart and the payment step of the order. With the additional check on the payment step introduced by commit 023d549 the tour was failing due to the relatively late rpc request handling compared to immediate clicks of the tour. `shop/payment` page was rendered faster than the update cart rpc (`shop/cart/update_json`) was processed. Cart update resets the delivery method on the order causing t
Original PR description
Tour 'shop_buy_product' checks the correctness of manipulating products and their quantities in the cart and the payment step of the order. With the additional check on the payment step introduced by commit 023d549 the tour was failing due to the relatively late rpc request handling compared to immediate clicks of the tour. `shop/payment` page was rendered faster than the update cart rpc (`shop/cart/update_json`) was processed. Cart update resets the delivery method on the order causing the validation error. That is why the tour is split in 2 separate functional parts. Forward-Port-Of: odoo/odoo#166670
Reproduce: * Create a database without demo data * Complete some information related to the main company (i.e. from the database manager form) * Install `account` * In the settings, in debug mode, trigger the installation of the demo data manually Result: The data manually set on the company is overridden to be in US, making the demo data of `account` lose its localized aspect. If for some reason the CoA could not be reloaded, we even don't have any demo at all because `try_loading` won'
Original PR description
Reproduce: * Create a database without demo data * Complete some information related to the main company (i.e. from the database manager form) * Install `account` * In the settings, in debug mode, trigger the installation of the demo data manually Result: The data manually set on the company is overridden to be in US, making the demo data of `account` lose its localized aspect. If for some reason the CoA could not be reloaded, we even don't have any demo at all because `try_loading` won't do anything at all. Solution: Do not override value possibly set by the user in the database configuration. We use the company name as a heuristic. If there is already a chart template installed (because the installation of a `l10n` module triggered it), then we try to load the dynamic demo data when loading the demo XML file. Forward-Port-Of: odoo/odoo#168232 Forward-Port-Of: odoo/odoo#166315
1 change
Resolved issues and error corrections
This update fixes a previous issue where the HR Attendance Kiosk always displayed in English. Now, the kiosk automatically uses the company's preferred language, ensuring a more localized and user-friendly experience for employees accessing attendance records.
Original PR description
Currently, no language was passed to the HR Attendance Kiosk, so it would default to English. This change passes the language of the company partner to the kiosk mode in order to allow companies having the portal in their own language. task-3976591 Forward-Port-Of: odoo/odoo#168343
22 changes
New functionality added to Odoo
Adds a Denmark-specific EC sales list report so businesses can prepare the information required by Danish authorities. The report includes a CSV export, making it easier to submit or share the data in the expected format.
Original PR description
Denmark government need a way to get ec sales. So now we have a report dedicated to denmark with an export to a CSV format task: 3756548
Enhancements to existing features
Time off allocation approvals now support a second approval step, allowing organizations to use a clearer two-level validation process. Allocation approval settings are aligned with time off approvals, and designated employee approvers can manage allocations from the management menu.
Original PR description
This commit introduces several improvements to the allocation management process: - A new state, "Second Approval" is added to streamline the approval process for time off allocations, enabling a two-tier validation mechanism. - Approval settings for allocations are now similar to time off, providing approval requirements for both time off officer and manager. - Employee approvers can now manage allocations under the management menu item. Task-3776596
The fleet salary configurator now uses a more realistic default threshold of 5 available cars for new vehicle request warnings instead of 1000. Available car counts also exclude vehicles in stages hidden from offers, and the setting now includes clearer guidance for administrators.
Studio now shows all available fields immediately when users create a related field, instead of initially limiting the list to linked-record fields. This makes configuration faster and reduces confusion for users setting up custom fields.
Original PR description
Specification: When a related field is created with Studio, the list only displays the (M2O) fields. If a field is selected, then all fields become available. Observed behavior: the list only displays the M2O fields Expected behavior: All the fields should directly be available while creating related field in studio. Task-3821059
Offer records now show direct navigation buttons based on signature progress. Users can quickly open the pending signature request for partially signed offers or jump to the related contract once an offer is fully signed, reducing manual searching and follow-up time.
Original PR description
Add smart button "Requested Signature" for offers in "Partially Signed" state, linking to the pending sign request. Implement "Contract" smart button for offers in "Fully Signed" state, directing to the contract form view. Task-3750988
Managers can now delete employee appraisals that are still waiting for confirmation, even if they do not have broader appraisal administration rights. This helps teams clean up draft or incorrect appraisal records more easily while keeping the change limited to unconfirmed appraisals.
Original PR description
This commit enables a manager, even without specific appraisal rights, to delete appraisals when they are in the "to confirm" state. Task-3777667
Resolved issues and error corrections
The spreadsheet pivot menu now shows the global filter option only for pivot header cells, preventing users from seeing an action that does not apply to regular pivot formulas. This reduces confusion and keeps spreadsheet filtering behavior aligned with the intended pivot workflow.
Miscellaneous changes
Update deferred entries settings text to be clearer and consistent with surrounding settings text updated in: https://github.com/odoo/odoo/pull/164539 task-3908720 Forward-Port-Of: odoo/enterprise#62039
Original PR description
Update deferred entries settings text to be clearer and consistent with surrounding settings text updated in: https://github.com/odoo/odoo/pull/164539 task-3908720 Forward-Port-Of: odoo/enterprise#62039
The test "Future Open Ended record not displayed" could fail if for some reason the domain used to fetchData is computed 1 second or more after the mocked datetime has been applied. In that case the domain constructed in AttendanceGanttModel contains the open ended record and the second assertion fails. Here we choose a safer mocked datetime. see build https://runbot.odoo.com/runbot/build/63759517 Forward-Port-Of: odoo/enterprise#64207
Original PR description
The test "Future Open Ended record not displayed" could fail if for some reason the domain used to fetchData is computed 1 second or more after the mocked datetime has been applied. In that case the domain constructed in AttendanceGanttModel contains the open ended record and the second assertion fails. Here we choose a safer mocked datetime. see build https://runbot.odoo.com/runbot/build/63759517 Forward-Port-Of: odoo/enterprise#64207
Since [1] the button never rendered due to the getter `showAddLeaveButton` not properly bound to the component. [1]: https://github.com/odoo/enterprise/commit/d18639785e622d97102227103d62ddb3a2716be6 Forward-Port-Of: odoo/enterprise#64205
Original PR description
Since [1] the button never rendered due to the getter `showAddLeaveButton` not properly bound to the component. [1]: https://github.com/odoo/enterprise/commit/d18639785e622d97102227103d62ddb3a2716be6 Forward-Port-Of: odoo/enterprise#64205
*: l10n_mx_edi_pos, pos_preparation_display, pos_settle_due Before this commit: ---  After this commit: --- Revised graphical interface for payment screen and update test tours to match  task-3888884 Forward-Port-Of: odoo/enterprise#62250
Original PR description
*: l10n_mx_edi_pos, pos_preparation_display, pos_settle_due Before this commit: ---  After this commit: --- Revised graphical interface for payment screen and update test tours to match  task-3888884 Forward-Port-Of: odoo/enterprise#62250
Versions -------- - 15.0e+ Steps ----- 1. If current UTC time is before 11:00, set user tz to Pacific/Niue; 2. if current UTC time is after 11:00, set user tz to Pacific/Kiritimati; 3. go to Helpdesk; 4. enable timesheets for a helpdesk team; 5. open a ticket of that helpdesk team; 6. start timer; 7. stop timer; 8. create timesheet. Issue ----- The date of the timesheet is set to the UTC date instead of the user date, which is one day off. Cause ----- The wizard creating
Original PR description
Versions -------- - 15.0e+ Steps ----- 1. If current UTC time is before 11:00, set user tz to Pacific/Niue; 2. if current UTC time is after 11:00, set user tz to Pacific/Kiritimati; 3. go to Helpdesk; 4. enable timesheets for a helpdesk team; 5. open a ticket of that helpdesk team; 6. start timer; 7. stop timer; 8. create timesheet. Issue ----- The date of the timesheet is set to the UTC date instead of the user date, which is one day off. Cause ----- The wizard creating timesheets adds a `Datetime.now()` value to `date`, which defaults to UTC time. Solution -------- Remove this line, allowing timesheets to be created with the default value, which does get adjusted for user timezone. opw-3834908 Forward-Port-Of: odoo/enterprise#63806 Forward-Port-Of: odoo/enterprise#63073
Steps to reproduce: - Open planning - Create a recurrence task for a user - Click on the slot and select the recurrence option and click on delete Issue: - You can see that no matter what the option is selected in form it is not reflected in delete dialog confirmation. So in this commit the recurrence option is synced in deleted conformation dialog task:3850839 Forward-Port-Of: odoo/enterprise#60601
Original PR description
Steps to reproduce: - Open planning - Create a recurrence task for a user - Click on the slot and select the recurrence option and click on delete Issue: - You can see that no matter what the option is selected in form it is not reflected in delete dialog confirmation. So in this commit the recurrence option is synced in deleted conformation dialog task:3850839 Forward-Port-Of: odoo/enterprise#60601
The issue: Inside the function _l10n_co_edi_generate_xml, the variable 'tax' at line 272 will be overridden by the 'account.tax' record which leads to a traceback in the second iteration, saying 'account.tax' object doesn't have a 'get' attribute Expected behavior: To not throw a traceback and generate the xml opw-3899575 Forward-Port-Of: odoo/enterprise#63277 Forward-Port-Of: odoo/enterprise#62290
Original PR description
The issue: Inside the function _l10n_co_edi_generate_xml, the variable 'tax' at line 272 will be overridden by the 'account.tax' record which leads to a traceback in the second iteration, saying 'account.tax' object doesn't have a 'get' attribute Expected behavior: To not throw a traceback and generate the xml opw-3899575 Forward-Port-Of: odoo/enterprise#63277 Forward-Port-Of: odoo/enterprise#62290
In previous commit https://github.com/odoo/enterprise/commit/099531438fe9ef7b008a2b281780ed3ee2175692 we added a new tag check. As we tought it was empty for non-nordic countries, we thought it was fine to have it in first place but happens it is sometimes filled in other countries but not with the payment reference, as in Switzerland. We now check to fill payment_ref, in order: 1. NtryDtls>RmtInf>Ustrd 2. NtryDtls>RmtInf>Strd>CdtrRefInf>Ref 3. Ntry>AddtlNtryInf (was buggy before https://g
Original PR description
In previous commit https://github.com/odoo/enterprise/commit/099531438fe9ef7b008a2b281780ed3ee2175692 we added a new tag check. As we tought it was empty for non-nordic countries, we thought it was fine to have it in first place but happens it is sometimes filled in other countries but not with the payment reference, as in Switzerland. We now check to fill payment_ref, in order: 1. NtryDtls>RmtInf>Ustrd 2. NtryDtls>RmtInf>Strd>CdtrRefInf>Ref 3. Ntry>AddtlNtryInf (was buggy before https://github.com/odoo/enterprise/pull/62703) 4. NtryDtls>RmtInf>Strd>AddtlRmtInf opw-3923665 opw-3971080 opw-3932651 opw-3918491 Forward-Port-Of: odoo/enterprise#64004
When the send receipt button is displayed in the receipt screen, it overflows the screen. This commit fixes the issue. Forward-Port-Of: odoo/enterprise#63988
Original PR description
When the send receipt button is displayed in the receipt screen, it overflows the screen. This commit fixes the issue. Forward-Port-Of: odoo/enterprise#63988
Button draft was not display on received vendor bills. opw-3903120 Forward-Port-Of: odoo/enterprise#64020
Original PR description
Button draft was not display on received vendor bills. opw-3903120 Forward-Port-Of: odoo/enterprise#64020
task-3597205 Forward-Port-Of: odoo/enterprise#63869 Forward-Port-Of: odoo/enterprise#59539
Original PR description
task-3597205 Forward-Port-Of: odoo/enterprise#63869 Forward-Port-Of: odoo/enterprise#59539
…on report steps to reproduce: - add new appraisal of employee and confirm it. - add new skills and update existing ones. - check the skill evaluation report issue: A newly created skill doesn't appear in the report since the previous skill level may contain null while creating new records. fix: Apply a left join on the report so that it can provide accurate results. also, add a subquery based on the last completed appraisal, since the last `appraisal_id` is updated on the pending
Original PR description
…on report steps to reproduce: - add new appraisal of employee and confirm it. - add new skills and update existing ones. - check the skill evaluation report issue: A newly created skill doesn't appear in the report since the previous skill level may contain null while creating new records. fix: Apply a left join on the report so that it can provide accurate results. also, add a subquery based on the last completed appraisal, since the last `appraisal_id` is updated on the pending state too. task-3810220 Forward-Port-Of: odoo/enterprise#64035 Forward-Port-Of: odoo/enterprise#60088
Purpose: -------- The frontend room view uses the "background-image" property to add a background image if one has been set on the room. This causes several 404 errors in qunit tests because the test room does not exist, resulting in a "room not found" exception when the browser tries to get the background image. This commit patches the view in the tests to remove the url part of the background-image property, so that the background image is not fetched anymore. In order to make th
Original PR description
Purpose: -------- The frontend room view uses the "background-image" property to add a background image if one has been set on the room. This causes several 404 errors in qunit tests because the test room does not exist, resulting in a "room not found" exception when the browser tries to get the background image. This commit patches the view in the tests to remove the url part of the background-image property, so that the background image is not fetched anymore. In order to make this patch possible, the background-image property value has been moved inside a getter. Task-3943099 Forward-Port-Of: odoo/enterprise#62990
The aim of this commit is to improve the perfomance of the datev features constrains checks. Context: Performance issue spotted on odoo.com prod. DB. Before the commit: Creating a partner takes up to 10 min. After the commit: Creating a new partner reduces the creation time to 2 min. task-id: None Forward-Port-Of: odoo/enterprise#64158 Forward-Port-Of: odoo/enterprise#63971
Original PR description
The aim of this commit is to improve the perfomance of the datev features constrains checks. Context: Performance issue spotted on odoo.com prod. DB. Before the commit: Creating a partner takes up to 10 min. After the commit: Creating a new partner reduces the creation time to 2 min. task-id: None Forward-Port-Of: odoo/enterprise#64158 Forward-Port-Of: odoo/enterprise#63971
Steps to reproduce: - Run fetching payslip without provide the tax code in Odoo taxes Current behaviour: - Exception raised Expected behaviour: - Should not raise any exception Explanation: next() method is missing default value so it raised exception when filtering return empty array and iter() returns None. task-3897198 Forward-Port-Of: odoo/enterprise#64072 Forward-Port-Of: odoo/enterprise#62432
Original PR description
Steps to reproduce: - Run fetching payslip without provide the tax code in Odoo taxes Current behaviour: - Exception raised Expected behaviour: - Should not raise any exception Explanation: next() method is missing default value so it raised exception when filtering return empty array and iter() returns None. task-3897198 Forward-Port-Of: odoo/enterprise#64072 Forward-Port-Of: odoo/enterprise#62432
15 changes
New functionality added to Odoo
A new Rhodes module has been created and added to the Odoo system. This module extends Odoo's functionality with new capabilities specific to Rhodes operations. The addition enables users to access Rhodes-related features within their Odoo environment.
Original PR description
Creation of Rhodes module 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
Enhancements to existing features
The salary configurator now intelligently handles document uploads by only requiring new files when they don't already exist on the contract. If a document is already on file, employees will simply see the existing file instead of being asked to upload it again. This reduces unnecessary re-uploads and streamlines the salary setup process.
Original PR description
Document fields in the salary configurator now check for existing files on the current contract. Fields are set to required only if no associated file is detected on the contract, otherwise we just show the already existed file. Task-3468245
This update prevents employees from deleting leave records for future periods when a payslip has already been generated and paid for that time. This protects payroll integrity by ensuring leave data remains consistent with finalized payroll records.
Original PR description
Employees should not be able to delete leaves in the future when there's a payslip generated and paid for that period. Task-3776411
Resolved issues and error corrections
Fixed a bug in the Planning module that prevented users from assigning a resource to multiple scheduling slots at once. Previously, attempting to select multiple empty slots and assign a resource would cause an error. This update allows the resource assignment feature to work correctly with multiple slots, improving the user experience when managing schedules.
Original PR description
Steps to reproduce: - Install Planning - Click on Schedule -> By Resource - Select multiple slots without a resource - Select a resource to add Issues: A traceback is shown because this line in the write function wasn't coded to work with recordset. https://github.com/odoo/enterprise/blob/70f0ce78ac5f976f93abd0b9ee239a998d6d7445/planning/models/planning.py#L803-L806 opw-3948517 Forward-Port-Of: odoo/enterprise#63450
A bug in the helpdesk module was causing unwanted email addresses to be added as ticket followers when multiple email domains were used. This fix ensures that only legitimate emails are added as followers by properly filtering out the helpdesk team's email alias, regardless of which domain it uses. This prevents confusion and keeps ticket follower lists clean and accurate.
Original PR description
With the introduction of alias domains in 17.0 an issue was uncovered in the helpdesk module where any additional alias names with different domains would be added as followers. This stemmed from an issue in _ticket_email_split which was not properly filtering emails out that matched the alias name because self was not yet defined when the method was called. This was not a problem before because this was immediately fed into _mail_find_partner_from_emails that would also filter out by alias_name. This is no longer the case because the domain has to also match. Passing in the newly created ticket and using this to map to team_id.alias_name fixes this issue by properly filtering out alias emails even with different domains. opw-3920634
This update corrects how Greece is identified in Dutch intrastat and tax reports. Greece uses different codes depending on the context—the ISO standard code (GR) versus the European Union code (EL). Since these are European reports, the EU code is now used consistently, ensuring accurate reporting for transactions involving Greece.
Original PR description
For Greece, the ISO 3166 code (GR) and European Union code (EL) is not the same. Since this is a european report, we need the European Union code. opw-3890635 Forward-Port-Of: odoo/enterprise#64087
This fix prevents spreadsheets from becoming unusable after users perform many large operations. The system now creates automatic snapshots every 2 hours instead of every 12 hours, which reduces the amount of data the server needs to load when reopening a spreadsheet. This prevents memory issues that could occur when handling very large spreadsheets with extensive edit histories.
Original PR description
Purpose ------- Let's say a user works a lot on a spreadsheet and performs a lot of heavy operations generating very large revisions (with lots of commands), such as copy-pasting a very large zone (there's one UPDATE_CELL command per copy-pas cell) If the user does multiple such very large revision, one after the other, every thing is fine client side. The next time the spreadsheet is open though: the server needs to load all those revisions to send them to the client. The revisions can be so large it can blow up the server memory limit. The spreadsheet cannot be open anymore. Solution -------- In this commit, we increase the number of snapshot by snapshotting more often. Previously, we used to snapshot when opening a spreadsheet and no activity was done in the spreadsheet in the last 12 hours. It's reduced to 2 hours in this commit. The reason we don't want to snapshot too often is that it kills the local history (CTRL+Z) of connected users. Task: 3940465
Fixed a bug where US payment files generated after 5 PM in Pacific timezone would incorrectly show tomorrow's date in the File Creation Date field. The system now correctly uses the user's local timezone when setting this date, ensuring accurate file timestamps regardless of when the file is created.
Original PR description
When a user in US/Pacific generates a file after 17:00 the File Creation Date field incorrectly has tomorrow's date. To fix it use the localized timestamp for the File Creation Date as well. opw-3942095 Forward-Port-Of: odoo/enterprise#64172
This fix resolves an issue where generating a bill in a restaurant Point of Sale would incorrectly send the order to the kitchen. The change removes unnecessary kitchen order processing during the billing step, ensuring orders only go to the kitchen when actually needed for food preparation.
Original PR description
Problem: In restaurant, when we make a bill, the order is made to the kitchen Steps to reproduce: - Install "Point of Sale" app and "pos_restaurant" and "pos_preparation_display" modules - Open a restaurant session - Select products for a table - Click on "Bill" - The order is now in the kitchen while it should not Cause: The full process for making an order is called with "sendOrderInPreparationUpdateLastChange" while it is not necessary to make a bill Solution: Remove the "sendOrderInPreparationUpdateLastChange" for the bill screen when pos_preparation_display is installed Note: Linked with this PR: https://github.com/odoo/odoo/pull/166844 opw-3938924
This fix corrects how payment references are extracted from bank statement files (CAMT format) across different countries. Previously, a field that is sometimes populated in non-Nordic countries like Switzerland was being checked first, causing incorrect or missing payment references. The fix reorders the priority of where to look for payment information to ensure the most reliable reference is captured first, improving the accuracy of imported bank transactions.
Original PR description
In previous commit https://github.com/odoo/enterprise/commit/099531438fe9ef7b008a2b281780ed3ee2175692 we added a new tag check. As we tought it was empty for non-nordic countries, we thought it was fine to have it in first place but happens it is sometimes filled in other countries but not with the payment reference, as in Switzerland. We now check to fill payment_ref, in order: 1. NtryDtls>RmtInf>Ustrd 2. NtryDtls>RmtInf>Strd>CdtrRefInf>Ref 3. Ntry>AddtlNtryInf (was buggy before https://github.com/odoo/enterprise/pull/62703) 4. NtryDtls>RmtInf>Strd>AddtlRmtInf opw-3923665 opw-3971080 opw-3932651 opw-3918491 Forward-Port-Of: odoo/enterprise#64004
This update prepares the Belgian POS blackbox system for Version 17 certification with several operational improvements. Key changes include removing the reprint option from the tip screen, enabling invoicing of previously non-invoiced orders, and allowing order cancellations that were previously restricted. The system now automatically handles work clock in/out, supports cash in/out operations, and ensures accurate sequence numbering on receipts and logs.
Original PR description
In anticipation of Version 17 certification, multiple adjustments were required. The option to reprint tickets has been eliminated from the tip screen. Furthermore, the functionality on this screen has been rectified to enable the invoicing of previously non-invoiced orders. Previously, this action was not feasible when an order was placed using a blackbox. This commit also involves alterations to values within the sale details template. Moreover, steps have been taken to guarantee the precision of sequences for both pro forma and standard sales. We've now enabled the option to cancel orders that were previously restricted.
This update fixes a bug where the system incorrectly rejected valid UTM source names as duplicates. The issue occurred when users deleted marketing templates but the associated tracking names remained in the system. The fix ensures the system properly checks for existing names across all tracking records, not just active templates, preventing false duplicate errors.
Original PR description
With this commit whenever utm.source name is written it will check its uniquness (generating a unique name if necessary). [Reproduce] - Install marketing_automation - Have Campaign with a Template: -…
With this commit whenever utm.source name is written it will check its uniquness (generating a unique name if necessary). [Reproduce] - Install marketing_automation - Have Campaign with a Template: - Access the Campaign's Template and go to the Settings tab. - Note down the NAME of the `utm.source` (found in the Advanced section, under the field "Name"). - Delete this template (which will also delete associated `mailing.mailing` records.) - Create new template (by returning to the Campaign form, opening an activity, creating template) - Open the Campaign's Template: - Disable read-only on the Name field in Advanced section (modify the `mailing.mailing.form` view). - Change its name to the previously noted `utm.source` NAME. - Save -> BUG: Trackback "The name must be unique" [Why this bug happens?] When you delete a template (`mailing.mailing`) related to a `utm.source`, the `utm.source` will still exist. Then, when attempting to change the `utm.source` name, the system is supposed to detect if the name already exists and generate a new unique name if necessary. However, due to the mechanism utilized in the function (ref.1), which searches for existing names based on existing templates (`mailing.mailing`), which you have deleted, the existing `utm.source` NAME won't be found. Consequently, the function mistakenly believes the name is unique and doesn't generate a new name, leading to the encountered error. (ref.1) `UtmMixin._get_unique_names` https://github.com/odoo/odoo/blob/205caa3d6539187009a8b8bbd1557e75fe045ff3/addons/utm/models/utm_mixin.py#L77 opw-3835704 Forward-Port-Of: odoo/enterprise#63993 Forward-Port-Of: odoo/enterprise#63360
This update fixes a reliability issue with the WhatsApp message unread counter that was not accurately tracking unread messages. The fix ensures that users see the correct number of unread messages in their WhatsApp conversations, improving the accuracy of message notifications and helping users stay on top of their communications.
Original PR description
opw-3877370 community: https://github.com/odoo/odoo/pull/165955
This fix resolves a critical error that prevented users from updating payments after creating and signing PPD invoices and external trade documents in the Mexican localization module. The issue caused the system to crash when attempting to process payment updates, which is now corrected to ensure smooth payment workflows.
Original PR description
Currently, a traceback with `KeyError: 'emisor'` occurs when attempting to update payments after creating and signing a PPD and external trade invoice, and registering a payment. opw-3904458
This update fixes a crash that occurred when users tried to access call activities that had been removed from the Call Queue. The system now properly updates the record when a call activity is deleted, ensuring the interface refreshes correctly and prevents errors when clicking on removed activities.
Original PR description
When call activity gets deleted, the record has to be updated so that it can trigger automatic re-rendering of the component. Steps to reproduce: - on crm lead schedule call activity and make sure that activity is at least 1 month old - book activity and save it - add it to `Call Queue` - remove it from `Call Queue` - try to access it/click on it