Daily updates from Odoo
Wednesday, June 5, 2024
11 changes
2 changes
Resolved issues and error corrections
This update refreshes Odoo's spreadsheet engine with several fixes that make day-to-day spreadsheet work more reliable. Users should see fewer issues when pasting charts, editing sheets, using formulas, exporting files, and working with charts or conditional formatting.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/086af6d9a [REL] 17.2.9 Task: 0 https://github.com/odoo/o-spreadsheet/commit/eb6592c40 [FIX] package: saas-17.2 is no…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/086af6d9a [REL] 17.2.9 Task: 0 https://github.com/odoo/o-spreadsheet/commit/eb6592c40 [FIX] package: saas-17.2 is no longer the latest version Task: 0 https://github.com/odoo/o-spreadsheet/commit/cc5e097fb [FIX] clipboard: cannot paste chart with deleted ranges Task: 3618758 https://github.com/odoo/o-spreadsheet/commit/2d3d75e67 [FIX] FigureComponent: Stop Ctrl+A propagation Task: 3863300 https://github.com/odoo/o-spreadsheet/commit/6ea6ed083 [FIX] functions: throw errors with formula that return range Task: 3918882 https://github.com/odoo/o-spreadsheet/commit/4ace22d3c [FIX] module array: accept negative index on choose cols/rows Task: 3918882 https://github.com/odoo/o-spreadsheet/commit/c2b60528b [FIX] functions: Conditional functions now handle ranges with different size Task: 3918882 https://github.com/odoo/o-spreadsheet/commit/88a94589c [FIX] functions: correctly handle simple arguments on conditional functions Task: 3918882 https://github.com/odoo/o-spreadsheet/commit/ee96f3f57 [PERF] evaluation: faster spreading Task: 0 https://github.com/odoo/o-spreadsheet/commit/e02dca3e0 [FIX] clipboard: do not change clipboard state on INSERT_CELLS Task: 3874117 https://github.com/odoo/o-spreadsheet/commit/37d51bd4f [FIX] xlsx: Skip non-exported formula with no result Task: 3491974 https://github.com/odoo/o-spreadsheet/commit/8d850d06d [FIX] cf: drag & drop CF break on scroll Task: 3951043 https://github.com/odoo/o-spreadsheet/commit/985b2ba68 [FIX] BottomBarSheet: give focus back to grid after sheet name edition Task: 3945145 https://github.com/odoo/o-spreadsheet/commit/dfcbc9a31 [FIX] chartjs: remove forced hover dot size Task: 3869065 Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Mehdi Rachico (mera) <mera@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
This fix prevents delivery orders for different customers from being combined in two-step delivery workflows. It preserves the correct delivery address and ensures each customer gets a separate outbound delivery order.
Original PR description
### Issue: Pickings associated to different customers are merged in 2 steps delivery setups. ### Steps to reproduce: - Create 2 storable products: P1 and P2 - Enable multistep routes in the settings…
### Issue: Pickings associated to different customers are merged in 2 steps delivery setups. ### Steps to reproduce: - Create 2 storable products: P1 and P2 - Enable multistep routes in the settings > set Warehouse Routes - Create a new warehouse WH2 with 2 steps delivery - Go to inventory > Pick (WH2) - Create and validate a new pick for Customer 1: 1 x P1 Note: A delivery order was created for customer 1 - Create and validate a new pick for Customer 2: 1 x P2 ### Expected behavior: A delivery order is created for customer 2 ### Current behavior: The new delivery order is merged with delivery order created for customer 1 and the delivery address is erased as the picking would be associated with 2 contacts. ### Cause of the issue: When generated for the customer delivery is generated by the 2 step delivery the `_assign_picking` methods tries to assign the move to an existing picking if possible: https://github.com/odoo/odoo/blob/71b4a97c9e3da94bfc0130371db2c02beb81eebe/addons/stock/models/stock_move.py#L1250-L1254 However, the `partner_id` is only used in the search domain of this picking if the usage of the `location_id/dest_id` is a transit: https://github.com/odoo/odoo/blob/71b4a97c9e3da94bfc0130371db2c02beb81eebe/addons/stock/models/stock_move.py#L1240-L1241 This should also be the case when the destination is a customer. ### Note: The issue did not occur prior to saas-17.2 since no "Out" transfer were generated by manual pick transfer in 2 steps delivery prior to this version. opw-3857526 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
1 change
Resolved issues and error corrections
This fixes an issue where discounts on subscription upsell orders could be applied incorrectly. It helps ensure customers receive the intended pricing and reduces the risk of billing errors during upsell transactions.
8 changes
Resolved issues and error corrections
Fixed an issue where users with incorrect eBay credentials would encounter a technical error instead of a clear message. The system now properly handles authentication failures, providing a better user experience when credentials are invalid or misconfigured.
Original PR description
users were getting a traceback from the sdk when credentials were incorrect AttributeError: 'Response' object has no attribute '_dom' opw-3873151 Forward-Port-Of: odoo/enterprise#63735 Forward-Port-Of: odoo/enterprise#62049
This fix corrects how the "current year earnings" account is calculated in Chile's 8-column financial report. Previously, the report incorrectly included previous period balances, causing discrepancies between debit/credit and asset/liability columns. Now the report accurately shows only current period activity, ensuring financial statements are balanced and consistent.
Original PR description
Before this PR: The 8-column report for the "current year earnings" account type (equity_unaffected) incorrectly included the previous balance. This caused inconsistencies in reports, leading to imbalances between debit/credit and debtor/creditor columns, as well as assets/liabilities. Previously, this issue could be addressed by modifying the include_initial_balance boolean in the "account.user.type" model. However, this boolean is now computed and resides in the "account.account" model, making it uneditable. After this PR: This fix ensures the "current year earnings" account reflects only the activity for the current period, excluding the previous balance. This change eliminates the need to rely on the include_initial_balance state for this account, leading to a consistent and accurate 8-column report. Forward-Port-Of: odoo/enterprise#60713
This update fixes a critical issue in Romanian financial reports where outdated configuration settings were causing system errors during upgrades. The fix explicitly removes incompatible settings from balance sheet and profit/loss reports, ensuring they work correctly with the current reporting system.
Original PR description
Some of the records had their `groupby` set to `account_id` in previous versions That field was removed from the data file and new expressions were added. This means that the records which already…
Some of the records had their `groupby` set to `account_id` in previous versions That field was removed from the data file and new expressions were added. This means that the records which already have `groupby` set won't get that field updated during an upgrade, and will trigger [an error](https://github.com/odoo/odoo/blob/17.0/addons/account/models/account_report.py#L571-L578). By explicitly removing the value from the field, we ensure the field will be emptied. The change in the data files comes from: https://github.com/odoo/enterprise/pull/52603 ``` odoo.tools.convert.ParseError: while parsing /home/odoo/src/enterprise/17.0/l10n_ro_reports/data/balance_sheet_short.xml:3 Groupby feature isn't supported by aggregation engine. Please remove the groupby value on 'SOLDE C | 43' ``` Note: The original change to the data file happened in saas~16.1. Given that it's not possible to upgrade to intermediate versions any more and there's no issue in standard, the PR targets 17.0. Forward-Port-Of: odoo/enterprise#62421
This fix resolves an issue where newly added employee skills were not appearing in the skills evaluation report. The problem occurred because the system wasn't properly handling new skill records that didn't have previous skill level data. The fix improves the report's data retrieval logic to ensure all skills, including newly created ones, are accurately displayed in employee appraisal reports.
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#60088
This fix corrects how the system identifies which pivots are being used in a spreadsheet when they span multiple sheets. Previously, pivots used in non-active sheets were incorrectly marked as unused, which could lead to confusion about data dependencies. The fix ensures accurate tracking of pivot usage across all sheets in a spreadsheet.
Original PR description
Enterprise adaptations of the community branch. Steps to reproduce in 17.0: There's no way to reproduce the issue in 17.0 because the faulty getter in only called on positions in the active sheet (pivot autofill, global filter auto-matching) Steps to reproduce in saas-17.1: - insert a pivot in a blank spreadsheet - delete all pivot formulas - insert a new sheet - in the new sheet: - in A1: type "1" - in A2: =ODOO.PIVOT(A1) - activate the first sheet again - Open the Data menu => the pivot 1 is marked as being unused, even though it's used in the second sheet Task: 3859472
This fix resolves an issue where users couldn't open spreadsheets from shared workspace portals, which was causing access right errors. Now internal users can properly access and open spreadsheets when clicking on them from the sharing portal page, improving the collaborative document sharing experience.
Original PR description
Steps to reproduce: - share a workspace with more than one document and a spreadsheet - open the sharing link,(make sure you are login as internal user) - from the sharing portal page, click on the spreadsheet title to open the spreadsheet => access right error Task: 3897719 Forward-Port-Of: odoo/enterprise#63256
This fix corrects an issue where timesheet dates were being displayed in UTC time instead of the user's local time zone, causing dates to appear one day off. The fix removes an unnecessary UTC time override in the timesheet creation process, allowing the system to properly respect each user's time zone settings.
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#63693 Forward-Port-Of: odoo/enterprise#63073
This fix resolves an issue where products with lot tracking could not be moved if they had inventory in customer locations. The system was incorrectly checking all inventory locations instead of only internal warehouse locations, causing errors during lot transfers. With this fix, users can now successfully move lots even when customer location inventory exists.
Original PR description
Description of the issue/feature this PR addresses: Products with lot tracking, have some quants in customer locations, function gets all quants not only internal locations Current behavior before PR: Raise exception when try to move location for stock.lot Desired behavior after PR is merged: Allow move stock.lot although it has quants in customer locations --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr