Daily updates from Odoo
Monday, February 10, 2025
22 changes · master
Enhancements to existing features
The bank reconciliation view now clearly labels entries that are not linked to a bank statement with “No bank Statement.” This makes it easier for users to distinguish these entries at a glance and reduces confusion during reconciliation.
Original PR description
Before this change, lines without statements were visually indistinguishable from those with statements in the bank reconciliation view. This update improves clarity by ensuring such lines are easier to differentiate by adding "No bank Statement" above the lines task: 4412424
This update modernizes automated tests for several Odoo Studio editing tools, including reports, lists, calendars, maps, charts, pivots, and new model creation. It helps ensure these Studio features remain stable and easier to maintain, without changing day-to-day user workflows.
This update improves automated checks around test bundles in Odoo Enterprise. It helps ensure export-related behavior in Web Studio remains reliable without introducing direct user-facing changes.
Activity summaries for tax report reminders no longer repeat the deadline, since the due date is already shown separately. This makes dashboard activities shorter and easier for users to scan.
Original PR description
We're removing the "deadline" from the summary as the actual deadline on the activity is enough for the users to know when it is due. This also makes the activity look more concise and easier to read on the dashboard. Task ID: 4501944
Resolved issues and error corrections
This update streamlines how live chat creates and manages helpdesk tickets, making the process easier to maintain and less prone to errors. It also updates related tests to help ensure ticket access and timesheet behavior remain reliable.
Original PR description
follow up of task-4432728 community: https://github.com/odoo/odoo/pull/196567
Miscellaneous changes
Steps: - enable rental transfers - activate MTO route - create a product with MTO route and 0 stock - create a rental order for that product, validate Issue: The rental order will create 2 pickings that are waiting for each other. This is because the MTO move is using the same rental route with the stock destination, so it ends on the return rental picking. Fix: Force the procurement to use the `route_id` of the `rule_id` of the origin move. This way it will correctly create a new
Original PR description
Steps: - enable rental transfers - activate MTO route - create a product with MTO route and 0 stock - create a rental order for that product, validate Issue: The rental order will create 2 pickings that are waiting for each other. This is because the MTO move is using the same rental route with the stock destination, so it ends on the return rental picking. Fix: Force the procurement to use the `route_id` of the `rule_id` of the origin move. This way it will correctly create a new picking from Vendor to Stock for the product. If the product has a Buy or Manufacture route, it will use those instead. Also found another issue when enabling, then disabling, then re-enabling rental pickings: the stock rule stays archived. It is now fixed and a test has been added. Forward-Port-Of: odoo/enterprise#78648 Forward-Port-Of: odoo/enterprise#76477
GroupingCategory and GroupingCode nodes have changed from optional to mandatory in SAF-T V1.3. For the category, we use RF-1167 for now as it's the most common value. task-4374014 Forward-Port-Of: odoo/enterprise#78778 Forward-Port-Of: odoo/enterprise#77423
Original PR description
GroupingCategory and GroupingCode nodes have changed from optional to mandatory in SAF-T V1.3. For the category, we use RF-1167 for now as it's the most common value. task-4374014 Forward-Port-Of: odoo/enterprise#78778 Forward-Port-Of: odoo/enterprise#77423
The override of `_action_launch_stock_rule` was passing its `previous_product_uom_qty` keyword argument as a positional parameter to the `super` call, preventing other overrides from passing it with its key name. This commit ensures that the argument is now passed correctly with its key name. It also makes the override kwargs-agnostic by packing and unpacking them with `**`, thus preventing future issues related to signature changes in the parent method. See also: - https://github.com/odo
Original PR description
The override of `_action_launch_stock_rule` was passing its `previous_product_uom_qty` keyword argument as a positional parameter to the `super` call, preventing other overrides from passing it with its key name. This commit ensures that the argument is now passed correctly with its key name. It also makes the override kwargs-agnostic by packing and unpacking them with `**`, thus preventing future issues related to signature changes in the parent method. See also: - https://github.com/odoo/enterprise/pull/77839 - https://github.com/odoo/documentation/pull/11823 Forward-Port-Of: odoo/enterprise#78786 Forward-Port-Of: odoo/enterprise#77839
Issue: ------ When making changes in version 17.0 using studio the correspondent standard view's noupdate becomes 'True' as per the logic implemented. But when we migrate the database to the further versions like 18.0. The changes made in that particular view in 18.0 will not be loaded and will cause errors since its inherited view's will not be compatible enough. For ex: If we make changes in a "Purchase Order"(i.e; purchase.report_purchaseorder) report then after saving the changes the n
Original PR description
Issue: ------ When making changes in version 17.0 using studio the correspondent standard view's noupdate becomes 'True' as per the logic implemented. But when we migrate the database to the further…
Issue: ------ When making changes in version 17.0 using studio the correspondent standard view's noupdate becomes 'True' as per the logic implemented. But when we migrate the database to the further versions like 18.0. The changes made in that particular view in 18.0 will not be loaded and will cause errors since its inherited view's will not be compatible enough. For ex: If we make changes in a "Purchase Order"(i.e; purchase.report_purchaseorder) report then after saving the changes the noupdate of that report view which is "purchase.report_purchaseorder_document" will be updated to 'true'. And the action record i.e; "purchase.action_report_purchase_order" noupdate will be updated to 'true'.   If the customer makes changes using studio then those changes will be recorded in the studio view and there is no point of making the standard view's noupdate to 'true'. Solution: ----------- Remove redundant code to overcome updating noupdate to 'true'. Steps to reproduce: ------------------------ 1. Create a database in version 17.0. 2. Make changes in any report using studio and save. 3. Migrate the database and try opening that report. 4. You'll encounter issues due to incompatibilty of views. Since, the changes made in the standard will not be loaded because it's noupdate is true. REF PRS: Enterprise PR: 1.https://github.com/odoo/enterprise/commit/2ae63d9a43ba973d905232105201d88e423a8245#diff-cf8f46a54f86279b4d773f0d39b23d22f046eb6d33a39c851f2a86dcd2b5b202R463 Forward-Port-Of: odoo/enterprise#78582
Before this commit, the /my/subscriptions/<int:order_id>/transaction route would create a draft invoice when it was called to anticipate a payment. post processing of payment.transaction is able to create the invoice and to associate it with the correct sale.order. In order to simplify the code by limiting the part of the code where subscription invoices can be created, we decided to let the _post_process do the work. taskid: 4368037 Forward-Port-Of: odoo/enterprise#77432
Original PR description
Before this commit, the /my/subscriptions/<int:order_id>/transaction route would create a draft invoice when it was called to anticipate a payment. post processing of payment.transaction is able to create the invoice and to associate it with the correct sale.order. In order to simplify the code by limiting the part of the code where subscription invoices can be created, we decided to let the _post_process do the work. taskid: 4368037 Forward-Port-Of: odoo/enterprise#77432
During testing of the "new" Chrome's headless mode (by default since version 128), a concurrency issue arise at the end of those tours: a last request to the server is actually sent during the unload of the view. This request actually reach the server even if Chrome is already closed and the test is cleaning itself (rollbacking the changes made in the database), resulting into a "release savepoint" mismatch on an already aborted transaction (example build's error [1]). This commit is kind of
Original PR description
During testing of the "new" Chrome's headless mode (by default since version 128), a concurrency issue arise at the end of those tours: a last request to the server is actually sent during the unload of the view. This request actually reach the server even if Chrome is already closed and the test is cleaning itself (rollbacking the changes made in the database), resulting into a "release savepoint" mismatch on an already aborted transaction (example build's error [1]). This commit is kind of a follow-up of a previous PR [2] where a last step allowing for the spreadsheet to unload was added and adding one more to actually wait to be back on the Document app. [1] https://runbot.odoo.com/runbot/build/74602509 [2] https://github.com/odoo/enterprise/pull/51795 Forward-Port-Of: odoo/enterprise#78896 Forward-Port-Of: odoo/enterprise#78797
During testing of the "new" Chrome's headless mode (by default since version 128), a concurrency issue arise at the end of those tours: a last request to the server is actually sent during the unload of the view (cf. save). This request actually reach the server even if Chrome is already closed and results into a SQl constraint error. Indeed, the (very basic) form views created for those tours are based on the "res.partner" model and only display the "name" field. This field isn't marked as "
Original PR description
During testing of the "new" Chrome's headless mode (by default since version 128), a concurrency issue arise at the end of those tours: a last request to the server is actually sent during the unload of the view (cf. save). This request actually reach the server even if Chrome is already closed and results into a SQl constraint error. Indeed, the (very basic) form views created for those tours are based on the "res.partner" model and only display the "name" field. This field isn't marked as "required" neither in the model, nor the view BUT has a SQL constraint attached to it... which makes it implicitly "required". This commit fixes it by properly marking them as such in the arch to let the client-side validation prevent the ultimate "save" request made during the unload. Forward-Port-Of: odoo/enterprise#78903 Forward-Port-Of: odoo/enterprise#78810
Versions -------- - 17.0+ Steps ----- 1. Use Belgian localization; 2. create an invoice for a Belgian customer; 3. pay the invoice using SEPA Direct Debit; 4. go to Accounting / Bank; 5. create a bank statement matching the SDD mandate details; 6. go to payment transactions linked to the invoice. Issue ----- The transaction is still pending, and the SDD Mandate hasn't been confirmed. Cause ----- When matching transactions to bank statement lines, it checks whether `tx.refer
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Use Belgian localization; 2. create an invoice for a Belgian customer; 3. pay the invoice using SEPA Direct Debit; 4. go to Accounting / Bank; 5. create a bank statement matching the SDD mandate details; 6. go to payment transactions linked to the invoice. Issue ----- The transaction is still pending, and the SDD Mandate hasn't been confirmed. Cause ----- When matching transactions to bank statement lines, it checks whether `tx.reference == line.payment_ref`. The `tx.reference` is based on the invoice name, whereas `payment_ref` depends on localization, with Belgian payment request being structured as `+++000/0000/12345+++`. Solution -------- When creating a SDD mandate transactions, display `tx.reference` as payment communication. opw-4380832 Forward-Port-Of: odoo/enterprise#78787 Forward-Port-Of: odoo/enterprise#78413
It is possible for a user to empty the value for `l10n_au_medicare_reduction` from an employee's form. Since this field is used in the computation of `l10n_au_tax_treatment_code`, doing so will trigger an error: ``` File "/home/odoo/src/enterprise/18.0/l10n_au_hr_payroll/models/hr_employee.py", line 347, in _compute_l10n_au_tax_treatment_code code += rec.l10n_au_medicare_reduction # Sixth Character TypeError: can only concatenate str (not "bool") to str ``` This error can also happe
Original PR description
It is possible for a user to empty the value for `l10n_au_medicare_reduction` from an employee's form. Since this field is used in the computation of `l10n_au_tax_treatment_code`, doing so will trigger an error:
```
File "/home/odoo/src/enterprise/18.0/l10n_au_hr_payroll/models/hr_employee.py", line 347, in _compute_l10n_au_tax_treatment_code
code += rec.l10n_au_medicare_reduction # Sixth Character
TypeError: can only concatenate str (not "bool") to str
```
This error can also happen during upgrades, when employee records are created before the module `l10n_au_hr_payroll` is loaded.
Forward-Port-Of: odoo/enterprise#78834[task-4421055](https://www.odoo.com/odoo/project.task/4421055) Forward-Port-Of: odoo/enterprise#78734
Original PR description
[task-4421055](https://www.odoo.com/odoo/project.task/4421055) Forward-Port-Of: odoo/enterprise#78734
With the introduction of Invoicing Enterprise (access to bank recon etc) a new user group was created "Invoicing & Banks" (`group_account_basic`) This group should also be able to access the customer statement / partner ledger (from the partner smart button) Task-4465208 Forward-Port-Of: odoo/enterprise#78807
Original PR description
With the introduction of Invoicing Enterprise (access to bank recon etc) a new user group was created "Invoicing & Banks" (`group_account_basic`) This group should also be able to access the customer statement / partner ledger (from the partner smart button) Task-4465208 Forward-Port-Of: odoo/enterprise#78807
Steps to Reproduce: - create a helpdesk ticket from the website form without attachments. - creation message in the chatter is missing. Cause: - subtype_id for helpdesk ticket messages was explicitly set in the bridge module's insert_attachment method. When no attachments were present, this prevented the _creation_subtype logic in the helpdesk.ticket model from executing, resulting in the missing creation message. Solution: - Added a condition in the insert_attachment method to skip mo
Original PR description
Steps to Reproduce: - create a helpdesk ticket from the website form without attachments. - creation message in the chatter is missing. Cause: - subtype_id for helpdesk ticket messages was explicitly set in the bridge module's insert_attachment method. When no attachments were present, this prevented the _creation_subtype logic in the helpdesk.ticket model from executing, resulting in the missing creation message. Solution: - Added a condition in the insert_attachment method to skip modifying messages when no attachments are present. It ensures that the default _creation_subtype logic handles subtype assignment, maintaining consistent and accurate creation message logging in the chatter. task-4397661 Forward-Port-Of: odoo/enterprise#78777 Forward-Port-Of: odoo/enterprise#76111
In the tree view of the payslip model, we can do mass edit to create a journal entry. Before, we were able to perform this action on a paid payslip which does not make sense. Now we have an error message if we try to do it. Task: 3874129 Forward-Port-Of: odoo/enterprise#78730 Forward-Port-Of: odoo/enterprise#75035
Original PR description
In the tree view of the payslip model, we can do mass edit to create a journal entry. Before, we were able to perform this action on a paid payslip which does not make sense. Now we have an error message if we try to do it. Task: 3874129 Forward-Port-Of: odoo/enterprise#78730 Forward-Port-Of: odoo/enterprise#75035
TaskID: 4558836 Forward-Port-Of: odoo/enterprise#78840
Original PR description
TaskID: 4558836 Forward-Port-Of: odoo/enterprise#78840
The aim of this commit is cleaning a weird indentation introduced by this commit [[1]]. no task id [1]: https://github.com/odoo/enterprise/commit/103369fb171654f4b0457d9b1629224def7465eb Forward-Port-Of: odoo/enterprise#78811
Original PR description
The aim of this commit is cleaning a weird indentation introduced by this commit [[1]]. no task id [1]: https://github.com/odoo/enterprise/commit/103369fb171654f4b0457d9b1629224def7465eb Forward-Port-Of: odoo/enterprise#78811
When the user claims the document and there is no valid token Odoo tries to re-generate the token, and instead of recalling to try to claim the document the code is wrongly calling the method to accept the document This logic was added in this https://github.com/odoo/enterprise/commit/3e906a93b91b5f66a4da850acc2b5ff2f43dd267 but for reason when the methods for accept/claim were merged into one method (_l10n_cl_action_response) -- Adhoc Ticket 86396 Forward-Port-Of: odoo/enterprise#782
Original PR description
When the user claims the document and there is no valid token Odoo tries to re-generate the token, and instead of recalling to try to claim the document the code is wrongly calling the method to accept the document This logic was added in this https://github.com/odoo/enterprise/commit/3e906a93b91b5f66a4da850acc2b5ff2f43dd267 but for reason when the methods for accept/claim were merged into one method (_l10n_cl_action_response) -- Adhoc Ticket 86396 Forward-Port-Of: odoo/enterprise#78248
In [1] the `params` section was refactored, but removing the `]` was missed. This caused an error, always returning "No encontrado". [1] https://github.com/odoo/enterprise/commit/14c1b2f8b36ade09be021d2ae202da19f88c0b78 Forward-Port-Of: odoo/enterprise#78891
Original PR description
In [1] the `params` section was refactored, but removing the `]` was missed. This caused an error, always returning "No encontrado". [1] https://github.com/odoo/enterprise/commit/14c1b2f8b36ade09be021d2ae202da19f88c0b78 Forward-Port-Of: odoo/enterprise#78891