Thursday, August 15, 2024
25 changes · master
Enhancements to existing features
Recruitment reports now stop counting time in a hiring stage when an applicant is refused. This gives teams a more accurate view of how long candidates spent in each stage before rejection, improving reporting and process analysis.
Original PR description
This commit introduces functionality to stop the timer on stage when an applicant is rejected. This feature is useful for tracking the duration an applicant spent in that stage before being rejected. task-3810883
Budget forms now include an ordering sequence for budget lines, making it easier for users to arrange and review line items in the desired order. This is a small usability improvement for budget management workflows.
Original PR description
Before this commit: - There is no sequence for the budget line in the budget form view. After this commit: - Add sequence for budget line in budget form view Task-4108938
This update makes a small correction so records can be viewed properly in editable lists and debugging contexts. It helps keep reporting and Studio customization workflows aligned with recent platform changes, reducing minor usability issues.
Original PR description
This commit applies a small x-path correction following changes made in https://github.com/odoo/odoo/pull/175348 task-3977729
Barcode-related pages now use cleaner, more human-readable web addresses. This makes links easier to understand, share, and verify without changing the underlying barcode workflows.
Original PR description
*= stock_barcode_mrp, stock_barcode_picking_batch This commit modifies existing URLs to the new format so that the URL's become more human readable. Task-3820230
The India reporting module now includes an updated Profit and Loss report with opening stock and closing stock lines. This gives businesses in India a more complete view of profitability by reflecting stock movements directly in the report.
Original PR description
This PR introduces a new Profit and Loss report for India, adding lines for closing stock and opening stock. community PR: https://github.com/odoo/odoo/pull/175091 **task**-4059890
The web grid module's automated tests were moved to a newer testing approach. This helps improve long-term maintainability and confidence in future updates without changing the user-facing grid features.
Original PR description
task-4028356 task-4028335
This update adjusts test coverage to reflect Odoo's newer, more readable URL format. It helps ensure related email and rental product flows continue to work correctly as links become clearer for users.
Original PR description
*= test_rental_product_configurators This commit modifies existing URLs to the new format so that the URL's become more human readable. Task-3820230
Point-of-sale IoT and preparation display pages now use cleaner, easier-to-read web addresses. This makes links more understandable for staff and easier to share or recognize without changing the underlying business workflow.
Original PR description
\* = [iot, preparation_display] This commit improves the readability of URLs by modifying them to a new, more human-friendly format. Task-3820230
The Mexican electronic invoicing integration for Point of Sale now uses clearer, more human-friendly URL formats. This makes links easier for users to read and recognize, with no major workflow changes expected.
Original PR description
This commit improves the readability of URLs by modifying them to a new, more human-friendly format. Task-3820230
Planning pages now use a clearer, more human-friendly URL format. This makes shared links and browser addresses easier for users to recognize without changing the underlying planning workflow.
Original PR description
This commit improves the readability of URLs by modifying them to a new, more human-friendly format. Task-3820230
The cohort reporting module's automated tests were moved to a newer testing framework. This improves maintainability and helps ensure the feature remains reliable without changing how users interact with it.
Original PR description
task-4028356
This update changes existing links in Discuss and manufacturing work order screens to a cleaner, more human-readable format. This makes shared URLs easier to understand while preserving the same navigation behavior.
Original PR description
This commit modifies existing URLs to the new format so that the URL's become more human readable. Task-3820230
Accounting accounts can now be shared between companies while still showing the correct company-specific account code in reports and searches. This reduces duplicated setup for multi-company organizations and improves consistency across accounting, consolidation, assets, payments, and reporting workflows.
Original PR description
- `account.code` is now a computed (company-dependent) field. Therefore, when searching for a code in a company that is different from the active company, one must use `with_company(company)`. - To use `account.code` in accounting reports, we need to modify `env['account.report']._get_sql_table_expression()` so that it returns a `Query` rather than a `tuple[SQL, SQL]`, so that we can use `env['account.account']._field_to_sql()` to add a join on `ir_property` to the query. - we remove uses of `self = self.with_context(lang=...)` when handling the translation of `account.name` since this is already handled by `_field_to_sql`. Community PR: https://github.com/odoo/odoo/pull/171079 Upgrade PR: https://github.com/odoo/upgrade/pull/6372 taskid: 3698780
Resolved issues and error corrections
This update corrects the setup for an Indian payroll salary report after a previous salary-by-head report removal. It helps keep payroll reporting components aligned so users do not encounter missing or outdated report references.
Original PR description
commit: https://github.com/odoo/enterprise/pull/59417/commits/e8c87c0980745baeb117ff09f9c665e2a8f6160a task-4107188
This update fixes a typo and adds missing translated text in the Indian GST return reporting area. It helps users see clearer, localized labels when working with GST return periods, reducing confusion in day-to-day compliance tasks.
Employee job title, role, and department are no longer changed immediately when an offer is signed, avoiding premature updates before the new contract begins. Contracts are also linked back to their originating offer, improving traceability between offers and employment records.
Original PR description
Prior, employee information - job_title, job_id and department_id were updated as soon as employee signed a new offer. This is flawed behavior, as even though employee signed offer, the new contract might have not started yet. In this task we correct this. After this, above mentioned employee information will not be updated as soon as offer is signed. Moreover, functionally it makes sense to link originating offer with the contract that was created from it. Thus, we add originated_offer_id field. task-3035630
Code cleanup and technical improvements
This update aligns the Enterprise WhatsApp module with related platform changes by making rating information available in the internal message store. It supports consistent handling of WhatsApp message ratings and includes security test coverage to help ensure access rules remain correct.
Original PR description
Enterprise counter-part. Part of task-3605717 https://github.com/odoo/odoo/pull/176203
Miscellaneous changes
This traceback arises when the user gives an invalid hour value to the end date, while creating or updating a planning template. To reproduce this issue: 1) Install `Planning` 2) Create a new `shift template` from planning configuration 3) Give an invalid hour value to the end date (greater than 24) 4) Try to save the record. Error:- ``` ValueError: hour must be in 0..23 ``` When the user gives an invalid hour value to the end date and tries to save it, a compute method
Original PR description
This traceback arises when the user gives an invalid hour value to the end date, while creating or updating a planning template. To reproduce this issue: 1) Install `Planning` 2) Create a new `shift template` from planning configuration 3) Give an invalid hour value to the end date (greater than 24) 4) Try to save the record. Error:- ``` ValueError: hour must be in 0..23 ``` When the user gives an invalid hour value to the end date and tries to save it, a compute method triggers in which hour is used to calculate the end time. https://github.com/odoo/enterprise/blob/14b37f4141f1c73712d2c5ce16e5fc815e2a6a9b/planning/models/planning_template.py#L37-L38 Which leads to the traceback. Already a condition is there to check the invalid hours for start time. By just modifying the existing condition we can resolve this issue. sentry-5655372261 Forward-Port-Of: odoo/enterprise#67580
### Steps to reproduce: - Create a new Budget with type Expense - Add budget line (ex: Administration) and a period - Open the budget - Create a new RFQ that uses the analytic distribution set on the budget - With a quantity greater than 1, the line should appear red before the budget is reached - For example with a budget of 10000 and a quantity of 2 then the line is red if the price is greater than 2500 ### Cause: Line in question : `(budget.committed_amount + line.price_subtotal * (
Original PR description
### Steps to reproduce: - Create a new Budget with type Expense - Add budget line (ex: Administration) and a period - Open the budget - Create a new RFQ that uses the analytic distribution set on the budget - With a quantity greater than 1, the line should appear red before the budget is reached - For example with a budget of 10000 and a quantity of 2 then the line is red if the price is greater than 2500 ### Cause: Line in question : `(budget.committed_amount + line.price_subtotal * (line.product_qty - line.qty_invoiced)) > budget.budget_amount` The calculation uses `price_subtotal` which is the total amount without taxes, so it already includes the quantity. ### Solution: Use `price_unit` instead of `price_subtotal`. opw-4002330 Forward-Port-Of: odoo/enterprise#66750
Issue ----- [Approvals, Purchase, Stock] 1. In approvals, set the current user as the approver for the "Create RFQ's" approval type. 2. Approvals > New Request > Create RFQ's > Select a product with a vendor setup ("Acoustic bloc screen" for example) > Submit > Approve > Create RFQ > Click smart button to navigate to the PO > Confirm the PO (should work) 4. Repeat step 2, ValidationError when trying to confirm the PO. Note: the issue only arises in this specific flow, the PO can still b
Original PR description
Issue ----- [Approvals, Purchase, Stock] 1. In approvals, set the current user as the approver for the "Create RFQ's" approval type. 2. Approvals > New Request > Create RFQ's > Select a product with…
Issue
-----
[Approvals, Purchase, Stock]
1. In approvals, set the current user as the approver for the "Create RFQ's" approval type.
2. Approvals > New Request > Create RFQ's > Select a product with a vendor setup ("Acoustic bloc screen" for example) > Submit > Approve > Create RFQ >
Click smart button to navigate to the PO > Confirm the PO (should work)
4. Repeat step 2, ValidationError when trying to confirm the PO.
Note: the issue only arises in this specific flow, the PO can still be confirmed by for example just refreshing the page.
Issue
-----
A 'default_name' key is added to the context when creating a request for a category which uses sequential names (which is the case for RFQ's approvals). https://github.com/odoo/enterprise/blob/65a8e25f1ff2d0faf17ad73c1402615d320ffc48/approvals/models/approval_category.py#L154
As a result, it gets propagated all the way to the creation of the picking when the PO is confirmed.
https://github.com/odoo/odoo/blob/beb8c7d86ae6062dbad9fcb17bc3141d14a9fcdc/addons/stock/models/stock_picking.py#L721 As pickings require a unique (name, company_id), a first picking can be created with the name 'New', but later ones will fail.
Fix
-----
Avoid propagating the default_name key when opening the purchase orders so the picking created when confirming the order will have the correct name.
opw-3990816
Forward-Port-Of: odoo/enterprise#66504Some reports display some informational columns (like the VAT for a partner, or the country of origin). These columns sometimes prevent the `Hide Lines at 0` option to correctly do its work: the desired behavior of this option is to hide the lines where the amounts are null. It shouldn't care about the "informational" columns, that are usually always present This commit force the `Hide Lines at 0` feature to ignore columns displaying information other than float, integer of monetary ones.
Original PR description
Some reports display some informational columns (like the VAT for a partner, or the country of origin). These columns sometimes prevent the `Hide Lines at 0` option to correctly do its work: the desired behavior of this option is to hide the lines where the amounts are null. It shouldn't care about the "informational" columns, that are usually always present This commit force the `Hide Lines at 0` feature to ignore columns displaying information other than float, integer of monetary ones. task-4006235 Forward-Port-Of: odoo/enterprise#67818 Forward-Port-Of: odoo/enterprise#65622
### Steps to reproduce: Have 2 companies: CO1 and CO2 - In the setting, enable Multi-Step Routes and Inter-Company Transactions - With CO1 and CO, enable Synchronize Sales and Purchase Order - Go to Inventory > Configuration > Warehouse Management > Routes - Unarchive the MTO Route - With CO1 create a route with a buy action and destination CO1/stock - With CO2 create a route with a manufacture action - Go to Inventory > Configuration > Products > Attributes - Create a product att
Original PR description
### Steps to reproduce: Have 2 companies: CO1 and CO2 - In the setting, enable Multi-Step Routes and Inter-Company Transactions - With CO1 and CO, enable Synchronize Sales and Purchase Order - Go to…
### Steps to reproduce: Have 2 companies: CO1 and CO2 - In the setting, enable Multi-Step Routes and Inter-Company Transactions - With CO1 and CO, enable Synchronize Sales and Purchase Order - Go to Inventory > Configuration > Warehouse Management > Routes - Unarchive the MTO Route - With CO1 create a route with a buy action and destination CO1/stock - With CO2 create a route with a manufacture action - Go to Inventory > Configuration > Products > Attributes - Create a product attribute with a value that "is_custom" - Create a storable product P with using MTO and tour CO1 and CO2 routes - Set CO2 as a vendor for the product - With CO1, create a SO for 1 unit of your product P - a popup asks you for a custom product attribute value, write "test" - Confirm the SO > Automatically creates a PO (w/ description) - Confirm the PO > Automatically create an SO in CO2 (w/ description) - Confirm the SO in CO2 > Automatically create an MO #### Issue: #### The custom description is missing on the final MO. #### Note: If you were to create an SO directly in CO2 for 1 unit of P, the custom description associated with the custom attribute value would be present on the associated MO. ### Cause of the issue: The MO is created by a procurement generated from the SOL during the call of the `_action_launch_stock_rule` method: https://github.com/odoo/odoo/blob/055184ea033e7068ce33c92390c73ae39b2db259/addons/sale_stock/models/sale_order_line.py#L345 The custom description that will appear on the MO and containing the informations related to the custom attribute values is generated here: https://github.com/odoo/odoo/blob/055184ea033e7068ce33c92390c73ae39b2db259/addons/sale_stock/models/sale_order_line.py#L267 However, this method will return an empty string because the `product_custom_attribute_value_ids` is absent from our SOL https://github.com/odoo/odoo/blob/055184ea033e7068ce33c92390c73ae39b2db259/addons/sale/models/sale_order_line.py#L338-L347 On the other hand, this `product_custom_attribute_value_ids` was set and is still existing on the original SO that started the flow in CO1. The reason that it is not present anymore on the last SO is because this SOL field has no equivalent on the `purchase.order.line` model and the information was therefore forgotten on the MO and has not been transferred directly from the PO of CO1 to the SO of CO2. ### Fix: We rely on the `sale_line_id` field of the `purchase.order.line` model in order to determine the original SOL of the final SOL and update the `product_custom_attribute_value_ids` accordingly. ### Note: As a side effect of our change in `sale_purchase_stock` linking our sol to the pol via the procurement commit 63ef74b can be reverted since the message is already automatically posted (the message is now written by the user who cancelled the SO rather than Odoobot). opw-3998861 --- Forward-Port-Of: odoo/enterprise#68139 Forward-Port-Of: odoo/enterprise#67172
Before this commit: Steps 1) Install l10n_es_reports 2) Switch to ES company 3) Create a EU vendor (any except SPAIN) + add TIN 4) Create a bill with last month date 5) Reverse that bill with current month date 6) Go to Tax reports 7) Switch to Tax Report (Mod 349) (ES) 8) Choose date range: This Month 9) Generate BOE => It shows an error with a traceback `/l10n_es_reports/models/aeat_tax_reports.py", line 1257, in _write_type2_refund_records previous_report_amoun
Original PR description
Before this commit:
Steps
1) Install l10n_es_reports
2) Switch to ES company
3) Create a EU vendor (any except SPAIN) + add TIN
4) Create a bill with last month date
5) Reverse that bill with current month date
6) Go to Tax reports
7) Switch to Tax Report (Mod 349) (ES)
8) Choose date range: This Month
9) Generate BOE
=> It shows an error with a traceback `/l10n_es_reports/models/aeat_tax_reports.py", line 1257, in _write_type2_refund_records
previous_report_amount = invoice_line_data['columns'][0]['no_format']
TypeError: 'NoneType' object is not subscriptable`
After this commit:
BOE in mod349 is generated properly without errors
opw-4055702
Forward-Port-Of: odoo/enterprise#68096This is needed to evaluate this column_invisible expression https://github.com/odoo/enterprise/blob/985c085edc66ccb27311a94cfb16f27b06d7bfec/industry_fsm_sale/views/project_sharing_views.xml#L69 opw-4015035 Forward-Port-Of: odoo/enterprise#68216 Forward-Port-Of: odoo/enterprise#68110
Original PR description
This is needed to evaluate this column_invisible expression https://github.com/odoo/enterprise/blob/985c085edc66ccb27311a94cfb16f27b06d7bfec/industry_fsm_sale/views/project_sharing_views.xml#L69 opw-4015035 Forward-Port-Of: odoo/enterprise#68216 Forward-Port-Of: odoo/enterprise#68110
### Fixes in ATS report: - Remove foreign documents '15' and '110'. SRI DIMM returns a validation error  - In sales, filter by commercial partner and not by partner because there may be different addresses (the ATS validates by ID number). - In sales, change the emission point to entity point (tag "codEstab" and "numEstabRuc"). As it says the Technical Sheet of ATS 
- In sales, filter by commercial partner and not by partner because there may be different addresses (the ATS validates by ID number).
- In sales, change the emission point to entity point (tag "codEstab" and "numEstabRuc"). As it says the Technical Sheet of ATS
- In sales, Get all the establishments registered at the SRI (tag "ventasEstablecimiento"). As it says the Technical Sheet of ATS
- Fix Unit tests
Forward-Port-Of: odoo/enterprise#67060