Daily updates from Odoo
Sunday, August 9, 2026
15 changes
3 changes
Resolved issues and error corrections
You'll need two users : - Internal User A that can create projects - User B with a granted portal access Optionnal third user to compare the flows : - Internal User B that can create tasks in a porject - With User A, create a new project with atleast a single stage - Go to the project settings - Make sure that Visibility is set to : "All internal users and invited portal users" - Click on Share Project - Add User B as a new Collaborator with the Edit acess mode - Confirm by clic
Original PR description
You'll need two users : - Internal User A that can create projects - User B with a granted portal access Optionnal third user to compare the flows : - Internal User B that can create tasks in a…
You'll need two users : - Internal User A that can create projects - User B with a granted portal access Optionnal third user to compare the flows : - Internal User B that can create tasks in a porject - With User A, create a new project with atleast a single stage - Go to the project settings - Make sure that Visibility is set to : "All internal users and invited portal users" - Click on Share Project - Add User B as a new Collaborator with the Edit acess mode - Confirm by clicking on Share Project - Still in the project settings, click on the blue user icon in the top right to edit the Followers : - Make sure you are following the project - Click on the edit button and make sure Task Created is checked Optionnal for easiness of testing : - Go to the User A settings and in Preferences > Notifications : In Odoo - Log in with User B (in a new incognito tab on the side is best) - Go to Projects > The project that has been shared - Create a new task No notification is sent to User A. If the same flow is done using User C, then a notification is correctly sent. The fields that determine to which users the notifications are sent to is `message_follower_ids`. In our case, the value of that field does not contain User A, so no notifcation is sent to them. The method responsible for assigning values to that field is `_message_auto_subscribe()` which adds follower using subtypes parent relationship. The parent subtype of tasks are projects. So, essentially, we look for followers of the parent project, and see if we can add them to our task. Before proceeding with the assignation, we check that the parent subtype's field was actually edited : https://github.com/odoo/odoo/blob/ea18f34a48d61350f80c79894bef66bf02840bfc/addons/mail/models/mail_thread.py#L4778-L4781 So we look that `updated_values` contains "project_id". `updated_values` is created by the the `mail_thread` create method by joining the values in `vals_list` and the context default variables. In our case, this should be enough since `default_project_id` is provided when creating a task : https://github.com/odoo/odoo/blob/ea18f34a48d61350f80c79894bef66bf02840bfc/addons/mail/models/mail_thread.py#L340-L344 But, a bit before this, the task create method edits the context to replace 'default_project_id' by 'default_create_in_project_id' : https://github.com/odoo/odoo/blob/ea18f34a48d61350f80c79894bef66bf02840bfc/addons/project/models/project_task.py#L1102-L1109 So we do not detect that `project_id` has been changed and don't actually add the followers. We remove the custom 'default_create_in_project_id` context opw-6026932 Forward-Port-Of: odoo/odoo#278824 Forward-Port-Of: odoo/odoo#278353
Description of the issue/feature this PR addresses: A user without accounting rights cannot open an invoice form when l10n_es_edi_verifactu is installed. The module adds a VeriFactu page and three warning banners to the standard invoice form without any groups restriction, so every user able to open an invoice reads three fields (l10n_es_edi_verifactu_document_ids, l10n_es_edi_verifactu_warning, l10n_es_edi_verifactu_warning_level) pointing at l10n_es_edi_verifactu.document. That model
Original PR description
Description of the issue/feature this PR addresses: A user without accounting rights cannot open an invoice form when l10n_es_edi_verifactu is installed. The module adds a VeriFactu page and three…
Description of the issue/feature this PR addresses: A user without accounting rights cannot open an invoice form when l10n_es_edi_verifactu is installed. The module adds a VeriFactu page and three warning banners to the standard invoice form without any groups restriction, so every user able to open an invoice reads three fields (l10n_es_edi_verifactu_document_ids, l10n_es_edi_verifactu_warning, l10n_es_edi_verifactu_warning_level) pointing at l10n_es_edi_verifactu.document. That model only grants read access to account.group_account_invoice and account.group_account_readonly. Steps to reproduce: - install `l10n_es_edi_verifactu` - create a salesman user with sales rights but no accounting right (*Own Documents Only* is enough) - create an ES company and an ES customer - give the salesman access to the ES company - activate Peppol in the general settings - log in as the salesman - create a sale order in the ES company for the ES customer - confirm it - click **Create Invoice** - click **Create Draft** Current behavior before PR: An error access is raised: Failed to read field account.move.l10n_es_edi_verifactu_document_ids You are not allowed to access 'Veri*Factu Document' (l10n_es_edi_verifactu.document) records. This operation is allowed for the following groups: - Invoicing/Billing - Technical/Show Accounting Features - Readonly Contact your administrator to request access if necessary. In Odoo sh (for databases 19.0), the standard test sale_management / TestSaleFlowTourPostInstall.test_basic_sale_flow_with_minimal_access_rights fails for the same reason as soon as l10n_es_edi_verifactu is installed alongside sale_management. Desired behavior after PR is merged: On a database with l10n_es_edi_verifactu installed, a non-accountant user having the possibility to create invoices should not have the error message displayed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#280879
Cash Basis moves should be posted at the date of the payment, not the date of the invoice nor the date when the reconciliation is done. If there is a lock date and the payment is before that lock date, it should be posted at the first day available after the lock date. task-6420600 Forward-Port-Of: odoo/odoo#281344 Forward-Port-Of: odoo/odoo#278917
Original PR description
Cash Basis moves should be posted at the date of the payment, not the date of the invoice nor the date when the reconciliation is done. If there is a lock date and the payment is before that lock date, it should be posted at the first day available after the lock date. task-6420600 Forward-Port-Of: odoo/odoo#281344 Forward-Port-Of: odoo/odoo#278917
2 changes
Resolved issues and error corrections
Cash Basis moves should be posted at the date of the payment, not the date of the invoice nor the date when the reconciliation is done. If there is a lock date and the payment is before that lock date, it should be posted at the first day available after the lock date. task-6420600 Forward-Port-Of: odoo/odoo#281344 Forward-Port-Of: odoo/odoo#278917
Original PR description
Cash Basis moves should be posted at the date of the payment, not the date of the invoice nor the date when the reconciliation is done. If there is a lock date and the payment is before that lock date, it should be posted at the first day available after the lock date. task-6420600 Forward-Port-Of: odoo/odoo#281344 Forward-Port-Of: odoo/odoo#278917
Description of the issue/feature this PR addresses: A user without accounting rights cannot open an invoice form when l10n_es_edi_verifactu is installed. The module adds a VeriFactu page and three warning banners to the standard invoice form without any groups restriction, so every user able to open an invoice reads three fields (l10n_es_edi_verifactu_document_ids, l10n_es_edi_verifactu_warning, l10n_es_edi_verifactu_warning_level) pointing at l10n_es_edi_verifactu.document. That model
Original PR description
Description of the issue/feature this PR addresses: A user without accounting rights cannot open an invoice form when l10n_es_edi_verifactu is installed. The module adds a VeriFactu page and three…
Description of the issue/feature this PR addresses: A user without accounting rights cannot open an invoice form when l10n_es_edi_verifactu is installed. The module adds a VeriFactu page and three warning banners to the standard invoice form without any groups restriction, so every user able to open an invoice reads three fields (l10n_es_edi_verifactu_document_ids, l10n_es_edi_verifactu_warning, l10n_es_edi_verifactu_warning_level) pointing at l10n_es_edi_verifactu.document. That model only grants read access to account.group_account_invoice and account.group_account_readonly. Steps to reproduce: - install `l10n_es_edi_verifactu` - create a salesman user with sales rights but no accounting right (*Own Documents Only* is enough) - create an ES company and an ES customer - give the salesman access to the ES company - activate Peppol in the general settings - log in as the salesman - create a sale order in the ES company for the ES customer - confirm it - click **Create Invoice** - click **Create Draft** Current behavior before PR: An error access is raised: Failed to read field account.move.l10n_es_edi_verifactu_document_ids You are not allowed to access 'Veri*Factu Document' (l10n_es_edi_verifactu.document) records. This operation is allowed for the following groups: - Invoicing/Billing - Technical/Show Accounting Features - Readonly Contact your administrator to request access if necessary. In Odoo sh (for databases 19.0), the standard test sale_management / TestSaleFlowTourPostInstall.test_basic_sale_flow_with_minimal_access_rights fails for the same reason as soon as l10n_es_edi_verifactu is installed alongside sale_management. Desired behavior after PR is merged: On a database with l10n_es_edi_verifactu installed, a non-accountant user having the possibility to create invoices should not have the error message displayed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#280879
1 change
Resolved issues and error corrections
Cash Basis moves should be posted at the date of the payment, not the date of the invoice nor the date when the reconciliation is done. If there is a lock date and the payment is before that lock date, it should be posted at the first day available after the lock date. task-6420600 Forward-Port-Of: odoo/odoo#281344 Forward-Port-Of: odoo/odoo#278917
Original PR description
Cash Basis moves should be posted at the date of the payment, not the date of the invoice nor the date when the reconciliation is done. If there is a lock date and the payment is before that lock date, it should be posted at the first day available after the lock date. task-6420600 Forward-Port-Of: odoo/odoo#281344 Forward-Port-Of: odoo/odoo#278917
2 changes
Resolved issues and error corrections
Cash Basis moves should be posted at the date of the payment, not the date of the invoice nor the date when the reconciliation is done. If there is a lock date and the payment is before that lock date, it should be posted at the first day available after the lock date. task-6420600 Forward-Port-Of: odoo/odoo#281220 Forward-Port-Of: odoo/odoo#278917
Original PR description
Cash Basis moves should be posted at the date of the payment, not the date of the invoice nor the date when the reconciliation is done. If there is a lock date and the payment is before that lock date, it should be posted at the first day available after the lock date. task-6420600 Forward-Port-Of: odoo/odoo#281220 Forward-Port-Of: odoo/odoo#278917
This commit fixes the verification JSON. For OSS taxes no_sujeto_loc and no_sujeto, CuotaTotal and ImporteTotal must Only include the base amount, not the tax amount. See the chatter in the task for AEAT guidelines. Also removed the validation error blocking no_sujeto_loc taxes with a non-zero amount, since OSS taxes legitimately have one in Odoo accounting (e.g. 22% IT VAT) even though it is excluded from the Veri*Factu json. upgrade :- https://github.com/odoo/upgrade/pull/10799 tas
Original PR description
This commit fixes the verification JSON. For OSS taxes no_sujeto_loc and no_sujeto, CuotaTotal and ImporteTotal must Only include the base amount, not the tax amount. See the chatter in the task for AEAT guidelines. Also removed the validation error blocking no_sujeto_loc taxes with a non-zero amount, since OSS taxes legitimately have one in Odoo accounting (e.g. 22% IT VAT) even though it is excluded from the Veri*Factu json. upgrade :- https://github.com/odoo/upgrade/pull/10799 task-5411766 Forward-Port-Of: odoo/odoo#280763 Forward-Port-Of: odoo/odoo#272068
5 changes
Resolved issues and error corrections
The timesheet assistant now avoids creating suggestions with missing or undefined details. This helps users receive clearer, more reliable suggested timesheet entries based on their activity.
Original PR description
Several aw.rule regexes use (.*) for the capture groups feeding the suggestion name/description, allowing an empty match and producing incorrect suggestions (e.g. "Discussing with undefined") Task-6377168 Forward-Port-Of: odoo/enterprise#126853 Forward-Port-Of: odoo/enterprise#125771
This fixes an issue where a Swiss payroll transmission value was not being recorded in the system logs. The correction helps payroll teams keep more complete records for review and compliance checks.
Original PR description
Forward-Port-Of: odoo/enterprise#127241
The batch picking barcode test now waits for the first scanned item quantity to update before selecting the next line. This prevents timing-related failures where quantities could be assigned to the wrong item during automated validation.
Original PR description
Problem: When scanning the first product, the second move line is clicked immediately after.…
Problem: When scanning the first product, the second move line is clicked immediately after. https://github.com/odoo/enterprise/blob/bfb8bab7636a84c829f16087771e00bf31ad2cce/stock_barcode_picking_batch/static/tests/tours/tour_test_barcode_batch_flows.js#L1529-L1541 If this happens before the first scan has finished, its quantity is incorrectly applied to the second move line that is clicked. This causes a 0 - 3 split instead of a 1 - 2 split, which results in there only being 6 move lines instead of 7. We updated our quantity on the `currentLine` https://github.com/odoo/enterprise/blob/bfb8bab7636a84c829f16087771e00bf31ad2cce/stock_barcode/static/src/models/barcode_model.js#L1478 When finding `currentLine`, we go through `_findLine` and use `this.selectedLineVirtualId`, which is the one that is currently selected in the UI https://github.com/odoo/enterprise/blob/bfb8bab7636a84c829f16087771e00bf31ad2cce/stock_barcode/static/src/models/barcode_model.js#L1705-L1712 Purpose: By adding this step, we wait until the first line’s quantity to be updated before it moves on and clicks on the second product. runbot-941211 Forward-Port-Of: odoo/enterprise#127118 Forward-Port-Of: odoo/enterprise#124162
The payroll list views now always show the warnings column instead of hiding it behind an optional menu with an empty label. This makes payroll warnings easier to notice and avoids a confusing user experience in payslip and pay run screens.
Original PR description
Currently, in the payslip and payrun view, we can see empty label in optional dropdown. Having empty label isn't UX friendly. This empty label is refered to payslip warnings. In this PR expected to change visibility of warning fields, The visibility must be always visible and the field is no longer optional. This condition applies to PayRun and Paylist ListViews. task-6424657 Forward-Port-Of: odoo/enterprise#127271 Forward-Port-Of: odoo/enterprise#125860
The live currency rate updater now points to the Romanian National Bank's new exchange-rate subdomain. This keeps daily exchange rate retrieval working after the bank retires the old web address in August 2026.
Original PR description
As of 6 August 2026, the XML files used by software applications to retrieve daily exchange rates will no longer be available directly through addresses on the www.bnr.ro domain and will be accessible exclusively via the curs.bnr.ro subdomain. The XML file names will remain unchanged; only the access domain will be modified. no-task Forward-Port-Of: odoo/enterprise#127177
1 change
Resolved issues and error corrections
Tax return deadline dates in email templates are now shown using the recipient user's locale settings. This prevents confusion caused by unfamiliar date formats and makes deadline communications clearer for users in different regions.
Original PR description
The date was not formatted according to the user's locale.
1 change
Resolved issues and error corrections
Description of the issue/feature this PR addresses: A user without accounting rights cannot open an invoice form when l10n_es_edi_verifactu is installed. The module adds a VeriFactu page and three warning banners to the standard invoice form without any groups restriction, so every user able to open an invoice reads three fields (l10n_es_edi_verifactu_document_ids, l10n_es_edi_verifactu_warning, l10n_es_edi_verifactu_warning_level) pointing at l10n_es_edi_verifactu.document. That model
Original PR description
Description of the issue/feature this PR addresses: A user without accounting rights cannot open an invoice form when l10n_es_edi_verifactu is installed. The module adds a VeriFactu page and three…
Description of the issue/feature this PR addresses: A user without accounting rights cannot open an invoice form when l10n_es_edi_verifactu is installed. The module adds a VeriFactu page and three warning banners to the standard invoice form without any groups restriction, so every user able to open an invoice reads three fields (l10n_es_edi_verifactu_document_ids, l10n_es_edi_verifactu_warning, l10n_es_edi_verifactu_warning_level) pointing at l10n_es_edi_verifactu.document. That model only grants read access to account.group_account_invoice and account.group_account_readonly. Steps to reproduce: - install `l10n_es_edi_verifactu` - create a salesman user with sales rights but no accounting right (*Own Documents Only* is enough) - create an ES company and an ES customer - give the salesman access to the ES company - activate Peppol in the general settings - log in as the salesman - create a sale order in the ES company for the ES customer - confirm it - click **Create Invoice** - click **Create Draft** Current behavior before PR: An error access is raised: Failed to read field account.move.l10n_es_edi_verifactu_document_ids You are not allowed to access 'Veri*Factu Document' (l10n_es_edi_verifactu.document) records. This operation is allowed for the following groups: - Invoicing/Billing - Technical/Show Accounting Features - Readonly Contact your administrator to request access if necessary. In Odoo sh (for databases 19.0), the standard test sale_management / TestSaleFlowTourPostInstall.test_basic_sale_flow_with_minimal_access_rights fails for the same reason as soon as l10n_es_edi_verifactu is installed alongside sale_management. Desired behavior after PR is merged: On a database with l10n_es_edi_verifactu installed, a non-accountant user having the possibility to create invoices should not have the error message displayed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#280879