Wednesday, January 29, 2025
11 changes
1 change
Resolved issues and error corrections
When a user deletes or archives a record opened directly from a URL, Odoo now avoids showing an empty or broken record page. If there is no previous page to return to, the system safely redirects to the default application, reducing errors and confusion.
Original PR description
- open a record with an URL: `/{model}/{id}`;
- delete or archive the record;
Before this commit, an empty form view was displayed, with an incorrect URL: `/{model}/new`. This form view was inconsistent, and would throw an error in some applications (such as accounting). Even if no error was thrown, an error would be thrown if the user clicked on the 'back' button.
This is not the correct behaviour, when deleting or archiving a record, the correct behaviour is :
- if a pager exists, display the next record;
- if not, return to the previous controller (the previous action, usually the multi-record view);
The issue here is that we don't have a previous action or a multi-record view.
Now, in this particular case, we will fallback to the default application.
opw-435412910 changes
Resolved issues and error corrections
Users can now download original PDF bills attached to newly created draft vendor bills without encountering an error. The fix ensures draft bill records are handled correctly when preparing the download, restoring a standard accounting workflow.
Original PR description
Users currently cannot retrieve original bills attached to newly created draft moves, because an error is blocking the action Steps to reproduce: - Go to Accounting > Vendor > Bills - Upload a pdf - Back in list view, select the created bill, Download > Original Bills Issue: Traceback will raise `AttributeError: 'bool' object has no attribute 'decode'` This occurs because, after https://github.com/odoo/odoo/commit/ce73ed61bcf293953bc0c821ceaef3ddb9a47e3c, draft moves are not named '/' anymore, the name field will be just `False`. However reportlab expects a string and it crashes opw-4502791
This fixes a problem where pressing Escape while editing a form in a dialog could cause an error instead of closing cleanly. It improves reliability when users cancel edits, especially in areas like Studio and other popup form views.
Original PR description
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
This fixes an issue where employees on flexible working schedules could have a one-day time off request counted as two days. The change ensures leave duration is calculated from the actual requested date range, helping keep balances and approvals accurate.
Original PR description
### Steps to reproduce: - Create a working schedule that is flexible - Assign this working schedule to an Employee - Create a time off type and set the request unit to be 'half day' - Create an…
### Steps to reproduce: - Create a working schedule that is flexible - Assign this working schedule to an Employee - Create a time off type and set the request unit to be 'half day' - Create an allocation for the created time off type for the employee with the flexible working schedule - Create a leave for the mentioned employee with the created time off type for 1 day - Notice the duration of the leave is 2 days not 1 ### Cause: When creating a working schedule we compute the duration of the periods and since 'attendance.calendar_id.hours_per_day' won't have a value each period will be 1 day. https://github.com/odoo/odoo/blob/18.0/addons/resource/models/resource_calendar_attendance.py#L82 So, when getting the duration of the leave where its request_unit is not 'day' the duration will be the summation of the periods' duration of the working schedule for the employee which in this case will be 1 for each period -each day has 2 periods with the value of 1- ### Fix: Check if the employee if on flexible hours we calcualte the duration as the difference between the date_to and date_from rounded up in days opw-4309551
This fixes an issue in Point of Sale where product stock could be shown incorrectly when a cashier changed product options during configuration. The update reduces duplicate stock checks and ensures the displayed on-hand quantity matches the selected product variant, helping staff make more accurate sales decisions.
Original PR description
Before this commit, multiple requests were sent when the user changed options in the product configuration. Additionally, the on-hand quantity was displayed incorrectly when opening the product configuration. When opening the configuration popup, the product was initially set. However, once the configuration was mounted, the selected attributes could result in a different product variant. We call `computeProductProduct` to update the product. The issue occurred because, while the first request was still in progress, a second request was triggered to fetch the correct product information. Since the first request was not yet finished, the second request was ignored, causing the configuration to display an incorrect on-hand quantity for the selected product variant. opw-4385171 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update brings Odoo's spreadsheet engine to a newer maintenance version with fixes for spreadsheet sessions, Excel import/export validation ranges, and chart trendlines. Business users should see more reliable spreadsheet behavior, especially when working with XLSX files and logarithmic chart trends.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/a881cffac [REL] 18.0.12 Task: 0 https://github.com/odoo/o-spreadsheet/commit/79731b80f [FIX] session: useless snapshot…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/a881cffac [REL] 18.0.12 Task: 0 https://github.com/odoo/o-spreadsheet/commit/79731b80f [FIX] session: useless snapshot on leave Task: 4356913 https://github.com/odoo/o-spreadsheet/commit/e8ae60230 [FIX] xlsx: fix data validation range Task: 4505771 https://github.com/odoo/o-spreadsheet/commit/b52dbde23 [REF] range: rename useFixedReference Task: 4506120 https://github.com/odoo/o-spreadsheet/commit/179614731 [FIX] xlsx: export data validation with unbounded range Task: 4505771 https://github.com/odoo/o-spreadsheet/commit/74263151a [FIX] charts: fix logarithmic dataset trendline Task: 4385057 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: Florian Damhaut (flda) <flda@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 keeps XML files from being selected as the main attachment for vendor bills when Italian localization is installed. It prevents unreadable files from being produced when users print original bills, preserving the expected PDF output.
Original PR description
**Issue:** When "l10n_it" is installed, an override of "_message_set_main_attachment_id" method is changing the default value of "filter_xml" param from True to False, which is impacting the general behavior when the module is installed. As a consequence, xml files can be set as main attachment of a bill, which generates unreadable PDF files when using "Print > Original Bills" action on a bill. opw-4439034 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Brazilian electronic invoices now send the invoice line description instead of only the product name, letting businesses include the extra detail they entered for each line. The fix also prevents service transaction errors from being incorrectly cleared, improving reliability for Brazilian AvaTax electronic invoicing.
Original PR description
We always send the product name, but sometimes users want to add more information to the electronic invoice. It makes more sense to send the line description (account.move.line's name field) instead. That allows the user to specify what they want and also aligns better with what the API expects (their field is called "description", not "productName"). To avoid changing function signatures in stable we override _l10n_br_build_avatax_line and browse the account.move.line using line_id. In master we'll clean it up by providing "description" directly in _get_line_data_for_external_taxes() for both account.move and sale.order. This also fixes a mistake that cleared errors for service transactions (introduced in the merge of l10n_br_avatax_services [1]). [1] https://github.com/odoo/enterprise/pull/64714 task-4401787
Accountants can now edit Brazilian NCM codes used for service invoices so they match the format required by each city. This helps prevent invoice rejections in cities whose local tax systems expect different code formats, such as leading zeros or no periods.
Original PR description
Goods invoices go through a central, federal API. Service invoices however, go through an API maintained by the city the business is located in. Because of this, there are thousands of different…
Goods invoices go through a central, federal API. Service invoices however, go through an API maintained by the city the business is located in. Because of this, there are thousands of different APIs. Avatax sits between us and those city APIs, but certain differences are not handled by them. The most blocking is the format of the NCM code. We based our NCM codes on the official law [1], but unfortunately the required format differs between cities. Some cities require a leading zero in front of the code (e.g., 04.10 instead of 4.10), presumably because that's what non-service NCM codes look like. Other cities may not require periods. Cities reject invoices with "wrong" NCM codes, so at the moment our service invoice integration doesn't work there. This seems to affect around 25% of cities. Avalara states they cannot translate the codes for us due to the large number of cities involved. So, users will have to figure out the required format of the NCM code from their city hall and edit the NCM codes based on that. In order to do so we make the NCM codes editable for accountants and provide views and menu items. NCM codes are loaded from CSV and are non-updateable (noupdate=False) by default. To avoid changes being overwritten during module updates we turn them updateable in the model's init() (called during module update). In master this can be removed and done in post_init_hook instead, so that it only happens once during module installation. It's not needed to change the post_init_hook here. After module installation the records will be noupdate=False, but init() always runs before l10n_br.ncm.code.csv is reloaded so manual changes will persist. [1] https://www.planalto.gov.br/ccivil_03/leis/lcp/lcp116.htm task-4374334
The EU OSS reports now show the closing entry button again in version 18.0. This lets users complete closing entries directly from the report because the underlying closing process is expected to work correctly again.
Original PR description
From version 18.0, the closing should work fine and there's no need to hide the closing button anymore. This reverts commit cf86ce0e0c7c47336446da5b335cbc53b7602fcd.
Uploading large images to Documents no longer automatically shrinks them. This preserves the original file quality and avoids unexpected changes to images stored by users.
Original PR description
Bug === When uploading a big image in documents, it's resized. It has been fixed in 17.4 with `Task-3944609`, but we re-introduced the issue during the refactor of documents. Task-4505777