Daily updates from Odoo
Sunday, July 26, 2026
11 changes
1 change
Resolved issues and error corrections
This fixes Uruguay electronic credit notes created from zero-value e-tickets so they include a required reference amount, even when it is 0.00. It helps prevent tax authority rejections and avoids an error for document types that do not use that field.
Original PR description
Problem: When generating an e-Ticket Credit Note for an original e-Ticket with a total amount of 0.00, the XML cleanup mechanism removes reference fields whose value is 0.00. As a result, the credit note is rejected by DGI with: "CODE 31: En línea de Referencia 1 si NO IndGlobal = 1 deben existir TpoDocRef, Serie, NroCFERef, MntCFERef, TpoMonedaRef." Solution: Ensure that MntCFERef is sent even if the value is 0.00. opw-6378783 Forward-Port-Of: odoo/enterprise#124595 Forward-Port-Of: odoo/enterprise#124354
1 change
Resolved issues and error corrections
This fixes Uruguay electronic credit notes for cases where the original e-Ticket total is 0.00. The required reference amount is now kept in the submitted XML, preventing DGI rejections and avoiding invoice processing errors for affected customers.
Original PR description
Problem: When generating an e-Ticket Credit Note for an original e-Ticket with a total amount of 0.00, the XML cleanup mechanism removes reference fields whose value is 0.00. As a result, the credit note is rejected by DGI with: "CODE 31: En línea de Referencia 1 si NO IndGlobal = 1 deben existir TpoDocRef, Serie, NroCFERef, MntCFERef, TpoMonedaRef." Solution: Ensure that MntCFERef is sent even if the value is 0.00. opw-6378783 Forward-Port-Of: odoo/enterprise#124595 Forward-Port-Of: odoo/enterprise#124354
3 changes
Resolved issues and error corrections
This fixes a display issue where Avalara-related fields could be hidden on contact and product forms when a company was not explicitly set. Businesses using Avalara tax integration for US or Canadian records can now see and manage the expected tax fields consistently.
Original PR description
**Steps to reproduce:**
- Install Accounting and account_avatax
- Use a US company (by default)
- Create a contact with Canada as country
**Issue:**
In "Sales & Purchase" tab, all the fields from avatax module are not displayed (i.e. "Avalara Code", "Avalara Partner Code", "Avalara Exemption").
**Cause:**
The `invisible` property of those fields is using `fiscal_country_codes` char field.
If no company is set on the record, `fiscal_country_codes` will contain the country code of the selected companies in addition to the country code of the record.
In this case, the value of `fiscal_country_codes` will be `US,CA` string, which triggers `fiscal_country_codes not in ('US', 'CA')` invisible condition.
opw-6328395
Forward-Port-Of: odoo/enterprise#124619This fixes an error that prevented users from saving changes to analytic distribution settings on employee records. Payroll accounting users can now update these employee analytics normally without running into a save-time traceback.
Original PR description
Problem: Users cannot change analytic distribution set on employees. Users encounter an error when trying to change it. Steps to reproduce: 1. Enable analytic accounting 2. Try to edit the analytic…
Problem: Users cannot change analytic distribution set on employees. Users encounter an error when trying to change it. Steps to reproduce: 1. Enable analytic accounting 2. Try to edit the analytic distribution field on an Employee 3. Notice the error being thrown when trying to save Cause: Analytic distribution field is a JSON field and JSON field and tracking is not supported on JSON fields. https://github.com/odoo/odoo/blob/2aa35eb9c7a709126dca65e81ca6e823706fbb19/addons/mail/models/mail_tracking_value.py#L172 Tracking is supported for other fields but is not supported for JSON fields, so setting tracking=True on a JSON fields leads to an error being thrown. The error gets thrown whenever the field is edited. Caused by 88a3e70 , as a result of this comment https://github.com/odoo/odoo/blob/0133e46f89df7dce8c39d2bacd29579d57a83fad/addons/hr/models/hr_version.py#L443 that mentioned that whitelisted fields should have tracking set to true. However, that's not necessary. opw-6405122 Forward-Port-Of: odoo/enterprise#125135
The Timesheets Assistant now opens in a more intuitive chronological view, avoids unnecessary duplicate loading, and keeps dismissed suggestions from reappearing. The update also smooths selection visuals and improves recognition of Discord browser activity, making automated timesheet suggestions feel more stable and trustworthy.
Original PR description
## [FIX] timesheet_grid: remove duplicate rpc call Before this commit, the `loadTimesheets` method is called 2 times in a row, that method does a rpc call to load the existing timesheets and so, it…
## [FIX] timesheet_grid: remove duplicate rpc call Before this commit, the `loadTimesheets` method is called 2 times in a row, that method does a rpc call to load the existing timesheets and so, it is not needed to call it 2 times since the rpc will return the exact same result. This commit removes the rpc call when we compute the suggestions to only load the timesheets when we load all the data. ## [FIX] timesheet_grid: show chronological view instead of project view Before this commit, the `by project` view were loaded first in the timesheet assistant action, to group the suggestion by project, the problem is at the beginning the view will not really show a perfect matching and so the user could think the feature does not work and he will not understand how to correctly match the suggestions shown in the view. This commit changes the view loaded by default in Timesheets Assistant to first show the chronological view, that view is more logical for the current user to rethink what he did in the past to correctly map the events to a project and a task when he generates his timesheets thanks to those events. The by project view is still useful afterwards when the system has learned the choices made by the current user. ## [FIX] timesheet_grid: ensure events are consumed forever Before this commit, the suggestions removed by the current user comes back when he changes the date and come back to the day he removes the suggestions. The reason is because a shallow copy of events consumed is made and that copy alters the duration of the initial object. This commit avoids copying the consumed events object to make sure the initial object is not altered when processing the events to remove them if they are removed before by the user. ### Steps to reproduce the issue: 1. install timesheet_grid and Activity watch, makes sure Activity watch collects some activities on your computer. 2. Go to Assistant menu in timesheets app. 3. Remove some suggestions displayed in the right panel. 4. Go to next date. 5. Come back to previous date. ### Expected Behavior: The suggestions removed should not appear again. ### Actual Behavior: The suggestions removed come back in the view. ## [FIX] timesheet_grid: fix flicker when suggestion selected Before this commit, when the user selects a suggestion in timesheet assistant, there is a small flicker appears because the height of the row grows because of the border added to highlight the suggestion selected. This commit reviews a bit the style to make sure the border bottom in the previous element is removed if the element is not selected or if the 2 consecutives suggestions are selected. ## [FIX] timesheet_grid: fix discord rules to handle discord in web Before this commit, when the user uses discord in its browser instead of the app on his computer, the discord rules don't catch the activity watch events because the tab title is different than the windows name in the app. This commit adapts the regex of Discord rules to handle the both use cases. task-[6385639](https://www.odoo.com/odoo/project.task/6385639)
1 change
Resolved issues and error corrections
This fixes an error that prevented users from saving changes to analytic distribution on employee records. The payroll accounting field remains available for use, but it is no longer tracked in the chatter where that tracking was unsupported.
Original PR description
Problem: Users cannot change analytic distribution set on employees. Users encounter an error when trying to change it. Steps to reproduce: 1. Enable analytic accounting 2. Try to edit the analytic…
Problem: Users cannot change analytic distribution set on employees. Users encounter an error when trying to change it. Steps to reproduce: 1. Enable analytic accounting 2. Try to edit the analytic distribution field on an Employee 3. Notice the error being thrown when trying to save Cause: Analytic distribution field is a JSON field and JSON field and tracking is not supported on JSON fields. https://github.com/odoo/odoo/blob/2aa35eb9c7a709126dca65e81ca6e823706fbb19/addons/mail/models/mail_tracking_value.py#L172 Tracking is supported for other fields but is not supported for JSON fields, so setting tracking=True on a JSON fields leads to an error being thrown. The error gets thrown whenever the field is edited. Caused by 88a3e70 , as a result of this comment https://github.com/odoo/odoo/blob/0133e46f89df7dce8c39d2bacd29579d57a83fad/addons/hr/models/hr_version.py#L443 that mentioned that whitelisted fields should have tracking set to true. However, that's not necessary. opw-6405122 Forward-Port-Of: odoo/enterprise#125135
1 change
Resolved issues and error corrections
This fix prevents the automated Mexican e-invoice status check from repeatedly reprocessing the same documents and potentially running indefinitely. It prioritizes older customer invoices and limits vendor bill checks to a defined time window, helping keep scheduled processing stable and reliable.
Original PR description
While trying to fix the SAT cron, we did not think it through it could cause infinite cron triggering. Indeed, the write_date is updated on every record that is handled. Fix is manyfold: - Avoid…
While trying to fix the SAT cron, we did not think it through it could cause infinite cron triggering. Indeed, the write_date is updated on every record that is handled. Fix is manyfold: - Avoid re-processing what we already check within the last 4 hours/12 hours depending on the type of the document. - The domain takes the *static* create date instead of the write_date to make sure we don't endless re-process the same record and that the window of 7/60 days applies. - Limit the Vendor Bill to be checked only during 7 days after their creation. - Use the create_date in the order of the search to ensure we process older records first, before their time-window closes. - Process the Vendor Bills last, this ensure Customer Invoices will be processed in priority in case we are not able to process everything within the last 4/12 hours. This is still imperfect and a little fragile, we will find a better solution in master, most likely by adding a dedicated field to keep track of the last SAT check. See https://github.com/odoo/enterprise/pull/123213 See https://github.com/odoo/enterprise/pull/103272 task-none Forward-Port-Of: odoo/enterprise#125317
1 change
Resolved issues and error corrections
This fix prevents the Mexican electronic invoicing status check from repeatedly reprocessing the same documents and potentially running endlessly. It prioritizes older customer invoices and limits vendor bill checks to reduce unnecessary processing and keep tax validation jobs running reliably.
Original PR description
While trying to fix the SAT cron, we did not think it through it could cause infinite cron triggering. Indeed, the write_date is updated on every record that is handled. Fix is manyfold: - Avoid…
While trying to fix the SAT cron, we did not think it through it could cause infinite cron triggering. Indeed, the write_date is updated on every record that is handled. Fix is manyfold: - Avoid re-processing what we already check within the last 4 hours/12 hours depending on the type of the document. - The domain takes the *static* create date instead of the write_date to make sure we don't endless re-process the same record and that the window of 7/60 days applies. - Limit the Vendor Bill to be checked only during 7 days after their creation. - Use the create_date in the order of the search to ensure we process older records first, before their time-window closes. - Process the Vendor Bills last, this ensure Customer Invoices will be processed in priority in case we are not able to process everything within the last 4/12 hours. This is still imperfect and a little fragile, we will find a better solution in master, most likely by adding a dedicated field to keep track of the last SAT check. See https://github.com/odoo/enterprise/pull/123213 See https://github.com/odoo/enterprise/pull/103272 task-none Forward-Port-Of: odoo/enterprise#125317
2 changes
Resolved issues and error corrections
This fixes an error that could appear when editing analytic distribution information on an employee after analytic accounting was enabled. The change prevents unsupported change tracking on that field, helping HR/payroll users update employee accounting details reliably.
Original PR description
This commit partially reverts [1] To reproduce the issue: 1. Enable analytic accounting 2. Try to edit the analytic distribution field on an Employee Error: a traceback appears Commit [1] makes a JSON field tracked, which is forbidden: https://github.com/odoo/odoo/blob/2aa35eb9c7a709126dca65e81ca6e823706fbb19/addons/mail/models/mail_tracking_value.py#L172 We cancel the tracking part of [1] so the production versions will follow the code on master: the field `analytic_distribution` will be both whitelisted and untracked (as done by [2]): https://github.com/odoo/enterprise/blob/84112a92c3e06f4975e2fa68b6c8876430ecb3e5/hr_payroll_account/models/hr_version.py#L9-L15 [1] https://github.com/odoo/enterprise/commit/88a3e70bba20c2d508f8970d31ce6ee7afd11ee4 [2] https://github.com/odoo/enterprise/commit/55bec464e3861d5023f7e78588142ddc22d500d8 opw-6405122 opw-6416523 opw-6412398 opw-6411399 opw-... Forward-Port-Of: odoo/enterprise#125135
Uruguayan electronic credit notes for original e-Tickets with a 0.00 total now keep the required reference amount in the submission. This prevents DGI rejection of valid zero-value credit notes and helps businesses issue compliant corrections without manual workarounds.
Original PR description
Problem: When generating an e-Ticket Credit Note for an original e-Ticket with a total amount of 0.00, the XML cleanup mechanism removes reference fields whose value is 0.00. As a result, the credit note is rejected by DGI with: "CODE 31: En línea de Referencia 1 si NO IndGlobal = 1 deben existir TpoDocRef, Serie, NroCFERef, MntCFERef, TpoMonedaRef." Solution: Ensure that MntCFERef is sent even if the value is 0.00. opw-6378783 Forward-Port-Of: odoo/enterprise#124595 Forward-Port-Of: odoo/enterprise#124354
1 change
Resolved issues and error corrections
This fixes a scheduling issue that could repeatedly recheck the same Mexican electronic invoicing documents and keep the background job running unnecessarily. The change prioritizes older customer invoices, limits vendor bill checks to a shorter window, and reduces duplicate processing so status checks are more stable and efficient.
Original PR description
While trying to fix the SAT cron, we did not think it through it could cause infinite cron triggering. Indeed, the write_date is updated on every record that is handled. Fix is manyfold: - Avoid…
While trying to fix the SAT cron, we did not think it through it could cause infinite cron triggering. Indeed, the write_date is updated on every record that is handled. Fix is manyfold: - Avoid re-processing what we already check within the last 4 hours/12 hours depending on the type of the document. - The domain takes the *static* create date instead of the write_date to make sure we don't endless re-process the same record and that the window of 7/60 days applies. - Limit the Vendor Bill to be checked only during 7 days after their creation. - Use the create_date in the order of the search to ensure we process older records first, before their time-window closes. - Process the Vendor Bills last, this ensure Customer Invoices will be processed in priority in case we are not able to process everything within the last 4/12 hours. This is still imperfect and a little fragile, we will find a better solution in master, most likely by adding a dedicated field to keep track of the last SAT check. See https://github.com/odoo/enterprise/pull/123213 See https://github.com/odoo/enterprise/pull/103272 task-none Forward-Port-Of: odoo/enterprise#125317