Daily updates from Odoo
Wednesday, June 5, 2024
11 changes · 17.0
Enhancements to existing features
This update improves how foreign currencies are handled when synchronizing bank transactions from Odoofin. The system now automatically activates foreign currencies, properly converts currency codes to currency IDs for correct display, and prevents validation errors. This ensures smoother bank reconciliation for companies dealing with multiple currencies.
Original PR description
...d on foreign_currency_code received from odoofin Send `include_foreign_currency` to odoofin to avoid throwing errors when odoofin returns `foreign_currency_code` and `amount_currency` for customers that don't have the fix. Convert `foreign_currency_code` to corresponding `foreign_currency_id` in order to be displayed correctly alongside the amount in `account.bank.statement.line` To avoid a validation error(Currency is not activated) pop up for every foreign currency resides in transactions received from Odoofin while fetching transactions, Automatically activating foreign currencies. Remove foreign_currency_id and amount_currency from retrieved transactions in `Fetch Missing Transactions` flow in order to not break the flow in stable.(These fields will be added to `account.bank.statement.line.transient` in master) Odoofin PR: https://github.com/odoo/odoofin/pull/265 task id: 2870614
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 prevents users from resetting invoices back to draft status after they have been successfully sent and accepted by AFIP (Argentina's tax authority). Previously, this was possible and caused data inconsistencies between Odoo and AFIP's records. Now, once an invoice is sent and validated, it cannot be edited or reverted to draft, ensuring data integrity and compliance with tax regulations.
Original PR description
Before this commit, when sending an invoice to the AFIP and that the result was accepted, it was still possible to reset the invoice the draft which caused discrepancies between the data in Odoo and the data that has already been sent to AFIP. This button to reset to draft is enabled for all users in Accounting. After an invoice is sent and validated, we cannot edit them. task-3955111 Forward-Port-Of: odoo/enterprise#63407
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
A CSS class name was updated in the spreadsheet module to match a recent library change. The button styling class was renamed from `o-sidePanelButton` to `o-button` to maintain consistency with the updated library. This ensures the version history panel buttons display correctly.
Original PR description
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo.
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