Friday, March 1, 2024
70 changes
Resolved issues and error corrections
This fixes a small issue that caused unnecessary warning messages in server logs when field service worksheet templates were looked up. The change helps keep logs cleaner and avoids misleading operational noise without changing user-facing behavior.
Original PR description
Before this commit, a warning is logged in the server logs because `=` operator is used with an array as right leaf in a domain used in a search in `_compute_worksheet_template_id` defined in `project.project` model. The operator used should be `in` instead of `=`, that's why we got that warning. This commit fixes the issue by changing the operator used inside that domain to use `in` instead of `=`. runbot-58374 X-original-commit: 2b12d5e8
Code cleanup and technical improvements
Miscellaneous changes
## Description Deleting planning slots can be slow on some databases that make heavy usage of the Timesheet/WorkEntries from shifts feature and/or they have large tables for their `account.analytic.line` and/or `hr.work. entry`. It can be especially felt when deleting all recurrences of a shifts. This is due to the missing indexes on the FKey to the `planning.slot` model on large models. Without an index on the FKey, deleting a `planning.slot` will trigger Seq.Scans on the tables that referenc
Original PR description
## Description Deleting planning slots can be slow on some databases that make heavy usage of the Timesheet/WorkEntries from shifts feature and/or they have large tables for their `account.analytic.line` and/or `hr.work. entry`. It can be especially felt when deleting all recurrences of a shifts. This is due to the missing indexes on the FKey to the `planning.slot` model on large models. Without an index on the FKey, deleting a `planning.slot` will trigger Seq.Scans on the tables that references the `planning.slot` model to set the field to NULL or trigger the SQL `ON DELETE` constrains. ## Fix Add the missing indexes. Partial on nulls because it's a sparse relationship. ## Reference task-3747131 Forward-Port-Of: odoo/enterprise#56681
This update changes how automated guided tour tests identify page elements, moving from an older method to a newer internal testing approach. It helps keep quality checks reliable across many business apps without changing the day-to-day user experience.
Original PR description
Before this commit, triggers (extra_triggers, alt_triggers and skip_triggers) defined in steps of tours were found in the DOM with $() jQuery function. In this commit, these steps are now found with Hoot queryAll() function. Triggers of steps have so been adapted to satisfy this adaptation. task~3600484 https://github.com/odoo/odoo/pull/155605
Steps to reproduce: 1. set up a shipping method with UPS rest module 2. enable "generate return label" on the shipping method 3. make a shipping and validate it A return label will be generated that has the customer's address as the receiver and the seller's address as the sender. This is conceptually wrong as the return label will be used to ship from the customer to the seller. This commit uses the correct addresses when generating labels. Also the name of the arguments are added whe
Original PR description
Steps to reproduce: 1. set up a shipping method with UPS rest module 2. enable "generate return label" on the shipping method 3. make a shipping and validate it A return label will be generated that has the customer's address as the receiver and the seller's address as the sender. This is conceptually wrong as the return label will be used to ship from the customer to the seller. This commit uses the correct addresses when generating labels. Also the name of the arguments are added when calling `_send_shipping` method for better readability. opw-3756731 Forward-Port-Of: odoo/enterprise#57477 Forward-Port-Of: odoo/enterprise#57037
The annual changes to the intrastat code lists have occured. In order to synchronise with these new standards, we have to add the new codes, and remove the old ones. This commit adds the new codes in into the relevant csv. We also add expiry dates for the removed codes, and start dates for the new codes. In forward ports, these should be added directly on the account.intrastat.code.csv (since the modules account_intrastat and account_intrastat_expiry were merged after v15.0) One of the cod
Original PR description
The annual changes to the intrastat code lists have occured. In order to synchronise with these new standards, we have to add the new codes, and remove the old ones. This commit adds the new codes in into the relevant csv. We also add expiry dates for the removed codes, and start dates for the new codes. In forward ports, these should be added directly on the account.intrastat.code.csv (since the modules account_intrastat and account_intrastat_expiry were merged after v15.0) One of the codes (50072060) has a supplementary unit, so we add that to the relevant dictionary, though in the forward ports this will be added directly in the data. task-id: 3747808 Forward-Port-Of: odoo/enterprise#57633 Forward-Port-Of: odoo/enterprise#57124
This commit ensures that non-UK companies using a UK fiscal position are correctly handled, using the foreign VAT when connecting and sending reports to the HMRC. Additionally, the need to input the VAT without the 'GB' prefix has been eliminated by automatically stripping the prefix before sending. task-3765235 Forward-Port-Of: odoo/enterprise#57570
Original PR description
This commit ensures that non-UK companies using a UK fiscal position are correctly handled, using the foreign VAT when connecting and sending reports to the HMRC. Additionally, the need to input the VAT without the 'GB' prefix has been eliminated by automatically stripping the prefix before sending. task-3765235 Forward-Port-Of: odoo/enterprise#57570
**Current behavior:** Selecting the pre-loaded 'My Team' filter from the search bar in the Timesheets view grid will list, in addition to employees managed by the current user, employees who have no assigned manager nor time sheet approver. **Expected behavior:** This filter will list exclusively employees who the current user is either the manager of or is the time sheet approver of. **Steps to reproduce:** 1. In the Timesheets application, select the My Team filter **Cause of the i
Original PR description
**Current behavior:** Selecting the pre-loaded 'My Team' filter from the search bar in the Timesheets view grid will list, in addition to employees managed by the current user, employees who have no assigned manager nor time sheet approver. **Expected behavior:** This filter will list exclusively employees who the current user is either the manager of or is the time sheet approver of. **Steps to reproduce:** 1. In the Timesheets application, select the My Team filter **Cause of the issue:** The filter's domain includes these aforementioned un-managed employees. **Fix:** Remove that part of the domain. This commit is a partial revision to one of the changes made by https://github.com/odoo/enterprise/commit/60dc8c38519b75b5383a54e923135d557e3737e0 (see log chatter on Odoo for associated ticket for justification) opw-3708825 Forward-Port-Of: odoo/enterprise#57049
Add the Bank Negara Malaysia as a live exchange rate service for malaysia. This is common practice in the country to get exchange rates from it. Task id # 3724397 Forward-Port-Of: odoo/enterprise#57694 Forward-Port-Of: odoo/enterprise#56030
Original PR description
Add the Bank Negara Malaysia as a live exchange rate service for malaysia. This is common practice in the country to get exchange rates from it. Task id # 3724397 Forward-Port-Of: odoo/enterprise#57694 Forward-Port-Of: odoo/enterprise#56030
### [I18N] l10n_fr_reports: add tax rounding terms A few of translations relating to 03ce6ce were not included with the original commit. This commit adds the terms to the l10n_fr_reports.pot file, and the translations to the fr.po file. Thank you Antoine (andu) for the Frenchification of the terms. task-id: 3717388 ### [I18N] l10n_fr_reports: restructure po/pot files Add the missing terms to the pot file. When the terms are missing from the pot file, but present in the po file,
Original PR description
### [I18N] l10n_fr_reports: add tax rounding terms A few of translations relating to 03ce6ce were not included with the original commit. This commit adds the terms to the l10n_fr_reports.pot file, and the translations to the fr.po file. Thank you Antoine (andu) for the Frenchification of the terms. task-id: 3717388 ### [I18N] l10n_fr_reports: restructure po/pot files Add the missing terms to the pot file. When the terms are missing from the pot file, but present in the po file, they get marked as "obsolete". This happens during the merge function that is called within tools/translate.py. In order to avoid this, the pot and po files have been re-generated and restructured in order to make future additions easier to merge. Forward-Port-Of: odoo/enterprise#57718 Forward-Port-Of: odoo/enterprise#56590
Steps to reproduce: ------------------- - go to Sales; - click on a sale order with tickets assigned to it; - click on the "Tickets" smart button; - group by stage. Issue: ------ A traceback appears. Cause: ------ The query formed is incorrect. We are using a Query object in the domain instead of the team id. Which has been placed in context beforehand. Solution: --------- Place the team id in the context. Note: ----- This will automatically be converted to a list if ne
Original PR description
Steps to reproduce: ------------------- - go to Sales; - click on a sale order with tickets assigned to it; - click on the "Tickets" smart button; - group by stage. Issue: ------ A traceback appears. Cause: ------ The query formed is incorrect. We are using a Query object in the domain instead of the team id. Which has been placed in context beforehand. Solution: --------- Place the team id in the context. Note: ----- This will automatically be converted to a list if necessary when generating the query with a domain using the `IN` operator (relation). opw-3759882 Forward-Port-Of: odoo/enterprise#57798 Forward-Port-Of: odoo/enterprise#57502
Make sure to use the resource calendar of the employee. Indeed, it is possible that the resource calendar set on the user is different than the one on the employee. Which can leads to a traceback if the resource calendar was not in the unavailabilities_by_calendar. As we base previous computation on employee, we also use the employee here. task-3698586 Forward-Port-Of: odoo/enterprise#57712
Original PR description
Make sure to use the resource calendar of the employee. Indeed, it is possible that the resource calendar set on the user is different than the one on the employee. Which can leads to a traceback if the resource calendar was not in the unavailabilities_by_calendar. As we base previous computation on employee, we also use the employee here. task-3698586 Forward-Port-Of: odoo/enterprise#57712
Due to a change in the base UBL template, the `<PriceAmount>` is no longer rounded to the number of decimals of the product price. Since the SUNAT only accepts numbers with a maximum of 10 decimals, we round the computed product price for Peru specifically to 10 decimals. [Issue reported by Fernando Vazquez (fvz)](https://www.odoo.com/web#id=3415758&cids=1&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#57578
Original PR description
Due to a change in the base UBL template, the `<PriceAmount>` is no longer rounded to the number of decimals of the product price. Since the SUNAT only accepts numbers with a maximum of 10 decimals, we round the computed product price for Peru specifically to 10 decimals. [Issue reported by Fernando Vazquez (fvz)](https://www.odoo.com/web#id=3415758&cids=1&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#57578
If you create an upsell for a subscription, when the upsell is confirmed the non-recurring products are copied into the parent subscription which trigger the creation of 2 delivery orders (one on upsell, one on parent sub) and also as there are 2 SOL in the report the product is considered sold twice. This commit fixes this by not creating lines for non recurring products in _subscription_update_line_data. task-3689908 Forward-Port-Of: odoo/enterprise#55613
Original PR description
If you create an upsell for a subscription, when the upsell is confirmed the non-recurring products are copied into the parent subscription which trigger the creation of 2 delivery orders (one on upsell, one on parent sub) and also as there are 2 SOL in the report the product is considered sold twice. This commit fixes this by not creating lines for non recurring products in _subscription_update_line_data. task-3689908 Forward-Port-Of: odoo/enterprise#55613
In some countries the journal report is used as a section of the tax report to provide details about the computed tax amounts. One such detail is the split between the deductible and non-deductible part of the tax computed. In order to provide these details, we add two new columns to the tax overview in the journal report that indicate the amounts of the tax that are deductible or non-deductible. [task-3696656](https://www.odoo.com/web#id=3696656&cids=1&menu_id=4720&action=333&active_id
Original PR description
In some countries the journal report is used as a section of the tax report to provide details about the computed tax amounts. One such detail is the split between the deductible and non-deductible part of the tax computed. In order to provide these details, we add two new columns to the tax overview in the journal report that indicate the amounts of the tax that are deductible or non-deductible. [task-3696656](https://www.odoo.com/web#id=3696656&cids=1&menu_id=4720&action=333&active_id=967&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#57657 Forward-Port-Of: odoo/enterprise#55010
Fix test after Community change, 1xxx accounts should have been debit tag, thus Natur='D'. Community: https://github.com/odoo/odoo/pull/119485 Forward-Port-Of: odoo/enterprise#57666 Forward-Port-Of: odoo/enterprise#57531
Original PR description
Fix test after Community change, 1xxx accounts should have been debit tag, thus Natur='D'. Community: https://github.com/odoo/odoo/pull/119485 Forward-Port-Of: odoo/enterprise#57666 Forward-Port-Of: odoo/enterprise#57531
**Before:** In the modified code, parts of the PivotController have been moved to PivotRenderer. However, the 'button template' is not extended in the pivot view, leading to issues rendering the validate button. **After:** By extending the correct class (PivotRenderer instead of PivotController) in the `TimesheetValidationPivotController`, we now have access to methods that were previously unavailable. Additionally, extending the `buttonTemplate` allows us to access the validate button, res
Original PR description
**Before:** In the modified code, parts of the PivotController have been moved to PivotRenderer. However, the 'button template' is not extended in the pivot view, leading to issues rendering the validate button. **After:** By extending the correct class (PivotRenderer instead of PivotController) in the `TimesheetValidationPivotController`, we now have access to methods that were previously unavailable. Additionally, extending the `buttonTemplate` allows us to access the validate button, resolving the rendering issue. This modification ensures that the TimesheetValidationPivotController now extends PivotRenderer, allowing it to access the necessary methods and resolve the rendering issue for the validate button. **Task**-3623493 Forward-Port-Of: odoo/enterprise#57656 Forward-Port-Of: odoo/enterprise#53165
Starshipit is the leading provider of integrated and automated fulfillment solutions for online businesses integrating with the leading carriers used in Australia and New Zealand, such as Australia Post, DHL, Aramex, CouriersPlease, and more This PR will add support to integrate with starshipit directly in Odoo, providing rates and shipping for users who need it. Task ID # 3041982 Forward-Port-Of: odoo/enterprise#57654 Forward-Port-Of: odoo/enterprise#47569
Original PR description
Starshipit is the leading provider of integrated and automated fulfillment solutions for online businesses integrating with the leading carriers used in Australia and New Zealand, such as Australia Post, DHL, Aramex, CouriersPlease, and more This PR will add support to integrate with starshipit directly in Odoo, providing rates and shipping for users who need it. Task ID # 3041982 Forward-Port-Of: odoo/enterprise#57654 Forward-Port-Of: odoo/enterprise#47569
Have an approval flow rather complex in four steps: - rule 0: notification order 1, exclusive - rule 1: notification order 2, exclusive - rule 2: notification order 2, exclusive - rule 3: notification order 3, exclusive, has a responsible Obviously, each validation should be done by a different user (and not an admin), because all rules are exclusive. Also, each rule has a responsible in the example below, but really only rule 3's is part of the real use case and is the object of the fix.
Original PR description
Have an approval flow rather complex in four steps: - rule 0: notification order 1, exclusive - rule 1: notification order 2, exclusive - rule 2: notification order 2, exclusive - rule 3:…
Have an approval flow rather complex in four steps: - rule 0: notification order 1, exclusive - rule 1: notification order 2, exclusive - rule 2: notification order 2, exclusive - rule 3: notification order 3, exclusive, has a responsible Obviously, each validation should be done by a different user (and not an admin), because all rules are exclusive. Also, each rule has a responsible in the example below, but really only rule 3's is part of the real use case and is the object of the fix. Validate 0: 1 and 2 receives an activity Validate 1: activity of 1 is removed validate 2: activity of 2 is removed, 3 receives an activity (<=====) Before this commit, 3 did not receive an activity. This was because, in this flow the rule 3 is evaluated for validation because every rule before it had been validated. However, in that part of the code, we ensure that no rule below it in notification order is not validated, but we do it in the context of the current user. So, when validating rule 3, we couldn't see the validations for at least of previous rule that another part of the code had seen before. After this commit, the rule 3 receives an activity, and the whole flow works as expected. opw-3752133 Forward-Port-Of: odoo/enterprise#57644 Forward-Port-Of: odoo/enterprise#57604
Fix the fetching of the appointment types which was triggering an Access Error for public and portal users as they didn't have the read access on the appointment.type model. Instead of calling the search method directly without sudo to apply the user access rules, rolling back to the 17.0 version where the search was performed using a sudo and the resulting recordset was then filtered based on the user access rules. This guarantees an access to the appointment.type model and always returns th
Original PR description
Fix the fetching of the appointment types which was triggering an Access Error for public and portal users as they didn't have the read access on the appointment.type model. Instead of calling the search method directly without sudo to apply the user access rules, rolling back to the 17.0 version where the search was performed using a sudo and the resulting recordset was then filtered based on the user access rules. This guarantees an access to the appointment.type model and always returns the appropriate recordset. related commit: 05a1080a66cefc1b0724e23c72dd2bf06343e4e3 Task-3765016 Forward-Port-Of: odoo/enterprise#57374
**Steps to reproduce:** 1- Install Helpdesk, Website module 2- Login using portal user 3- Navigate to tickest and search by assignees **Current behavior before PR:** When searching by assignees using a portal user you will not get any results. This is happening because the portal user seems to not have the access to search in 'res.users' so when the orm parse the user_id assigned to the ticket to a name it will not be able to parse it for the portal user. **Desired behavior after PR
Original PR description
**Steps to reproduce:** 1- Install Helpdesk, Website module 2- Login using portal user 3- Navigate to tickest and search by assignees **Current behavior before PR:** When searching by assignees using a portal user you will not get any results. This is happening because the portal user seems to not have the access to search in 'res.users' so when the orm parse the user_id assigned to the ticket to a name it will not be able to parse it for the portal user. **Desired behavior after PR is merged:** We search first for the users that are matching the search key in 'res.users' using 'sudo()' then get their ids and search in 'helpdesk.ticket' using those ids opw-3719387 Forward-Port-Of: odoo/enterprise#56716
Based on last runbot counters Forward-Port-Of: odoo/enterprise#57731
Original PR description
Based on last runbot counters Forward-Port-Of: odoo/enterprise#57731
the headers of the xlsx report were not translated this commit fixes that by adding the missing translations into the controller task-3718923 Forward-Port-Of: odoo/enterprise#55761
Original PR description
the headers of the xlsx report were not translated this commit fixes that by adding the missing translations into the controller task-3718923 Forward-Port-Of: odoo/enterprise#55761
steps to reproduce: 1. Go to approvals with no rights 2. create a new approval request 3. add an approver -> the approver cannot be selected because the line is readonly expected behavior: the approver can be selected Explaination of the issue: The field can_edit_user_id is set to False when no user is selected because when you add a line no user is selected by default. behavior after the fix: the approver can be selected task-3602617 Forward-Port-Of: odoo/enterprise#54822
Original PR description
steps to reproduce: 1. Go to approvals with no rights 2. create a new approval request 3. add an approver -> the approver cannot be selected because the line is readonly expected behavior: the approver can be selected Explaination of the issue: The field can_edit_user_id is set to False when no user is selected because when you add a line no user is selected by default. behavior after the fix: the approver can be selected task-3602617 Forward-Port-Of: odoo/enterprise#54822
### Cause When validating an address, we take for granted that Avatax returns latitude and longitude, while it's optional. We started using Avatax's returned geocoordinates in `saas-16.2`, https://github.com/odoo/enterprise/commit/282b878d8c441aaf546e6ce5d5c7dbe9f831d5b2 ### Steps to reproduce * install `account_avatax` * in the settings, enable and setup Avatax. Make sure to enable Address Validation. * create a partner with the following address: - Street 1: 999 Canada Pl - Cit
Original PR description
### Cause When validating an address, we take for granted that Avatax returns latitude and longitude, while it's optional. We started using Avatax's returned geocoordinates in `saas-16.2`, https://github.com/odoo/enterprise/commit/282b878d8c441aaf546e6ce5d5c7dbe9f831d5b2 ### Steps to reproduce * install `account_avatax` * in the settings, enable and setup Avatax. Make sure to enable Address Validation. * create a partner with the following address: - Street 1: 999 Canada Pl - City: Vancouver - State: British Columbia (CA) - Zip: V6C 3B5 - Country: Canada * click the 'Validate' button, next to the country You should be met with a traceback: `KeyError: 'latitude'` Ticket link: https://www.odoo.com/web#model=project.task&id=3752775 opw-3752775 Forward-Port-Of: odoo/enterprise#57612
Bug === Currently, we can not login to Instagram, because a permission is missing. This commit adds the missing permission, and we upgrade from 10.0 to 17.0. Task-3761561 Forward-Port-Of: odoo/enterprise#57693 Forward-Port-Of: odoo/enterprise#57218
Original PR description
Bug === Currently, we can not login to Instagram, because a permission is missing. This commit adds the missing permission, and we upgrade from 10.0 to 17.0. Task-3761561 Forward-Port-Of: odoo/enterprise#57693 Forward-Port-Of: odoo/enterprise#57218