Navigate
Branch
Thursday, August 15, 2024
42 changes
8 changes
Resolved issues and error corrections
This change prevents upgrades from incorrectly reassigning the short Spanish URL code when a regional Spanish language is already using it. It helps avoid upgrade errors for databases that enabled Spanish variants such as Argentina Spanish before moving to newer versions.
Original PR description
Steps to reproduce [`17.2`]: - Start a fresh DB. - Enable one of the Spanish sub-languages except the `Spanish LATAM` (the one with default `/es` url code) e.g., `"es_AR"`. - An error is triggered…
Steps to reproduce [`17.2`]: - Start a fresh DB. - Enable one of the Spanish sub-languages except the `Spanish LATAM` (the one with default `/es` url code) e.g., `"es_AR"`. - An error is triggered when upgrading to a `17.3+` version by the code trying to set the `'es'` url code while it was already available in another record. Starting from [1], we allow using the short url code `'es'` when a Spanish sub-language is enabled (as long as `es_419` is not) [A]. We also update the records in XML to set the Spanish LATAM (`es_419`) as the one with the default `'es'`, assuming that the `base.lang_es` record will always hold the `'es'` url code. Running the XML updates again in the situation of [A] will try to set the unique `es` url code on a record while another record (other than `base.lang_es`) is holding it (`"es_AR"` in this case). The goal of this commit is to simply add a `noupdate` for the XML updates so they are only loaded on initialization. [1]: https://github.com/odoo/odoo/commit/a992d2deab9d582cc33dc31f0b1bd610f82add0d 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 internal automated test for user presence updates so it no longer depends on timing-sensitive websocket behavior. The change helps keep test results stable and reduces false failures in development and release validation.
Original PR description
The `test_notify_on_status_change` ensures user presences are received when updated. To do so, they send a websocket message to the server. However, there is no guarantee the presence was updated after sending the message as the processing is asynchronous. This PR fixes the issue by directly calling `_update_presence` and waitng for the answer through the websocket. runbot-74017
Miscellaneous changes
Commit 775c113382231 change the variable name from `i` to `picking` but the fw-port 9a3b2940da55f keeps the old name. Resulting on the access token is never found. 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 Forward-Port-Of: odoo/odoo#176560
Original PR description
Commit 775c113382231 change the variable name from `i` to `picking` but the fw-port 9a3b2940da55f keeps the old name. Resulting on the access token is never found. 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 Forward-Port-Of: odoo/odoo#176560
steps: - be connected as someone with no accrual - give accrual allocation to an employee - go to his time offs using the smart button on his employee profile -> no settings to set the date, has_accrual_allocation is false because our user's employee doesn't have accrual allocation expected -> see the date picker on the leave dashboard if the employee has accrual allocations, not the connected user Forward-Port-Of: odoo/odoo#175686
Original PR description
steps: - be connected as someone with no accrual - give accrual allocation to an employee - go to his time offs using the smart button on his employee profile -> no settings to set the date, has_accrual_allocation is false because our user's employee doesn't have accrual allocation expected -> see the date picker on the leave dashboard if the employee has accrual allocations, not the connected user Forward-Port-Of: odoo/odoo#175686
Problem --------- Currently, when reversing a move, the current company is used as recipient bank. 1. Set a bank on a partner A 2. Go to Accounting 3. Set A as the customer of the invoice 4. Set a bank under 'recipient bank' in Other Info tab 5. Post the invoice 6. "Add Credit Note" 7. Fill in with wathever and press Reverse -> The Other Info tab of the reverse move has the company bank and not the customer's Objective --------- Obtain a similar behavior as when a credit note is
Original PR description
Problem --------- Currently, when reversing a move, the current company is used as recipient bank. 1. Set a bank on a partner A 2. Go to Accounting 3. Set A as the customer of the invoice 4. Set a bank under 'recipient bank' in Other Info tab 5. Post the invoice 6. "Add Credit Note" 7. Fill in with wathever and press Reverse -> The Other Info tab of the reverse move has the company bank and not the customer's Objective --------- Obtain a similar behavior as when a credit note is created directly: have the customer's bank set as recipient bank. Solution --------- Provide a default bank id that is set, if possible, to one of the customer's bank. opw-4035448 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173640
Steps to reproduce: - Create a product - Update its quantity and set 4 in Stock - Create two MO that consume each 2 units of that product with the same scheduled date - Create a scrap order with 1 quantity of that product and validate it Issue: The unreserve will be done on the first MO. When going through the candidate move lines in the `_free_reservation()`, we sort them depending on their picking, their date if they have a move, or their id if they don't. The issue is that when
Original PR description
Steps to reproduce: - Create a product - Update its quantity and set 4 in Stock - Create two MO that consume each 2 units of that product with the same scheduled date - Create a scrap order with 1 quantity of that product and validate it Issue: The unreserve will be done on the first MO. When going through the candidate move lines in the `_free_reservation()`, we sort them depending on their picking, their date if they have a move, or their id if they don't. The issue is that when their related move have an equal date, then the order becomes underministic. Now, always sort by their id as a last resort, so we have a consistent order no matter what. opw-4046240 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176399 Forward-Port-Of: odoo/odoo#174442
Steps to reproduce: 1. Install `l10n_in_withholding` and `l10n_it_edi_withholding` 2. Create a new company with country `India` and load CoA TDS taxes doesn't get created After this commit: We resolve the above issue. Since the issue was caused by a typo in the method name in `l10n_in_withholding` which had a definition in `l10n_it_edi_withholding` Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: ---
Original PR description
Steps to reproduce: 1. Install `l10n_in_withholding` and `l10n_it_edi_withholding` 2. Create a new company with country `India` and load CoA TDS taxes doesn't get created After this commit: We resolve the above issue. Since the issue was caused by a typo in the method name in `l10n_in_withholding` which had a definition in `l10n_it_edi_withholding` 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 Forward-Port-Of: odoo/odoo#176565
Steps: - install 'purchase' and 'analytic' - open purchase/RFQ - create a new rfq - add a new line in the subview list - Toggle `Analytic Distribution` optional column - Edit 'Analytic Distribution' col with the widget (`analytic_disribution`) - Select first column to edit it (`Projects (100%)`) - Click on `Search More` in the dropdown - A new dialog is opened `Search: Projects` - Go to filters and click `Add Custom Filter` - Another modal is now opened `Add Custom Filter` - Click on
Original PR description
Steps: - install 'purchase' and 'analytic' - open purchase/RFQ - create a new rfq - add a new line in the subview list - Toggle `Analytic Distribution` optional column - Edit 'Analytic Distribution'…
Steps:
- install 'purchase' and 'analytic'
- open purchase/RFQ
- create a new rfq
- add a new line in the subview list
- Toggle `Analytic Distribution` optional column
- Edit 'Analytic Distribution' col with the widget (`analytic_disribution`)
- Select first column to edit it (`Projects (100%)`)
- Click on `Search More` in the dropdown
- A new dialog is opened `Search: Projects`
- Go to filters and click `Add Custom Filter`
- Another modal is now opened `Add Custom Filter`
- Click on the first domain input
- After clicking on this input, the initial `analytic_distribution` drodown is closed
- This is the cause of the problem
- Validate your domain
- Traceback `Component is destroyed`
The initial problem comes from `AnalyticDistribution` Component.
There's a listener on `click`on `document` to manage whether or not to close the widget.
There are several cases that prevent the widget from closing:
- having an active modal containing a list view or kanban view with the following selectors:
- `'.o_modal:not(.o_inactive_modal) .o_list_view'`
- `'.o_modal:not(.o_inactive_modal) .o_kanban_view'`.
- if the click occurred in the widget element
- if the dropdown is closed
However in many other cases we have undesired behavior (unwanted closing of the widget):
- a click on dialog that is open and not modal (as in the steps above)
- a click on a popover
- drag and drop an active modal to the side
This fix normally corrects the first three cases, but unfortunately I haven't found a way to correct the case of the palette command where the `ev.target` is at the point where the element selected in the palette points into the dom, especially as this is not currently the customer's problem.
Here's how the other cases are fixed:
instead of having a condition for each case
(as there used to be for modal list view and modal kanban view)
```js
const modal = document.querySelector('.modal:not(.o_inactive_modal)');
const clickedInSearchMoreDialog = modal && modal.querySelector('.o_list_view') && modal.contains(ev.target);
const clickedInKanbanSelectorDialog = modal && modal.querySelector('.o_kanban_view') && modal.contains(ev.target);
```
I create a list of css selectors corresponding to the elements in which the `ev.target` must not be located in order to close. In particular, I include the two cases already handled by the code, as well as the new ones.
Instead of having the two previous conditions, I just have one selector in my list.
https://github.com/odoo/odoo/blob/4637514b4b1550014fc6affff1b0753ab9bc0f69/addons/analytic/static/src/components/analytic_distribution/analytic_distribution.js#L611
So I add the `o_popover` and `o_dialog` selectors to correct my initial problem.
When dragging and dropping a modal, the `ev.target` is always equal to the document, so to prevent the `analytic_distribution` widget from closing in this case I check that it's not equal to `documentElement`.
https://github.com/odoo/odoo/blob/4637514b4b1550014fc6affff1b0753ab9bc0f69/addons/analytic/static/src/components/analytic_distribution/analytic_distribution.js#L617
opw-3954404
Forward-Port-Of: odoo/odoo#16892025 changes
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#670609 changes
New functionality added to Odoo
This update adds support for two Luxembourg tax credit rules to the payroll system: the Employee Tax Credit (Crédit d'impôt salarié) and the Carbon Tax Compensation Credit (Crédit d'Impôt pour Compensation taxe Carbone). These new rules enable accurate calculation of employee tax benefits and carbon tax compensation in Luxembourg payroll processing.
Original PR description
This will add rules for the "Crédit d'impôt salarié" and for the "Crédit d'Impôt pour Compensation taxe Carbone" to the Luxembourg loca. Task: 3970107 Forward-Port-Of: odoo/enterprise#64260
Enhancements to existing features
This update extends the US payroll system to support Alabama, Nevada, Washington, and Colorado with their respective tax rules and calculations. The enhancement ensures accurate payroll processing for employees in these states and improves the robustness of the payroll calculation engine by adding proper error handling to prevent undefined variables.
Original PR description
This will add rules for the payroll in Alabama, Nevada, Washington and Colorado. Task: 3923285
The signing feature now enforces minimum size requirements for signature and document fields to prevent users from accidentally creating boxes that are too small to be practical. Fields will maintain a minimum width of 5.5% of the page width and a minimum height of 1% of the page height, ensuring better usability and consistency in document signing workflows.
Original PR description
This commit aims to add a minimum box size for sign items. regardless of how the user resizes them, they should maintain this minimum size. Task: 4014579
Resolved issues and error corrections
This update fixes two display problems in the sign module: labels with hourglass icons that were overlapping action buttons, and a search panel that was taking up too much space on smaller screens, hiding important content. The changes improve the layout so all elements display correctly regardless of screen size.
Original PR description
Before this commit, the bottom right label in sign templates which included the hourglass icon was overlapping the action buttons and the search panel in the left position of the screen was occupying a big part of the screen when the width was small, hiding the sign templates and sign documents in the bottom of the page. After this commit, the bottom right label does not overlaps the action buttons anymore and when the screen is small (in width) we hide the search panel for showing the sign templates and sign documents correctly. task-4077791
The field service reporting tour has been fixed to run independently regardless of whether demo data is loaded. Previously, the tour relied on specific demo data being present, which caused it to fail in environments without demo data. The fix adds fallback selectors to handle both scenarios, ensuring the tour works consistently across all installations.
Original PR description
- 17.0 <hr> - Currently, the tour is written according to the demo data. The selector .o_form_sheet div[name] input will match if the work template is 'Device Installation and Maintenance' . This template is available in the demo. If the demo loads, the default 'Device Installation and Maintenance' will be set via the post hook. When the demo does not load, we will have the default template instead. That's why we used the .o_form_sheet p.oe-command-temporary-hint class in the OR condition. - Remove import `loaded_demo_data` from industry_fsm tests because it was not in use from this [commit](https://github.com/odoo/enterprise/commit/90ca61c62ecb0e5ddcf4d1e1ec9e0a2bf27c27f1). task-4086026
Fixed a bug where users could resend signing request links even after the request was already completed, canceled, or refused, causing unwanted duplicate emails. The system now properly checks the status of signing requests before allowing resends, preventing email spam and confusion.
Original PR description
Versions:
------------
17.0
Steps to reproduce:
-------------------------
1. Send a sign request with 2 signers, setting a reminder to be sent every day.
2. Two emails will be sent to different signers.
3. Change the local date to 2 days ahead.
4. Run the "Send: Sign Reminder" cron.
- Two more emails will be received, and one signer will complete their sign request.
5. Change the dates again and run the cron job.
- One email will be sent to the remaining signer.
6. From the old sign request email, copy the link and try to resend it.
- The user should not be able to resend the new link.
Issue:
-------
Resending the link does not check the state of the sign request and items, allowing multiple sends.
Solution:
-----------
Resending the link is only possible if the request and items are not already completed, canceled, or refused.
task: 4002440This update fixes warning messages in Kenya's electronic invoicing system to only appear when a company has an active OSCU (Online Sales Control Unit). Previously, warnings about quantity mismatches on invoices and bills of materials would display regardless of whether the company was using Kenya's EDI system, causing unnecessary alerts for non-Kenyan users. The change also removes unused code to keep the system clean.
Original PR description
Two warnings need to be conditionally hidden if the company does not have an OSCU active: - the warning on invoices that the delivered quantities do not match invoiced quantities; and - the warning on BoMs. In addition, we take the opportunity to remove the method `env['product.product']._compute_l10n_ke_validation_message` which is dead code.
This fix prevents the creation of unnecessary zero-balance tax lines when reconciling bank statements with 0% tax rates. Previously, users would see empty tax lines in the reconciliation widget that would persist after validation. This update removes those unnecessary lines, making the reconciliation process cleaner and more accurate.
Original PR description
Have a 0% Tax Open bank reconciliation widget Reconcile a bank statement with a manual operation including the 0% tax Issue: On the reconciliation widget a void line will be shown After validation the 0 balance tax line will be created opw-4043498 Forward-Port-Of: odoo/enterprise#68159 Forward-Port-Of: odoo/enterprise#67458
The payroll module's guided training tours were broken due to outdated references to removed features. This fix updates the tours to work with the current payroll system, ensuring employees can properly learn how to use payroll functions through the interactive guided experience.
Original PR description
This commit fixes the broken tour in payroll as the previous one depended on actions that have been removed. task-3621276