Friday, February 28, 2025
13 changes · 18.0
Enhancements to existing features
Unpublished products used as choices inside an eCommerce combo can now still show their images to public and portal shoppers. This makes the combo selection experience clearer without requiring each individual combo item to be published separately.
Original PR description
Similarly to other types of products, combo products must be published to make them available in eCommerce. However, combo item products (i.e. the different choices in a combo) don't need to be published. Unfortunately, if a product is unpublished, public/portal users don't have access to its images, so they won't be shown in the combo configurator. This is a bad UX, as public/portal users are expected to make a product selection, but we don't show them the corresponding images. This PR uses the `src` attribute of the `img` tag to show the raw combo item's image instead of using the image url, bypassing access checks. This is done only for combo items that are not published. task-4337641 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Consolidation reports can now be configured to group accounting entries by account code and account name without requiring a strict one-to-one account mapping between companies. This makes consolidation setup more flexible for businesses with multiple accounts sharing the same code, while avoiding impact on existing accounting flows.
Original PR description
Since https://github.com/odoo/enterprise/commit/a94227b6f305ffabbe18a5ea98335a3b17659d2d, it is possible in standard report engines to group by non-stored related fields. Thanks to this, it is now…
Since https://github.com/odoo/enterprise/commit/a94227b6f305ffabbe18a5ea98335a3b17659d2d, it is possible in standard report engines to group by non-stored related fields. Thanks to this, it is now possible to greatly improve the configuration of consolidation reports, by grouping the move lines by account_id.code, then account_id.name, provided that non-stored related fields are added on account.move.line for those values. This way, it becomes possible to configure multiple accounts mapped to the same code, without having to ensure a 1 to 1 relationship between the accounts of the source and consolidating company. We received a lot of feedback from people wanting to avoir the 1 to 1 mapping, and needing to configure such customized groupby on the report. The add of a related fields is a bit too technical to be explained in any kind of functional documentation; therefore we make the choice to add them in the standard code. They are non-stored, and will have no impact on any other flow. Note that this groupby customization only works on standard engines at the moment. Custom engines still need to be adapted, but this will come in a future PR.
Resolved issues and error corrections
This fixes an Italian e-invoicing issue where an invoice line could disappear after a negative line was redistributed as a discount. Businesses sending Italian electronic invoices will now have complete invoice details in the generated XML, reducing the risk of missing line information.
Original PR description
Currently in the italian e-invoice system it is not allowed to report negative lines so when the system needs to encode an invoice with negative lines it will dispatch them over the other lines with same tax, keeping the negative amount as discount. However when the discounted line amount is 0 this line is not reported in the e-invoice anymore Steps to reproduce: - With IT Company setup - Create an invoice for IT customer, with lines: 1. Quantity 1 | Price 0.0 | Tax 22% 2. Quantity 1 | Price 150.0 | Tax 22% 3. Quantity 1 | Price 100.0 | Tax 22% 4. Quantity 1 | Price -200.0 | Tax 22% - Confirm & send - Check generated e-invoice xml Issue: Line 3 is missing This occurs because after dispatching negative lines on suitable candidates we ignore nulled lines opw-4501951
Merging or transferring restaurant orders now carries over already-sent preparation updates correctly, so kitchen printers do not reprint the same changes. This helps restaurant staff avoid confusion and duplicate preparation work when tables are merged or moved.
Original PR description
When trasnsfering/merging order with some preparation changes, the preparation changes are not correctly transferred to the new order. Steps to reproduce: ------------------- * Setup a restaurant…
When trasnsfering/merging order with some preparation changes, the preparation changes are not correctly transferred to the new order. Steps to reproduce: ------------------- * Setup a restaurant with a kitchen printer * Open PoS restaurant * Open table 1 add any product and send it to kitchen * Open table 2 add the same product and send it to kitchen * Merge table 1 and table 2 > Observation: The preparation change are printed again Why the fix: ------------ The issue is that the preparation change were not transferred to the new order. This was causing the preparation change to be printed again. I identified 6 use cases to test : - Transfer sent product on table with same product sent - Transfer sent product on table with same product not sent - Transfer sent product on table without the same product - Transfer not sent product on table with same product not sent - Transfer not sent product on table with same product sent - Transfer not sent product on table without the same product https://github.com/odoo/odoo/blob/948c36a7d8706126dce3f43e9f074d16c10d3395/addons/point_of_sale/static/src/app/models/utils/order_change.js#L16-L18 We need to make sure to ignore changes that have exactly 0 quantity https://github.com/odoo-dev/odoo/blob/948c36a7d8706126dce3f43e9f074d16c10d3395/addons/pos_restaurant/static/src/overrides/models/pos_store.js#L335 Here we need to make sure that the order are synchronised. This is not really needed for real use, but in the tour it was not working because it was going too fast opw-4462713
Odoo now correctly handles rejected Worldline payments, such as payments made with an expired credit card. This prevents subscription payment processing from crashing and allows the rejection reason to be handled properly.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Have an expired credit card; 2. have an Odoo subscription; 3. pay subscription with expired credit card. Issue ----- Handling of notification data crashes when fetching a dict key: ```python payment_data = notification_data['payment'] ``` Cause ----- Commit c3c9c12d790e forwards rejected payments to handle the reason they were rejected. The issue is that notification data from rejected payments doesn't have an immediate `payment` key. Instead, it contains the following keys: - `errorId` - `errors` - `paymentResult` The `payment` key we need is located in the `paymentResult` value. Solution -------- Use a new variable `payment_result`, and set it to the `paymentResult` value if it exists, otherwise to `notification_data`. We can ignore the `errors` value as it is identical to the one in the `statusOutput` value of `paymentResult`. opw-4481602
This fixes an invoicing issue where editing a product description on an invoice line could remove the product name from the printed PDF. The invoice line update now preserves the product name, helping customers receive clearer and more accurate invoice documents.
Original PR description
Steps: - Install account app. - Go to invoice add a product. - Update product description from invoice line. - Print invoice. Issue: - Product name is missing in PDF file. Cause: - Updating line name remove product name from line name and only add newly added string description. In `product_label_section_and_note_field` widget we only display description without product name in description input even description contains product name in it but when user update that description input we forgot to take product name into account. Fix: - Take product name into account when updating description from that widget. opw-4599839 opw-4603802 opw-4571431
This change rolls back a previous Worldline payment handling update that could cause payment processing to crash when certain rejection details were missing. It helps keep checkout and payment workflows stable for businesses using Worldline.
Original PR description
Versions -------- - 18.0+ Reason ------ Payment processing may crash on ```python payment_data = notification_data['payment'] ``` This reverts commit c3c9c12d790ee3acfe9f637358e306b75616c76f.
DIN5008 report PDFs now display section backgrounds, line separators, and bold column headers correctly again. This restores the expected professional layout for quotations and other documents after styling was lost during a prior refactoring.
Original PR description
### Steps to reproduce:
- Install l10_din5008 and select the DIN5008 layout in the settings
- Go to Sale, create a quotation with section lines
- Confirm and send
- The generated PDF have several styles missing:
- Section lines have no background color
- There are no line separations
- Column titles are not bold
### Cause:
The style that was applied to all reports was removed during a refactoring in 18.0.
https://github.com/odoo/odoo/pull/169512
### Solution:
Change the CSS of the DIN5008 report to make it look like in 17.0.
In 17.0
In 18.0
After this commit
opw-4572732This fix prevents timesheet entry failures when a duplicated sales order refers to a project accounting record that was already deleted. Users can now add timesheets to tasks created from duplicated sales orders without encountering a missing account error.
Original PR description
## Issue: When duplicating a sale order with a service product that creates tasks, adding a timesheet entry to the task from the duplicate sale order fails if the original task and project were…
## Issue: When duplicating a sale order with a service product that creates tasks, adding a timesheet entry to the task from the duplicate sale order fails if the original task and project were deleted before duplication. ## Steps to reproduce: - disable Analytic Accounting. - Create a service product that create a test, keep project empty. - create a project. - create a sale order with the service product and the project. - confirm the sale order. - remove the task that was created by the service product and delete the project. - duplicate the sale order. - confirm the duplicate sale order. - open the task created by the sale order. - try adding a timesheet to the task. - an error is raised saying that the analytic account doesn't exist. ## Root cause: - When we delete a project, it's linked analytic account is removed automatically by the `project_project` override of the `unlink` method, but it might be still referred in the analytic distribution of sale order line, so when we try fetching it in `_timesheet_preprocess_get_accounts` it gives the "Missing Record" error. ## Fix: - make sure the analytic account exists when browsing to them in `_timesheet_preprocess_get_accounts`. - fallback to super when there are no analytic accounts OPW-4474903 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Portal users with permission to read or edit a shared Knowledge article can now open attachments added to comments on that article. This fixes an access issue that prevented invited users from viewing files they were meant to see.
Original PR description
Steps to reproduce =================== Admin: 1. Create an article 2. Share the article 3. Add a portal user as a member 4. Write a comment (using the editor, select the text, and use the toolbar to write a comment) 5. Attach a file to the new message Portal: 6. Go to the created article 7. Go to the comment with the message and attachment 8. Download/view the attachment => No access to the document After this commit ================= Portal user who has read or write access to the linked article is granted the access Task-4223292
Belgian payroll calculations now include holiday pay recovery when determining the Employment Bonus, and bonus parts are capped before calculating the total. This helps produce more accurate payslips and reduces payroll correction risks for affected employees.
Original PR description
…onus
Fixes an issue where users could not sign templates after the default "User" signing role had been deleted. The signing flow now handles the missing role gracefully instead of showing an error, reducing disruption for teams using Odoo Sign.
Original PR description
Currently, an error occurs when signing a template if its 'User' role record has been deleted. **Steps to reproduce:** - Install the `sign` module. - Navigate to `Sign > Configuration > Roles`. - Delete the record with `name: User`. - Open any template and click on the `Sign Now` button - Observe the error. **Error:** `ValueError: External ID not found in the system: sign.sign_item_role_user` The error occurs because the system attempts to fetch the role `sign.sign_item_role_user` at [1], but it is unavailable as the user has already deleted it. This commit ensures that if the role does not exist, the function will return `None` instead of raising an exception. [1] - https://github.com/odoo/enterprise/blob/37f453519d6373a87bfca783351b6efd1bd0800a/sign/wizard/sign_send_request.py#L130 Sentry - 6303245045
Ecuador electronic invoices now exclude placeholder combo product lines that have no taxes, preventing government rejection of the XML. The printed invoice is also aligned with the electronic invoice so customers see consistent information.
Original PR description
### Steps to reproduce: - In Sale app, create a quotation with a combo product - Confirm, Create invoice - Select the "Payment Method (SRI)" - Confirm - Click "Process now" to create the XML - There is a line for the combo product with no taxes but the government refuses lines with no taxes on XML ### Cause: The line of the combo product is there only to specify that the invoice originated from a combo product. ### Solution: Remove the line where the product is of type "combo" and where there are no taxes before generating the XML. The PO also wanted to remove the line from the PDF to keep the XML and the PDF coherent. opw-4557375