Friday, June 21, 2024
9 changes · 17.0
New functionality added to Odoo
This update adds support for the Banco Central Uruguayo (BCU) as a new currency exchange rate provider for Uruguay. Users can now automatically fetch live currency rates directly from Uruguay's central bank, improving the accuracy and timeliness of currency conversions for businesses operating in or with Uruguay.
Resolved issues and error corrections
This fix resolves an issue where deferred accounting entries were not properly handled when a lock date was set and a move was reset to draft and reposted. The system now correctly links reversal entries to the original move and uses the proper accounting date, preventing errors when reposting moves with deferred expenses or income.
Original PR description
Steps to reproduce: ------------------- 1. Create a move with date = 01/01/24, start = 01/06/23, end = 31/05/24. 2. Post the move, the deferred entries are created 3. Set the All User Lock Date to…
Steps to reproduce: ------------------- 1. Create a move with date = 01/01/24, start = 01/06/23, end = 31/05/24. 2. Post the move, the deferred entries are created 3. Set the All User Lock Date to 31/12/23 4. Reset the move to draft - The deferral moves of 2024 are deleted. - The deferral moves of 2023 are still linked to the move - The reversed deferral moves of 2023 are created but not linked to the move and they are dated on the 1st January (first day after the lock date) 5. Post the move again A traceback is raised because of an assert that verifies that we shouldn't regenerate deferral entries if a move already has them. Solution: --------- 1. The generated reversal of the deferrals of 2023 should be linked to the move. 2. Now that this is done, we can remove the assert because all deferral entries will cancel out each other (i.e. the aggregation will result in no deferral entries). 3. When reverting, we will now use the accounting date instead of the first day after the lock date (if there is one) opw-3861179 https://github.com/odoo/odoo/pull/164316
This update fixes an issue where the Recurring Revenue field was displaying in reports even when the feature was disabled in settings. Now the field will only appear when the Recurring Revenue feature is actually enabled, ensuring a cleaner and more accurate user experience that matches the configured settings.
Original PR description
**Before this PR:** Some fields are associated with groups in XML files, but they are visible even though the groups are disabled. (Recurring Revenue is not ticked in settings, i.e., the feature is not activated). **After this PR:** recurring_revenue fields in the measure will only be visible when it is ticked in settings, i.e., only when the feature is activated. Task-3810415 Forward-Port-Of: odoo/enterprise#60228
This fix resolves an issue where warehouse staff couldn't open certain pickings in the Barcode app. The problem occurred when a product had both a kit bill of materials and product packaging configured. The barcode system now properly loads all required packaging information upfront, allowing these pickings to be processed without errors.
Original PR description
**Current behavior:** A picking with a move for a product with kit BOM that also has some product packaging can be un-openable in Barcode. **Expected behavior:** Any picking should be able to be…
**Current behavior:** A picking with a move for a product with kit BOM that also has some product packaging can be un-openable in Barcode. **Expected behavior:** Any picking should be able to be processed in Barcode. **Steps to reproduce:** *Enable product packagings* 1. Create a storable product with a kit BOM and a product packaging 2. Make some picking that has a move for the new product, confirm it so the moves for the kit components are created 3. Add stock move lines for each of the moves, fill out their `qty_done` field with the required amount 4. Save the picking record, go into Barcode 5. Try to open the picking -> trace back **Cause of the issue:** The Barcode client tries to read the package record of the BOM product/product template but it was never fetched into the barcode cache. **Fix:** Ensure any packaging record that could have an attempted access is fetched by the barcode client `onWillStart()`. opw-3895426 Forward-Port-Of: odoo/enterprise#64750 Forward-Port-Of: odoo/enterprise#64024
The rental schedule gantt view was only showing rental products that had existing orders, instead of displaying all available rental products. This fix ensures that when the total number of rental products is below the system limit, all products are displayed in the schedule view, providing users with a complete view of their rental inventory.
Original PR description
**Steps to reproduce:** - Install Rental module - Check gantt view in Rental > Schedule **Current behavior before PR:** We are just showing the products that has orders. This is happening because in…
**Steps to reproduce:** - Install Rental module - Check gantt view in Rental > Schedule **Current behavior before PR:** We are just showing the products that has orders. This is happening because in those commit https://github.com/odoo/enterprise/pull/37757/commits/0c2f235d4876467df287f30ab3cb09785603cd7f https://github.com/odoo/enterprise/pull/37757/commits/836909419893b522890776d3ec2f16476ae21108 we introduced the group limit and get_gantt_data and rental_schedule has not get adapted with this new behaviour. So what is happening is that '_read_group_product_ids' https://github.com/odoo/enterprise/blob/17.0/sale_renting/report/rental_schedule.py#L20 is not called as there is a limit so https://github.com/odoo/enterprise/blob/17.0/web_gantt/models/models.py#L76 This computes to be False so https://github.com/odoo/odoo/blob/17.0/odoo/models.py#L2745:L2754 '_read_group_fill_results' will not get called to call '_read_group_product_ids' **Desired behavior after PR is merged:** After override 'get_gantt_data' we are now checking if all products count is more than the limit we just return the products that already have orders. **Other solution:** We might just remove the group_limit https://github.com/odoo/enterprise/blob/17.0/sale_renting/report/rental_schedule_views.xml#L54 and just go with the '_read_group_product_ids'. opw-3959031
This fix restores the default recipient addresses in follow-up email templates. Previously, when users cleared the "To (Partners)" field in a template and saved it, the addresses would not reappear when reopening the follow-up report. The fix reintroduces the default value logic to ensure recipient addresses are properly populated.
Original PR description
### Steps to reproduce the issue: 1. Go to _Accounting > Customers > Follow-up Reports_ select one of the reports 2. Click on "Follow up" 3. Open the template in the Content Template field 4. Empty the To (Partners) field in this template 5. Save and close 6. Close the Follow Up and reopen it 5. There is no address in the field ### Explanation: With previous fix, we removed the `default_get` value but did not add a default one in the compute. ### Suggested fix: The default value will be the same as the one previously in `default_get`. The purpose is to restore the previous workflow and then add the template's values. opw-3878125 Forward-Port-Of: odoo/enterprise#65038 Forward-Port-Of: odoo/enterprise#64902
This fix prevents customers from booking appointments on dates that have all-day events synced from Google Calendar. Previously, all-day events were incorrectly excluded from availability checks, allowing double-bookings. The fix adjusts how the system searches for conflicting events to properly include all-day events that overlap with requested appointment times.
Original PR description
Versions -------- - 15.0+ Steps ----- 1. Sync with Google Calendar; 2. create a recurrent all day event in google calendar; 3. make sure it shows as "busy"; 4. make an appointment via website on that…
Versions -------- - 15.0+ Steps ----- 1. Sync with Google Calendar; 2. create a recurrent all day event in google calendar; 3. make sure it shows as "busy"; 4. make an appointment via website on that day. Issue ----- You are allowed to make an appointment on slots that overlap the synced event. Cause ----- Recurrent day events synced via Google Calendar have their start & end date equal to each other, so the event's "end date" could be 24 hours before the actual end. Commit ad4219876cee4f4b996a7cc72fd176b51be3a063 added an the `_slot_availability_prepare_values_meetings` method, optimized to not include conditions on `start_date` and `allday`. Instead, it filters event by date ranges. In our scenario, an `allday` event with start & end dates set to something like `2022-02-14 00:00:00`, may get excluded from the search when this is also the value of the starting point of the search, due to `stop` not being strictly greater than the starting point. Solution -------- Do an inclusive range search instead of an exclusive one. opw-3793009 Forward-Port-Of: odoo/enterprise#65023 Forward-Port-Of: odoo/enterprise#63761
This update fixes a bug that prevented users from closing their POS session when two employees were logged in simultaneously on different devices. The changes reorganize sales report logic to the blackbox module to ensure compliance with Belgian certification requirements.
Original PR description
This commit, combined with the partial revert of commit f5b1c9f1f966f4eec0a4000ee768f2782fd9a98f, moves the logic of the sales report needed for the certification to the blackbox module. It also solves a bug where users could not close the session if two users were clocked in at the same time on two different devices. Community PR: odoo/odoo#169993 Original Community PR: odoo/odoo#148155 Original Enterprise PR: odoo/enterprise#53654
This fix corrects how lunch breaks are calculated in the HR system. Previously, lunch times were being counted even when employees were on leave or during public holidays. Now the system properly excludes these periods, ensuring accurate lunch break records for payroll and attendance tracking.
Original PR description
Currently when we look at lunch times, we do not take leaves into account, resulting in lunch-time being computed when you have public holidays or time off