Tuesday, November 5, 2024
30 changes · saas-17.4
Resolved issues and error corrections
The popout button in the chatter top bar has been restored after a recent change caused it to stop working. Users can once again open chatter content in a separate popout window, improving usability when reviewing messages or attachments.
Original PR description
Before this commit, the chatter popout button was not working. This comes from recent changes to popout service that were affected to popout from attachment but not from chatter [1]. task-4275364 [1]: https://github.com/odoo/odoo/pull/174878
This fixes how favorite stock operation types are found, so users see the correct favorite items when filtering or searching. It helps prevent misleading stock operation lists and keeps warehouse workflows consistent.
Original PR description
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
The Point of Sale now loads only the product attribute values it actually needs. This reduces unnecessary data handling, helping improve performance and responsiveness without changing cashier workflows.
Original PR description
Before this commit, some unnecessary attributes might be loaded. This change ensures that only the required attributes are loaded, improving efficiency and performance. opw-4298915 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Point of Sale cash moves now complete without failing when no sales order is linked. This prevents interruptions for cashiers and keeps cash management workflows reliable.
Original PR description
Before this commit, performing a cash move would cause an error due to a missing order when calling `getReceiptHeaderData`. opw-4309610 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes how chat bubble previews are shown by using the appropriate popover behavior instead of adding special dropdown behavior. It keeps the chat preview experience working while reducing unnecessary changes in shared interface components, lowering the risk of side effects elsewhere.
Original PR description
Since [1], the ChatBubble component have been introduced by using a Dropdown component in its template. The Dropdown component is used with advanced props in order to give it a simple tooltip…
Since [1], the ChatBubble component have been introduced by using a Dropdown component in its template. The Dropdown component is used with advanced props in order to give it a simple tooltip behavior. In order to achieve this, the Dropdown component has been updated by adding a new `arrow` property, which is passed to the underlying Popover component that, in turn, had to get updated in order to support this simple use case. This commit reverts the changes to the Dropdown and Popover components and adapts the ChatBubble component in order to use a simple popover, which is controlled in such a way that it behaves as a tooltip. Additional note: - simple tooltips could not have been used in this case as the ChatBubble needs are greater than the [data-tooltip-*] attributes could offer, especially for styling but also because complex objects are passed (proxies) to the preview template, which could not get stringified to get passed as elements' attributes. [1]: https://github.com/odoo/odoo/commit/82e3295d43f7809661a40d1b21ffbcbce23c700b
This fixes how favorite inventory operation types are searched so the system uses the intended comparison logic. It helps users see accurate favorite results in stock workflows and avoids incorrect filtering behavior.
Original PR description
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
Point of Sale orders now always show zero margin for combo products, even if a cost was set before the product was changed to a combo. This prevents misleading profitability figures in order reporting.
Original PR description
If you create a product with a cost and type combo, and you sell it in the PoS. The margin would not be 0 but it should always be 0 as this is the combo product. Steps to reproduce: ------------------- * Create a product, and set a cost on it * Change the product type to combo * Open PoS and sell this product * Go back to the order list > Observation: On the order you just made you will see that the margin for the combo product is not 0. Why the fix: ------------ We make sure to always set the margin to 0 for combo products. Actually combo product should never have a cost, but if you set a cost before changing it's type to combo it would be the case. opw-4171177 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update makes an automated Project app test more reliable by waiting for the task status changes to fully appear before continuing. It reduces occasional false test failures without changing day-to-day user behavior.
Original PR description
Before this commit, sometimes the test failed because the step to cancelled a sub-task is not yet done in the UI (the record has not yet been reloaded) before the next step is executed. This commit changes some trigger in some steps to be more precise but also add an additional step to make sure the dropdown showing the task states is correctly closed before checking if the sub-task is correctly marked as done. runbot-73414
Miscellaneous changes
Steps to reproduce ------------------ 1. Create a SO with a product with with the "Prepaid" Invoice Policy and "Hours" unit that creates a task in a project. 2. Create a new billable project and a task in that project, and set the partner of the SO created earlier on the new task. 3. Set the SOL of the SO from step 1 on the task. 4. Check that in the Timesheets notebook, you see a value for "Time Remaining on SO". 5. Go to the reporting and group by project, and display the "Time Remaining
Original PR description
Steps to reproduce ------------------ 1. Create a SO with a product with with the "Prepaid" Invoice Policy and "Hours" unit that creates a task in a project. 2. Create a new billable project and a task in that project, and set the partner of the SO created earlier on the new task. 3. Set the SOL of the SO from step 1 on the task. 4. Check that in the Timesheets notebook, you see a value for "Time Remaining on SO". 5. Go to the reporting and group by project, and display the "Time Remaining on SO". 6. There is a value for the project generated by the SO, but not for the one created manually. --- This bug occurs because we only account for the task generated by a SOL of the SO when computing the remaining hours on SO in the reporting. This PR fixes the way it is computed. Task-4280965 Forward-Port-Of: odoo/odoo#184915
Since domain methods of fields are set using the actual class method instead of a lambda, it is not possible to inherit those methods when inheriting the model. This issue is fixed by using a lambda function to call the domain method. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185972 Forward-Port-Of: odoo/odoo#185419
Original PR description
Since domain methods of fields are set using the actual class method instead of a lambda, it is not possible to inherit those methods when inheriting the model. This issue is fixed by using a lambda function to call the domain method. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185972 Forward-Port-Of: odoo/odoo#185419
## [FIX] l10n_ar: prevent errors from deleted tax group When users delete the tax group `tax_group_percepcion_ganancias` while using the Argentinian localization, it will an error when trying to send an electronic invoice or generate the VAT books, since it depends on this specific tax group. There is no clearer way to identify this tax group than by its XML ID. This commit does two things: 1. It prevents users from deleting this required tax group when the company is using the Argenti
Original PR description
## [FIX] l10n_ar: prevent errors from deleted tax group When users delete the tax group `tax_group_percepcion_ganancias` while using the Argentinian localization, it will an error when trying to send…
## [FIX] l10n_ar: prevent errors from deleted tax group When users delete the tax group `tax_group_percepcion_ganancias` while using the Argentinian localization, it will an error when trying to send an electronic invoice or generate the VAT books, since it depends on this specific tax group. There is no clearer way to identify this tax group than by its XML ID. This commit does two things: 1. It prevents users from deleting this required tax group when the company is using the Argentinian localization. 2. If the tax group was already removed, it will show a useful error message when it can't be found and redirect the user to the settings where they can reload their chart template in order to reinstall the tax group. [task-3853596](https://www.odoo.com/odoo/all-tasks/3853596) [opw-3685073](https://www.odoo.com/odoo/all-tasks/3685073) ## [FIX] account: fallback on company data when loading chart template Currently when loading a chart template for a company which is referencing some records by XML ID, we look for these records in the database. This could fail in some cases, like this: - We have a company set up with a CoA and delete one of its default accounts in the company settings and replace it by another account. - We try to create a branch company under the former one. When trying to save the branch company, we try loading the chart template on it, setting also the default accounts. We look in the database for the right reference, but since the parent company deleted the original account, the process fails and the branch can't be created. In this commit we provide a sensible fallback. If the record referenced in the chart template can't be found, we try looking what was already set on the company or its root. As such, we will be able to create the branch successfully and the user can always adapt the defaults later. [task-3853596](https://www.odoo.com/odoo/all-tasks/3853596) [opw-3677061](https://www.odoo.com/odoo/all-tasks/3677061) [opw-3681481](https://www.odoo.com/odoo/all-tasks/3681481) [opw-3681456](https://www.odoo.com/odoo/all-tasks/3681456) [opw-3672507](https://www.odoo.com/odoo/all-tasks/3672507) [opw-3669164](https://www.odoo.com/odoo/all-tasks/3669164) [opw-3694606](https://www.odoo.com/odoo/all-tasks/3694606) [opw-3705870](https://www.odoo.com/odoo/all-tasks/3705870) [opw-3704826](https://www.odoo.com/odoo/all-tasks/3704826) Forward-Port-Of: odoo/odoo#185563 Forward-Port-Of: odoo/odoo#183609
Steps ----- - Install l10n_fr_hr_holidays - Use french company and be in a timezone different than UTC - Set your user's employee to use a different working hours schedule than the french company - Take a day of paid time off -> Two days of paid time off appear on the Dashboard (if not in an UTC timezone). Cause ----- For full days leaves, the hours are set to min and max to avoid calculation issues https://github.com/odoo/odoo/blob/24e100a5acf7531787a646ff1473c4b027d1ad12/addons/l
Original PR description
Steps ----- - Install l10n_fr_hr_holidays - Use french company and be in a timezone different than UTC - Set your user's employee to use a different working hours schedule than the french company - Take a day of paid time off -> Two days of paid time off appear on the Dashboard (if not in an UTC timezone). Cause ----- For full days leaves, the hours are set to min and max to avoid calculation issues https://github.com/odoo/odoo/blob/24e100a5acf7531787a646ff1473c4b027d1ad12/addons/l10n_fr_hr_holidays/models/hr_leave.py#L39-L40 But is not converted to UTC time, leading to the leave being displayed over several days if not created by a user in UTC time. Change ----- For full days leaves, adjust the start and end time of the leave in the same way that is currently done for half days. This also makes the leave's hours closer to reality. opw-4203972 Forward-Port-Of: odoo/odoo#182816
[MOV] web_editor, website: move isImageCorsProtected function in utils The goal of this commit is to move the `isImageCorsProtected()` function in the `web_editor` utils as it is will be needed in the next commit. opw-3959983 ---------------------------------------------------------------------------------------------------------------------------------------------- [FIX] web_editor,*: forbid the change of image field by webp CORS image *: website_sale The goal of this commit
Original PR description
[MOV] web_editor, website: move isImageCorsProtected function in utils The goal of this commit is to move the `isImageCorsProtected()` function in the `web_editor` utils as it is will be needed in…
[MOV] web_editor, website: move isImageCorsProtected function in utils The goal of this commit is to move the `isImageCorsProtected()` function in the `web_editor` utils as it is will be needed in the next commit. opw-3959983 ---------------------------------------------------------------------------------------------------------------------------------------------- [FIX] web_editor,*: forbid the change of image field by webp CORS image *: website_sale The goal of this commit is to avoid that a user replaces an image field by a webp CORS protected image (e.g. https://www.gstatic.com/webp/gallery/1.webp). There are two main reasons for that: - As explained in [1], the resized images have to be generated when a webp image has been uploaded. This is something that we are currently not able to do for CORS protected images. - As explained in [2], a jpeg image has to be generated when a webp image has been uploaded. This is also something that we are currently not able to do for CORS protected images. We also apply the same logic for the addition of extra product images. Indeed, in this case, when choosing an image among the existing attachments or when uploading new images, we can not rely on DOM information to determine if the changed image is an image field as the image is not already part of the DOM. [1]: https://github.com/odoo/odoo/commit/0ba3617f9dacf2a63288b30245a610782d943c5a [2]: https://github.com/odoo/odoo/commit/c035d0003d09289fde0aabcb21849c2914524c01 opw-3959983 ----------------------------------------------------------------------------------------------------------------------------------------------------------- [FIX] website_sale: avoid converting some extra images to webp Steps to reproduce the bug: - Go on a product page. - Enter in edit mode and click on "Add Extra Images". - Click on "Add URL" and upload an external CORS protected image (e.g. https://tinyjpg.com/images/social/website.jpg). - Click on "Add" to use this image as an external image. -> Error. Since [3], images uploaded through the website builder that are neither gif nor svg are converted to the webp format by default except if those images are CORS protected. The goal of this commit is to adapt [4] to follow the same logic and not convert uploaded product extra image to webp if the image is CORS protected. [3]: https://github.com/odoo/odoo/commit/0449fe85cb0e1d639a4e1aeba26e90906f79254d [4]: https://github.com/odoo/odoo/commit/b284293c18b6bcdafe2bda989c5e0a084d1acbd1 opw-3959983 Forward-Port-Of: odoo/odoo#169628
Steps to reproduce ================== - Install crm - Go to CRM - Open a record - Open actions menu (cog icon next to breadcrumbs) - Add Properties - Set a value to the new property - Go back to kanban view - Switch to list view - Check the property field in optional columns menu to show the column - Remove "My Pipeline" filter - Add "My Pipeline" filter - The property column does not exist anywhere anymore Cause of the issue ================== The relational model adds mod
Original PR description
Steps to reproduce ================== - Install crm - Go to CRM - Open a record - Open actions menu (cog icon next to breadcrumbs) - Add Properties - Set a value to the new property - Go back to kanban view - Switch to list view - Check the property field in optional columns menu to show the column - Remove "My Pipeline" filter - Add "My Pipeline" filter - The property column does not exist anywhere anymore Cause of the issue ================== The relational model adds model info in a global shared field definition object and then list renderer uses these info for properties fields. The search bar also uses this object and adds properties fields info. Both are adding and using incompatible info. Solution ======== Define correctly the minimum acceptable of the properties definitions when needed in the model and do not add model info in these definitions. opw-4264560 Forward-Port-Of: odoo/odoo#186111 Forward-Port-Of: odoo/odoo#185828
The test was failing in winter because of the offset is -005 and not -004. The test is mainly there to check that a non migrated tz will behave as the replacement tz. Making the expected offset dynamic solve the issue. Runbot error: 105674 Forward-Port-Of: odoo/odoo#186108
Original PR description
The test was failing in winter because of the offset is -005 and not -004. The test is mainly there to check that a non migrated tz will behave as the replacement tz. Making the expected offset dynamic solve the issue. Runbot error: 105674 Forward-Port-Of: odoo/odoo#186108
Apart from the wrong domain, the performance issues are also huge. Description of the issue/feature this PR addresses: Wrong code. Wrong domain, affecting also performance 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#179683
Original PR description
Apart from the wrong domain, the performance issues are also huge. Description of the issue/feature this PR addresses: Wrong code. Wrong domain, affecting also performance 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#179683
Description of the issue/feature this PR addresses: TestAPIKeys.test_delete creates an user, which might trigger an automated action. However that action would fail [here](https://github.com/odoo/odoo/blob/17.0/addons/base_automation/models/base_automation.py#L67), since the mockup request that is set up in the test does not include a function request.get_json_data() nor request.httprequest.args Current behavior before PR: The test fails on databases that have an automated action triggered
Original PR description
Description of the issue/feature this PR addresses: TestAPIKeys.test_delete creates an user, which might trigger an automated action. However that action would fail [here](https://github.com/odoo/odoo/blob/17.0/addons/base_automation/models/base_automation.py#L67), since the mockup request that is set up in the test does not include a function request.get_json_data() nor request.httprequest.args Current behavior before PR: The test fails on databases that have an automated action triggered on user creation Desired behavior after PR is merged: This test should not fail on such databases This issue has been discussed [here](https://discord.com/channels/678381219515465750/687339689522364423/1300410221482479636) Forward-Port-Of: odoo/odoo#185493
Fixed onboarding Email Marketing tour which is not working properly. Reason ====== We're not getting this `'input[name="subject"]',` trigger for some reasons, & there is no `name` attribute with input. we do have `id` in input, but in v16 we got id as `subject` and v17+ gets `subject_0` so that can't be used. Also, the next trigger should be after user click on input field not when they write. One more point, sometimes it got stuck after selecting a theme and did not shows the pointer
Original PR description
Fixed onboarding Email Marketing tour which is not working properly. Reason ====== We're not getting this `'input[name="subject"]',` trigger for some reasons, & there is no `name` attribute with input. we do have `id` in input, but in v16 we got id as `subject` and v17+ gets `subject_0` so that can't be used. Also, the next trigger should be after user click on input field not when they write. One more point, sometimes it got stuck after selecting a theme and did not shows the pointer. Fixed/Improved that & used common classes that works on all version. Task-4210376 Forward-Port-Of: odoo/odoo#185174 Forward-Port-Of: odoo/odoo#182034
A previous fix[^1] prevents installing a wrong l10n if the country doesn't match. But it should still match if the template is not for a specific country. For instance, Fiji should instanciate the generic CoA. If a better one should be installed instead, the hook will be overridden when the module will be installed thanks to the `countries` flag of the l10n manifests. [^1]: 7f3a094a117477833b2814f0cfd3d574c6c22b53 Forward-Port-Of: odoo/odoo#186171
Original PR description
A previous fix[^1] prevents installing a wrong l10n if the country doesn't match. But it should still match if the template is not for a specific country. For instance, Fiji should instanciate the generic CoA. If a better one should be installed instead, the hook will be overridden when the module will be installed thanks to the `countries` flag of the l10n manifests. [^1]: 7f3a094a117477833b2814f0cfd3d574c6c22b53 Forward-Port-Of: odoo/odoo#186171
This PR aims to solve an old issue that was not fixed with the Milk redesign. Prior to this PR, there were different layout issues including colors, sizes, or dark mode adaptations. These issues were making the view looking different from the other one, resulting in consistencies issues. This PR tweaks some CSS in order to handle most of these issues. task-3713647 | /// | 17.0 | This PR | |--------|--------|--------| | LM | <img alt="image" src="https://github.com/user-attachments/
Original PR description
This PR aims to solve an old issue that was not fixed with the Milk redesign. Prior to this PR, there were different layout issues including colors, sizes, or dark mode adaptations. These issues were…
This PR aims to solve an old issue that was not fixed with the Milk redesign. Prior to this PR, there were different layout issues including colors, sizes, or dark mode adaptations. These issues were making the view looking different from the other one, resulting in consistencies issues. This PR tweaks some CSS in order to handle most of these issues. task-3713647 | /// | 17.0 | This PR | |--------|--------|--------| | LM | <img alt="image" src="https://github.com/user-attachments/assets/09eba47a-8d9e-4a4b-af73-f8f83321a454"> | <img alt="image" src="https://github.com/user-attachments/assets/bea7c02c-2118-4262-9433-52cddd99e7e7"> | | DM | <img alt="image" src="https://github.com/user-attachments/assets/416bd1a5-9c7f-44d7-a78d-f479074f5f42"> | <img width="1530" alt="image" src="https://github.com/user-attachments/assets/9fb77db6-7752-403a-82de-9d03b9fe46e6"> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186156
When an iFrame and its parent document are from different origins, contentDocument is null. See: https://developer.mozilla.org/en-US/docs/Web/API/HTMLIFrameElement/contentDocument This will cause an error when interacting with an iFrame that contains a Google Slide, which is from a different origin. Due to this, we need to check that there's a contentDocument before trying to use its content. opw-4240622 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com
Original PR description
When an iFrame and its parent document are from different origins, contentDocument is null. See: https://developer.mozilla.org/en-US/docs/Web/API/HTMLIFrameElement/contentDocument This will cause an error when interacting with an iFrame that contains a Google Slide, which is from a different origin. Due to this, we need to check that there's a contentDocument before trying to use its content. opw-4240622 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185107
Steps to reproduce: - insert a pivot with more rows than columns - write in a cell =TRANSPOSE(ODOO.PIVOT.TABLE(1)) - right-click on the grand total value => boom When computing which cell of the pivot table is clicked, we assume the matrix comes directly from the ODOO.PIVOT.TABLE(...) function to compute the offsets from the array formula. But it's completely wrong as the cell could at a completely different place if the matrix is manipulated by other functions before being outputted
Original PR description
Steps to reproduce: - insert a pivot with more rows than columns - write in a cell =TRANSPOSE(ODOO.PIVOT.TABLE(1)) - right-click on the grand total value => boom When computing which cell of the pivot table is clicked, we assume the matrix comes directly from the ODOO.PIVOT.TABLE(...) function to compute the offsets from the array formula. But it's completely wrong as the cell could at a completely different place if the matrix is manipulated by other functions before being outputted to the grid. Task: 4292134 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185534
Since domain method for the Sales Order Item field is not harcoded anymore, the inheritance in this module is now considered, so it needs to be adapted to work correctly with the expected value, i.e. returning a list instead of a string. [FIX] helpdesk_sale_timesheet: unharcode domain method of SO line field Since domain method of the Sales Order Item field is set using the actual class method instead of a lambda, it is not possible to inherit that method when inheriting the model.
Original PR description
Since domain method for the Sales Order Item field is not harcoded anymore, the inheritance in this module is now considered, so it needs to be adapted to work correctly with the expected value, i.e. returning a list instead of a string. [FIX] helpdesk_sale_timesheet: unharcode domain method of SO line field Since domain method of the Sales Order Item field is set using the actual class method instead of a lambda, it is not possible to inherit that method when inheriting the model. This issue is fixed by using a lambda function to call the domain method. Forward-Port-Of: odoo/enterprise#73126 Forward-Port-Of: odoo/enterprise#72931
Before this PR: - POS order lines were matched without sorting `tax_ids`, which could cause mismatches when the tax IDs were in a different order between `details_pos_line` and `account_move_line`. After this PR: - POS order lines are matched by comparing `tax_ids` in sorted order, ensuring consistent matching regardless of the order of tax IDs. Forward-Port-Of: odoo/enterprise#73268
Original PR description
Before this PR: - POS order lines were matched without sorting `tax_ids`, which could cause mismatches when the tax IDs were in a different order between `details_pos_line` and `account_move_line`. After this PR: - POS order lines are matched by comparing `tax_ids` in sorted order, ensuring consistent matching regardless of the order of tax IDs. Forward-Port-Of: odoo/enterprise#73268
This commit is a backport of https://github.com/odoo/enterprise/commit/e2da8c4fbbfb50ddc033cf30885fef4394cbe2dc It enables printing receipts in the kiosk using the iot which was not supported before. opw-4120145 Forward-Port-Of: odoo/enterprise#69906
Original PR description
This commit is a backport of https://github.com/odoo/enterprise/commit/e2da8c4fbbfb50ddc033cf30885fef4394cbe2dc It enables printing receipts in the kiosk using the iot which was not supported before. opw-4120145 Forward-Port-Of: odoo/enterprise#69906
**Steps to reproduce:** - Install l10n_pk_reports - Switch to a Pakistani company (e.g. PK Company) - Create a Journal entry crediting an account of "Other Income" type (e.g. 3112003 Misc Income) - Post the journal entry - Go to "Accounting / Reporting / Statement Reports / Profit and Loss" - Select "Profit and Loss (PK)" report **Issue:** The created journal entry is negative in the "Other Income" section and its value is subtracted from "Gross Profit" section, reducing "Profit of the
Original PR description
**Steps to reproduce:** - Install l10n_pk_reports - Switch to a Pakistani company (e.g. PK Company) - Create a Journal entry crediting an account of "Other Income" type (e.g. 3112003 Misc Income) - Post the journal entry - Go to "Accounting / Reporting / Statement Reports / Profit and Loss" - Select "Profit and Loss (PK)" report **Issue:** The created journal entry is negative in the "Other Income" section and its value is subtracted from "Gross Profit" section, reducing "Profit of the Year" section, which is not correct. On the other hand, if the normal "Profit and Loss" report is selected, the created journal entry is positive and its value is added to "Gross Profit" section, increasing "Net Profit" section, which is correct. opw-4185212 Forward-Port-Of: odoo/enterprise#72378
The SLA success rate was previously being computed using the entire history of closed tickets as the domain. This is contrary to the expected behavior, given the helper text on Odoo and the list view of tickets that opens up if you click the percentage. This commit changes the domain to only consider tickets that were closed in the last 7 days. To reproduce on Runbot, follow the steps laid out here, as the process involves forcing tickets to fail and be older than 7 days closed: htt
Original PR description
The SLA success rate was previously being computed using the entire history of closed tickets as the domain. This is contrary to the expected behavior, given the helper text on Odoo and the list view of tickets that opens up if you click the percentage. This commit changes the domain to only consider tickets that were closed in the last 7 days. To reproduce on Runbot, follow the steps laid out here, as the process involves forcing tickets to fail and be older than 7 days closed: https://www.odoo.com/odoo/49/tasks/4206255 opw-4206255 Forward-Port-Of: odoo/enterprise#71600
- Added 'post_install' and '-at_install' tags to ensure the test is executed after all modules are installed, necessary for `test_skill_search_on_ocr_results` to run fully. - Fixed the test to detect when no skills were being added to the applicant, even though some should have been. - Updated the skills search regex: replaced `\s` tags with `\b` tags to correctly detect the first and last words in `ocr_tokens`. Forward-Port-Of: odoo/enterprise#70862
Original PR description
- Added 'post_install' and '-at_install' tags to ensure the test is executed after all modules are installed, necessary for `test_skill_search_on_ocr_results` to run fully. - Fixed the test to detect when no skills were being added to the applicant, even though some should have been. - Updated the skills search regex: replaced `\s` tags with `\b` tags to correctly detect the first and last words in `ocr_tokens`. Forward-Port-Of: odoo/enterprise#70862
…anys Have a ir.default that sets one line into a one2many on some models. In studio, edit the form view of the main model, then navigate to edit the one2many, with the ir.default having been triggered (there is one virual line in the one2many). Before this commit there was a crash because "false" is not a valid id for the staticlist. After this commit, there is no crash, and the virtual record doesn't appear. opw-4289233 Forward-Port-Of: odoo/enterprise#73220
Original PR description
…anys Have a ir.default that sets one line into a one2many on some models. In studio, edit the form view of the main model, then navigate to edit the one2many, with the ir.default having been triggered (there is one virual line in the one2many). Before this commit there was a crash because "false" is not a valid id for the staticlist. After this commit, there is no crash, and the virtual record doesn't appear. opw-4289233 Forward-Port-Of: odoo/enterprise#73220
The error Avalara returns for this is too generic to be useful: Rejeição: Evento não atende o Schema XML específico We found out by contacting Avalara support that the error in this case was a reason that was too short. Let's prevent this from re-occuring. opw-4298175 Forward-Port-Of: odoo/enterprise#73209
Original PR description
The error Avalara returns for this is too generic to be useful: Rejeição: Evento não atende o Schema XML específico We found out by contacting Avalara support that the error in this case was a reason that was too short. Let's prevent this from re-occuring. opw-4298175 Forward-Port-Of: odoo/enterprise#73209