Tuesday, July 15, 2025
5 changes · 17.0
Resolved issues and error corrections
This fixes survey invitation emails so they use the subject configured on the survey email template instead of always reverting to the default survey subject. Businesses can now rely on customized invitation wording being shown correctly when sharing surveys by email.
Original PR description
Description of the issue/feature this PR addresses:
When a user updates the subject on a template used for a survey, it does not pull the subject from the template. It uses the default subject that is used when computing the subject for a survey email that is sent out. This bug came as a part of [this commit](https://github.com/odoo/odoo/commit/220e0271bf43e914950b8ae0d4a1cca5f3ea6d9c).
I've used an elif condition over here as opposed to calling super which was being done before so that the default of Participate to X survey still becomes the default subject.
opw-4654411
Steps to reproduce on runbot:
1. Go to mail templates and search for Survey
2. Open the Survey: Invite template
3. Update the subject on this template
4. Open the Surveys app and select any survey
5. Click on Share and then enable send by email
6. The subject here will default to "Participate to {Survey Name}"
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prManufacturing users can now print bill of materials reports even when a byproduct has a quantity of zero. The report avoids an invalid cost calculation and shows the byproduct cost as zero in that case, preventing a crash during printing.
Original PR description
**Issue**:
Printing the BOM crashes when one of the byproduct quantity is set to 0
**Steps to reproduce**:
- Open the manufactoring app
- Go to settings and activate by-product settings
- Go to Products > Bills of Materials
- Open a BOM
- Put the quantity of one the by-product by 0
- Click on overview
- Click on the print button
**Cause**:
In the `mrp_report_bom_structure.xml` template, there is this division:
- `<td class="text-end" t-esc="byproduct['bom_cost'] / byproduct['quantity']" t-options='{"widget": "monetary", "display_currency": currency}'/>`
without checking if `byproduct['quantity']` is different than 0.
**Solution**:
Added the check on `byproduct['quantity']` in the foreach
**Additional notes**:
Since it makes no real sense to have a non-zero BoM cost associated with a byproduct whose quantity is zero, the cost is set to 0 when the quantity is 0.
opw-4853525
Forward-Port-Of: odoo/odoo#213936This fixes a failing sales test by removing an incorrect check that expected an invoice amount to be zero. The correction helps keep automated testing reliable without changing how users create or manage sales orders.
Original PR description
steps to reproduce:
1- install l10n_ke_edi_oscu_mrp
2- run test test_discount_and_untaxed_subtotal
the assert is not needed and wrong in the test , as you can see there is another 2 asserts that checks
```
self.assertEqual(line.price_subtotal, 17527.41)
self.assertEqual(line.untaxed_amount_to_invoice, line.price_subtotal)
```
which indicates that `untaxed_amount_to_invoice` is equal to `price_subtotal` which is equal to 17527.41 not 0.
build_error-70728When an employee is archived, the departure process now correctly removes that user's approver links from other employee records even if they are only assigned to one approver role. This prevents outdated time off, expense, or timesheet approver assignments from remaining after someone leaves.
Original PR description
Currently, a user needs to be time off, expense and timesheet approver of an employee for those links to be removed by the departure wizard. If not all the approver fields are the same user, that link will not be removed. Steps to reproduce: - Set Marc Demo as only Time Off approver on an employee. - Archive Marc Demo's employee (This does not remove time off approver from the previous employee) To rectify this issue, we correctly group the `user_domain` so that their contents are properly OR'd. Forward-Port-Of: odoo/odoo#213513
The scheduled eSignature reminder process now handles requests that do not have an expiration date. This prevents reminder jobs from crashing and helps ensure signing workflows continue without interruption.
Original PR description
The cron can fetch record with no validity date,
so the check request.validity < today
raise
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/saas-18.3/odoo/tools/safe_eval.py", line 397, in safe_eval
return unsafe_eval(c, globals_dict, locals_dict)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "ir.actions.server(5136,)", line 3, in <module>
File "/home/odoo/src/enterprise/saas-18.3/sign/models/sign_request.py", line 437, in _cron_reminder
if request.validity < today:
^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: '<' not supported between instances of 'bool' and 'datetime.date'
```