Daily updates from Odoo
Thursday, February 27, 2025
8 changes
1 change
Resolved issues and error corrections
This fixes how India GST reporting identifies company records in multi-company or branch setups. It avoids using a parent company’s credentials for a child company that may have its own independent credentials, reducing the risk of incorrect GST report access or filing context.
Original PR description
In this commit we are partially reverting the company_domain changes because using `child_of`, is not the best option here. Due to it risks the using the credentials of the parent company for the child company records where a child can have an independent credentials The change was introduced because the in India, we can have same PAN entity with multi-company or branches where we wanted to make sure, that any child company does not have the record in that case. But described above as said it is not the best option to do.
7 changes
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