Daily updates from Odoo
Friday, July 31, 2026
51 changes · saas-19.4
Resolved issues and error corrections
The Belgian minimum salary warning is now limited to employees under Belgian payroll rules. This prevents irrelevant salary alerts from appearing for employees in other countries, reducing confusion for payroll users.
Original PR description
[FIX] l10n_be: fix min salary warning appearance in other l18n Bug reproduc: 1 - Install l10n_be_hr_payroll 2 - Go to some US employee, make its wage to 10. 3 - The warning "Annual salary is below 34654" will be there. Bug cause: 1 - The issue is created without controlling the country of the version Bug solution: 1 - Add Belgium country check to the issue creation task-6412374 Forward-Port-Of: odoo/enterprise#125279
This fixes an automated test for Mexican point-of-sale invoicing by ensuring the original sale is fully synchronized before a refund is started. It helps keep refund and invoice validation reliable without changing the business workflow for users.
Original PR description
In this commit: =============== - Fix the `test_mx_pos_invoice_order_and_refund` tour, which fails with the warning: `The amount of the order must be positive for a sale and negative for a refund`. - The failure is caused by the refund flow starting before the original order has been fully synced with the backend. - A previous attempt to fix this in odoo/enterprise#109362 by waiting for `FeedbackScreen.isShown()` was not sufficient. Fix: ==== - Add a `Chrome.waitForOrdersSync()` waiting step to the tour to ensure the original order is fully synced before starting the refund flow. Error: 237980 Forward-Port-Of: odoo/enterprise#124948
This fix updates the Hungarian Intrastat tax return process to match recent changes in the Hungarian reporting setup. It prevents errors during return generation, helping businesses submit the required Intrastat information reliably.
Original PR description
Here https://github.com/odoo/odoo/pull/253556, we made few changes in the `l10n_hu` report. We basically split some expresions into multiple small one. This has been done for the integration of ec sales list (a60). But hu intrastat was still using the old expressions, leading to an error. This commit aims to adapt the intrastat code to fit with the new a60 expressions. no-task Forward-Port-Of: odoo/enterprise#122662
Ri.Ba. batch payment validation now accepts valid San Marino bank accounts in addition to Italian ones. This prevents payment file generation from being blocked for companies using San Marino IBANs and keeps the exported record format compliant.
Original PR description
**_Steps to reproduce :_** - Install l10n_it_riba. - Configure a company with a San Marino (SM) IBAN as the bank account for the journal used for Ri.Ba. - Create a customer payment and add it to a…
**_Steps to reproduce :_** - Install l10n_it_riba. - Configure a company with a San Marino (SM) IBAN as the bank account for the journal used for Ri.Ba. - Create a customer payment and add it to a Batch Payment using the Ri.Ba. payment method. - Validate the Batch Payment. **_Observed behavior :_** The validation fails with the error: `Only bank accounts with an Italian IBAN are allowed to use Ri.Ba. payments` **_Cause :_** The Ri.Ba. validation logic only accepts IBANs with the IT country code and incorrectly rejects valid San Marino (SM) IBANs. **_Fix :_** - Update the Ri.Ba. IBAN validation to accept both Italian (IT) and San Marino (SM) IBANs when generating Ri.Ba. payment files. - While validating Batch Payments for SM IBANs, we observed that the extracted value could overlap with the branch code portion, causing the generated RIBA record to exceed the expected 120-character length. This change updates the extraction logic to prevent overlap and ensure compliance with the required record format. **_opw_** - 6303820 Forward-Port-Of: odoo/enterprise#126082 Forward-Port-Of: odoo/enterprise#121439
The accounting reports now handle invoices linked to a tax that was originally a group of taxes but later changed. This prevents the Journal Report from failing, so users can continue reviewing audit reports even after tax configuration updates.
Original PR description
**Steps to reproduce:** - Install account_reports - Create a tax * Tax Computation: Group of Taxes * Definition: [Add a tax] - Create an invoice with that tax - Confirm the invoice - Edit the tax by changing "Tax Computation" to "Percentage" - Go to "Accounting / Reporting / Audit Reports / Journal Report" **Issue:** A KeyError is raised. **Cause:** While generating the data, a group of taxes is found in the journal items. When trying to retrieve its info from the dict listing the groups of taxes, its ID is not found but the system assumes that it's present. opw-6377465 Forward-Port-Of: odoo/enterprise#125291
This fix prevents crashes when selecting projects in the timesheet grid and makes keyboard selection behave as expected. Users can now use Space and Shift+Arrow to select items without accidentally opening forms or causing errors.
Original PR description
Previously, selecting items in the project view caused a crash because the component incorrectly iterated over group metadata instead of the underlying `.suggestions`. Additionally, keyboard navigation (Space or Shift+Arrow) inappropriately triggered the creation form, leading to errors on unmounted components. This commit: - Fixes the mapping logic to correctly iterate over `.suggestions`. - Decouples the selection logic from form opening, allowing Space to toggle selection and Shift+Arrow to select ranges smoothly. Forward-Port-Of: odoo/enterprise#126248
This fix prevents German point-of-sale transaction cancellations from being rejected when earlier transaction data lacks receipt details. It automatically uses a minimal cancellation receipt when needed, helping stores complete cancellations reliably while keeping existing transaction details unchanged.
Original PR description
When cancelling active transactions, the schema was forwarded as-is from the listed transaction. ACTIVE transactions can have an empty schema, and Fiskaly rejects the cancellation PUT with:
{
"code": "E_TX_NO_TYPE_DEFINED",
"message": "`schema.raw.process_type` must be defined for
updating or finishing a transaction",
"status_code": 409,
"error": "Conflict"
}
Fall back to a minimal CANCELLATION receipt schema when the transaction has no schema, while preserving any schema that is already present.
opw-6345005
Forward-Port-Of: odoo/enterprise#122130The Partner Ledger email wizard now opens correctly when several companies use different currencies. This prevents a crash during recipient calculation, allowing finance teams to send reports by email without interruption.
Original PR description
### Description of the issue/feature this PR addresses Sending the **Partner Ledger** report by email in a multi-currency setup (several companies using different currencies) crashes the send wizard…
### Description of the issue/feature this PR addresses Sending the **Partner Ledger** report by email in a multi-currency setup (several companies using different currencies) crashes the send wizard on opening with: ``` psycopg2.errors.UndefinedTable: relation "account_currency_table" does not exist ``` ### Current behavior before PR To compute the recipients, `AccountPartnerLedgerReportHandler._get_report_send_recipients` runs `_get_query_sums`, whose SQL joins the currency table. In a multi-currency setup that table is a **temporary** table that must be created beforehand by `AccountReport._init_currency_table`. Every regular rendering entry point calls `_init_currency_table` before running currency-table queries, but the report-sending path does not, so the query fails on a missing `account_currency_table` relation. ### Desired behavior after PR is merged `_init_currency_table(options)` is called before running the query, so the temporary table exists. It is a no-op in mono-currency setups (early return in `_init_currency_table`), so mono-currency behavior is unchanged. ### Steps to reproduce 1. Have several companies using different currencies. 2. Select more than one of them in the company switcher. 3. Open **Accounting > Reporting > Partner Ledger**. 4. Click **Send by email** → the wizard crashes on opening. Video: https://drive.google.com/file/d/1skpg7YDtxcY1PCtURyzk5PdFPi7ZPreG/view A regression test covering the multi-currency send-recipients path is included in `test_partner_ledger_report.py`. I've created the task #6362131 for this issue Forward-Port-Of: odoo/enterprise#124900 Forward-Port-Of: odoo/enterprise#122897
This update corrects an automated payroll attendance test so it uses the right pay category and overtime unit setup. It helps ensure payroll overtime scenarios are validated reliably, reducing the risk of future payroll issues going unnoticed.
Original PR description
Set the employee's Pay Category to the test structure type, so the pay run finds a matching version, and create the overtime work entry type in hours. Also drops the leftover Continue step after the payslip is opened. task-6432271 Forward-Port-Of: odoo/enterprise#126219
Payroll decimal precision settings will no longer be reset to default values when the Payroll module is upgraded. This protects company-specific payroll rounding and rate precision customizations from being silently overwritten.
Original PR description
decimal.precision records are user-configurable settings that may be adjusted per company needs. With noupdate="0", every module upgrade resets the 'Payroll' and 'Payroll Rate' precision values back to their defaults, silently discarding any customization made by the user. This is inconsistent with the standard pattern used across Odoo modules. For example, the 'quality' module correctly loads its decimal.precision records with noupdate="1". The same convention is followed in core addons such as 'product' and 'account'. The forcecreate="True" attribute already ensures the records are created on fresh installations, so noupdate="1" only prevents overwriting existing values on upgrade — which is the expected behavior for configuration data. Forward-Port-Of: odoo/enterprise#120509
The online payment status now updates correctly when users move between batch payment records. This prevents outdated payment information from appearing, helping users see whether each batch payment has been signed or is still pending.
Original PR description
To display the `payment_online_status` field, we use a widget called `account_online_payment_refresh_button`. The issue is that the widget don't update the field value when switching from one record to another. Steps to reproduce: 1. Create 2 batch payments 2. Do a payment initiation with the first one, and sign it 3. Do another payment initiation with the second one, but don't sign it. 4. Open 1 batch, and try to switch records with the pager 5. You should see the value is not updated task-6420585 Forward-Port-Of: odoo/enterprise#126215 Forward-Port-Of: odoo/enterprise#125643
Polish JPK tax exports now use the supplier's bill reference in the purchase document field when one is provided. This makes exported tax files better match official reporting requirements and avoids showing the internal vendor bill number instead.
Original PR description
**Steps to reproduce:** - Install the `l10n_pl_reports` module and switch to a `PL Company`. - Create and confirm a vendor bill with a `Bill Reference` and `Taxes`. - Navigate to Accounting >…
**Steps to reproduce:** - Install the `l10n_pl_reports` module and switch to a `PL Company`. - Create and confirm a vendor bill with a `Bill Reference` and `Taxes`. - Navigate to Accounting > Reporting > Tax Report and select `This Month`. - From the dropdown, click `JPK` > `Export XML`. - Open the generated XML file and observe the `DowodZakupu` field. **Observation:** `DowodZakupu` contains the vendor `Bill Number` even when a `Bill Reference` is set. **Root Cause:** At [1], `DowodZakupu` is populated only with the vendor `Bill number`(`move_name`) instead of using the `Bill reference`(`ref`) when available. **Fix:** This commit ensures `DowodZakupu` contains the `Bill Reference` when it is available in JPK exports. **Reference:** https://www.podatki.gov.pl/media/eqrn3dey/broszura-jpk_vat-z-deklaracj%C4%85-od-1-lutego-2026-r-en.pdf (page 41) [1]: https://github.com/odoo/enterprise/blob/4b0404058b280136f6865090562f95e18d4d7e0b/l10n_pl_reports/data/jpk_export_templates.xml#L208 opw-6299827 Forward-Port-Of: odoo/enterprise#126113 Forward-Port-Of: odoo/enterprise#121117
This fix prevents a Knowledge automated tour from failing because of leftover collaboration state from a previous test. It improves the reliability of internal quality checks without changing how users interact with Knowledge.
Original PR description
This aims to fix Runbot build error #937788 ([1]) which wasn't fully fixed by commit [2] (see error #944595 ([3])). A collaboration error was thrown during a tour which makes no use of collaboration. Commit [2] made sure the bus from the previous test didn't persist when running this tour so it doesn't interfere, but it didn't fully reset it. [1]: https://runbot.odoo.com/odoo/runbot.build.error/937788 [2]: https://github.com/odoo/enterprise/commit/a6050dd60c587d09443907bdf955805159dbdb2e [3]: https://runbot.odoo.com/odoo/runbot.build.error/944595 Forward-Port-Of: odoo/enterprise#126195
Corrected a small payroll validation error that could prevent the Mexican payroll accounting EDI module from installing successfully. This helps ensure companies using Mexican payroll localization can install or upgrade the module without encountering an unexpected failure.
Original PR description
[`_l10n_mx_is_curp_needed`] was called with self instead of slip. However, the method expects a payslip record from its caller, [`_compute_issues`]. This typo was introduced in:…
[`_l10n_mx_is_curp_needed`] was called with self instead of slip. However, the method expects a payslip record from its caller, [`_compute_issues`].
This typo was introduced in:
odoo/enterprise@07201466e54f28c6d295d63b908e9a65e39f4862
```py
/home/odoo/src/enterprise/saas-19.3/hr_payroll/models/hr_payslip.py(1913)_compute_issues()
-> issues = generate_issue(slip, context)
/home/odoo/src/enterprise/saas-19.3/l10n_mx_hr_payroll_account_edi/models/hr_payslip.py(235)_issue_mx_warnings()
-> if not slip.company_id.l10n_mx_curp and self._l10n_mx_is_curp_needed():
/home/odoo/src/enterprise/saas-19.3/l10n_mx_hr_payroll_account_edi/models/hr_payslip.py(322)_l10n_mx_is_curp_needed()
-> not self.company_id.partner_id.is_company
/home/odoo/src/odoo/saas-19.3/odoo/orm/fields.py(1726)__get__()
-> record.ensure_one()
> /home/odoo/src/odoo/saas-19.3/odoo/orm/models.py(5344)ensure_one()
-> raise ValueError("Expected singleton: %s" % self)
```
This causes module installation to fail with:
```py
File "/home/odoo/src/odoo/saas-19.3/odoo/tools/convert.py", line 779, in convert_csv_import
raise Exception(env._(
Exception: Module loading l10n_mx_hr_payroll_account_edi failed: file l10n_mx_hr_payroll_account_edi/data/hr.employee.type.csv could not be processed:
Ocurrió un error desconocido durante la importación: <class 'ValueError'>: Expected singleton: res.partner(7, 9)
```
upg-4468049
[`_l10n_mx_is_curp_needed`]: https://github.com/odoo/enterprise/blob/saas-19.3/l10n_mx_hr_payroll_account_edi/models/hr_payslip.py#L235
[`_compute_issues`]: https://github.com/odoo/enterprise/blob/saas-19.3/hr_payroll/models/hr_payslip.py#L1904-L1913
Forward-Port-Of: odoo/enterprise#126096
Forward-Port-Of: odoo/enterprise#125623This fixes how Mexican electronic payment documents calculate related invoice balances when exchange rate differences and credit notes are involved. Businesses should see accurate paid and remaining amounts in CFDI payment XMLs, reducing reporting errors after invoices are fully settled.
Original PR description
### Issue: Attributes of DoctoRelacionado node in the XML display an incorrect value because the exchange rate difference entry distorts the calculation, even though the invoice was fully settled.…
### Issue: Attributes of DoctoRelacionado node in the XML display an incorrect value because the exchange rate difference entry distorts the calculation, even though the invoice was fully settled. https://drive.google.com/file/d/1ntQny0o8bkkfYtY5ZNBK0Yq7Rq0I-yfz/view ### Fix: Sorting partials by "not exchange_move_id" first broke the chronological order whenever the invoice/payment partial itself carried an exchange difference (e.g. a foreign currency payment settled at another rate). This made the residual-chain algorithm consume the credit note's "other_residual" on the wrong payment, so ImpSaldoAnt/ImpPagado/ ImpSaldoInsoluto in the payment CFDI's DoctoRelacionado stayed wrong even though the invoice was fully paid. Populate the exchange move mapping in a separate first pass and sort the partials purely by date/id, so credit notes are always deducted from the correct payment. task-id:[6363092](https://www.odoo.com/odoo/project/49/tasks/6363092) Forward-Port-Of: odoo/enterprise#126061 Forward-Port-Of: odoo/enterprise#124882
The POS preparation display badge now counts the same active orders that appear on the preparation screen. This prevents overnight orders from disappearing from the badge too early and stops reset orders from being counted after they are removed from the screen.
Original PR description
Steps to reproduce: - Configure a preparation display on a POS config with a product category - Place an order and leave it in a non-final stage - Keep the session open past midnight Issue: The…
Steps to reproduce: - Configure a preparation display on a POS config with a product category - Place an order and leave it in a non-final stage - Keep the session open past midnight Issue: The kanban order-count badge drops the order once its create_date falls behind "today", while the preparation screen still lists it. The same divergence makes the badge keep counting an order that a "Reset" already removed from the screen. _compute_order_count() scoped its search on pos_config_id and create_date >= today, whereas the screen is built by get_preparation_display_order() from _get_open_orders_in_display() and _get_stageless_orders_in_display(), which have no date filter and instead bound the set by the order stage `done` flag and the session state. An order open across midnight is therefore in the screen set but not in the badge set. Conversely reset() marks the current stage done, which drops the order from the screen set, but the badge only skipped orders whose latest stage is the final stage, so an order reset while still in the first stage stayed counted. opw-6414302 Forward-Port-Of: odoo/enterprise#126139 Forward-Port-Of: odoo/enterprise#125984
A previous fix that only applied to an older version was incorrectly carried forward and could cause an error in the bank reconciliation quick create flow. This update removes that unsuitable change so the accounting workflow behaves correctly in this version.
Original PR description
This commit https://github.com/odoo/enterprise/commit/e559d9f5acbd176792db0dedc4e1f0cad7271457 fixed a problem only happening in 19.0. The commit shouldn't have been forward ported. no task id Forward-Port-Of: odoo/enterprise#126039
Bank reconciliation now shows the same supporting attachments in the list view as users already see in the kanban view. This reduces confusion and helps accounting teams access the right documents consistently during reconciliation.
Original PR description
The aim of this commit is showing the same attachment in the bank reconciliation list view than in the kanban view. Before this commit, the field used to display the attachments was attachment_ids, this field were a related on the attachment_ids from account.move. This fix, removes the related to only keep a domain on the One2Many field. Thanks to the relational database, Odoo is giving us the right attachments when we want to display the field. task-6153002 Forward-Port-Of: odoo/enterprise#117245
Steps: - Install portal app - Go to my/addresses page. - Update main address of current user. Issues: - `Main Address` badge is not visible on main address. - Editing main address is not opening `my/account` page. Cause: - Since PR https://github.com/odoo/odoo/pull/232539 t-call syntax changed and expect to add attribute directly instead t-set but forget to adept it for `is_user_address` and `address_update_url`. Fix: - Move those variable directly into t-call instead t-set. For
Original PR description
Steps: - Install portal app - Go to my/addresses page. - Update main address of current user. Issues: - `Main Address` badge is not visible on main address. - Editing main address is not opening `my/account` page. Cause: - Since PR https://github.com/odoo/odoo/pull/232539 t-call syntax changed and expect to add attribute directly instead t-set but forget to adept it for `is_user_address` and `address_update_url`. Fix: - Move those variable directly into t-call instead t-set. Forward-Port-Of: odoo/odoo#278812
Error-1 : ``` raise ValueError('External ID not found in the system: %s' % xmlid) ValueError: External ID not found in the system: account.1_l10n_id_domestic_fiscal_position ``` Error-2 : ``` raise ValueError('External ID not found in the system: %s' % xmlid) ValueError: External ID not found in the system: account.1_tax_luxury_sales ``` Reason-1 : - In [this](https://github.com/odoo/odoo/commit/e342a45aceb60b44052c5d52e9ecc35a9a7340da) commit new account.fiscal.positions were ad
Original PR description
Error-1 : ``` raise ValueError('External ID not found in the system: %s' % xmlid) ValueError: External ID not found in the system: account.1_l10n_id_domestic_fiscal_position ``` Error-2 : ``` raise…
Error-1 :
```
raise ValueError('External ID not found in the system: %s' % xmlid)
ValueError: External ID not found in the system:
account.1_l10n_id_domestic_fiscal_position
```
Error-2 :
```
raise ValueError('External ID not found in the system: %s' % xmlid)
ValueError: External ID not found in the system: account.1_tax_luxury_sales
```
Reason-1 :
- In [this](https://github.com/odoo/odoo/commit/e342a45aceb60b44052c5d52e9ecc35a9a7340da) commit new account.fiscal.positions were added and linked to acc.tax using fiscal_position_ids .
- In [this](https://github.com/odoo/odoo/blob/saas-19.2/addons/l10n_id/migrations/1.3/end-migrate_update_taxes.py) migration script, while creating taxes it didnt find fiscal positions, so need to create them first.
Reason-2 :
- original_tax_ids was also added in same commit, if client deleted those tax(ie tax_luxury_sales) will fail while creating `tax_luxury_sales_pemungut_ppn`, It needs to be created first too.
- upg : [4341887](https://upgrade.odoo.com/odoo/upgrade.request/4341887)
- opw : [6285978](https://www.odoo.com/odoo/project/70/tasks/6285978)
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#269802Currently, an error occurs when installing the hr_holidays_attendance module. **Steps to Reproduce:** - Install the `hr_attendance` module without demo data. - Go to `Attendance` > `Configuration` > `Overtime Rulesets` and open the `Default Ruleset` record. - Delete its `linked overtime rules`. - Install the `hr_holidays_attendance` module. **Error:** ```py Exception: Cannot update missing record 'hr_attendance.hr_attendance_overtime_employee_schedule_rule' odoo.tools.conver
Original PR description
Currently, an error occurs when installing the hr_holidays_attendance module. **Steps to Reproduce:** - Install the `hr_attendance` module without demo data. - Go to `Attendance` > `Configuration` >…
Currently, an error occurs when installing the hr_holidays_attendance module.
**Steps to Reproduce:**
- Install the `hr_attendance` module without demo data.
- Go to `Attendance` > `Configuration` > `Overtime Rulesets` and open the `Default Ruleset` record.
- Delete its `linked overtime rules`.
- Install the `hr_holidays_attendance` module.
**Error:**
```py
Exception: Cannot update missing record 'hr_attendance.hr_attendance_overtime_employee_schedule_rule'
odoo.tools.convert.ParseError: while parsing /home/odoo/odoo18/community/addons/hr_holidays_attendance/data/hr_holidays_attendance_data.xml:7, somewhere inside <record id="hr_attendance.hr_attendance_overtime_employee_schedule_rule" model="hr.attendance.overtime.rule">
<field name="compensable_as_leave" eval="True"/>
</record>
```
This error occurs when the user deletes all overtime rules and then installs the hr_holidays_attendance
module. During installation, the module attempts to update the deleted overtime rule records,
which raises an error [1].
This commit uses forcecreate="0" to skip updating records if the corresponding overtime
rules do not exist.
[1]- https://github.com/odoo/odoo/blob/da0a83761f38ee4a2940015b6c8f7190c310a4a0/addons/hr_holidays_attendance/data/hr_holidays_attendance_data.xml#L7-L12
sentry-7372074675
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#279088
Forward-Port-Of: odoo/odoo#277656Reading the `display_name` of a working schedule line of a 2 weeks calendar crashes: the compute reads `record.weektype` while the field is named `week_type`. ### Steps to reproduce - Switch a working schedule to a 2 weeks calendar. - Open one of its lines in a form view, e.g. with the `View Button` optional column in developer mode. opw-6427314 Forward-Port-Of: odoo/odoo#279194
Original PR description
Reading the `display_name` of a working schedule line of a 2 weeks calendar crashes: the compute reads `record.weektype` while the field is named `week_type`. ### Steps to reproduce - Switch a working schedule to a 2 weeks calendar. - Open one of its lines in a form view, e.g. with the `View Button` optional column in developer mode. opw-6427314 Forward-Port-Of: odoo/odoo#279194
With pos_hr enabled, the cash in/out popup uses the cashier's `work_contact_id` as partner for the `account.bank.statement.line`. When that partner is archived or not part of the limited partner loading, the relation cannot be resolved in the frontend and the statement line is created with `partner_id = False`. Deleting such a cash move then crashes in `delete_cash_in_out`: File ".../point_of_sale/models/pos_session.py", line 1877, in delete_cash_in_out action = cashier_name +
Original PR description
With pos_hr enabled, the cash in/out popup uses the cashier's `work_contact_id` as partner for the `account.bank.statement.line`. When that partner is archived or not part of the limited partner…
With pos_hr enabled, the cash in/out popup uses the cashier's `work_contact_id` as partner for the `account.bank.statement.line`. When that partner is archived or not part of the limited partner loading, the relation cannot be resolved in the frontend and the statement line is created with `partner_id = False`.
Deleting such a cash move then crashes in `delete_cash_in_out`:
File ".../point_of_sale/models/pos_session.py", line 1877, in delete_cash_in_out
action = cashier_name + ': ' + str(amount)
TypeError: unsupported operand type(s) for +: 'bool' and 'str'
Steps to reproduce:
- Enable "Multi Employees per Session" (pos_hr) on a PoS config
- Archive the work contact of an employee, or make sure it is not included in the limited partner loading
- Open a session, log in as that employee and register a cash in/out
- As a manager, delete the cash move from the cash move list => Traceback, the cash move cannot be deleted
opw-6389830
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#278462
Forward-Port-Of: odoo/odoo#276598[FIX] stock: fix user permission to edit lots Issue: An user with the Role/User that is Inventory/Administrator is unable to edit the custom Lot/Serial Steps to reproduce: 1. Take a user with Role/User 2. Assign them Inventory/Administrator 3. Log in as this user and create a product tracked by lots 4. Go to the Inventory tab and try editing the field Custom Lot/Serial Cause: Only Role/Administrator can create Ir.Sequence, therefore even if a Role/User is Inventory/Administrator tri
Original PR description
[FIX] stock: fix user permission to edit lots Issue: An user with the Role/User that is Inventory/Administrator is unable to edit the custom Lot/Serial Steps to reproduce: 1. Take a user with Role/User 2. Assign them Inventory/Administrator 3. Log in as this user and create a product tracked by lots 4. Go to the Inventory tab and try editing the field Custom Lot/Serial Cause: Only Role/Administrator can create Ir.Sequence, therefore even if a Role/User is Inventory/Administrator tries to create a new Ir.Sequence (ex: editing a custom Lot/Serial) it will still throw him an error as he is not Role/Administrator Fix: To avoid the permissions issue at the time of creation we use sudo to bypass the Role/User lack of permissions. opw-6269415 Forward-Port-Of: odoo/odoo#278453 Forward-Port-Of: odoo/odoo#268799
Stripe recommends connecting to a reader returned by the most recent discovery call. However, the POS Stripe interface discovered readers as soon as the Stripe Terminal object was created, during POS loading. This means a POS reload performed long before the first payment could populate `pos.discoveredReaders` with stale reader objects. If the first Stripe Terminal payment happens much later, the SDK may try to connect using outdated reader/credential state and fail with an expired Connection
Original PR description
Stripe recommends connecting to a reader returned by the most recent discovery call. However, the POS Stripe interface discovered readers as soon as the Stripe Terminal object was created, during POS loading. This means a POS reload performed long before the first payment could populate `pos.discoveredReaders` with stale reader objects. If the first Stripe Terminal payment happens much later, the SDK may try to connect using outdated reader/credential state and fail with an expired ConnectionToken. Move reader discovery to `connectReader()` so Odoo connects using fresh discovery results, and stop discovering readers eagerly when creating the Stripe Terminal instance. opw-6311626 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#277765 Forward-Port-Of: odoo/odoo#276875
### Issue: When importing EDI documents such as Peppol files, Swiss VAT numbers may be formatted or unformatted When `base_vat` is installed, VAT is stored formatted in Odoo (e.g. `CHE-530.781.296 TVA`) If the format differs, the matching fails and a new partner is created at each import ### Cause: `_retrieve_partner` lacked Swiss-specific VAT normalization logic in `_get_country_specific_vat_variants`, causing it to miss formatted variants with language suffixes (`TVA`, `MWST`, `IVA`)
Original PR description
### Issue: When importing EDI documents such as Peppol files, Swiss VAT numbers may be formatted or unformatted When `base_vat` is installed, VAT is stored formatted in Odoo (e.g. `CHE-530.781.296…
### Issue: When importing EDI documents such as Peppol files, Swiss VAT numbers may be formatted or unformatted When `base_vat` is installed, VAT is stored formatted in Odoo (e.g. `CHE-530.781.296 TVA`) If the format differs, the matching fails and a new partner is created at each import ### Cause: `_retrieve_partner` lacked Swiss-specific VAT normalization logic in `_get_country_specific_vat_variants`, causing it to miss formatted variants with language suffixes (`TVA`, `MWST`, `IVA`) Even when the match succeeded, `_import_ubl_create_missing_customer` still compared VAT strings without stripping `-` and lang suffixes for CH partners, causing a false mismatch and triggering partner creation anyway ### Notes: The partner match improvement is backported from 18.3: https://github.com/odoo/odoo/commit/f1a5a3d72a26ee471d2ef1d8034136208b2bcebc The original fix was incomplete — it added `_get_country_specific_vat_variants` but missed the VAT comparison fix in `_import_ubl_create_missing_customer`, allowing the issue to persist after a successful match `base_vat` is required to get the fix fully working ### Steps to reproduce: - Install `account` and `base_vat` - Create a Vendor (Name: Test CH Vendor, Country: Switzerland, Tax ID: CHE-530.781.296 TVA) - Import a [Peppol Bill](https://github.com/user-attachments/files/27202997/CH_bill_to_import.xml) with VAT `CHE530781296TVA` Before the fix, a new partner is created instead of matching the existing one opw-6353387 Forward-Port-Of: odoo/odoo#279184 Forward-Port-Of: odoo/odoo#274398
Following the rework of payment provider states (cf. PR https://github.com/odoo/odoo/pull/249545), `_toggle_post_processing_cron` only checked for installed providers using `module_state in ('installed', 'to install')`. However, providers that are not linked to a specific module (such as custom providers or test providers) have `module_id = False`, which causes `module_state` to evaluate to `False`. As a result, setting up these providers left the post-processing cron inactive, causing `test
Original PR description
Following the rework of payment provider states (cf. PR https://github.com/odoo/odoo/pull/249545),
`_toggle_post_processing_cron` only checked for installed providers using `module_state in ('installed', 'to install')`.
However, providers that are not linked to a specific module (such as custom providers or test providers) have `module_id = False`, which causes `module_state` to evaluate to `False`. As a result, setting up these providers left the post-processing cron inactive, causing `test_installing_provider_activates_post_processing_cron` to fail.
This commit updates the search domain in
`_toggle_post_processing_cron()` to also include providers where `module_id = False`, matching the domain logic used in `_find_available_providers()`.
runbot-940173Taxes with SAF-T code 21 and 22 are not correct and needed modification where they should be set to 0% because: - The foreign supplier invoices without Norwegian VAT, so the invoice total shouldn't increase - You must still self-assess 25% VAT and report it - The 25% is booked as both output and input VAT simultaneously → net cash effect = 0 - Only the basis amount is reported in the VAT return (import boxes) task-6254727 Forward-Port-Of: odoo/odoo#278896 Forward-Port-Of: odoo/odoo#26751
Original PR description
Taxes with SAF-T code 21 and 22 are not correct and needed modification where they should be set to 0% because: - The foreign supplier invoices without Norwegian VAT, so the invoice total shouldn't increase - You must still self-assess 25% VAT and report it - The 25% is booked as both output and input VAT simultaneously → net cash effect = 0 - Only the basis amount is reported in the VAT return (import boxes) task-6254727 Forward-Port-Of: odoo/odoo#278896 Forward-Port-Of: odoo/odoo#267510
The mail.message/delete bus handler accessed selfMember?.seen_message_id.id with optional chaining only on selfMember, not on seen_message_id. When a member has never seen any message in a channel (seen_message_id is False), accessing .id threw 'TypeError: can't access property id, selfMember.seen_message_id is undefined', breaking message deletion for that user (e.g. deleting a message in a channel the user never opened. Add optional chaining on seen_message_id so the unread counter is simpl
Original PR description
The mail.message/delete bus handler accessed selfMember?.seen_message_id.id with optional chaining only on selfMember, not on seen_message_id. When a member has never seen any message in a channel (seen_message_id is False), accessing .id threw 'TypeError: can't access property id, selfMember.seen_message_id is undefined', breaking message deletion for that user (e.g. deleting a message in a channel the user never opened. Add optional chaining on seen_message_id so the unread counter is simply not decremented when no message has been seen yet. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#279279 Forward-Port-Of: odoo/odoo#277417
Test `load dashboard that doesn't exist` sometimes fails because the test doesn't wait for the rpc to complete before checking the error message. This commit adds a wait for the next animation frame to ensure the rpc has completed before checking the error message. Runbot-940389 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/su
Original PR description
Test `load dashboard that doesn't exist` sometimes fails because the test doesn't wait for the rpc to complete before checking the error message. This commit adds a wait for the next animation frame to ensure the rpc has completed before checking the error message. Runbot-940389 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#279418
Follow-up to #247929, which limited `forever` recurrences to a 15-year horizon (`calendar.max_recurrence_years`) for *yearly* and *monthly* frequencies but left *weekly* and *daily* on the hard cap `MAX_RECURRENT_EVENT` (720), ignoring the parameter. A weekly `forever` event therefore always materializes 720 occurrences (~14 years) regardless of `calendar.max_recurrence_years`, and a daily one ignores the parameter too. This applies the year limit to weekly and daily as well, accounting for th
Original PR description
Follow-up to #247929, which limited `forever` recurrences to a 15-year horizon (`calendar.max_recurrence_years`) for *yearly* and *monthly* frequencies but left *weekly* and *daily* on the hard cap `MAX_RECURRENT_EVENT` (720), ignoring the parameter. A weekly `forever` event therefore always materializes 720 occurrences (~14 years) regardless of `calendar.max_recurrence_years`, and a daily one ignores the parameter too. This applies the year limit to weekly and daily as well, accounting for the number of selected weekdays and the interval, while still capping at `MAX_RECURRENT_EVENT`. Steps to reproduce: 1. Set `calendar.max_recurrence_years` to e.g. 2. 2. Create a weekly event repeating "forever". 3. Before: 720 occurrences (~14 years). After: ~106 (2 years). task / context: extends #247929. Forward-Port-Of: odoo/odoo#272615 Forward-Port-Of: odoo/odoo#270348
hash_sign has become very used all over the place, so more and more tokens depend on `database.secret`, increasing the impact of that secret needing one day to be rotated or being compromised. To avoid making `database.secret` a single point of failure, we would like `hash_sign` to support a custom secret supplied by caller. task-6391264 Forward-Port-Of: odoo/odoo#278256 Forward-Port-Of: odoo/odoo#276474
Original PR description
hash_sign has become very used all over the place, so more and more tokens depend on `database.secret`, increasing the impact of that secret needing one day to be rotated or being compromised. To avoid making `database.secret` a single point of failure, we would like `hash_sign` to support a custom secret supplied by caller. task-6391264 Forward-Port-Of: odoo/odoo#278256 Forward-Port-Of: odoo/odoo#276474
Steps to reproduce --- 1. Confirm a purchase order and receive it a few days later. 2. Open Purchase, Reporting, Purchase and add the "Effective Days To Arrival" measure. Observed: the value is counted from the line's scheduled date instead of the order date, and can even be negative when the scheduled date precedes the confirmation date. Issue --- The metric is meant to be the effective lead time, the number of days between the order confirmation and the actual receipt, falling back
Original PR description
Steps to reproduce --- 1. Confirm a purchase order and receive it a few days later. 2. Open Purchase, Reporting, Purchase and add the "Effective Days To Arrival" measure. Observed: the value is…
Steps to reproduce --- 1. Confirm a purchase order and receive it a few days later. 2. Open Purchase, Reporting, Purchase and add the "Effective Days To Arrival" measure. Observed: the value is counted from the line's scheduled date instead of the order date, and can even be negative when the scheduled date precedes the confirmation date. Issue --- The metric is meant to be the effective lead time, the number of days between the order confirmation and the actual receipt, falling back to the planned "days to receive" when nothing has been received yet according to [task](https://www.odoo.com/odoo/project/809/tasks/3691573). The query instead computes age(date_planned, COALESCE(date_done, date_order)), so once a receipt exists it returns date_planned - date_done (the gap between the scheduled date and the receipt) rather than date_done - date_order. https://github.com/odoo/odoo/blob/c06be48ce7277a667719fd756e0a1f63e91cda27/addons/purchase_stock/report/purchase_report.py#L20-L28 opw-6226523 Forward-Port-Of: odoo/odoo#279267 Forward-Port-Of: odoo/odoo#268843
Problem: Clicking an image padding option in Studio reports closes the dropdown, but the selected option is not applied. Cause: When editing inside an `iframe`, `unFocusEditable` is triggered on `focusin`, which runs `selection_leave_handlers` and closes the dropdown before the `click` event can propagate. Solution: Add `data-prevent-closing-overlay="true"` to the image padding dropdown, as done for other dropdowns, so it remains open until the click event is handled. Steps to reprod
Original PR description
Problem: Clicking an image padding option in Studio reports closes the dropdown, but the selected option is not applied. Cause: When editing inside an `iframe`, `unFocusEditable` is triggered on `focusin`, which runs `selection_leave_handlers` and closes the dropdown before the `click` event can propagate. Solution: Add `data-prevent-closing-overlay="true"` to the image padding dropdown, as done for other dropdowns, so it remains open until the click event is handled. Steps to reproduce: - Open a new report. - Add an image. - Select the image. - Open the padding dropdown. - Click a padding option. - Observe that the dropdown closes but the padding is not applied. task-6368964 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#279408 Forward-Port-Of: odoo/odoo#276448
The test "show pulse effect on fullscreen mode only when another participant's camera is on" fails from time to time on runbot: the pulse never lands on the fullscreen button. The first rtc session of a channel posts a call notification message, whose new_message notification fetches channels_as_member. That response carries the rtc sessions with their server values, so when it lands after the mock remote turned the camera on, is_camera_on goes back to false. videoCountNotSelf drops to 0 and
Original PR description
The test "show pulse effect on fullscreen mode only when another participant's camera is on" fails from time to time on runbot: the pulse never lands on the fullscreen button. The first rtc session of a channel posts a call notification message, whose new_message notification fetches channels_as_member. That response carries the rtc sessions with their server values, so when it lands after the mock remote turned the camera on, is_camera_on goes back to false. videoCountNotSelf drops to 0 and its onUpdate sets promoteFullscreen to INACTIVE for good, as only a change of the count sets it back to ACTIVE. A real participant also stores is_camera_on on the server, so a fetch never brings outdated values back. Make the mock remote do the same. https://runbot.odoo.com/odoo/error/242050 Forward-Port-Of: odoo/odoo#279178
In the Italian localization, a bill should not be reset to draft once it has been sent to SDI. The exception is when the document was rejected or imported (0440cbab7a9cc183c7836fe58196799afdc00513). Steps to reproduce: - Create a vendor bill with l10n_it_edi enabled. - Send it to SDI. - The "Reset to Draft" button is still visible. opw-6350928 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#273616
Original PR description
In the Italian localization, a bill should not be reset to draft once it has been sent to SDI. The exception is when the document was rejected or imported (0440cbab7a9cc183c7836fe58196799afdc00513). Steps to reproduce: - Create a vendor bill with l10n_it_edi enabled. - Send it to SDI. - The "Reset to Draft" button is still visible. opw-6350928 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#273616
Clicking a Unit Cost in the stock report opens the Unit Cost History of that product. The action filters on `active_id`, which the cost cell fills with the id of the row that was clicked. That value was overwritten: the cell context was merged first and the context of the running action last, so the latter won. When the list comes from "Inventory at Date", that context carries the id of the `stock.quantity.history` record the wizard just created, which is not a product id at all. The history
Original PR description
Clicking a Unit Cost in the stock report opens the Unit Cost History of that product. The action filters on `active_id`, which the cost cell fills with the id of the row that was clicked. That value was overwritten: the cell context was merged first and the context of the running action last, so the latter won. When the list comes from "Inventory at Date", that context carries the id of the `stock.quantity.history` record the wizard just created, which is not a product id at all. The history then opens on whichever product happens to carry that id, and stays empty when none does. Steps to reproduce: - Inventory > Reporting > Stock, click a Unit Cost -> the history of that product opens, as expected - go back, click "Inventory at Date" and confirm - click that same Unit Cost -> another product's history opens, or an empty list opw-6391778 Forward-Port-Of: odoo/odoo#279116
**Issue:** `test_mail_template_dynamic_placeholder_tour` tour is failing sometimes with the following error: `Tour mail_template_dynamic_field_tour → Step Click on contact (trigger: div[name="model_id"] .ui-autocomplete). TypeError: Cannot read properties of undefined (reading 'click')` **Cause:** It happens that the element is not loaded yet after the delay and clicking on an undefined element triggers the error. **Solution:** Make sure to only click on the element when it's ready.
Original PR description
**Issue:** `test_mail_template_dynamic_placeholder_tour` tour is failing sometimes with the following error: `Tour mail_template_dynamic_field_tour → Step Click on contact (trigger: div[name="model_id"] .ui-autocomplete). TypeError: Cannot read properties of undefined (reading 'click')` **Cause:** It happens that the element is not loaded yet after the delay and clicking on an undefined element triggers the error. **Solution:** Make sure to only click on the element when it's ready. runbot-223306 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#278983 Forward-Port-Of: odoo/odoo#277954
Currently, when adding a line discount it does not reflect on the receipt. Steps to reproduce: ------------------- * Add items to the order * For one of them use a line discount (% button) * Pay the order * Generate the receipt > The mention x% discount off on y is not displayed Why the fix: ------------ On the product screen the mention is shown and the value is computed here: https://github.com/odoo/odoo/blob/fc2230fb44dc421fe280d49da9b2d8134e1a0702/addons/point_of_sale/static/s
Original PR description
Currently, when adding a line discount it does not reflect on the receipt. Steps to reproduce: ------------------- * Add items to the order * For one of them use a line discount (% button) * Pay the order * Generate the receipt > The mention x% discount off on y is not displayed Why the fix: ------------ On the product screen the mention is shown and the value is computed here: https://github.com/odoo/odoo/blob/fc2230fb44dc421fe280d49da9b2d8134e1a0702/addons/point_of_sale/static/src/app/models/accounting/pos_order_line_accounting.js#L54-L66 We can reuse this fonction for the frontend, in the backend we translate it. We don't show this mention for the chosen products of a combo product. opw-6290821 Forward-Port-Of: odoo/odoo#274717 Forward-Port-Of: odoo/odoo#270734
Routes inherited from product category are not available when on replenish. Steps to reproduce: ------------------- * Create a new route and allow it on product category * Create a product category and add the route * Add the category to a product * use the repenish button -> the category route is not available on the replenishment Observation: ------------- When opening replenishment, it will open the view_product_replenish, in that view, it will use allowed_route_ids to allow us
Original PR description
Routes inherited from product category are not available when on replenish. Steps to reproduce: ------------------- * Create a new route and allow it on product category * Create a product category…
Routes inherited from product category are not available when on replenish. Steps to reproduce: ------------------- * Create a new route and allow it on product category * Create a product category and add the route * Add the category to a product * use the repenish button -> the category route is not available on the replenishment Observation: ------------- When opening replenishment, it will open the view_product_replenish, in that view, it will use allowed_route_ids to allow us to choose a route for this replenishment: https://github.com/odoo/odoo/blob/2f25b2a70eca5b4f3c2e1d6c7003b1760afc0ba0/addons/stock/wizard/product_replenish_views.xml#L37 allowed_route_ids is compute in the mixin with the following domain: https://github.com/odoo/odoo/blob/2f25b2a70eca5b4f3c2e1d6c7003b1760afc0ba0/addons/stock/models/stock_replenish_mixin.py#L18-L21 https://github.com/odoo/odoo/blob/2f25b2a70eca5b4f3c2e1d6c7003b1760afc0ba0/addons/stock/models/stock_replenish_mixin.py#L25-L31 this only take into account route from the product and not the ones from the product category. https://github.com/odoo/odoo/blob/deeecf7cd02e7383b591835b0c6495e3ddead0ff/addons/stock/models/stock_location.py#L511 opw-6297308 Forward-Port-Of: odoo/odoo#271535
`onClickValidate`'s signature changed to `onClickValidate(args = {})`, so passing `true` directly from the Viva app callback made `isForceValidate` silently resolve to `false` instead of `true`. The previous `validateOrder` override was also dead code, since that method moved off `PaymentScreen` to `PosStore` and so we now override `onClickValidate` instead. Forward-Port-Of: odoo/odoo#278116
Original PR description
`onClickValidate`'s signature changed to `onClickValidate(args = {})`, so passing `true` directly from the Viva app callback made `isForceValidate` silently resolve to `false` instead of `true`.
The previous `validateOrder` override was also dead code, since that method moved off `PaymentScreen` to `PosStore` and so we now override `onClickValidate` instead.
Forward-Port-Of: odoo/odoo#278116Before this commit, the pointerup event when doing a drag'n'drop in kanban view was containing the kanban card placeholder. Now, this placeholder isn't considered anymore to prevent unwanted target in the event. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#278324
Original PR description
Before this commit, the pointerup event when doing a drag'n'drop in kanban view was containing the kanban card placeholder. Now, this placeholder isn't considered anymore to prevent unwanted target in the event. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#278324
Before this commit, starting a tour in test mode on the tours viewz wasn't triggering the redirect at the first step of the tour. Now, it redirect. TASK-6331071 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#276531
Original PR description
Before this commit, starting a tour in test mode on the tours viewz wasn't triggering the redirect at the first step of the tour. Now, it redirect. TASK-6331071 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#276531
The state_id field was not cleared when editing an address and switching to a country without states — the state selector reset visually, but the stale state_id was still saved to the backend. Steps to reproduce: 1. Add a product to the cart. 2. Go to checkout and edit the address, selecting a country that has states. 3. Edit the address again, now selecting a country without states. 4. Save and check the contact in the backend: state_id still holds the state from the previo
Original PR description
The state_id field was not cleared when editing an address and switching to a country without states — the state selector reset visually, but the stale state_id was still saved to the backend. Steps to reproduce: 1. Add a product to the cart. 2. Go to checkout and edit the address, selecting a country that has states. 3. Edit the address again, now selecting a country without states. 4. Save and check the contact in the backend: state_id still holds the state from the previous country. Solution: reset the state_id select options for the new country. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#278660 Forward-Port-Of: odoo/odoo#278125
Steps to reproduce: - Edit a page. - Drop a carousel snippet like s_quotes_carousel - Click "Add Slide" with the browser console open(for concrete race condition) => Traceback: TypeError: Cannot read properties of null (reading 'classList') Cause: `slide()` used the editor window's `Carousel` instead of the iframe's. This created a second Carousel instance for the same element. Both instances updated the indicators at the same time, causing one to remove the active indicator before the
Original PR description
Steps to reproduce: - Edit a page. - Drop a carousel snippet like s_quotes_carousel - Click "Add Slide" with the browser console open(for concrete race condition) => Traceback: TypeError: Cannot read properties of null (reading 'classList') Cause: `slide()` used the editor window's `Carousel` instead of the iframe's. This created a second Carousel instance for the same element. Both instances updated the indicators at the same time, causing one to remove the active indicator before the other tried to use it, leading to the traceback. Fix: Use `this.window.Carousel` so the iframe's existing Carousel instance is reused instead of creating a second one. task-6084484 Forward-Port-Of: odoo/odoo#279117 Forward-Port-Of: odoo/odoo#275903
### Issue before this commit: 1. When generating a FatturaPA XML for a self-invoice (reverse charge / autofattura, e.g. TD17-TD19) with the "Reference" (ref) field filled in, the supplier's invoice number was placed under <DatiOrdineAcquisto> instead of <DatiFattureCollegate>. 2. When a credit note was generated from a vendor bill, the <IdDocumento> in <DatiFattureCollegate> contained Odoo's internal document number (e.g. BILL/2026/07/0002) instead of the actual reference of the invoice rece
Original PR description
### Issue before this commit: 1. When generating a FatturaPA XML for a self-invoice (reverse charge / autofattura, e.g. TD17-TD19) with the "Reference" (ref) field filled in, the supplier's invoice…
### Issue before this commit: 1. When generating a FatturaPA XML for a self-invoice (reverse charge / autofattura, e.g. TD17-TD19) with the "Reference" (ref) field filled in, the supplier's invoice number was placed under <DatiOrdineAcquisto> instead of <DatiFattureCollegate>. 2. When a credit note was generated from a vendor bill, the <IdDocumento> in <DatiFattureCollegate> contained Odoo's internal document number (e.g. BILL/2026/07/0002) instead of the actual reference of the invoice received from the supplier (ref). ### Steps to reproduce the issue: ISSUE 1: 1. Download Accounting and l10n_it 2. Go to Vendor -> Bills 3. Create a bill with: 1. Italian company as vendor 2. Product with tax 22% S RC 3. Bill reference filled (ex. FT00001) 4. Send it to SDI, open the XML and see that the tag <IdDocumento> is inside the tag <DatiOrdineAcquisto> while it sohuld be inside <Datifatturecollegate> ISSUE 2: 1. From a bill created click Credit Note 2. Send to SDI again, open the XML and see that the tag <IdDocumento> contains the bill reference created in Odoo while it should take the reference of the original invoice SENT by the vendor ### Cause of the issue: 1. The template's t-elif chain did not distinguish between self-invoices and regular documents, so any value in record.ref was routed to DatiOrdineAcquisto regardless of context. 2. Separately, the linked_moves loop always used linked_move.name to populate <IdDocumento>, which for vendor bills/refunds is Odoo's own sequential number, not the supplier's original invoice number. ### Reason to introduce the fix: 1. For the official FatturaPA Technical Specifications, DatiOrdineAcquisto must only reference a purchase order, while DatiFattureCollegate must reference a related invoice — which is the correct category for the supplier document being integrated in a self-invoice. This is confirmed by the Agenzia delle Entrate documentation: https://www.agenziaentrate.gov.it/portale/documents/d/guest/allegato-a-specifiche-tecniche-vers-1-9 (p.107, chapter Compilazione del documento XML con codice TD17) 2. For credit/debit notes, <IdDocumento> inside <DatiFattureCollegate> must contain the number of the original invoice being referenced/varied, not an internally generated document number, as clarified here: https://www.pa.sm/ticket/kb/faq.php?id=46 opw-6117968 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#276523
Portal subscribe task can create tb because the task was archived before unsubscribing. opw-6397850 Forward-Port-Of: odoo/odoo#279071 Forward-Port-Of: odoo/odoo#278667
Original PR description
Portal subscribe task can create tb because the task was archived before unsubscribing. opw-6397850 Forward-Port-Of: odoo/odoo#279071 Forward-Port-Of: odoo/odoo#278667
When an image is start-aligned, if a list is defined after it, its bullets/numbers/checkboxes are rendered on top of the image. This commit makes the bullets rendered after the image. Steps to reproduce: - Edit a website page - Drop a text page - Insert an image with `/image` - Align image to the left - Insert a bullet list or a numbered list or a checkbox list with some indented entries => Some bullets were rendered on top of the image Additionally, the start-align is neutral
Original PR description
When an image is start-aligned, if a list is defined after it, its bullets/numbers/checkboxes are rendered on top of the image. This commit makes the bullets rendered after the image. Steps to reproduce: - Edit a website page - Drop a text page - Insert an image with `/image` - Align image to the left - Insert a bullet list or a numbered list or a checkbox list with some indented entries => Some bullets were rendered on top of the image Additionally, the start-align is neutralized inside list lines because other approaches do not provide a satisfactory layout - and break further situations. task-6116437 Forward-Port-Of: odoo/odoo#260325
to reproduce: ============= - Have a database with a large number of kit BoMs (e.g. ~160k phantom mrp.bom records). - Open Inventory Valuation. - The request never returns and hangs forever. problem: ======== Commit 11e9c1297439 started searching the valued products with `('qty_available', '!=', 0)`. On `product.product` this triggers the mrp override `_search_qty_available_new`, which loads every phantom BoM in the database and computes `qty_available` (via BoM explode) for each
Original PR description
to reproduce: ============= - Have a database with a large number of kit BoMs (e.g. ~160k phantom mrp.bom records). - Open Inventory Valuation. - The request never returns and hangs forever. problem:…
to reproduce:
=============
- Have a database with a large number of kit BoMs (e.g. ~160k phantom
mrp.bom records).
- Open Inventory Valuation.
- The request never returns and hangs forever.
problem:
========
Commit 11e9c1297439 started searching the valued products with
`('qty_available', '!=', 0)`. On `product.product` this triggers the mrp
override `_search_qty_available_new`, which loads every phantom BoM in the
database and computes `qty_available` (via BoM explode) for each kit. On top
of that, the override builds the kit products recordset with repeated
`kit_products |= ...` unions, which is O(n^2). With a large catalog of kits
the combination of O(n) heavy explodes and O(n^2) unions never returns.
On top of the performance issue, the new search dropped the kit exclusion
that `_get_accounts_by_product` previously applied through
`_get_valuation_product_domain` (`('is_kits', '=', False)` in mrp_account),
so phantom products - which are never valued on their own - were wrongly
pulled into the valuation.
solution:
=========
Restore the kit exclusion: search the valued products through
`_get_valuation_product_domain()` (which adds `('is_kits', '=', False)` in
mrp_account) instead of the ad-hoc `('is_storable', '=', True)` domain, so
phantom products are no longer valued.
Add a `skip_kit_qty_available` context key on `_search_qty_available_new` so
callers that intentionally exclude kits can skip the costly kit BoM expansion
and return the base (quant-based) result directly. The key is set in
mrp_account (via `_get_valuation_product_context`), alongside the domain that
already excludes kits, so the optimization and its precondition stay in the
same layer.
Also make the remaining kit path in `_search_qty_available_new` scale: build
the kit products recordset in a single pass instead of O(n^2) recordset
unions, and use a set for membership checks.
Benchmark:
==========
for `_get_report_data()` (averaged over 5 runs):
| # Input data (phantom kits) | Before PR | After PR |
| :---: | :---: | :---: |
| 1,000 | 2.558 s | 35.5 ms |
| 5,000 | 10.991 s | 41.6 ms |
| 10,000 | 20.869 s | 66.0 ms |
| 25,000 | 61.807 s | 80.7 ms |
| 50,000 | 195.382 s | 87.9 ms |
the improvement is **~99% faster**
opw-6312168
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#273982A return coming back from the customer must always decrease the delivered quantity of a sale order line, even when it is not linked to its original delivery (no origin_returned_move_id and its picking has no return_id) These unlinked returns are created through a negative procurement, example: when the ordered quantity is reduced below the delivered one. Steps to reproduce: - Confirm a sale order of 10 and deliver the 10 - Cancel the order and reset it to draft - Reduce the line quantit
Original PR description
A return coming back from the customer must always decrease the delivered quantity of a sale order line, even when it is not linked to its original delivery (no origin_returned_move_id and its picking has no return_id) These unlinked returns are created through a negative procurement, example: when the ordered quantity is reduced below the delivered one. Steps to reproduce: - Confirm a sale order of 10 and deliver the 10 - Cancel the order and reset it to draft - Reduce the line quantity from 10 to 4 - Re-confirm: the pull rule generates a return of 6 with to_refund set but no origin_returned_move_id nor picking.return_id - Validate that return Before: delivered stays at 10. After: delivered is 4. opw-6345628 Forward-Port-Of: odoo/odoo#274399
The implementation of the highlight of missing required settings (#249321) was discarding the `SearchableSetting` if the `<setting>` had no `id`. This behavior disabled the highlight of the setting formPage in those cases. This commit fixes the issue by allowing `settingId` to be undefined. Note that `settingId` can safely be undefined since it is used only for the highlight behavior and during a case of url hash check. task-6364849 Forward-Port-Of: odoo/odoo#276871
Original PR description
The implementation of the highlight of missing required settings (#249321) was discarding the `SearchableSetting` if the `<setting>` had no `id`. This behavior disabled the highlight of the setting formPage in those cases. This commit fixes the issue by allowing `settingId` to be undefined. Note that `settingId` can safely be undefined since it is used only for the highlight behavior and during a case of url hash check. task-6364849 Forward-Port-Of: odoo/odoo#276871