Wednesday, July 30, 2025
35 changes · saas-18.4
Enhancements to existing features
The IoT Box homepage now shows a more accurate warning when its SSL certificate is invalid. The message no longer incorrectly suggests that a subscription is required, reducing confusion for users and support teams.
Original PR description
When the IoT Box doesn't have a valid ssl certificate, we used to display a warning telling that there is no valid subscription. As users don't need a subscription anymore to get a valid certificate, we now only tell that the certificate is invalid. Task: 4978644 Forward-Port-Of: odoo/odoo#221152
This update expands the invoice document information Odoo can handle for electronic invoicing. It helps meet Peruvian e-invoicing requirements after recent UBL-related changes, improving compatibility for affected accounting workflows.
Original PR description
l10n_pe_edi requires more from the UBL 2.1 spec than currently supported post UBL refactor. As such we add the datatypes necessary to support it. task-4605204
The IoT Box image now prepares its log viewing shortcut to show colored log output when colorized logs are introduced. This should make future troubleshooting easier by preserving visual highlighting in log files.
Original PR description
in order for the alias to be ready for when we add colors to logs, we added the `-R` option for the `less` command to render colors.
The website image quality check has been updated to work with the redesigned website builder. This helps ensure image optimization behavior remains reliable and reduces the risk of regressions in future website updates.
Original PR description
`website_image_quality` tour was previously broken due to DOM structure changes introduced by the new website builder and was consequently disabled. This commit updates the tour steps to align with the new DOM and re-enables the associated test. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change improves Odoo's testing behavior when simulated time is used, ensuring database time matches the application time during tests. It helps make time-sensitive tests more reliable without affecting normal production use.
Original PR description
[IMP] sql_db: replace now to reflect the time offset When using the faketime lib to test Odoo, only the Odoo processes are affected, so it does not reproduce the reality. With this commit, when an environment variable `ODOO_FAKETIME_MODE` is set, the cursor `now` function is altered the same way faketime alters the Odoo processes. See https://github.com/wolfcw/libfaketime Forward-Port-Of: odoo/odoo#220865 Forward-Port-Of: odoo/odoo#219671
This update adds automated testing for a restaurant point-of-sale flow where an unsent order is selected from a popup, sent to preparation, and paid in one sequence. It helps reduce the risk of checkout or kitchen preparation issues reaching users.
Original PR description
In this commit: ----------------------------- - Add test to ensure clicking order in the popup sends the order to preparation and validate payment in one flow. Task: 4804669 Related PR - https://github.com/odoo/odoo/pull/211642 Forward-Port-Of: odoo/enterprise#86413
Resolved issues and error corrections
Fixes an issue where an unsupported device connected to an IoT box made the system repeatedly report device changes every few seconds. This reduces unnecessary database requests and log noise without changing normal device behavior.
Original PR description
In the forward port of odoo/odoo#218109, a bug was introduced where if an unsupported device is connected, the device list is always detected as being changed, so the IoT box sends devices to the database every 3 seconds. This doesn't cause any problems other than spamming the logs and the DB with requests, but should be fixed regardless. After this commit, the unsupported devices are taken into account correctly when detecting device changes. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#221183
Users can now update progress bar values reliably when using Firefox. This fixes a browser-specific issue where changes entered in list views were not saved, improving consistency across supported browsers.
Original PR description
Before this commit, the input of the progressbar field couldn't be updated on firefox. It works on the other browsers by chance. In the list renderer, we call `preventDefault` on enter keydown. The event is first catch by the list renderer. This call is enough to prevent "change" event to trigger but on chromium browsers it is actually triggered (but should not). The progressbar field catches it and saves the new value. On firefox, the "change" event is never triggered. The commit fixes the input by using the input field hook to make it behave correctly. task-4881210 Forward-Port-Of: odoo/odoo#218860 Forward-Port-Of: odoo/odoo#215770
The website editor now shows the blue selection overlay at the correct height when previewing options for countdown and chart snippets. This makes editing these snippets clearer and avoids visual confusion for users building website pages.
Original PR description
When previewing options of certain snippets in the website editor, the builder overlay (in blue) did not have the correct height. Concerned snippets: countdown and chart. Steps to reproduce for the countdown snippet: 1. Open the website editor. 2. Add a countdown snippet. 3. Hover over any of the snippet options. 4. Observe that the blue overlay does not appear correctly around the countdown snippet. The issue with the chart snippet can be reproduced similarly.
The website form builder now clears a field's conditional visibility rule when its dependency is no longer valid after renaming fields. This prevents confusing self-reference situations that could cause errors when saving a website form.
Original PR description
Since the `html_builder`, the dependency field did not get unselected when it became unavailable for selection after a label rename. This commit removes the conditional visibility on a field in such a case. Steps to reproduce: - Drop a Form snippet - Add a text field named "A" - Add a text field named "B" - Add a conditional visibility on "B" that relies on "A" - Rename "B" to "A" => The conditional visibility remained applied and, upon save, this led to errors because of the self-reference. task-4367641
This fixes a typo in the Peru localization data where Huancayo was incorrectly written with an extra space. The correction helps ensure city names appear accurately in business records and local address data.
Original PR description
The Huancayo has an extra space in the name. Instead of Huancayo it is written Hua ncayo in the csv file. opw-4947526 Forward-Port-Of: odoo/odoo#220835 Forward-Port-Of: odoo/odoo#219888
This fix prevents an error from appearing when a user clears the Employee field while creating a time off allocation measured in hours. It improves reliability in the Time Off workflow by handling incomplete allocation forms more gracefully.
Original PR description
A traceback occurs when a user removes the Employee field while creating a time off allocation record. **To reproduce the issue:** 1) Install the `Time Off` module. 2) Create a new time off…
A traceback occurs when a user removes the Employee field while creating a time off allocation record. **To reproduce the issue:** 1) Install the `Time Off` module. 2) Create a new time off allocation record. 3) Navigate to the `Related Time Off Type` record. 4) Change the `Take Time Off in` option to Hours. 5) Return to the allocation and remove the Employee field. **Error:** ``` ZeroDivisionError: float division by zero ``` **Cause:** - When the Employee field is cleared, the `_compute_number_of_days` method is triggered. - Since the allocation_unit is set to Hours, this method attempts to calculate `number_of_days` using `_get_hours_per_day`. https://github.com/odoo/odoo/blob/96d4bd7911ba122610fd42c009da0a8e565e50ec/addons/hr_holidays/models/hr_leave_allocation.py#L256-L262 - However, when `employee_id` is missing, `_get_hours_per_day` returns 0, resulting in a division by zero. https://github.com/odoo/odoo/blob/96d4bd7911ba122610fd42c009da0a8e565e50ec/addons/hr_holidays/models/hr_employee.py#L140-L143 **Solution:** Since the employee_id is a required field in allocation, Adding an extra check for employee_id will resolve this issue. opw-4937893 Forward-Port-Of: odoo/odoo#221115 Forward-Port-Of: odoo/odoo#219403
This fixes an automated website tour that could get stuck while checking a popup animation. The change makes the test wait for the animation to finish and confirms the element has moved off screen, improving test reliability without changing customer-facing website behavior.
Original PR description
## Version 18.0+ ## Issue The tour `snippet_popup_and_animations` times out when trying to wait for the last column to become "not animated and hidden". This happens because the element never…
## Version 18.0+ ## Issue The tour `snippet_popup_and_animations` times out when trying to wait for the last column to become "not animated and hidden". This happens because the element never actually becomes `hidden` after the scroll-triggered animation ends — it remains in the DOM and visible. ## Cause Commit 7e85f88214b6b57db87a6c1964286f0b7813f6ff attempted to fix a selector that was always true by adding `:hidden`, assuming the element would be hidden once the scroll animation completed. But since the element’s visibility is never changed via `display: none` or `visibility: hidden`, the `:hidden` condition never matches, blocking the tour. ## Fix Remove the `:hidden` pseudo-class from the trigger. Instead, wait for the `.o_animating` class to be removed (indicating the end of the animation), then: - Add a short delay to ensure animation processing is complete. - Check that the element is outside of the viewport (scrolled out). - Verify that `animation-delay` is approximately 0. runbot-227077 Forward-Port-Of: odoo/odoo#219979 Forward-Port-Of: odoo/odoo#215567
This fix ensures mail conversations send their access and existence status back to the system even when a request contains no items. This helps avoid missing conversation state and supports more reliable messaging behavior for users.
Original PR description
Even if the request is an empty array, access (and existence of thread) should be sent. How to reproduce: https://github.com/odoo/odoo/pull/220605 Forward-Port-Of: odoo/odoo#220924 Forward-Port-Of: odoo/odoo#220774
The custom filter builder now limits image and other file-based fields to checks for whether a value exists or not. This prevents users from selecting unsupported filter options that could trigger an error when saving or applying filters.
Original PR description
The system encountered an error when users attempted to apply invalid filters on `binary fields` (e.g., `image_1024`). The error occurs when operators like 'is in' with empty string values ('') are…
The system encountered an error when users attempted to apply invalid filters on `binary fields` (e.g., `image_1024`). The error occurs when operators like 'is in' with empty string values ('') are used, as binary fields are stored As attachments only support existence checks.
**Steps to produce:-**
1. Add a filter like `[('image_1024', 'in', [])]` in the custom filter where the image exists(eg, Products) and save.
2. Error triggered.
**Error:-**
`Binary field 'Image 1024' stored in attachment: ignore image_1024 in [''] .`
**Solution:-**
- The `web` client's filter operator selection logic has been updated to restrict options for `binary` field types. Now, for binary fields, only the `is set` (`!= False`) and `is not set` (`= False`) operators will be available in the custom filter builder.
**Sentry - 6236134077**
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#221133
Forward-Port-Of: odoo/odoo#213608This update makes an automated mail test more stable by avoiding timing-sensitive checks while messages are edited repeatedly. It helps reduce false failures in quality checks without changing normal user behavior.
Original PR description
Before this commit, the "Can edit message comment in chatter" test could fail intermittently. The test performs three edits on the same message, and due to the asynchronous nature of the bus (mock…
Before this commit, the "Can edit message comment in chatter" test could fail intermittently. The test performs three edits on the same message, and due to the asynchronous nature of the bus (mock server > websocket > worker bus service > subscribers), bus notification are received later than rpc results. The test was asserting composer content between edits, which is unnecessary and sensitive to race conditions. For example: - First edit is sent. - Second edit is sent. - First edit is received. - Third edit opens the composer with outdated content. This is unlikely to occur in practice. This commit resolves the issue by removing non essential composer assertions. fixes runbot-227618 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220812 Forward-Port-Of: odoo/odoo#220389
Form fields displayed side by side now align their borders correctly when one field contains a nested input. This removes duplicated styling that caused extra padding, improving visual consistency in forms.
Original PR description
Inside form views when an input is displayed next to an other which contains nested `o_input`, the border is misaligned. This is due to a duplication of the `o_input` style in `form_controller.scss` which overrides the rule handling nested `o_input` in `fields.scss` resulting in 2x the necessary padding. [task-4974502](https://www.odoo.com/web#id=4974502&cids=1&menu_id=4720&action=333&active_id=1695&model=project.task&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220751
Fixed a display issue where the calendar “more” popover could look transparent on non-working days, letting events behind it show through. The popover now keeps a solid background, improving readability and reducing visual confusion for calendar users.
Original PR description
This commit resolves a visual issue with the FullCalendar "more" popover, where its background could appear partially transparent—causing events behind it to show through and creating a poor user experience. The problem was introduced with the update to FullCalendar v6.1.10, which applies cell-related classes (like o_calendar_disabled) to the popover. On non-working days, this class applies a semi-transparent grey background, affecting the popover's readability. The fix ensures that the popover background remains opaque in this specific case, restoring proper visual separation from underlying content. task-4916099 Forward-Port-Of: odoo/odoo#218877
Users can now apply theme colors to buttons in the HTML editor without running into an error. This fixes a small but visible editing issue that could interrupt website or content customization workflows.
Original PR description
Before this commit, it was not possible to set the color of a button to a theme color because an error would occur. A loop would try to remove all style while the color is applied through a class. This temporary fix removes the error.
This fix corrects mismatched formulas in the POS HR spreadsheet dashboard. Business users should see more reliable dashboard figures, helping avoid confusion when reviewing point-of-sale HR metrics.
Original PR description
Task: 4930419 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#218100 Forward-Port-Of: odoo/odoo#217908
Users working with French company invoices can now remove the Delivery Address field from the invoice view without triggering an error. This keeps Studio customization stable and avoids disruption when adapting invoice screens to business needs.
Original PR description
The system will crash with an error when we try to remove the field 'Delivery Address' from the invoice view while in 'fr company'. **Steps to Produce:-** - Install `l10n_fr` and `web_studio` with…
The system will crash with an error when we try to remove the field 'Delivery Address' from the invoice view while in 'fr company'. **Steps to Produce:-** - Install `l10n_fr` and `web_studio` with demo data. - Switch to `FR Company`. - Go to `Invoicing > Customers > Invoices`. - Open any invoice > Toggle studio > Click on `Delivery Address` > and then click on `REMOVE FROM VIEW`. - Observe the error. **Error:-** `IndexError: list index out of range` **Root Cause:-** - At [1], the `_get_view` method unconditionally expects the `partner_shipping_id` field to be present in the invoice form view. - It performs an `xpath` search for the field and immediately attempts to access the first element of the result list. **Solution:-** - Now, if the `partner_shipping_id` field exists in the view, then the logic proceeds as before. If it's not found, the code block is simply skipped. [1]: https://github.com/odoo/odoo/blob/044833804c9e10048ec10d7e982c98c4f33f4cf4/addons/l10n_fr_invoice_addr/models/account_move.py#L16 **sentry-6746543069** I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#218974
Restaurant point of sale refunds now complete without showing the unnecessary confirmation dialog for sending orders to the preparation display. This keeps the refund process smoother and avoids staff interruptions during returns.
Original PR description
Before this commit: ---------------------- - The Send Order to Preparation Display confirmation dialog also appeared when validating a refund, which was not necessary and interrupted the expected flow. After this commit: ------------------------ - No dialog shown for refunds. Task-4804669 Related PR - https://github.com/odoo/enterprise/pull/86413 Forward-Port-Of: odoo/odoo#211642
The Philippine BIR 2307 export checks now reflect the required ZIP code field and the correct payment description source. This helps ensure tax reports match expected regulatory export details and reduces false test failures.
Original PR description
The BIR 2307 XLS export was missing the `ZIP_code` and incorrectly showing the `nature` of payment from the invoice line instead of the tax description. In this commit: --- - updates the tests to include the `zip_code` column and fetch the correct `nature` from the tax description. - adjust name fields to reflect individual vs company partner logic. community-PR- odoo/odoo#214940 --- task-4880921 Forward-Port-Of: odoo/enterprise#91202 Forward-Port-Of: odoo/enterprise#91120
Activities configured on reconciliation models are now added to the related bank statement line when the model is triggered. This ensures accounting teams receive the intended follow-up tasks and do not miss work that was previously not created.
Original PR description
On a reco model, you can set an activity that should be applied on the statement line where the reco model is triggered. Before this commit the activity was not set. task-4954201 Forward-Port-Of: odoo/enterprise#90540
Starshipit shipping labels now include both address lines when a second street line is provided. This helps ensure carriers receive the full delivery address, reducing the risk of incomplete shipments or delivery issues.
Original PR description
Current behaviour: --- When using Starshipit, street2 is not included in the payload sent to the API. Expected behaviour: --- Street and Street2 should be both included if street2 is set, separated by a space. Steps to reproduce: --- 1. Install delivery_starshipit 2. Create starshipit Shipping Method 3. Create an Australian partner 4. Make sure street2 is set 5. Make a new sale order 6. Set the Australian partner 7. Set a product and click on "Add shipping" 8. Set starshipit as the method to use 9. Confirm and validate the delivery 10. Only the first street is sent opw-4907475 Forward-Port-Of: odoo/enterprise#90775 Forward-Port-Of: odoo/enterprise#89725
Fixes an error that could appear when users cleared and reselected a start date while tracking time on a manufacturing work order. This helps users update time tracking details without interruption or unexpected error screens.
Original PR description
When the user removes the value of the start date and selects the value again in the start date, a traceback will appear Steps to reproduce the error: - Create one mo > Work orders > Add a line >…
When the user removes the value of the start date and
selects the value again in the start date,
a traceback will appear
Steps to reproduce the error:
- Create one mo > Work orders > Add a line > Click on Open work order button
- In Time Tracking > Add a line > Remove the start date >
Select the start date again > Apply
Traceback:
```
TypeError: '<' not supported between instances of 'bool' and 'datetime.datetime'
File "odoo/http.py", line 2373, in __call__
response = request._serve_db()
File "odoo/http.py", line 1903, in _serve_db
return self._transactioning(
File "odoo/http.py", line 1966, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1933, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2177, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 223, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 754, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 35, in call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 459, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "addons/web/models/models.py", line 1007, in onchange
record._apply_onchange_methods(field_name, result)
File "odoo/models.py", line 7028, in _apply_onchange_methods
res = method(self)
File "addons/mrp/models/mrp_workcenter.py", line 448, in _date_start_changed
self._loss_type_change()
File "addons/mrp/models/mrp_workcenter.py", line 473, in _loss_type_change
if self.workorder_id.duration > self.workorder_id.duration_expected:
File "odoo/fields.py", line 1208, in __get__
self.recompute(record)
File "odoo/fields.py", line 1423, in recompute
apply_except_missing(self.compute_value, recs)
File "odoo/fields.py", line 1396, in apply_except_missing
func(records)
File "odoo/fields.py", line 1445, in compute_value
records._compute_field_value(self)
File "odoo/models.py", line 5037, in _compute_field_value
fields.determine(field.compute, self)
File "odoo/fields.py", line 101, in determine
return needle(*args)
File "home/odoo/src/enterprise/saas-17.4/mrp_workorder_hr_account/models/mrp_workorder.py", line 62, in _compute_duration
super()._compute_duration()
File "home/odoo/src/enterprise/saas-17.4/mrp_workorder/models/mrp_workorder.py", line 762, in _compute_duration
wo.duration = wo.get_duration()
File "home/odoo/src/enterprise/saas-17.4/mrp_workorder/models/mrp_workorder.py", line 838, in get_duration
duration += self._intervals_duration([(t.date_start, t.date_end or now, t) for t in times])
File "home/odoo/src/enterprise/saas-17.4/mrp_workorder/models/mrp_workorder.py", line 826, in _intervals_duration
for date_start, date_stop, timer in Intervals(intervals):
File "addons/resource/models/utils.py", line 124, in __init__
for value, flag, recs in sorted(_boundaries(intervals, 'start', 'stop')):
File "addons/resource/models/utils.py", line 51, in _boundaries
if start < stop:
```
https://github.com/odoo/enterprise/blob/1f626176d28762683dc32ddbb351d994be894a71/mrp_workorder/models/mrp_workorder.py#L787 Here when "date_start" is empty,
It leads to the above traceback.
sentry-5679416830
Forward-Port-Of: odoo/enterprise#91259
Forward-Port-Of: odoo/enterprise#68014This fix ensures field service tests use the correct time zone information, preventing failures that only happened in some environments. It helps keep automated quality checks stable and reduces delays caused by false test failures.
Original PR description
the task was missing the timezone context, which caused the test to fail in some environments. build_error-227059
Fixed an issue that prevented users from opening signing documents created by someone whose user account was later deleted. This keeps access to existing signature requests reliable and avoids an error screen in that edge case.
Original PR description
## Issue: ## Before this commit, opening a sign request created by a deleted user would raise an Owl Error ## Cause: ## The `action.params` are used as a fallback in the signRequest setup But sometimes sometimes the `action.params`are undefined, causing access to `action.params.create_uid` to fail ## Fix: ## The document can be open with `create_uid` set to False So we just added a check for `action.params` to be set before accessing his properties If the create_uid isn't in the context or in the params, it will be set to False ## Steps to reproduce: - Create a user (to be deleted later) - Create a sign request with this user - Delete the user - Try to open the sign request - The error should be displayed opw-4786368 Forward-Port-Of: odoo/enterprise#88758
This update improves how the website generator replaces content in HTML, avoiding unnecessary extra processing as replacement lists grow. This should make generated website pages faster and more reliable without changing the user-facing workflow.
Original PR description
Fixed issue where regex where larger than required due to growing dictionnary of replacements. Improved global replacements by creating the patern early and sharing it accross all replacement.
This update keeps several Odoo Enterprise areas working reliably with newer platform versions, including Python 3.13 and Debian Trixie. It mainly adjusts automated checks to handle updated date, PDF, and formatting behavior so future upgrades are less likely to be blocked by false failures.
Original PR description
Forward-Port-Of: odoo/enterprise#91053 Forward-Port-Of: odoo/enterprise#90352
The Dutch tax reporting flow now correctly handles returns that have more than one closing entry. Users will only see a warning when at least one related closing entry is still in draft, reducing incorrect warnings and helping submissions proceed more reliably.
Original PR description
Before this commit: As multiple closing moves can exist for a return, the check for the state of the closing move was incorrect. It was assuming only one closing move exists, which could lead to issues if multiple closing moves were present. After this commit: The code now checks if any of the closing moves are in 'draft' state before raising a warning. opw-4976827 Forward-Port-Of: odoo/enterprise#91223
Fixes an error that could occur when printing a Follow-up Letter from a partner's action menu. Users can now generate overdue payment follow-up letters reliably, even when the report is launched through this alternate menu path.
Original PR description
### Steps to reproduce: - Settings > Technical > Reporting > Reports - Search for "Print Follow-up Letter" - Click on "Add to the Print menu" - Create an overdue invoice for a partner - On the partner page, click the gear to show the actions - Then click "Print Follow-up Letter" - Traceback ### Cause: This [line](https://github.com/odoo/enterprise/blob/82375d181cd138b497e695e747b63c009c0538fc/account_followup/models/res_partner.py#L291) tries to read `options['followup_line']` but with this flow `followup_line` is not in the options. ### Solution: Use `get` and fallback on the followup line on the partner. opw-4864880 Forward-Port-Of: odoo/enterprise#88543
Fixed an issue where scheduled Sign reminders could crash if a signing request had no “Valid Until” date. This keeps reminder emails running reliably for documents that are intentionally left without an expiration date.
Original PR description
When a `sign.request` record has `validity` as `False`, attempting to send a reminder via the `_cron_reminder` method leads to a crash. **Steps to Reproduce:-** 1. Install the `Sign` module. 2.…
When a `sign.request` record has `validity` as `False`, attempting to send a reminder via the `_cron_reminder` method leads to a crash.
**Steps to Reproduce:-**
1. Install the `Sign` module.
2. Navigate to the Sign section and click on `Upload PDF & Sign`
3. Upload any PDF document and add your signature, then click `Send`
4. In the new wizard, remove the value for `Valid Until` and enable the `reminder` option. Set the reminder to `every 1 day.`
5. When our scheduled action named `Sign: Send Mail Reminder` executes the following day, it will throw an error.
**Error:-**
`TypeError(''<' not supported between instances of 'bool' and 'datetime.date'') while evaluating 'model._cron_reminder()''`
**Root Cause:-**
The SQL query within the `_cron_reminder()` method retrieves all records where:
- The request is `active` and in the `sent` state.
- Either:
- `validity < today` or
- A reminder is due based on `last_reminder + reminder`.
The fetched records are then iterated through at [1].
[1]
https://github.com/odoo/enterprise/blob/ac4aeeea98dcf2fc7f06e6a3fabc55e256330e2c/sign/models/sign_request.py#L454
If `validity` is `False`, this comparison raises a `TypeError` because it is invalid to compare a `boolean` with `datetime.date`.
**Solution:-**
- A safety check was added before the comparison between `request.validity` and today's date, ensuring that `request.validity` exists.
Sentry-6727599497
Forward-Port-Of: odoo/enterprise#89646This fixes how quarterly GST return periods are labeled for India after a prior logic change. The period now uses the correct ending month, helping reports show the right return period and reducing filing confusion.
Original PR description
In this commit: https://github.com/odoo/enterprise/commit/75b72df06a109b5e89a2c8e98bc29a1fe120fb68, the quarters key was updated. Previously, it used the start month of the quarter, but it now uses the end month instead. However, the `return_period_month_year` field is still being computed based on the start month. With this PR, the `return_period_month_year` will now be computed correctly based on the updated logic. **opw**-4970000 Forward-Port-Of: odoo/enterprise#91109
The Starshipit shipping cost banner will no longer appear on deliveries using other delivery methods. This prevents confusing messages for staff and keeps delivery screens focused on the selected carrier.
Original PR description
A Strashipit banner was appearing on all deliveries, un-depending on the Delivery Method. Steps to reproduce: * Install 'delivery_starshipit' * Create a delivery with another Delivery Method selected, and a Carrier Price of 0. * The Starshipit banner "The Shipping Cost is being fetched in the background" appears Fix: Filter out 'invisible' condition on non-Starshipit delivery methods opw-4940717 Forward-Port-Of: odoo/enterprise#90994