Daily updates from Odoo
Friday, March 29, 2024
24 changes · master
Enhancements to existing features
The IoT system now checks whether its live connection is actually needed before activating it on an IoT box. This reduces unnecessary background activity and can help improve reliability and resource usage without changing day-to-day user workflows.
Original PR description
Previously, the WebSocket connection remained active even when not in use. Now, the system checks WebSocket usage before sending the iot_channel to the iot box. If the WebSocket is unused, False will be sent. task:3761864 community: 158775
This update adds automated checks for task scheduling from the task Gantt view. It helps ensure users can continue planning tasks based on selected timeframes without regressions in future changes.
Original PR description
In task 3644342, a feature was added to allow users to plan their tasks according to the timeframe they selected in the gantt view of tasks. This PR will add some tests to ensure that this feature is never broken. task-3800455
The project map view now shows a helpful message when there are no tasks to display. This gives users clearer guidance instead of leaving the map area empty, improving usability in project navigation.
Original PR description
- master ### Project map view improvement - Added a helper message when there is no task available in the map view. task-3734820
The Field Service Report module’s automated tests were updated to stay aligned with related platform changes. This helps maintain reliability and reduces the risk of regressions without changing day-to-day user workflows.
Original PR description
This commit is a follow-up of its community part. It aims to update the tests to fit the changes made. task - 3741976 community pr: https://github.com/odoo/odoo/pull/156086
The Field Service report menu for planning by worksheet template now shows its views in the same order as other planning menus. This makes navigation more predictable and reduces confusion for users moving between planning screens.
Original PR description
…plate menu Before this PR: - The views in the 'planning by worksheet template' menu are not in the same order as the other 'planning' menus from field service, which is inconsistent. After this PR: - The views in the 'planning by worksheet template' menu are the same order as the other 'planning' menus from field service, which is consistent now task-3770938
Resolved issues and error corrections
The Swiss payroll setup now points to the correct employee view after a duplicate payroll section was removed. This prevents related payroll information from being placed incorrectly and helps keep employee payroll screens consistent.
Original PR description
Before this commit, and the commit introduced in odoo/odoo#158508, two group named "payroll_group" were present on the employee view. The group introduced in hr has been removed and the one in payroll kept. This commit changes the xml_id used as inheritance in l10n_ch_hr_payroll to inherit the view defined in payroll rather than the view from hr_contract to allow inserting some content after the group mentionned above.
The field service task signing pop-up now appears above the page header as intended. This prevents confusion for workers signing worksheets from the customer portal and removes a visual overlay gap at the top of the page.
Original PR description
Steps: Install industry_fsm, worksheet and website. Create a task, set Joel Willis as assignee and add a worksheet. Log in as Joel Willis, got to that task and click sign. Issue: Z-wise, the modal isn't above the header. Cause: The modal is at the same level as the sign button, that is in the sidebar, which has `position: sticky;`. This fixes the `z-index` to the default value (even setting it manually has no impact). The fact that the modal's z-index is greater than the header's doesn't matter, as its container limits it. Solution: Put the modal div in the main content, which will never be sticky. Also, `mt-5 pt-5` were creating a "non grayed" stripe in the upper part of the page (where the header is at), so we delete it. task-3644729
Website form submissions to existing helpdesk tickets no longer add confusing HTML tags or irrelevant text in the ticket chatter. This keeps ticket history clearer for support teams reviewing customer requests.
Original PR description
**Steps:** - Open website and go to contact us - Using web editor option click on existing form and change its action - In create task action > select an existing ticket - Fill and submit the form - Open Ticket and go to the ticket given in create task action - Open the ticket created from the website - Have a glance at the chatter **Issue:** - Chatter is showing irrelevant information. (namely html tags) **Cause:** - Regrettably, due to last-minute changes preceding the merge, the review process for PR(https://github.com/odoo/enterprise/pull/47278) was unintentionally skipped. As a result, certain modifications were pushed that do not align with the expected standards. **Fix:** - Taking corrective action by adding proper if condition and assigning values correctly which will resolve this issue promptly. **Task**-3674768
This fix prevents a system error in Mexican electronic invoicing for Point of Sale orders by checking whether invoice information is available before using it. It helps keep automated validation and related POS invoicing flows stable without changing user-facing behavior.
Original PR description
### Commit 1: Fix the runbot issue number 60914 by verifying that the field to_invoice exists in the pos.order dict before trying to access it. Runbot error ID: 60914
Miscellaneous changes
Before this fix, errors occurred in certain sections of the sales subscription dashboard when attempting to load it without demo data. This PR resolves the problem by incorporating IFERROR into the formulas to leave them empty in case of errors. Task ID: 3754211 Forward-Port-Of: odoo/enterprise#59510
Original PR description
Before this fix, errors occurred in certain sections of the sales subscription dashboard when attempting to load it without demo data. This PR resolves the problem by incorporating IFERROR into the formulas to leave them empty in case of errors. Task ID: 3754211 Forward-Port-Of: odoo/enterprise#59510
There were a few issues with the new version 3.0 of the Delivery Guide (Carta Porte): - TipoMateria should only be visible when it's an external trade. - NumRegIdTrib should only be visible when the customer's country is not MX. - Visibility of customs related fields (that were added in version 3.0) should not depend on the state of the picking. task-3755473 Forward-Port-Of: odoo/enterprise#59442 Forward-Port-Of: odoo/enterprise#57822
Original PR description
There were a few issues with the new version 3.0 of the Delivery Guide (Carta Porte): - TipoMateria should only be visible when it's an external trade. - NumRegIdTrib should only be visible when the customer's country is not MX. - Visibility of customs related fields (that were added in version 3.0) should not depend on the state of the picking. task-3755473 Forward-Port-Of: odoo/enterprise#59442 Forward-Port-Of: odoo/enterprise#57822
Prevents the user to reset to draft a tax closing entry if subsequent closing entries are already posted. This way, the user is forced to reset to draft progressively back in time the closing entries. Accounting wise, this case should not happen. It is by the way prevented by the irreversible_lock_date module (which can be however uninstalled). This mechanism solves an issue with carryovers that need to be progressively recomputed when resetting to draft a closing entry. Another issue has als
Original PR description
Prevents the user to reset to draft a tax closing entry if subsequent closing entries are already posted. This way, the user is forced to reset to draft progressively back in time the closing entries. Accounting wise, this case should not happen. It is by the way prevented by the irreversible_lock_date module (which can be however uninstalled). This mechanism solves an issue with carryovers that need to be progressively recomputed when resetting to draft a closing entry. Another issue has also been fixed. The 'Closing Entry' button in the Tax Report has inconsistent behavior when the closing entry is already posted and then reset to draft. This issue was solved in 17 in this commit: https://github.com/odoo/enterprise/commit/49f664db942f3b7f5d343ac7a42608839b5595bf. It is backported in order to make the draft closing entry flow as smooth as possible. task-3520338 Forward-Port-Of: odoo/enterprise#59476 Forward-Port-Of: odoo/enterprise#52875
A lot of clients are blocked because they have a bad VAT number somewhere. If the compacting (remove spaces, dots, ...) gives an error, it will just not compact the number and put the original one. opw-3816072 Forward-Port-Of: odoo/enterprise#59319 Forward-Port-Of: odoo/enterprise#59282
Original PR description
A lot of clients are blocked because they have a bad VAT number somewhere. If the compacting (remove spaces, dots, ...) gives an error, it will just not compact the number and put the original one. opw-3816072 Forward-Port-Of: odoo/enterprise#59319 Forward-Port-Of: odoo/enterprise#59282
Community: https://github.com/odoo/odoo/pull/159529 Design Themes: https://github.com/odoo/design-themes/pull/794 Forward-Port-Of: odoo/enterprise#59568
Original PR description
Community: https://github.com/odoo/odoo/pull/159529 Design Themes: https://github.com/odoo/design-themes/pull/794 Forward-Port-Of: odoo/enterprise#59568
See also: - https://github.com/odoo/odoo/pull/159618 Forward-Port-Of: odoo/enterprise#59607
Original PR description
See also: - https://github.com/odoo/odoo/pull/159618 Forward-Port-Of: odoo/enterprise#59607
This tour was failing undeterministically because the values set in the dialog were not saved to the database. A naive fix was quickly merged in 2be6e64ef23717ab36dbba87723db666a1757eee: we kept the default values in the dialog (so it was no longer failing even if the values weren't saved). This actually occurs because we call `action_pos_order_invoice` before saving the values of the dialog to the server. Adding an `await` fixes this. Hence we can set a random (different from the default
Original PR description
This tour was failing undeterministically because the values set in the dialog were not saved to the database. A naive fix was quickly merged in 2be6e64ef23717ab36dbba87723db666a1757eee: we kept the default values in the dialog (so it was no longer failing even if the values weren't saved). This actually occurs because we call `action_pos_order_invoice` before saving the values of the dialog to the server. Adding an `await` fixes this. Hence we can set a random (different from the default) `l10n_mx_edi_usage` and `l10n_mx_edi_cfdi_to_public`. runbot build error 60671 Forward-Port-Of: odoo/enterprise#59354
### Context In Colombia, a withholding tax is applied to the VAT, calculated as a percentage of the VAT amount. A typical scenario involves a VAT at 19% and a withholding tax at 15% of the VAT's 19%. The existing system constraints prevent directly using the value of one tax as the base for another, leading to a workaround by setting it to -2.85 (representing 15% of 19%). ### Problem The electronic invoice requirements mandate the submission of base amounts and taxed values for each tax
Original PR description
### Context In Colombia, a withholding tax is applied to the VAT, calculated as a percentage of the VAT amount. A typical scenario involves a VAT at 19% and a withholding tax at 15% of the VAT's 19%.…
### Context In Colombia, a withholding tax is applied to the VAT, calculated as a percentage of the VAT amount. A typical scenario involves a VAT at 19% and a withholding tax at 15% of the VAT's 19%. The existing system constraints prevent directly using the value of one tax as the base for another, leading to a workaround by setting it to -2.85 (representing 15% of 19%). ### Problem The electronic invoice requirements mandate the submission of base amounts and taxed values for each tax and invoice line. Due to our system's limitation in directly calculating the base for the withholding tax, our approach has been to reverse calculate the base using the tax amount divided by its rate. This method introduces inaccuracies because the tax amount is rounded, and those inaccuracies can in turn result in the electronic document being rejected. ### Solution There's currently no way to properly fix this, so we have to rely on some dodgy programming. This commit changes the calculation method to focus on directly determining and computing the VAT amount subject to withholding. opw-3744872 Forward-Port-Of: odoo/enterprise#59221 Forward-Port-Of: odoo/enterprise#58377
STEP TO REPRODUCE: ================== * Go on Appraisal application * Select an appraisal * Click on "ask feedback" button * Add in recipients field an employee without user linked to him task: 3818033 Forward-Port-Of: odoo/enterprise#59464 Forward-Port-Of: odoo/enterprise#59125
Original PR description
STEP TO REPRODUCE:
==================
* Go on Appraisal application
* Select an appraisal
* Click on "ask feedback" button
* Add in recipients field an employee without user linked to him
task: 3818033
Forward-Port-Of: odoo/enterprise#59464
Forward-Port-Of: odoo/enterprise#59125During this commit: https://github.com/odoo/enterprise/commit/02252c3af7637835e34d0c19a609e1aa05b5a653#diff-fcb2837955e2fcf5fb3885f86c0f12f8facd7cd24d73e1f151957c33db381f9e A duplicate variable was introduced. This commit will remove that. no task-id Forward-Port-Of: odoo/enterprise#59432
Original PR description
During this commit: https://github.com/odoo/enterprise/commit/02252c3af7637835e34d0c19a609e1aa05b5a653#diff-fcb2837955e2fcf5fb3885f86c0f12f8facd7cd24d73e1f151957c33db381f9e A duplicate variable was introduced. This commit will remove that. no task-id Forward-Port-Of: odoo/enterprise#59432
Wrong conflict resolution when forward porting odoo/enterprise@7ff6e2b04110d1e3c046388927409ec46d39800e Task-3778173 Forward-Port-Of: odoo/enterprise#59420
Original PR description
Wrong conflict resolution when forward porting odoo/enterprise@7ff6e2b04110d1e3c046388927409ec46d39800e Task-3778173 Forward-Port-Of: odoo/enterprise#59420
Issue: ------ It is possible to change the recurrence of a product if it has already been sold (correct behaviour). The customer receives a warning, but the `recurring_invoice` field is still set to `True`, whereas it may have been set to `False` before the operation. Solution: --------- Prevent the `recurring_invoice` field from being changed if a confirmed sale order line contains this product, to avoid confusion. opw-3457160 Forward-Port-Of: odoo/enterprise#59367
Original PR description
Issue: ------ It is possible to change the recurrence of a product if it has already been sold (correct behaviour). The customer receives a warning, but the `recurring_invoice` field is still set to `True`, whereas it may have been set to `False` before the operation. Solution: --------- Prevent the `recurring_invoice` field from being changed if a confirmed sale order line contains this product, to avoid confusion. opw-3457160 Forward-Port-Of: odoo/enterprise#59367
https://www2.partena-professional.be/LegalPortal/servlet/servlet.FileDownload?file=00P3X00002H45q2UAB Forward-Port-Of: odoo/enterprise#59418
Original PR description
https://www2.partena-professional.be/LegalPortal/servlet/servlet.FileDownload?file=00P3X00002H45q2UAB Forward-Port-Of: odoo/enterprise#59418
When we use the `|` (or) version of this rule the ORM generates two sub-queries when checking the company. This causes sub-optimal and in some cases really bad planning for the queries and thus PG takes hours to complete them. Example (formatted): ```sql SELECT "mrp_routing_workcenter".id FROM "mrp_routing_workcenter" LEFT JOIN "mrp_bom" AS "mrp_routing_workcenter__bom_id" ON "mrp_routing_workcenter"."bom_id" = "mrp_routing_workcenter__bom_id"."id" WHERE "mrp_rou
Original PR description
When we use the `|` (or) version of this rule the ORM generates two sub-queries when checking the company. This causes sub-optimal and in some cases really bad planning for the queries and thus PG…
When we use the `|` (or) version of this rule the ORM generates two sub-queries when checking the company. This causes sub-optimal and in some cases really bad planning for the queries and thus PG takes hours to complete them.
Example (formatted):
```sql
SELECT "mrp_routing_workcenter".id
FROM "mrp_routing_workcenter"
LEFT JOIN "mrp_bom" AS "mrp_routing_workcenter__bom_id"
ON "mrp_routing_workcenter"."bom_id" = "mrp_routing_workcenter__bom_id"."id"
WHERE "mrp_routing_workcenter"."workcenter_id" in (1)
AND ( ("mrp_routing_workcenter"."bom_id" in (
SELECT "mrp_bom".id
FROM "mrp_bom"
WHERE ("mrp_bom"."company_id" in (1))
)
)
OR ("mrp_routing_workcenter"."bom_id" in (
SELECT "mrp_bom".id
FROM "mrp_bom"
WHERE "mrp_bom"."company_id" IS NULL
)
)
)
ORDER BY "mrp_routing_workcenter__bom_id"."sequence",
"mrp_routing_workcenter__bom_id"."id",
"mrp_routing_workcenter"."sequence",
"mrp_routing_workcenter"."id"
```
If we use the single term version the generated query has only one sub-query:
```sql
SELECT "mrp_routing_workcenter".id
FROM "mrp_routing_workcenter"
LEFT JOIN "mrp_bom" AS "mrp_routing_workcenter__bom_id"
ON "mrp_routing_workcenter"."bom_id" = "mrp_routing_workcenter__bom_id"."id"
WHERE "mrp_routing_workcenter"."workcenter_id" in (1)
AND ( ("mrp_routing_workcenter"."bom_id" in (
SELECT "mrp_bom".id
FROM "mrp_bom"
WHERE (("mrp_bom"."company_id" in (1))
OR ("mrp_bom"."company_id" IS NULL))
)
)
)
ORDER BY "mrp_routing_workcenter__bom_id"."sequence",
"mrp_routing_workcenter__bom_id"."id",
"mrp_routing_workcenter"."sequence",
"mrp_routing_workcenter"."id"
```
In this version PG is able to produce a better query plan resulting in better execution times.
Also, the `company_id` field is required on some models, so the "= False" comparison is useless.
Forward-Port-Of: odoo/enterprise#59406
Forward-Port-Of: odoo/enterprise#58756Bug === If the thumbnail update failed, an error is raised in the browser. This can happen if it was already updated by someone else. Forward-Port-Of: odoo/enterprise#59144
Original PR description
Bug === If the thumbnail update failed, an error is raised in the browser. This can happen if it was already updated by someone else. Forward-Port-Of: odoo/enterprise#59144