Thursday, February 27, 2025
12 changes · 18.0
Enhancements to existing features
Point of Sale can now support payment methods that do not automatically send a payment to the terminal as soon as a payment line is added. This helps with scenarios such as splitting a purchase across multiple cards or adjusting the amount before sending it to the terminal, while keeping the existing fast payment behavior as the default.
Original PR description
Enterprise PR: https://github.com/odoo/enterprise/pull/79432 As part of adding the Tyro payment method, new functionality was required in order to not automatically send payments to the terminal upon adding a payment line. This gives a chance to input a different payment amount, for example when splitting the payment between multiple cards. By default the behaviour is the same as before, but if a payment method overrides `fast_payments` to false, then payments will not be sent automatically (the same behaviour as pre v18). task-4086116 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update streamlines the point-of-sale scale weighing flow and related IoT scale driver code to support EU Measuring Instruments Directive compliance. By removing unused code and narrowing the certified code area, it makes scale-related POS operations easier to verify and maintain.
Original PR description
In order to comply with the EU Measuring Instruments Directive, the code for weighing products must be verified with a checksum to ensure it has not been modified. This PR refactors both the IoT driver and the POS code, with the goal of removing dead code and making the amount of code that needs to be certified as small as possible. Enterprise PR: https://github.com/odoo/enterprise/pull/75269 task-3929839 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Inventory transfers involving many serial-numbered items are now validated much faster. The change reduces repeated accounting checks during stock valuation, cutting wait times significantly for warehouse and purchasing workflows.
Original PR description
### Description: Validating a picking with serial numbers can be slow. This is caused by the method `_account_entry_move` which was made to be called one by one on each valuation layer. The issue is each time this method is called, it needs to check if the move is in or out, which is not optimal since each valuation layer can have the same move. ### Fix: We can't change the way `_account_entry_move` works in stable but we can batch `_is_in` and `_is_out` outside the method. This change will reduce the time taken by each `_account_entry_move` and remove unnecessary calls. ### Benchmark (in 18): | # of moves | Before | After | |---------------------|----------|---------| | 8 (with 1000 each) | 13:57 | 3:46 | | 3 (with 1489 each) | 8min | 2:53 | | 1 (with 1489) | 2:47 | 36s | ### Reference: opw-4550348
The website generator now gives the website scraper more control over style customizations instead of applying fixed restrictions. This should improve how generated websites preserve or adapt visual styling from source sites.
Original PR description
Remove the restrictions of the make_scss_customizations from the website generator and instead let the website scraper have full control.
This update helps POS installations in EU countries comply with weighing-scale certification rules by verifying the relevant scale software with a checksum. It also adds a POS status indicator and an auto-fix option for rounding settings when certification requirements are not met.
Original PR description
In order to comply with the EU Measuring Instruments Directive, the code for weighing products must be verified with a checksum to ensure it has not been modified. This commit adds an endpoint for retrieving the checksum of the relevant scale code, as well as refactoring of the code to make it as simpler and to reduce the amount of code that needs to be certified. Community PR: https://github.com/odoo/odoo/pull/189846 task-3929839
Resolved issues and error corrections
Invoices created from sales orders now show combo products as section headings instead of zero-value product lines. This avoids confusing zero-amount, untaxed lines that can cause issues with electronic invoicing checks.
Original PR description
Before, when invoices were created from a sales order and one of the lines is a combo product, it would create a regular invoice line for that with the combo product, but the price would be zero and no taxes. The problem with that when sending electronic invoicing documents, is that it will treat that as a zero line. (and some EDIs might e.g. complain there is no tax on there) So, that way when creating the invoice line, we define it as a subsection with the product name as description but without product. opw-4410461 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
Project-created bills and invoices no longer assign analytic tracking to payable or receivable journal lines. This prevents those settlement lines from distorting analytic account gross margin, so project profitability reports show the expected figures.
Original PR description
### Steps to reproduce: - Install sale, project, and accountant. - Allow Analytic Accounting from settings. - Open project application. - Create a project with a billable feature. - Add invoices in the topbar. - Select invoices and create a new invoice. - Add a product to the invoice (you will see analytic is added). Go to the journal items tab. ### Issue: When the user opens the Analytical Account, the gross margin is shown incorrectly. ### Cause: When a bill or invoice is created from the project topbar, the analytical distribution is set in the payable/receivable journal items, causing the gross margin to show as 0. ### Fix: In this commit, we remove the setting of the analytical distribution in the payable/receivable journal items. As a result, no journal items related to payable/receivable will be added to the Analytic Line. task-4377544
This fix ensures pickup-in-store addresses include the selected state when used during checkout. It prevents payment validation errors for Click and Collect orders in locations where delivery availability depends on state settings.
Original PR description
Steps to reproduce:
1) Enable Click and Collect
2) Configure pick up in store and add a store in US with state set
3) Set the available country to US and available state as in the
store's partner
4) Enable Pay on site
5) Go to /shop page and add a storable product
6) Proceed to payment and pay choosing pickup in store delivery method
and pay on site payment method
7) Observe an error
Reason:
/shop/payment/validate checks for payment errors. When confirming a
sales order with pickup in-store dm the partner_shipping_id is set to
the created partner from the selected pickup point address.
However, the state was missing which resulted in creating a partner
with an empty state causing the `_get_delivery_methods` called by
`_get_shop_payment_errors` show an error.
Solution:
Save a state for pickup location data
opw-4592939Restaurant staff are now protected from accidentally sending the same order more than once when order submission is slow, such as when preparation printers are involved. The order button is locked while processing, reducing duplicate kitchen tickets and the need for manual checks.
Original PR description
before this commit and since commit 42b207f, the pos_restaurant does not lock the state of the order button anymore. This has as an effect that if the order submitting takes a lot of time (which e.g. happens when a preparation printer is configured) the user could press the order button multiple times. This situation can happen both intentionally or unintentionally. The end result is a disturbed flow for users, where orders are sent multiple times in preparation and therefore need to be manually checked by the staff regularly risking wrong extra order preparation otherwise. This commit reverts the changes adding back the state locking the order button while it's being processed. opw-4242269
Custom fields added to online job application forms now appear in the applicant notes section instead of the activity chatter. This keeps applicant information in the expected place, making it easier for recruiters to review submissions.
Original PR description
**Steps to Reproduce:** 1. Install the `website_hr_recruitment` module. 2. Navigate to the job application form. 3. Use the editor to add a custom text field. 4. Submit an application. **Issue:** The…
**Steps to Reproduce:**
1. Install the `website_hr_recruitment` module.
2. Navigate to the job application form.
3. Use the editor to add a custom text field.
4. Submit an application.
**Issue:**
The data entered in the custom field appears in the chatter section of the applicant record instead of the notes section.
**Solution:**
Setting `website_form_default_field_id` to `hr_recruitment.field_hr_applicant__applicant_notes`. Ensure that data from custom fields is correctly saved in the notes section of the applicant record.
Description of the issue/feature this PR addresses:
- In version 17.4, the [website_form_default_field_id](https://github.com/odoo/odoo/blob/saas-17.4/addons/website_hr_recruitment/data/config_data.xml#L23) was assigned to the description field, but in version 18, description field [was removed](https://github.com/odoo/odoo/commit/e0f281433eec3f34d6f720656ead51e417679cd1#diff-12b0850af29a9858b955218c748c4469b9cbe95d07fc75c656506dec3451e005L38), and a new [notes](https://github.com/odoo/odoo/commit/e0f281433eec3f34d6f720656ead51e417679cd1#diff-12b0850af29a9858b955218c748c4469b9cbe95d07fc75c656506dec3451e005R115) field was introduced. The website_form_default_field_id was left as null.
- The solution is to correctly map the custom fields to the notes section by setting the website_form_default_field_id to point to the appropriate field (applicant_notes).
**Current behavior before PR:**
#### Before the fix, the website_form_default_field_id was null, and custom field data would not appear in the notes section.
```psql
v_18.0=# select id,name,website_form_default_field_id from ir_model where model = 'hr.applicant';
id | name | website_form_default_field_id
-----+------------------------+-------------------------------
437 | {"en_US": "Applicant"} |
(1 row)
```
**Desired behavior after PR is merged:**
#### After the PR is applied, the website_form_default_field_id should be set to the applicant_notes field, ensuring custom fields are saved in the notes section.
```psql
v_check_fix=# select id,name,website_form_default_field_id from ir_model where model = 'hr.applicant';
id | name | website_form_default_field_id
-----+------------------------+-------------------------------
437 | {"en_US": "Applicant"} | 4453
(1 row)
v_check_fix=# select id,name,model,ttype from ir_model_fields where id = 4453;
id | name | model | ttype
------+-----------------+--------------+-------
4453 | applicant_notes | hr.applicant | html
(1 row)
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prFolders in the Documents search panel are now shown in a predictable sorted order instead of appearing randomly. This helps users with many folders find what they need more quickly while manual folder ordering is unavailable.
Original PR description
It's very difficult to find folders when they are returned in an arbitrary order. Furthermore, as we've removed the sequence field in 18.0, users have no way to change the ordering of these folders. With this change, users with many folders will at least be able to do something until re-ordering by sequence is made possible again in 18.2 Task-4512349
Fixes an issue where decorative footer backgrounds in report layouts could cover report content while editing XML in Odoo Studio. This improves the report editing experience by keeping previews readable and closer to the intended layout behavior.
Original PR description
Before this commit, in the wave and bubble layouts, the SVG acting as an overlay background of the footer was displayed on top of the report when entering the XML Editor of the reportEditor. This is due to multiple factors, all of which linked to how wkhtmltopdf works: - header and footers seem to be rendered in their own viewport, the top parameter is the start of the footer itself, not that of the page. - absolute positioning wrecks havoc in z-index with SVG's ..... Even though the HTML of the waves' and bubbles' layouts doesn't seem very well written, it does work in the current state of the art of Odoo's PDF rendering. This commit adapts the JS code in the XML editor of the reportEditor to account for it. opw-4508900