Daily updates from Odoo
Wednesday, October 16, 2024
17 changes
2 changes
Resolved issues and error corrections
This fix ensures invoice tax is calculated from the same rounded base amount shown as the tax-excluded total. It prevents small mismatches in tax totals, such as a one-cent difference, when global rounding is used with discounted invoice lines.
Original PR description
### Steps to reproduce the issue: 1. Make sure the Rounding Method is set to "Round Globally" 2. Have a Tax of 21% 3. Create a Product with sale price 5.75 and set the Sale Tax 4. Create an Invoice and add 6 lines with the Product 5. For each line, set the quantity to 5 and add an 18% discount 6. The Tax Amount is of 29.70 when the Total Tax Excluded is of 141.48 (141.48 * 21% ~= 29.71) ### Explanation: Since 17.2, the base amount of a tax is not rounded before the calculation of the tax amount, this creates an issue where the base amount and `amount_untaxed` are different when `tax_calculation_rounding_method` is set to 'round_globally'. (e.g.: 141.45 vs 141.48) ### Fix reasoning: `raw_price` is rounded out if `precision_rounding` is specified to avoid rounding to unit, it will replace all occurences of `price_unit * quantity` in the tax calculation. opw-4136024
The calendar library used by Odoo was updated to prevent a crash when viewing tasks with back-to-back scheduling. This improves reliability for users working with project and timesheet calendars, especially around dense task schedules.
Original PR description
Steps to reproduce: - Install Timesheet - Delete all tasks - Run server actions to create tasks with the following scripts https://gist.github.com/mattismegevand/5db26ee9d1e7756e7fe4600897244c1e - Go to Project -> Tasks -> All tasks - Switch to calendar view and go to june 2024 Issues: A traceback appears, the cause is an infinite recursion caused by the computation of the intersection. Since two events are next to each other their intersection is null but fullcalendar try to compute it anyway which leads to the intersection span being null which causes a traceback. I suspect that the fix is https://github.com/fullcalendar/fullcalendar/commit/362a37345a4b7cb65d16f345e8555f727f1c8450 However for good measure and to fix preemptively other bug from fullcalendar an update seems like the best decision. opw-3997810
2 changes
Resolved issues and error corrections
A new shop floor setting lets manufacturers control how many work order cards are shown at once. This helps teams keep the screen focused and easier to use when many manufacturing orders are active.
Original PR description
…e shop floor
This update fixes how the Master Production Schedule handles ordering limits and lead times across different planning periods. It helps avoid misleading replenishment quantities, such as applying a monthly cap to a yearly view, and improves demand forecasts for components with lead times.
Original PR description
This PR contains the following commits: - [IMP] mrp_mps: hide Order buttons in non-default periods When the date type shown (year, month, week, day) is different from the one defined in the settings, we hide the order buttons. - [FIX] mrp_mps: disable max_to_replenish_qty in non-default period `max_to_replenish_qty` should only be applied for the period defined in the settings. Otherwise we have situation where a limit of 15 per month is applied for a whole year. - [FIX] mrp_mps: use real dates with lead times When a bom has a lead time, we want to use the real date to compute the indirect demand forecast of the components in the MPS. task 4172967
8 changes
Resolved issues and error corrections
This fixes the invoice print template so VAT amounts show correctly in the totals section when invoices with standard tax are sent or printed. Businesses using GCC invoice localization will see accurate tax totals on customer-facing documents.
Original PR description
Create an Invoice with a standard tax Send&Print Issue: In totals section VAT amount will be wrong opw-4256242 opw-4256566
This fixes website editing behavior for SVG shapes and illustrations that still use older file paths after the content moved to a new location. Business users will see the correct editing options, such as Dynamic Colors, while unsupported actions like cropping illustrations remain blocked as intended.
Original PR description
In [1] shapes and illustrations were moved to `html_editor`. While some features have been adapted to the new path, others did not. No upgrade script was created to convert existing `/web_editor/shape/` paths to new `/html_editor/shape/` paths. Instead, the old route was kept available. However, some conditions, selectors and domains that recognized those paths have not been adapted to detect both kinds of paths. This commit adapts those conditions, selectors and domains so that both kinds of paths are identified as being shapes or illustrations. Steps to reproduce: - Add an SVG illustration in a website page - Select it => The "Dynamic Colors" options were not displayed [1]: https://github.com/odoo/odoo/commit/44129d85bdc993e37384536519a03d7c29ac7e83 task-4052712
This fixes an ecommerce issue where choosing the same product in multiple combo options only added it once to the cart. Customers now get a separate cart line for each selected combo item, so orders better match what they selected and expect to receive.
Original PR description
When using combo products in ecommerce, if two of the combos contained the same product and they were selected, only one row with a quantity of 1 would be created. e.g. if a you had a double burger combo product and the combos looked like: - Burger 1: Cheeseburger, Double Cheeseburger, Chicken Burger - Burger 2: Cheeseburger, Double Cheeseburger Currently if you were to choose double cheeseburger in both options it would only add 1 burger with quantity of 1 to the basket. Ideally it should be following the same practise as sale orders and create a line per each item. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix restores lot and serial number information in Maintenance when Inventory is also installed. It avoids a dependency issue that could prevent the feature from working reliably in existing databases.
Original PR description
Commit [1] is using models and data from `stock` module but `maintenance` does not depend on this one. A bridge would not be a solution on stable, since existing DBs that have both `stock` and `maintenance` would just lose the feature (the bridge would not be auto-installed) [1] https://github.com/odoo-dev/odoo/commit/1f2a5806b832529bd2ec53a878991e04800079bf sentry-5964505411
This fix lets users select multiple cells in tables when editing HTML content in Firefox. It removes a browser-specific editing issue, making table editing more reliable for users who work in Firefox.
Original PR description
This is a forward port of [1] to html_editor Issue: ====== - We can't select multiple cells in a table Origin of the issue: ==================== - When selecting multiple rows or columns inside a table in firefox, firefox creates multiples ranges per table cell selected. Solution: ========= - The first time we encounter more than 1 range, we merge them together and we manually update the selection - After the manual upadte, firefox will not trigger selectionchange anymore when we move the mouse, to deal with that we just manually call `handleFirefoxSelection` in `mousemove` event. task-4240675 [1]: https://github.com/odoo/odoo/commit/541c8baa550f072530c3ab9b7d3a9c32e2e6f095
Customers who must log in before ordering event tickets will no longer lose their selected tickets after signing in. This prevents frustration and avoids forcing attendees to restart the booking process.
Original PR description
Steps to reproduce ==================== - Say logging is mandatory to order (website settings). - Log in as a visitor, pick some tickets, and fill in the attendee details. - Try to confirm. - You are redirected to the login page and then to the event. - Your tickets are lost and you need to start again. After this PR ================== The cart will be restored with the ticket picked up, after login. Task-4039974
Posting tax closings for foreign VAT reports no longer changes the company tax lock date. This prevents unnecessary restrictions and exceptions when businesses still need to post activity for other jurisdictions.
Original PR description
Before this commit, posting any tax closing would always set the tax lock date. This was a bit restrictive, and required making lock date exceptions in order to post operations for other non-closed reports. We alleviate that by only setting the tax lock date when the domestic closing is posted ; the idea being it's the main one. So, tax closings posted for other countries for which a foreign VAT fiscal position is defined do not affect the tax lock date anymore.
This update prevents Odoo from creating duplicate Avalara tax records when taxes share the same visible name but have different jurisdiction codes. It reduces billing and tax calculation interruptions by aligning how taxes are matched with Odoo's uniqueness rules.
Original PR description
We recently reworked the way taxes are named [1]. It considered the description part of the "key" that uniquely identifies a tax. The description contains the jurisCode field returned by Avatax [2].…
We recently reworked the way taxes are named [1]. It considered the description part of the "key" that uniquely identifies a tax. The description contains the jurisCode field returned by Avatax [2]. This key is used to find an already existing tax, and creates it if it doesn't yet exist. _constrains_name() of account.tax however, doesn't consider the description field. This means that two taxes with the same name (e.g. CA STATE 6%) and different jurisdiction codes (e.g. 001 and 013) cause issues. The first one will be created as normal. When the second one is processed it will fail to find a match because the description is different, so Odoo will create a second one resulting in a constraint error. To resolve this, stop adding the jurisdiction code and stop looking at the description all together. In the end it's not critical information that needs to be in Odoo. For tax details the user already relies on the Avalara portal anyway. [1] https://github.com/odoo/enterprise/pull/68549 [2] State assigned code identifying the jurisdiction. Note that this is not necessarily a unique identifier of the jurisdiction.
5 changes
Resolved issues and error corrections
This fix improves the robustness of the Spanish Profit and Loss report by using stricter date range calculations. Previously, if an account was incorrectly configured with the wrong type, the report could display incorrect historical balances. The fix ensures the report handles such misconfigurations more gracefully without requiring immediate account corrections.
Original PR description
Before this fix, when a P&L account was wrongly configured with a Balance Sheet type, the 'normal' date_scope set on the P&L expressions made it so that the balance of this account was computed on the whole accounting history. Of course, the most proper fix in that case is to fix the account type, but using strict_range as the date_scope will just make the report a little more robust. This is a partial backport of what was done in https://github.com/odoo/enterprise/commit/6e607e662dd2ae3ee5e3616bded11b62332ac2f9 for 18.0 Forward-Port-Of: odoo/enterprise#71578
This update resolves an error that occurred when users tried to filter subscriptions by customer or salesperson in the subscription dashboard. The fix corrects the underlying field references used for filtering, allowing users to successfully apply these filters without encountering system errors.
Original PR description
Currently, an error was generated when the user tries to filter `Customer/Saleperson` in the subscription dashboard.
error: `Invalid field sale.subscription.report.message_partner_ids in leaf ('message_partner_ids', 'in', [3])`
This is because we have used fields 'message_partner_ids' and 'activity_user_id' to filter out records, but this field is not available in the model.
This commit will fix the above issue by using fielels 'partner_id' and 'user_id' to fielter records.
sentry-5657224204This fix improves the responsiveness of shared spreadsheets by processing updates immediately instead of waiting for server confirmation through the websocket. Users will now see their changes reflected faster, and the system is more reliable if the connection drops while they're the only person editing the spreadsheet.
Original PR description
With this commit, the user will not have to wait for the acknowledge message coming through the websocket to process it, it will be processed directly after the message is sent, if the message is accepted server-side. With this commit, we are now robust to the case the websocket connection is dropped **and** the user is alone in the spreadsheet. Task: 4243943 Forward-Port-Of: odoo/enterprise#71782
This fix corrects how shift end times are calculated when employees have working calendars with breaks. Previously, the system would simply add the shift duration to the start time without accounting for lunch breaks or other non-working intervals, resulting in incorrect end times. Now the scheduling system properly considers the employee's working calendar and break times when calculating shift durations.
Original PR description
**Steps to reproduce:** - Create a working calendar 8:00 - 12:00 13:00 - 15:00 - Set in employee and company, as you mentioned everywhere. - The create a shift template 11 :00 - 15:00 (3 hrs) - Now create a planning slot with this shift template. - Expected start date - End date 11:00 - 15:00 - Actual start - end 11:00 - 14:00 **Current behavior before PR:** The end time is not calculated correctly if we have working calendar because we just add the duration to the start time without taking into consideration that there might be a break hour in the middle of the duration. **Desired behavior after PR is merged:** We are now considering the employee resource calendar in our calculation for the time of the slot. opw-3890629 Forward-Port-Of: odoo/enterprise#63002
Fixed an issue in the Argentine VAT report that was causing the system to slow down or crash when displaying large numbers of records (over 6,000 lines). The fix limits the number of records shown in the web interface while still allowing the full dataset to be exported to Excel or PDF files.
Original PR description
ticket 80761