Daily updates from Odoo
Monday, September 29, 2025
17 changes · master
Resolved issues and error corrections
This fix prevents Field Service tasks from crashing when a previously created worksheet template is selected after the Field Service app has been uninstalled and reinstalled. User-created worksheet templates tied to the removed setup are now cleaned up during uninstallation, avoiding broken templates and improving reliability.
Original PR description
When user uninstalls and reinstalls `industry_fsm` the user created template is not removed causing `model_id` for the worksheet template turning `False` and raising a key error when indexing via `model_id`. **Replication steps:** * Install `industry_fsm` * Field Service>Configuration>Settings>Enable Worksheet templates * Configuration>Templates>Create New Template * Uninstall and reinstall `Field Service` * Field Service>New Task>Set worksheet template to the one you created `KeyError: False` **Solution:** * Unlink user created worksheet template on uninstallation of the application. **Sentry-6615576986** Forward-Port-Of: odoo/enterprise#86084
Payroll payments created from payslips now use the correct bank account when tax partner lines are involved. This helps prevent payments from being assigned to the wrong recipient bank details and adds checks to avoid regressions.
Original PR description
In the `hr_payroll` module, when creating the payments based on a payslip, the property `partner_bank_id` of the created payments is not always set to the correct bank account. From now on, when a payment will be created for a tax partner line, the `partner_id` of the payment is set to the tax partner, the `partner_bank_id` will now contain the bank account of the employee. We added the `test_bank_account_partner_payment_payslip` test to check that the payment generated for Professional Tax is made to the correct bank account. Odoo: odoo/odoo#222608 Task link: https://www.odoo.com/odoo/my-tasks/4979220 task-4979220
Support Document Credit Notes in Colombian electronic invoicing now consistently use the required internal reference format when sent to DIAN. This prevents rejection errors caused by sending barcode or UNSPSC identifiers with unsupported schemes.
Original PR description
Before this PR:
- Support Document Credit Notes sent barcode (scheme 010) when available, causing DIAN `NSAZ13` error and document rejection.
After this PR:
- Although a product has all of these 3 fields configured (barcode, UNSPSC, internal reference), still, for a Support Document Credit Note, the `cac:StandardItemIdentification` is always sent with the Internal Reference information ('999', 'Estándar de adopción del contribuyente').
- If internal reference is not configured, then barcode or UNSPSC code is sent with scheme ('999', 'Estándar de adopción del contribuyente').
task-4796034
Forward-Port-Of: odoo/enterprise#94140VAT payment instructions sent through the mail composer now display more neatly in the chatter. This prevents awkward word breaks and misaligned fields, making the information easier to read and more professional for Belgian and Dutch reporting workflows.
Original PR description
Issue: -VAT payment instructions sent via mail composer were shown in the chatter with poor formatting. -Words could be split in half and fields were misaligned. Fix: -Updated the layout to improve text wrapping and field alignment in the chatter. Impact: -Ensures VAT payment instructions are displayed clearly and professionally in the chatter. task-5065873 Forward-Port-Of: odoo/enterprise#93986
This fixes Swedish tax reporting so non-EU goods purchases with VAT are correctly marked as deductible input VAT. It helps ensure VAT reports reflect the right amounts for Swedish compliance and avoids related reporting test failures.
Original PR description
The Swedish taxes "EX G" (VAT Purchase of goods outside EU) with a non-zero amount should have the tag se_48 (Input VAT to be deducted). opw-4916405
New users can now load demo data in the Appraisal module without running into an access-related error. This makes onboarding and trial setup smoother for users who do not have administrator rights.
Original PR description
Currently, an error occurs when a new user tries to load demo data in the `Appraisal` module. Steps to reproduce: --- - Install `hr_appraisal` module (without demo data) - Create NEW user > Login…
Currently, an error occurs when a new user tries to load demo data in the `Appraisal` module.
Steps to reproduce:
---
- Install `hr_appraisal` module (without demo data)
- Create NEW user > Login with new user
- Open `Appraisal` and Click `Load Demo Data`
Traceback:
---
```py
ParseError: <record id="calendar_event_appraisal_1" model="calendar.event" forcecreate="1">
<field name="user_id" ref="base.user_admin"/>
<field name="name">Appraisal of Emma Granger</field>
<field name="partner_ids" eval="[(6,0,[ref('hr.work_contact_sj'), ref('hr.work_contact_mw'), ref('hr.work_contact_eg')])]"/>
<field name="start" eval="(DateTime.now() + relativedelta(months=1)).strftime('%Y-%m-%d 07:00:00')"/>
<field name="stop" eval="(DateTime.now() + relativedelta(months=1)).strftime('%Y-%m-%d 09:00:00')"/>
<field name="res_model_id" ref="hr_appraisal.model_hr_appraisal"/>
<field name="res_model">hr.appraisal</field>
<field name="res_id" ref="hr_appraisal.hr_appraisal_1"/>
</record>
ValueError: ParseError('while parsing /home/odoo/odoo/enterprise/hr_appraisal/data/scenarios/hr_appraisal_scenario.xml:561, somewhere inside\n<record id="calendar_event_appraisal_1" model="calendar.event" forcecreate="1">\n <field name="user_id" ref="base.user_admin"/>\n <field name="name">Appraisal of Emma Granger</field>\n <field name="partner_ids" eval="[(6,0,[ref(\'hr.work_contact_sj\'), ref(\'hr.work_contact_mw\'), ref(\'hr.work_contact_eg\')])]"/>\n <field name="start" eval="(DateTime.now() + relativedelta(months=1)).strftime(\'%Y-%m-%d 07:00:00\')"/>\n <field name="stop" eval="(DateTime.now() + relativedelta(months=1)).strftime(\'%Y-%m-%d 09:00:00\')"/>\n <field name="res_model_id" ref="hr_appraisal.model_hr_appraisal"/>\n <field name="res_model">hr.appraisal</field>\n <field name="res_id" ref="hr_appraisal.hr_appraisal_1"/>\n </record>') while evaluating
'action = model._load_demo_data()'
```
This error occurs because the new user has not been granted administrative rights.
This commit resolves the issue by granting the user superuser rights.
sentry-6110523247
Forward-Port-Of: odoo/enterprise#95622
Forward-Port-Of: odoo/enterprise#93461The Chilean F29 tax report proposal has been reorganized to better match reporting needs, including clearer sections, updated calculations, and improved submission handling. This helps businesses prepare VAT and withholding information more accurately and reduces upgrade issues from older report fields.
Original PR description
https://github.com/odoo/odoo/pull/191572
The AI field picker now prevents the same field from being selected more than once and clearly marks fields that are already chosen. Long field names also wrap correctly, making them easier to review and remove when needed.
Original PR description
before this commit: When you press Enter in the field picker, it will always pick the same field again, even if it is not visible. After this commit: A field can only be selected once, and it stays visible in the list. Added a visual check to show that the field is already selected. Forward-Port-Of: odoo/enterprise#93890
The Mexican DIOT report download now places the “exempt imports” and “exempt” values in the correct columns. This prevents confusion or filing issues caused by the two correctly calculated values appearing in the wrong positions.
Original PR description
The description of the columns “exempt imports” and “exempt” is somewhat ambiguous, so when developing the diot, there was a small error in the order of the columns. The values are calculated correctly, but columns 49 and 50 were inadvertently swapped. This Pr changes the order of the columns in the downloadable file (txt) and corrects the tests due to the change. Task-id: 5096808 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#95679 Forward-Port-Of: odoo/enterprise#95383
Fixes an issue in Brazilian electronic invoicing where confirming several invoices at the same time could fail unexpectedly. This helps accounting teams process batches of invoices more reliably without manual retries or interruptions.
Original PR description
opw-5107516 Forward-Port-Of: odoo/enterprise#95532 Forward-Port-Of: odoo/enterprise#95511
Chilean electronic invoice imports now correctly treat lines marked with exemption code 6 as negative amounts. This prevents vendor bills from being imported with overstated positive values, improving accounting accuracy and compliance with Chilean e-invoicing rules.
Original PR description
### Issue: When, in a DTE file, a line has the code 6 in `IndExe`. The amount of the line is supposed to be negative. (See the [doc](https://www.sii.cl/factura_electronica/formato_dte.pdf) page 31/32) ### Steps to reproduce: - Install 'l10n_cl_edi' and switrch to a Chilean company - Have a DTE file with a line having '6' in `IndExe`: - In Accounting > Vendor > Bills, click the button "Upload" and select the DTE file - The imported move has positive values on the every lines ### Cause: The values of `IndExe` are not considered. ### Solution: Add a condition changing the sign of `price_unit` when 6 is in `IndExe` opw-4954723 Forward-Port-Of: odoo/enterprise#95405 Forward-Port-Of: odoo/enterprise#93393
The barcode kanban view now only shows existing inventory records instead of allowing new stock quantity records to be created. This prevents accidental inventory entries and helps keep stock data accurate when users scan or type product barcodes.
Original PR description
Steps to reproduce: - Scan or type product barcode - Navigate to Kanban View Problem: - New `stock.quants` are not supposed to be created from `stock.quant.kanban.barcode`, its only to supposed to show existing ones. Forward-Port-Of: odoo/enterprise#95487 Forward-Port-Of: odoo/enterprise#94802
This fix improves how salary amounts and currency symbols are displayed in the salary configurator, making contract offers easier to read. It also ensures part-time gross salary details keep all related values, preventing incomplete employer cost information.
Original PR description
The salary configurator had several UI inconsistencies that impacted the readability of contract offers:
- Replaced complex input-group styling with flexbox layout in resume_sidebar.xml to properly align currency symbols and values using Bootstrap's fs-5 and fw-normal classes
- Added align-items-center and justify-content-end for consistent spacing
- Changed tuple reconstruction in main.py to use (_('Gross (Part Time)'), *salary_tuple[1:]) to preserve all salary_tuple values (positions 1-5) instead of truncating to only first 3 elements
task-5063224
Forward-Port-Of: odoo/enterprise#94453This fix prevents an error that could occur when a currency rate filter is closed after the accounting report view has already been left or removed. It helps keep financial reports stable during navigation and avoids disruptive crashes for users.
Original PR description
For the currency rate filter, applyFilters is called when the dropdown is closed. It might heppen that we have the dropdown open then we click on something that trigger the destruction of the report view but that still trigger applyFilters which try to apply filter on a destroyed component which is illegal. To prevent this we check if the component is destroyed before reloading the controller. Forward-Port-Of: odoo/enterprise#94530 Forward-Port-Of: odoo/enterprise#94313
Tax return reports for UK and New Zealand now follow the company’s configured fiscal year instead of assuming a calendar year. This prevents transactions from being included in the wrong quarter when the fiscal year ends on a date other than December 31.
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_uk_reports - Switch to a British company (e.g. UK Company) - In Accounting settings, set the last day of the fiscal year to another date than "December 31" (e.g. "January 31") - Create some invoices with tax between the 1st of January and the 30th of April - Go to "Accounting / Accounting / Closing / Tax Returns" - Open the "Tax Report (GB)" for the first quarter (i.e. Tax Q1) **Issue: (same issue for NZ localization)** The Tax Report is ignoring the configured date of the fiscal year. All the invoices from January are included and those from April are excluded. It should be the opposite. **Solution:** Override the "_get_start_date_elements" method for the British tax report that allows to define the start date. opw-4939971 opw-5067877 Forward-Port-Of: odoo/enterprise#94936 Forward-Port-Of: odoo/enterprise#94793
This fix prevents hidden editor cursor markers in Knowledge comments from multiplying and causing errors. It helps keep comment editing stable and avoids unexpected crashes when working with Knowledge articles.
Original PR description
Context: `\ufeff` characters are used in the editor to handle how the cursor behaves when using arrow keys. In the case of knowledge comments, we want to have 2 cursor positions at each comment…
Context: `\ufeff` characters are used in the editor to handle how the cursor behaves when using arrow keys. In the case of knowledge comments, we want to have 2 cursor positions at each comment boundary. I.e.: at the first beacon, we want a cursor position before the anchor (outside of the comment), and one after (inside of the comment). Issue: Since this [commit], empty links receive 2 `zwnbsp` nodes to allow the user to type inside, instead of 1 previously. However knowledge comments beacons are not editable and only need one `zwnbsp`, since we never want to type inside. Furthermore, having 2 and nothing in between them would cause an issue when their content is normalized, which may lead to a traceback: - `link_plugin` executes `selection.anchorNode.parentNode.normalize();` which merges 2 FEFF together. However the function `isZwnbsp` does return true for one text node with 2 FEFF characters. This means that during the next "add feffs" phase, new text nodes with one `FEFF` characters will be added, creating a growing loop generating new `FEFF` at every normalization phase. - Furthermore, merging the nodes in one text node may not result in a new step in some cases, which prevent the `history_plugin` from registering the new node in time in its `nodeMap`, which may lead to a serialization traceback. Resolution: This commit stops using the deprecated `padLinkWithZwnbsp` method to ensure that there are 3 `zwnbsp` characters for each beacon: 2 around it, and one inside. [commit]: https://github.com/odoo/odoo/commit/f0eaeb6 task-5046068 Forward-Port-Of: odoo/enterprise#95550
This update stabilizes an automated test in the equity module by checking each cap table record individually instead of depending on record order. It reduces false test failures and helps keep development and release validation more dependable without changing user-facing behavior.
Original PR description
The test `test_option_into_share` was failing because `assertRecordValues` compares lists in order, and the records returned by the `cap.table` search were not in the same sequence as the expected values in the test. This commit makes the test deterministic by replacing list-based `assertRecordValues` calls with individual assertions per record. [RB-232585](https://runbot.odoo.com/odoo/error/232585) Forward-Port-Of: odoo/enterprise#95187