Thursday, October 10, 2024
103 changes
Enhancements to existing features
This change adds a test setting that can introduce a delay during guided test tours, laying the groundwork for detecting inconsistent or unpredictable failures. It helps improve future test reliability, but does not change how business users use Odoo today.
Original PR description
In commit, we add an environment variable to launch a tour in which we will look for undeterministic errors. The environment variable is a delay (in seconds). You can then launch a tour with "check" parameter or set the environment variable ODOO_TOUR_DELAY to search for undeterminisms. The search for the undeterministic error in a tour is not yet implemented. This commit comes before this implementation. But here is how it will work: When the trigger of a step of a tour has been found, we wait this delay and then, we look again for the trigger in the DOM. If the element found is different from the first, then it triggers an error. 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
Resolved issues and error corrections
This fixes an issue where spreadsheet pivot tables could show a “see records” option for calculated fields when no underlying record existed. The change prevents users from opening an invalid record view and avoids a traceback, making spreadsheet reports more reliable.
Original PR description
Some methods in the pivot_model didn't handle the `NO_RECORD_AT_THIS_POSITION` constant returned by positional pivot formulas. This lead to a `see_record` visible where it shouldn't be, that caused a tracabeck. Task: [4210956](https://www.odoo.com/web#id=4210956&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) 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
Documentation and clarification updates
This pull request records that contributor mavi-tux has signed Odoo's Contributor License Agreement. It supports legal compliance for accepting their future contributions and has no direct effect on product functionality.
Original PR description
Description of the issue/feature this PR addresses: CLA Signature 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
Miscellaneous changes
### Issue: When validating a stock picking created with a sendcloud picking method the partner assocaited with the delivery has no parent_id, so that the code will raise an error the one raised by: https://github.com/odoo/enterprise/blob/070a780db047d849db268a40f1b488dce0a80c6a/delivery_sendcloud/models/sendcloud_service.py#L556-L560 see commit fbeefb5f7d1e429b22d8fd6fc06b7c28b9c236a6 ### Steps to reproduce: - Create a sendcloud delivery method - go to website and order a product, go to
Original PR description
### Issue: When validating a stock picking created with a sendcloud picking method the partner assocaited with the delivery has no parent_id, so that the code will raise an error the one raised by:…
This change makes an automated website slides test wait until the page preview is fully ready before checking fullscreen mode. It reduces intermittent test failures, helping keep releases and updates more stable without changing user-facing behavior.
Original PR description
The tour full_screen_web_editor fails at step ":iframe .o_wslides_fs_main" (check we land on the fullscreen view) from time to time on the runbot. We could reproduce the problem locally by setting a timeout on that step below 1400 ms. As this step (like others) is loaded in the WebsitePreview iframe that set the attribute "is-ready" on the iframe node when some assets are loaded (website.assets_all_wysiwyg), we have added a step before, that wait for that (stepUtils.waitIframeIsReady()). With that change, the tour succeeed even if we set a very low timeout on the failing step. So it should solve the problem. Task-4222573
This fixes an automated test for the Knowledge calendar command so it uses the standard editor tour helper. The change helps keep quality checks stable without changing how users work with Knowledge.
Original PR description
We use tour_helper editor instead of programmatic run().
This fix corrects a naming error that could cause recruitment document extraction to fail unexpectedly. It helps keep candidate processing stable and adds test coverage to prevent the issue from returning.
Original PR description
* traceback due to typo: applicant_id -> candidate_id task-4207776
### Issue: When validating a stock picking created with a sendcloud picking method the partner assocaited with the delivery has no parent_id, so that the code will raise an error the one raised by: https://github.com/odoo/enterprise/blob/070a780db047d849db268a40f1b488dce0a80c6a/delivery_sendcloud/models/sendcloud_service.py#L556-L560 see commit fbeefb5f7d1e429b22d8fd6fc06b7c28b9c236a6 ### Steps to reproduce: - Create a sendcloud delivery method - go to website and order a product, go to checkout - pick sendcloud delivery method - select a relay location - go to odoo backend, go the sale order created by the website - click the SO deliveries smart button - Validate the delivery #### > Invalid operation ### Cause of the issue: When the customer checkouts, it confirms the sale order and generate a delivery linked to that SO via the `_action_launch_stock_rule`: https://github.com/odoo/odoo/blob/a91da6a5e835c11f59a4847026ffc79ba97969c5/addons/sale_stock/models/sale_order.py#L153-L155 Later in this confirm, the `partner_shipping_id` of the SO is changed to be associated with a `res.partner` of type `delivery`: https://github.com/odoo/odoo/blob/a91da6a5e835c11f59a4847026ffc79ba97969c5/addons/delivery/models/sale_order.py#L178-L183 but the partner of the picking is not changed accordingly. However, the `delivery_sendcloud` module expects ti receive this delivery partner as a `partner_id` which raises. ### Note: The error is only reproducible after 17.4 even though the only change is that the piece of code creating the partner was moved from `website_sale` to `delivery` by commit 6a28ecf201acaa1e09d3f02184b49f9b3f17486a HOWEVER, this change has a huge impact as it change the inheritance chain of the `sale.order` model: more precisely, the overrides of the `_action_confirm` in which the stock move is created happens before the overrides creating the partner of type delivery while the flow use to be generated in the opposite order so that the picking was created with the updated partner data ! opw-4181787 opw-4188628 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182396
Steps to reproduce: - Have a draggable that uses an iframe - The iframe must be offset from the page (0,0) - The draggable must be outside of the iframe - Yank the mouse fast over the iframe, such that the mouse goes over the iframe before the dragged item can catch up. -> the dragged item is offset from the mouse so long as the mouse remains over the iframe. In 17.2 this issue affects the mailing editor inside marketing automation when editing an activity. This is because it does
Original PR description
Steps to reproduce: - Have a draggable that uses an iframe - The iframe must be offset from the page (0,0) - The draggable must be outside of the iframe - Yank the mouse fast over the iframe, such…
Steps to reproduce: - Have a draggable that uses an iframe - The iframe must be offset from the page (0,0) - The draggable must be outside of the iframe - Yank the mouse fast over the iframe, such that the mouse goes over the iframe before the dragged item can catch up. -> the dragged item is offset from the mouse so long as the mouse remains over the iframe. In 17.2 this issue affects the mailing editor inside marketing automation when editing an activity. This is because it does not inherit pe-none in that scenario, unlike inside form views. Drag and drop relies on `clientX` and `clientY` being in the coordinates of the viewport. When entering an iframe, mouse event coordinates (other than screen-based) are given relative to the viewport of the iframe. This means the position of the drag and drop does not match the position of the mouse. This can be fixed by preventing the iframe from becoming the target of the event using style="pointer-event: none;" on the iframe itself. task-4160857 Forward-Port-Of: odoo/odoo#181812
Commit that introduced the issue https://github.com/odoo/odoo/pull/128108/commits/33a04876cad58f413455bdc406c1ad4c70d73e1b Steps to reproduce the issue: ============================= - Create a new mass mailing - Add cover snippet - Test the email - Background image doesn't appear Origin of the issue: ==================== After the chnage of the mentioned commit, we add a div with a black background filter. It displays correclty in mass_mailing view since it has opacity 0.5 but afte
Original PR description
Commit that introduced the issue https://github.com/odoo/odoo/pull/128108/commits/33a04876cad58f413455bdc406c1ad4c70d73e1b Steps to reproduce the issue: ============================= - Create a new mass mailing - Add cover snippet - Test the email - Background image doesn't appear Origin of the issue: ==================== After the chnage of the mentioned commit, we add a div with a black background filter. It displays correclty in mass_mailing view since it has opacity 0.5 but after the `inline` process of the template we convert rgba colors to hex color with `rgbToHex` because some email engines doesn't support rgba. As a result, we will have a black div that covers the background image in the sent email. Solution: ========= Rever the change. task-4070400 Forward-Port-Of: odoo/odoo#182943 Forward-Port-Of: odoo/odoo#177174
Before https://github.com/odoo/odoo/pull/137691, select a groupby in the dropdown of a pivot header would close the dropdown. Now the dropdown stays open and it is possible to add several row/col groupbys at the same time but the pivot model is not updated correctly because the update of the model is based on the groupId of the header for which the dropdown was opened. The simpler/best solution to that problem is to restore the previous behavior. Task ID: 3985217 Forward-Port-Of: odoo/o
Original PR description
Before https://github.com/odoo/odoo/pull/137691, select a groupby in the dropdown of a pivot header would close the dropdown. Now the dropdown stays open and it is possible to add several row/col groupbys at the same time but the pivot model is not updated correctly because the update of the model is based on the groupId of the header for which the dropdown was opened. The simpler/best solution to that problem is to restore the previous behavior. Task ID: 3985217 Forward-Port-Of: odoo/odoo#182788 Forward-Port-Of: odoo/odoo#182746
**Steps to reproduce:** - Install Accounting - Create an invoice with any product - Go to "Journal Items" tab - Input a label for the payment term line (it should be empty) - Confirm the invoice **Issue:** The input label of the payment term line is replaced by the "Payment Reference" of the invoice. For bills, it is replaced by an empty string as there is no default value for the payment reference. **Solution:** Only use the payment reference of the invoice as label for the paymen
Original PR description
**Steps to reproduce:** - Install Accounting - Create an invoice with any product - Go to "Journal Items" tab - Input a label for the payment term line (it should be empty) - Confirm the invoice **Issue:** The input label of the payment term line is replaced by the "Payment Reference" of the invoice. For bills, it is replaced by an empty string as there is no default value for the payment reference. **Solution:** Only use the payment reference of the invoice as label for the payment term line if it has not been modified manually. This can be done by checking that their values in _origin are similar. opw-4173634 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182722 Forward-Port-Of: odoo/odoo#182136
The issue: While running the test test_multi_edit_start_date_wo, the calendar is set to the Europe/Brussels timezone when demo data is loaded. However, when demo data is not loaded, the calendar defaults to the UTC timezone. The fix: Adapt the timezone runbot-56562 Forward-Port-Of: odoo/odoo#177235
Original PR description
The issue: While running the test test_multi_edit_start_date_wo, the calendar is set to the Europe/Brussels timezone when demo data is loaded. However, when demo data is not loaded, the calendar defaults to the UTC timezone. The fix: Adapt the timezone runbot-56562 Forward-Port-Of: odoo/odoo#177235
Issue: ====== mass mailing iframe size isn't correct. Steps to reproduce the issue: ============================= It doesn't alwyas happen because of race condition, so you may need to try multiple times. - Create a new mass mailing - Add 3 `image-text` snippets - You can't scroll down in the editable area because the size of the iframe is smaller than it's content. Origin of the issue: ==================== The function that resizes the iframe in mass mailing is defined in [
Original PR description
Issue: ====== mass mailing iframe size isn't correct. Steps to reproduce the issue: ============================= It doesn't alwyas happen because of race condition, so you may need to try multiple…
Issue: ====== mass mailing iframe size isn't correct. Steps to reproduce the issue: ============================= It doesn't alwyas happen because of race condition, so you may need to try multiple times. - Create a new mass mailing - Add 3 `image-text` snippets - You can't scroll down in the editable area because the size of the iframe is smaller than it's content. Origin of the issue: ==================== The function that resizes the iframe in mass mailing is defined in [1]. In `onDragStart` in [2] we call `addStyle` on the iframe to make sure it has `pointerEvents:auto` style. Now when the drag ends there are 2 events executing in parallel which are : - `onPointerUp` in [3]: which will call `dragEnd` which itself will call `cleanup` so it will assign the old style attribute to the iframe. - resizing of the iframe from the `_resizeObserver` Now if `_resizeMailingEditorIframe` is called first then it will have the new size and then the cleanup will assign the old style which have the wrong size which makes the editable smaller than its content and we can't scroll down the editable. Solution: ========= We use `addClass` instead of `addStyle`. task-4041275 [1]: https://github.com/odoo/odoo/blob/db29299d91111837d02bc62d573afb915fe673dd/addons/mass_mailing/static/src/js/mailing_mailing_view_form_full_width.js#L19 [2]: https://github.com/odoo/odoo/blob/db29299d91111837d02bc62d573afb915fe673dd/addons/web_editor/static/src/js/editor/drag_and_drop.js#L135 [3]: https://github.com/odoo/odoo/blob/db29299d91111837d02bc62d573afb915fe673dd/addons/web/static/src/core/utils/draggable_hook_builder.js#L752 Forward-Port-Of: odoo/odoo#179605
Steps: - Install the hr_holidays module - Click on the `Pending Requests` from dashboard Description of the issue/feature this PR addresses: In the Time Off module, when clicking on Pending Requests, it opens the allocation with the only second approval filter. Fix: This PR resolves the issue by setting the default search filter to first approval along with second approval. task-4208036 Forward-Port-Of: odoo/odoo#181227
Original PR description
Steps: - Install the hr_holidays module - Click on the `Pending Requests` from dashboard Description of the issue/feature this PR addresses: In the Time Off module, when clicking on Pending Requests, it opens the allocation with the only second approval filter. Fix: This PR resolves the issue by setting the default search filter to first approval along with second approval. task-4208036 Forward-Port-Of: odoo/odoo#181227
On the IoT box, translations are not supported as there is no language context and no po/pot files. However, there were still some usages of the `_` function which will now log a warning in version 18.0+. In this PR we simply remove the usages of `_`, as it was not translating anyway and removes the warnings. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182911 Forward-Port-Of: odoo/odoo#182767
Original PR description
On the IoT box, translations are not supported as there is no language context and no po/pot files. However, there were still some usages of the `_` function which will now log a warning in version 18.0+. In this PR we simply remove the usages of `_`, as it was not translating anyway and removes the warnings. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182911 Forward-Port-Of: odoo/odoo#182767
Steps to reproduce : ==== - Install pos_sale module. - Create a quotation in sales and confirm it. - Open Point of Sale - Open Session and load orders from session. - Select the quotation and do 50% down payment. - Create new order and again load the same quotation. - Due balance remains same. Issue: ==== - Due balance is not updated, everytime it shows total amount. Fix : ==== - Instead of total amount , amount unpaid is displayed which show correct due balance. task- 42040
Original PR description
Steps to reproduce : ==== - Install pos_sale module. - Create a quotation in sales and confirm it. - Open Point of Sale - Open Session and load orders from session. - Select the quotation and do 50% down payment. - Create new order and again load the same quotation. - Due balance remains same. Issue: ==== - Due balance is not updated, everytime it shows total amount. Fix : ==== - Instead of total amount , amount unpaid is displayed which show correct due balance. task- 4204048 Forward-Port-Of: odoo/odoo#182939 Forward-Port-Of: odoo/odoo#181809
Since [1] when Bootstrap was upgraded to version 5.3, the `$table-bg` variable is obtained from `$body-bg` instead of being transparent as it was previously. Because of this, when a "Boxed", "Frame" or "Postcard" layout is used, and a background color is specified, that color is used as table background, even if they are nested within cards that have a white background. This commit restores the transparent table background. Steps to reproduce: - Install eCommerce - Set a "Postcard" layou
Original PR description
Since [1] when Bootstrap was upgraded to version 5.3, the `$table-bg` variable is obtained from `$body-bg` instead of being transparent as it was previously. Because of this, when a "Boxed", "Frame" or "Postcard" layout is used, and a background color is specified, that color is used as table background, even if they are nested within cards that have a white background. This commit restores the transparent table background. Steps to reproduce: - Install eCommerce - Set a "Postcard" layout - Specify a non-white background color - Add a product to the card - Proceed to the checkout page => The total area used the body background instead of the card background. [1]: https://github.com/odoo/odoo/commit/058212e12b5079eba870bde9775fe98f27928935#diff-b037a8f5f304da130ba183549bf6abf5126d1bc118033211aa865ae74d3bca51R739 opw-4203976 Forward-Port-Of: odoo/odoo#182735
Add support for the Peppol PINT SG format, which will become active by the end of this year and required during the next one. Task id # 4122312 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182980 Forward-Port-Of: odoo/odoo#177137
Original PR description
Add support for the Peppol PINT SG format, which will become active by the end of this year and required during the next one. Task id # 4122312 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182980 Forward-Port-Of: odoo/odoo#177137
Before this commit, a regular expression was restricting the input units to `[A-Za-z%-]` characters. It made sense initially because those units were limited to technical terms with an untranslated name. But this makes "human" units such as "days" not recognized when using languages where the translated name either contains accents, or is not made of latin alphabet letters at all. This commit adapts the regular expression to consider a sequence of non-blank characters as the unit instead.
Original PR description
Before this commit, a regular expression was restricting the input units to `[A-Za-z%-]` characters. It made sense initially because those units were limited to technical terms with an untranslated name. But this makes "human" units such as "days" not recognized when using languages where the translated name either contains accents, or is not made of latin alphabet letters at all. This commit adapts the regular expression to consider a sequence of non-blank characters as the unit instead. Steps to reproduce: - Install Website - Drop a Popup inside the homepage - Switch user to Spanish - Edit the popup => The "Ocultar para" option did not display its value because "días" contains an accent. - Switch user to Japanese - Edit the popup => The "次のものに非表示" option did not display its value because "日" is not an alphabet letter. opw-4200520 Forward-Port-Of: odoo/odoo#182637
Have a grouped kanban view with existing groups but no records s.t. sample records are displayed (e.g. in CRM pipeline with a default filter, or in Project in a new project). Click on the "+" icon in a column to quick create a record. The first time, it's fine. Click on the menu again to relaunch the action (do not reload the webclient), and do the same: there's a flickering as sample records briefly appear "as real records" (i.e. they're not displayed as ghosts), before completely desappearing.
Original PR description
Have a grouped kanban view with existing groups but no records s.t. sample records are displayed (e.g. in CRM pipeline with a default filter, or in Project in a new project). Click on the "+" icon in…
Have a grouped kanban view with existing groups but no records s.t. sample records are displayed (e.g. in CRM pipeline with a default filter, or in Project in a new project). Click on the "+" icon in a column to quick create a record. The first time, it's fine. Click on the menu again to relaunch the action (do not reload the webclient), and do the same: there's a flickering as sample records briefly appear "as real records" (i.e. they're not displayed as ghosts), before completely desappearing. This is even more obvious on a slow network. The difference between the first time and the others is that the form view used in the quick create must be loaded the first time, and is in cache afterwards. When we click on the "+" icon, the following happens: - we remove sample records from the groups and we enable the quick create in a column => triggers a rendering of the KanbanRenderer - in the same tick, we toggle the useSampleModel flag on the model => triggers a rendering of the Controller After its rendering, the Controller no longer has the classname `o_view_sample_data` which ensures that sample records are displayed as ghosts. After its rendering, the Renderer no longer contains sample records. The flickering occurs when the rendering of the Renderer is async (the one of the Controller being always sync, as it doesn't wait for his children to be re-rendered, as their props didn't change). Indeed, in that case, there's a small timeframe during which the controller no longer has the classname `o_view_sample_data` but the renderer still contains sample records. Normally, the rendering of the Renderer should always be sync. Indeed, we triggered the loadViews in its onWillStart but we didn't wait for the rpc to return (we have a `isLoaded` flag, and we have an empty rendering while `isLoaded` is false). However, when the loadViews is already in the cache, the promise is resolves in the next microTick, and we directly render the component with the state `isLoaded` true, i.e. with the KanbanQuickCreateController. But that component is always async, as it loads the form view data (onchange) in its onWillStart, and must wait for it. As a consequence, in that case, the whole rendering of the Renderer is delayed. To fix the issue, this commit simply ensures that the rendering of the KanbanRecordQuickCreate is **always** sync, by toggling the `isLoaded` flag in onMounted instead of onWillStart. That way, the Renderer is rendered without the sample records in the same animationFrame as the Controller, and only then we toggle the KanbanQuickCreateController. Closes #181743 Task~4196741 Forward-Port-Of: odoo/odoo#182437 Forward-Port-Of: odoo/odoo#182300
Currently we always try to add a string informing about the used declaration of intent to the invoice / sale order PDF. I.e. it also happens when no declaration of intent is selected. After this commit the string is only added in case there is actually a declaration of intent selected. opw-4237368 Forward-Port-Of: odoo/odoo#182913
Original PR description
Currently we always try to add a string informing about the used declaration of intent to the invoice / sale order PDF. I.e. it also happens when no declaration of intent is selected. After this commit the string is only added in case there is actually a declaration of intent selected. opw-4237368 Forward-Port-Of: odoo/odoo#182913
Add support for the Peppol PINT ANZ format, which will become active by the end of this year and required during the next one. Task id # 3758343 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177142
Original PR description
Add support for the Peppol PINT ANZ format, which will become active by the end of this year and required during the next one. Task id # 3758343 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177142
On the purchase invoice form, the Italian localization adds a button that allows sending the tax EDI to the Italian administration. This depends on the field l10n_it_edi_is_self_invoice that is a computed field that will need access to the model account.report.line. In order to reproduce the issue, change the access rights of Marc Demo to Accounting: Billing, go to Accounting > Vendors > Bills and hit New. This commit fixes the issue by adding a sudo at the right place. Source: post-
Original PR description
On the purchase invoice form, the Italian localization adds a button that allows sending the tax EDI to the Italian administration. This depends on the field l10n_it_edi_is_self_invoice that is a computed field that will need access to the model account.report.line. In order to reproduce the issue, change the access rights of Marc Demo to Accounting: Billing, go to Accounting > Vendors > Bills and hit New. This commit fixes the issue by adding a sudo at the right place. Source: post-Odoo.com migration feedback Forward-Port-Of: odoo/odoo#176222
Some "week" date filters show records of the wrong week if the current day is Monday. This PR fixes them. Task-4219531 Forward-Port-Of: odoo/enterprise#71044
Original PR description
Some "week" date filters show records of the wrong week if the current day is Monday. This PR fixes them. Task-4219531 Forward-Port-Of: odoo/enterprise#71044
In 2022, Republic of Turkey officially renamed itself to Republic of Türkiye. So, its name needed to be changed in its Odoo modules. Moreover, updated Turkish modules descriptions according to this excalidraw: https://link.excalidraw.com/readonly/rbesZEAkXUS8rVgXplgm?darkMode=true task-4182931 Forward-Port-Of: odoo/enterprise#71573 Forward-Port-Of: odoo/enterprise#70304
Original PR description
In 2022, Republic of Turkey officially renamed itself to Republic of Türkiye. So, its name needed to be changed in its Odoo modules. Moreover, updated Turkish modules descriptions according to this excalidraw: https://link.excalidraw.com/readonly/rbesZEAkXUS8rVgXplgm?darkMode=true task-4182931 Forward-Port-Of: odoo/enterprise#71573 Forward-Port-Of: odoo/enterprise#70304