Thursday, November 28, 2024
122 changes
17 changes
Enhancements to existing features
Several Odoo apps were updated to follow the latest guidelines for scheduled background tasks. This helps make routine automated work more consistent and easier to maintain, with limited direct impact on day-to-day users.
This update adjusts scheduled accounting and localization tasks to follow Odoo’s new background job guidelines. It should make recurring processes such as bank synchronization, follow-ups, currency rates, and tax/reporting exports more consistent and easier to maintain, with limited direct impact on day-to-day users.
This update adjusts the appointment scheduling area to help automated checks run more reliably. It reduces the risk of unstable test results, supporting smoother maintenance without changing day-to-day business workflows.
The subscription expiration background process has been cleaned up to make it easier to maintain and more reliable. This reduces internal complexity around subscription lifecycle handling without introducing a major visible change for users.
Updates scheduled background tasks for Marketing Automation, Social, Push Notifications, and WhatsApp to follow the latest operational guidelines. This should help these automated processes run more consistently and predictably without changing day-to-day user workflows.
This update aligns scheduled background jobs for SEPA direct debit, Amazon sales, and eBay sales with the latest Odoo guidelines. It helps improve consistency and reliability of automated sales and payment processing tasks without changing day-to-day user workflows.
Original PR description
main PR: odoo/odoo#151628 task-id: 3687442
This update aligns subscription and document signing background jobs with newer scheduling guidelines. It should make recurring subscription and signing processes more consistent and easier to maintain, with limited direct impact on day-to-day users.
Original PR description
https://github.com/odoo/odoo/pull/151732
Resolved issues and error corrections
This fixes an issue where customers could run into problems when making an early payment on a subscription with a zero amount. It helps ensure the subscription payment flow works correctly even when no money is due.
Miscellaneous changes
Before this commit, if a pivot have an invalid model (renaming, deletion, ...), some tracebacks were raised (opening the side panel, ...) This commit fixes the issue by handling the case where the pivot model is invalid by showing a clear error in the cell (see community PR) and displaying an error in the side panel of the pivot (this commit) Task: 4280402 Forward-Port-Of: odoo/enterprise#72576
Original PR description
Before this commit, if a pivot have an invalid model (renaming, deletion, ...), some tracebacks were raised (opening the side panel, ...) This commit fixes the issue by handling the case where the pivot model is invalid by showing a clear error in the cell (see community PR) and displaying an error in the side panel of the pivot (this commit) Task: 4280402 Forward-Port-Of: odoo/enterprise#72576
5 changes
Resolved issues and error corrections
This update fixes a test failure related to how products are assigned to helpdesk tickets. The previous test was overly strict about the order of products, which could cause it to fail. The change simplifies the test by verifying the correct products are present, regardless of their order, ensuring consistent functionality.
Original PR description
Before this commit, the `/helpdesk_stock:TestHelpdeskStock.test_helpdesk_ticket_product_from_parent_company` test could fail if the records contained in `suitable_product_ids` of a ticket created, inside the test, are not in the same order than the list of ids expected. This commit replaces the following assert: `self.assertEqual(ticket.suitable_product_ids.ids, [company_product.id, employee_product.id], 'Employee should see SOs of parent company')` by ```py self.assertEqual(len(ticket.suitable_product_ids), 2, '2 products should be visible') self.assertIn(company_product, ticket.suitable_product_ids, 'Employee should see SOs of parent company') self.assertIn(employee_product, ticket.suitable_product_ids, 'Employee should see SOs of parent company') ``` by doing that the order will no longer fail the test since finally the order is not really important in that test case. runbot-106821 Forward-Port-Of: odoo/enterprise#74806
this commit prevent the auto installation of the french payroll because it's not up to date and currently maintained task-4283506 Forward-Port-Of: odoo/enterprise#72980
Original PR description
this commit prevent the auto installation of the french payroll because it's not up to date and currently maintained task-4283506 Forward-Port-Of: odoo/enterprise#72980
### Steps to reproduce: - Install "l10n_mx" and switch to a Mexican company - Create a vendor bill with this partner using the tax "Exento" - Go to Reports -> Tax report -> DIOT.txt ### Cause: For partners that only have lines with the tax "Exento", no information are retrieved for the report. The columns "Type of third", "type of operation", "VAT", etc. are empty in the Tax report before trying to download the DIOT report. When trying to generate the txt file, the code tries to access th
Original PR description
### Steps to reproduce: - Install "l10n_mx" and switch to a Mexican company - Create a vendor bill with this partner using the tax "Exento" - Go to Reports -> Tax report -> DIOT.txt ### Cause: For…
### Steps to reproduce: - Install "l10n_mx" and switch to a Mexican company - Create a vendor bill with this partner using the tax "Exento" - Go to Reports -> Tax report -> DIOT.txt ### Cause: For partners that only have lines with the tax "Exento", no information are retrieved for the report. The columns "Type of third", "type of operation", "VAT", etc. are empty in the Tax report before trying to download the DIOT report. When trying to generate the txt file, the code tries to access the value "third_party_code" in a dictionary but the key is not there so an error is raised. This occurs because the tax "Exento" is "on_invoice" so there are no cash basis entry created. But in the custom query to retrieve the information of the partners it is specified the journal_id must be part of the cash basis journals. So no lines with "on_invoice" taxes were selected. ### Solution: Remove the journal restriction. opw-4312155 Forward-Port-Of: odoo/enterprise#74585 Forward-Port-Of: odoo/enterprise#74105
Steps to reproduce ================== - Go to planning - Open studio - Change the default scale to Month (expanded) - Close studio - Switch to Schedule > By Role => Cannot destructure property 'defaultRange' of 'metaData.scales[scaleId]' Cause of the issue ================== The planning view has the scales attribute as `scales="day,week,month,year"`. month_3 is not part of the allowed scales. opw-4175183 Forward-Port-Of: odoo/enterprise#74407
Original PR description
Steps to reproduce ================== - Go to planning - Open studio - Change the default scale to Month (expanded) - Close studio - Switch to Schedule > By Role => Cannot destructure property 'defaultRange' of 'metaData.scales[scaleId]' Cause of the issue ================== The planning view has the scales attribute as `scales="day,week,month,year"`. month_3 is not part of the allowed scales. opw-4175183 Forward-Port-Of: odoo/enterprise#74407
Purpose ======= Fix the calendar slots selection display when sharing appointment availabilities. Specification ============= The working hours have recently been added to the user's calendar. To highlight those, the non-business hours cells are grayed out (from 9am to 5pm). Following this change, it is now difficult to differentiate the non-business hours cells from the "Share Availabilities" gray overlay set on all the past cells. Fixing that by darkening a bit the color of the past
Original PR description
Purpose ======= Fix the calendar slots selection display when sharing appointment availabilities. Specification ============= The working hours have recently been added to the user's calendar. To highlight those, the non-business hours cells are grayed out (from 9am to 5pm). Following this change, it is now difficult to differentiate the non-business hours cells from the "Share Availabilities" gray overlay set on all the past cells. Fixing that by darkening a bit the color of the past cells when sharing availabilities. Additionally, for today, a div with a computed height was added to gray out cells before the current time. This div is now pushing the non-business hours divs which makes them overflow the day display. Fixing that by changing today's past hours div to position absolute. related commit: odoo/odoo@09ddd9f46c0d7528cb0138af283f6ec4f388a445 Task-4337795 Forward-Port-Of: odoo/enterprise#74349
This PR fixes some minor color scheme issue within Documents. Prior to this PR, some elements where using raw values instead of BS one, which led to some dark mode issues (e.g hardcoding the border-color hex will not adapt it if we are in dark mode). Same thing goes for some color mix that were using `$o-white` thus pure black in dark mode, while it should have used `$o-view-background-color` which is already dark mode proof. Since we were tweaking some values here and there, this com
Original PR description
This PR fixes some minor color scheme issue within Documents. Prior to this PR, some elements where using raw values instead of BS one, which led to some dark mode issues (e.g hardcoding the…
This PR fixes some minor color scheme issue within Documents. Prior to this PR, some elements where using raw values instead of BS one, which led to some dark mode issues (e.g hardcoding the border-color hex will not adapt it if we are in dark mode). Same thing goes for some color mix that were using `$o-white` thus pure black in dark mode, while it should have used `$o-view-background-color` which is already dark mode proof. Since we were tweaking some values here and there, this commit adapts some part of the code by rationalizing the value, either by using BS variables, CSS one to ease the maintainability of the code as well as avoiding `!important` statements. | 18.0 | This PR | |--------|--------| | <img width="310" alt="image" src="https://github.com/user-attachments/assets/16bcf240-84aa-4788-8527-7103a80deb40"> | <img width="308" alt="image" src="https://github.com/user-attachments/assets/476b6fd3-ab4d-4b1e-bf51-1ef50151f333"> | |  |  | task-4357165 Forward-Port-Of: odoo/enterprise#74464
When the customer clicks on the validate button in delivery with Sendcloud carrier, a traceback will appear. Steps to reproduce the error: - Enable Sendcloud Connecter - Go to Inventory > Configuration > Delivery Methods > Create new Method > Provider: SendCloud > Max Weight: 2 kg - Create a new product A > Type: Goods > Weight: 10 kg - Create a new Delivery > add Product A > Carrier: SendCloud > Validate Traceback: ``` File "home/odoo/src/enterprise/18.0/delivery_sendcloud/mode
Original PR description
When the customer clicks on the validate button in delivery with Sendcloud carrier,
a traceback will appear.
Steps to reproduce the error:
- Enable Sendcloud Connecter
- Go to Inventory > Configuration > Delivery Methods > Create new Method >
Provider: SendCloud > Max Weight: 2 kg
- Create a new product A > Type: Goods > Weight: 10 kg
- Create a new Delivery > add Product A > Carrier: SendCloud > Validate
Traceback:
```
File "home/odoo/src/enterprise/18.0/delivery_sendcloud/models/sendcloud_service.py", line 389, in _prepare_parcel
product_moves = format_list(self.env, overweight_products.mapped('name'))
AttributeError: 'SendCloud' object has no attribute 'env'
```
https://github.com/odoo/enterprise/blob/5dd7022e079bbb45492356a66a60c98a249cec8a/delivery_sendcloud/models/sendcloud_service.py#L389
Here, ``self`` is used instead of ``picking``,
So, It will lead to the above traceback.
sentry-6086972478
Forward-Port-Of: odoo/enterprise#74474Backport of https://github.com/odoo/enterprise/pull/69565 Forward-Port-Of: odoo/enterprise#73994
Original PR description
Backport of https://github.com/odoo/enterprise/pull/69565 Forward-Port-Of: odoo/enterprise#73994
Oversight of odoo/enterprise#73209. Service invoices don't use the reason field at all (hidden in view) and thus will always fail the constraint. To fix it, disable the constraint for service invoices. opw-4354637 Forward-Port-Of: odoo/enterprise#74619 Forward-Port-Of: odoo/enterprise#74552
Original PR description
Oversight of odoo/enterprise#73209. Service invoices don't use the reason field at all (hidden in view) and thus will always fail the constraint. To fix it, disable the constraint for service invoices. opw-4354637 Forward-Port-Of: odoo/enterprise#74619 Forward-Port-Of: odoo/enterprise#74552
This update resolves a visual issue where the search bar dropdown menu in the Shop Floor view would extend beyond the screen's edge on smaller devices. The fix ensures the dropdown remains within the designated viewport, improving usability across different screen sizes. This enhancement maintains a consistent and professional user experience.
Original PR description
Steps to reproduce ================== - Use a small viewport - Open the Shop Floor - Click on the dropdown toggle next to the search bar => The dropdown goes outside the viewport Cause of the issue ================== In the shopfloor, the search view has a max width of 65%. Solution ======== We can set the max-width of the search bar menu as the minimum between the initial value and 65% opw-4232114
This update corrects a bug in the Romanian financial reports that was displaying incorrect date ranges for the start of year column. Specifically, it resolved an issue where the start date was calculated incorrectly, leading to inaccurate comparisons. This ensures the reports accurately reflect financial data.
Original PR description
- When doing comparisons on the report the start of year column header would display an impossible date range ex. 'Jan 2024 - Dec 2023'. - When the date range would start at exactly 1 Jan YEAR, the date would be calculated incorrectly to 1 Jan YEAR-1.
This update corrects a validation issue in the l10n_mx_edi module, ensuring the CFDI origin field is correctly populated. This prevents errors related to incorrect origin codes and guarantees accurate CFDI data validation, improving compliance and data integrity.
Original PR description
Fix validation to ensure the CFDI origin field is assigned properly. Prevents cases like `04|`, ensuring the UUID is correctly validated.
Before:
`{'tipo_relacion': '04', 'cfdi_relationado_list': ['']}`
After:
`{'tipo_relacion': '04', 'cfdi_relationado_list': []}`This update corrects a technical issue that prevented users from properly extending a key method within the fleet expense tracking module. Previously, attempts to modify this method resulted in missing data. This fix ensures that users can now correctly customize and extend this functionality, improving flexibility and adaptability.
Original PR description
When trying to extend `_get_deferred_lines_values` method, you don't received argument "line"