Thursday, June 6, 2024
75 changes · saas-17.1
Resolved issues and error corrections
A compatibility issue with the updated editor library caused QWeb profiling views to fail when displaying debug information. The fix changes where Odoo adds its extra information so the profiling view loads reliably again.
Original PR description
With the update of ace to 1.32.3, the lib is formatting her cells by getting them with hardcoded position in a array (here: 0, 1 and 2). On our side we are adding our o_info as first element, so the lib returns a traceback because her elements are shifted. After this commit, our info node is added after the lib nodes to not shift the all bunch. runbot issue 55085 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue where opening Customer Invoices from a project's profitability updates could show a misleading “record not found” message. The project view now links to the correct customer invoice, helping users review project revenue without interruption.
Original PR description
Steps to reproduce: ------------------- - create a project - create an invoice with Analytic Distribution for the project - go to the project's updates - in profitability section, click on "Customer Invoices" Issue: ------ A notification appears: ``` It seems the record with ID X cannot be found. It might have been deleted. ``` Cause: ------ The arguments in JSON format are: ``` "["other_invoice_revenues", [["id", "in", [X]]], X]" ``` with X not corresponding to the invoice id. They are determined by the method `_get_action_for_profitability_section`. In which the ids are `invoices_move_lines.ids` (in `_get_revenues_items_from_invoices`). Solution: --------- Find the `account.move` from the `account.move.line`. Note: Introduced with the commit abd40a461c289bfe092784977077ceb1c7ef12f3 opw-3924836
Employment Hero payslip fetching now handles cases where a tax code is not configured in Odoo taxes. This prevents an unexpected error during payroll import and helps businesses continue processing payslips even when some tax mapping data is absent.
Original PR description
Steps to reproduce: - Run fetching payslip without provide the tax code in Odoo taxes Current behaviour: - Exception raised Expected behaviour: - Should not raise any exception Explanation: next() method is missing default value so it raised exception when filtering return empty array and iter() returns None. task-3897198
Miscellaneous changes
Current behavior: If a product has some variants you shouldn't be able to change his type to combo Steps to reproduce: - Create a product, and add some variants to it - Try to change his type to "Combo" - You shouldn't be able to do it, as combo product shouldn't have variants opw-3961311 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168242
Original PR description
Current behavior: If a product has some variants you shouldn't be able to change his type to combo Steps to reproduce: - Create a product, and add some variants to it - Try to change his type to "Combo" - You shouldn't be able to do it, as combo product shouldn't have variants opw-3961311 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168242
Current behavior: When settling and invoicing a sale order in the PoS, the untaxed invoiced amount was not taking the pos order lines into account Steps to reproduce: - Create a sale order - Open a PoS and settle the sale order - Validate it - Go back to the original sale order and check the Untaxed Invoiced Amount. (The field might not be present in the form, you can add it with studio) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit
Original PR description
Current behavior: When settling and invoicing a sale order in the PoS, the untaxed invoiced amount was not taking the pos order lines into account Steps to reproduce: - Create a sale order - Open a PoS and settle the sale order - Validate it - Go back to the original sale order and check the Untaxed Invoiced Amount. (The field might not be present in the form, you can add it with studio) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167580 Forward-Port-Of: odoo/odoo#162634
Current behavior: Sometimes payment made with adyen where blocked in the "Waiting for card" status when cancelling a payment. As the issue is not reproducible consistantly I made a diagram to show what I think is happening. It was probably happening because the last_adyen_status was emptied at a wrong moment. To fix this we make sure that a real new payment request is made before emptying it. Before this fix when doing a cancel request, it would empty the last_adyen_status  opw-3427860 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168056 Forward-Port-Of: odoo/odoo#165792
starts. If the user language cannot be determined, it uses the one set in the html `lang` attribute. If this language is not installed, the webclient translation route does not return lang parameters such as date fortmat. However, the JS code expects those parameters to be available and missing parameters lead to multiple errors (e.g. when calling `parseDatetime` which requires the date format). This PR ignore the lang passed to this route if it is not installed in order for it to fallback
Original PR description
starts. If the user language cannot be determined, it uses the one set in the html `lang` attribute. If this language is not installed, the webclient translation route does not return lang parameters such as date fortmat. However, the JS code expects those parameters to be available and missing parameters lead to multiple errors (e.g. when calling `parseDatetime` which requires the date format). This PR ignore the lang passed to this route if it is not installed in order for it to fallback to the context lang. Steps to reproduce the issue: - Create an html page and set the lang attribute value to the IETF Xhosa tag (xh-ZA) - A request to `/web/webclient/translation` is made and an error is displayed in the console. opw-3953457 Forward-Port-Of: odoo/odoo#167491
Current behavior: In certain currencies, you have coin of values like 0.025 that requires more than 2 decimal places. But in the coin/bills view they were not correctly showed. Values like 0.025 would appear as 0.02 Steps to reproduce: - Create a new company using a currency that needs 3 decimal places (Bahraini Dinar) - Try to create coin/bills with a value like 0.025 - After saving the last part cannot be seen anymore opw-3950930 --- I confirm I have signed the CLA and read the PR
Original PR description
Current behavior: In certain currencies, you have coin of values like 0.025 that requires more than 2 decimal places. But in the coin/bills view they were not correctly showed. Values like 0.025 would appear as 0.02 Steps to reproduce: - Create a new company using a currency that needs 3 decimal places (Bahraini Dinar) - Try to create coin/bills with a value like 0.025 - After saving the last part cannot be seen anymore opw-3950930 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168011 Forward-Port-Of: odoo/odoo#167497
Before this commit, the attendees were not allowed to remove anyone from the event (including themselves) when editing the event in the form view. This was a problem that came after updating the views to OWL and also reverting the PR [#133504](https://github.com/odoo/odoo/pull/133504). After this commit, the event attendees can perform attendee removals normally because we check inside the compute if it the current attendee was indeed an attendee right before the change is completed. task-
Original PR description
Before this commit, the attendees were not allowed to remove anyone from the event (including themselves) when editing the event in the form view. This was a problem that came after updating the views to OWL and also reverting the PR [#133504](https://github.com/odoo/odoo/pull/133504). After this commit, the event attendees can perform attendee removals normally because we check inside the compute if it the current attendee was indeed an attendee right before the change is completed. task-3948322 Forward-Port-Of: odoo/odoo#166696
A fix's term was changing during the fw-port, but it's pot file was not re-exported to match. Therefore, re-export so that it translates properly. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167809 Forward-Port-Of: odoo/odoo#167745
Original PR description
A fix's term was changing during the fw-port, but it's pot file was not re-exported to match. Therefore, re-export so that it translates properly. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167809 Forward-Port-Of: odoo/odoo#167745
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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 Forward-Port-Of: odoo/odoo#144139
Original PR description
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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 Forward-Port-Of: odoo/odoo#144139
Steps to reproduce: - Install Sales and Loyalty modules - Create a discount & loyalty program with type of 'Buy X get Y' and a reward product that has a quantity on-hand - Archive the discount & loyalty program - Check the quantity of the product you put as reward Current behavior before PR: The reward product lose its quantity when archiving the corresponding discount & loyalty program. This is happening because when archiving the program we archive the reward product too. https://
Original PR description
Steps to reproduce: - Install Sales and Loyalty modules - Create a discount & loyalty program with type of 'Buy X get Y' and a reward product that has a quantity on-hand - Archive the discount & loyalty program - Check the quantity of the product you put as reward Current behavior before PR: The reward product lose its quantity when archiving the corresponding discount & loyalty program. This is happening because when archiving the program we archive the reward product too. https://github.com/odoo/odoo/blob/17.0/addons/loyalty/models/loyalty_reward.py#L239 Desired behavior after PR is merged: We are now archiving just the free product that got created when we were creating the discount & loyalty program not the main product. This is happening only when the reward type is 'Product' opw-3909184 Forward-Port-Of: odoo/odoo#165225
## Issue: When creating an activity linked to a record like a lead, if we edit this activity, for example from To-Do to Meeting, we lose the context from the Lead and have a bad context based on the activity instead, resulting in an improper link in the calendar. ## Steps to reproduce: 1. Install CRM (this will also install the rest of the required modules). 2. Create or use an existing Lead. 3. Create a new To-Do activity. 4. Click on edit for this activity and change it to Meeting. 5
Original PR description
## Issue: When creating an activity linked to a record like a lead, if we edit this activity, for example from To-Do to Meeting, we lose the context from the Lead and have a bad context based on the…
## Issue: When creating an activity linked to a record like a lead, if we edit this activity, for example from To-Do to Meeting, we lose the context from the Lead and have a bad context based on the activity instead, resulting in an improper link in the calendar. ## Steps to reproduce: 1. Install CRM (this will also install the rest of the required modules). 2. Create or use an existing Lead. 3. Create a new To-Do activity. 4. Click on edit for this activity and change it to Meeting. 5. Now click on Open Calendar and place the activity. 6. Click on the calendar event we have just created, and we will see a link to "Activity". Click on it. ## Solution: To ensure the proper link to the Lead/Opportunity, we need to pass the right context when editing the activity. This issue arose from changes made in `activity_service.js` and the addition of the model `mail.activity.schedule`, which separates the edit and create functions, unlike the behavior we had in 16.0. opw-3942711 Before  After  Forward-Port-Of: odoo/odoo#167996
Steps to reproduce: - In Website edit mode. - Drag and drop a "Form" snippet onto the page. - Add a multi checkboxes field to the form. - Edit the text of a checkboxes input. - click on the toggle button next to this input. - Bug: the button remains disabled. (next click is ok) This bug occurs because when we search for the checkbox that should be selected in the "values" variable (in the "_notifyCurrentState()" function of the "we-list" widget), we search for it based on its ID in
Original PR description
Steps to reproduce: - In Website edit mode. - Drag and drop a "Form" snippet onto the page. - Add a multi checkboxes field to the form. - Edit the text of a checkboxes input. - click on the toggle button next to this input. - Bug: the button remains disabled. (next click is ok) This bug occurs because when we search for the checkbox that should be selected in the "values" variable (in the "_notifyCurrentState()" function of the "we-list" widget), we search for it based on its ID in the DOM. However, on the first click on the toggle, the ID has not yet been defined in the DOM according to the "values" variable. task-3901472 Forward-Port-Of: odoo/odoo#167842 Forward-Port-Of: odoo/odoo#165264
Before this commit, an error occurred in the following scenario: - Open Point of Sale and sell a product with lot tracking - Close/Post the Point of Sale session - Open the product record and disable tracking in the inventory tab - Start a new session, click on Orders and sort for Paid orders opw-3921893 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166915
Original PR description
Before this commit, an error occurred in the following scenario: - Open Point of Sale and sell a product with lot tracking - Close/Post the Point of Sale session - Open the product record and disable tracking in the inventory tab - Start a new session, click on Orders and sort for Paid orders opw-3921893 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166915
This commit addresses the issue where the Product Configurator Popup was displayed unnecessarily when there was only one value for each attribute of a product. The implementation now includes a check to ensure that the popup is shown only when there are more that one choices available. This enhancement improves the user experience by avoiding the display of a redundant popup without viable options. opw-3903425 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/
Original PR description
This commit addresses the issue where the Product Configurator Popup was displayed unnecessarily when there was only one value for each attribute of a product. The implementation now includes a check to ensure that the popup is shown only when there are more that one choices available. This enhancement improves the user experience by avoiding the display of a redundant popup without viable options. opw-3903425 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#164384
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 Forward-Port-Of: odoo/odoo#164643
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 Forward-Port-Of: odoo/odoo#164643
Before this commit, loading an attribute value with an image would cause a TypeError due to the image data being of bytes type, which is not JSON serializable. This commit prevents this error by removing the image data before serialization. opw-3957587 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167765
Original PR description
Before this commit, loading an attribute value with an image would cause a TypeError due to the image data being of bytes type, which is not JSON serializable. This commit prevents this error by removing the image data before serialization. opw-3957587 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167765
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 Forward-Port-Of: odoo/odoo#164514
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 Forward-Port-Of: odoo/odoo#164514
- Remove the zero-rated tax from non-taxable tags as it is incorrectly applied, and instead, add it to items tagged with GST. - task - 3957555 Forward-Port-Of: odoo/odoo#167754
Original PR description
- Remove the zero-rated tax from non-taxable tags as it is incorrectly applied, and instead, add it to items tagged with GST. - task - 3957555 Forward-Port-Of: odoo/odoo#167754
task-3597205 Forward-Port-Of: odoo/odoo#159477
Original PR description
task-3597205 Forward-Port-Of: odoo/odoo#159477
In this PR fixes following bugs: - Subtasks don't set by-default to the configured stage. users have to manually set it after saving. - Expected: stages by default set upon creation. - the task name goes empty after selecting a project, even if you rewrite it and switch projects. This only happens in the Quick Add feature in the kanban view after enabling timesheets in the project settings. task-3706741 Description of the issue/feature this PR addresses: Current behavior b
Original PR description
In this PR fixes following bugs: - Subtasks don't set by-default to the configured stage. users have to manually set it after saving. - Expected: stages by default set upon creation. - the task name goes empty after selecting a project, even if you rewrite it and switch projects. This only happens in the Quick Add feature in the kanban view after enabling timesheets in the project settings. task-3706741 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 Forward-Port-Of: odoo/odoo#153607
Since [1] the legends tooltips are misplaced. A similar issue has been fixed for the main tooltips of the graph view. See [2] Since [3] the Chart.js lib has been updated and the event received by hovering the legend is now wrapped in an object. To access the native event we also need to access the `native` key of that object. [1]: https://github.com/odoo/odoo/commit/c8ca9da7bcee2c122a9d6cf8cda89f02823ba42d [2]: https://github.com/odoo/odoo/commit/c1f08c60b7272e5a30951c53b67427e2f205b72
Original PR description
Since [1] the legends tooltips are misplaced. A similar issue has been fixed for the main tooltips of the graph view. See [2] Since [3] the Chart.js lib has been updated and the event received by hovering the legend is now wrapped in an object. To access the native event we also need to access the `native` key of that object. [1]: https://github.com/odoo/odoo/commit/c8ca9da7bcee2c122a9d6cf8cda89f02823ba42d [2]: https://github.com/odoo/odoo/commit/c1f08c60b7272e5a30951c53b67427e2f205b722 [3]: https://github.com/odoo/odoo/commit/7e3c1ecdb86110912b15722e600f9571692807ed Forward-Port-Of: odoo/odoo#167971
**Description of the issue/feature this PR addresses:** fine tuning of https://github.com/odoo/odoo/commit/f8182fb625eb3e20c85388d4c342553af4fe7ab9 to prevent an olverload of postgres. @thle-odoo @sofiagvaladze I have update the commit. I use 'inselect' to reduce the query size. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167439
Original PR description
**Description of the issue/feature this PR addresses:** fine tuning of https://github.com/odoo/odoo/commit/f8182fb625eb3e20c85388d4c342553af4fe7ab9 to prevent an olverload of postgres. @thle-odoo @sofiagvaladze I have update the commit. I use 'inselect' to reduce the query size. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167439
Add a background image for the iot homepage 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 Forward-Port-Of: odoo/odoo#167010
Original PR description
Add a background image for the iot homepage 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 Forward-Port-Of: odoo/odoo#167010
Description of the issue this commit addresses: When creating an invoice line with the analytic module installed, if the analytic field is show, focusing in on a line adds a little height offset to the entire line which makes the view shaky. This is not wanted. --- Steps to reproduce: 1 - Install analytic app 2 - Open a new invoice and display the analytic field in the invoice lines 3 - Add a new line, don't add any data inside it. 4 - Focus out, focus in, focus out, focus in. 5
Original PR description
Description of the issue this commit addresses: When creating an invoice line with the analytic module installed, if the analytic field is show, focusing in on a line adds a little height offset to…
Description of the issue this commit addresses: When creating an invoice line with the analytic module installed, if the analytic field is show, focusing in on a line adds a little height offset to the entire line which makes the view shaky. This is not wanted. --- Steps to reproduce: 1 - Install analytic app 2 - Open a new invoice and display the analytic field in the invoice lines 3 - Add a new line, don't add any data inside it. 4 - Focus out, focus in, focus out, focus in. 5 - You can see that focus in adds a few px and focus out removes them. --- Desired behavior after this commit is merged: This commit adds a fixed default height to the analyti widget to make sure there is no weird height computation when the focus happens. This way, we can make sure that the line height stays constant whether the focus is in or out of the line. --- no task-feedback --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167723
Purpose ======= Fix the session chart labels which were disappearing when zooming on the chart. Specification ============= When zooming, the chart x axis ticks were skipped / hidden leading to the labels disappearance. Fixing the issue by preventing the x axis ticks from being skipped. Task-3918382 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167914 Forward-Port-Of: odoo/odoo#166462
Original PR description
Purpose ======= Fix the session chart labels which were disappearing when zooming on the chart. Specification ============= When zooming, the chart x axis ticks were skipped / hidden leading to the labels disappearance. Fixing the issue by preventing the x axis ticks from being skipped. Task-3918382 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167914 Forward-Port-Of: odoo/odoo#166462
Purpose ======= Fix the tooltip header color which wasn't reactive to the theme color (light vs dark theme). The header text is black instead of white in light theme and is thus not visible on the tooltip black background. Specification ============= Overwritting the h5 color style that is set to a dark color by the basic bootstrap style. The border-bottom isn't visible in the dark theme because of the tooltip border color style. This border style is applied to the external border
Original PR description
Purpose ======= Fix the tooltip header color which wasn't reactive to the theme color (light vs dark theme). The header text is black instead of white in light theme and is thus not visible on the tooltip black background. Specification ============= Overwritting the h5 color style that is set to a dark color by the basic bootstrap style. The border-bottom isn't visible in the dark theme because of the tooltip border color style. This border style is applied to the external borders of the tooltip and thus shoudln't be changed. Replacing the border-bottom class by a hr tag as it is more adequate for a divider and its color is independant from the tooltip basic border color. Task-3956309 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167833 Forward-Port-Of: odoo/odoo#167174
When setting `l10n_it_has_tax_representative` to False, the field `l10n_it_tax_representative_partner_id` stays set, this leads to inconsistencies when generating the xml on e-invoicing. Steps: - Install l10n_it_edi - Go to the form view of the italian company - On E-invoicing tab, check the `l10n_it_has_tax_representative` field, set `l10n_it_tax_representative_partner` and save - Create and confirm an invoice - Check the xml that has been generated, there is a field `RappresentanteFiscal
Original PR description
When setting `l10n_it_has_tax_representative` to False, the field `l10n_it_tax_representative_partner_id` stays set, this leads to inconsistencies when generating the xml on e-invoicing. Steps: - Install l10n_it_edi - Go to the form view of the italian company - On E-invoicing tab, check the `l10n_it_has_tax_representative` field, set `l10n_it_tax_representative_partner` and save - Create and confirm an invoice - Check the xml that has been generated, there is a field `RappresentanteFiscale` with `l10n_it_tax_representative_partner` infos - Go back to company form view, uncheck the `l10n_it_has_tax_representative` field and save - Create and confirm an other invoice - Check the xml generated -> The field `RappresentanteFiscale` is still there, it should not be. Fix: Add a compute to `l10n_it_tax_representative_partner` to set it to False when unchecking `l10n_it_has_tax_representative` opw-3947519 Forward-Port-Of: odoo/odoo#167825 Forward-Port-Of: odoo/odoo#166732
In this Pr, the driver or the future driver of the car is in sync with the partner of the employee Task-3693838 Forward-Port-Of: odoo/odoo#157057
Original PR description
In this Pr, the driver or the future driver of the car is in sync with the partner of the employee Task-3693838 Forward-Port-Of: odoo/odoo#157057
opw-3954458 Forward-Port-Of: odoo/odoo#167078
Original PR description
opw-3954458 Forward-Port-Of: odoo/odoo#167078
Issue: ------ In the input of a float factor field, it is not possible to use the ‘,’ as a decimal point, even if this is defined in the localization. This is because the value is calculated via: ```js let factorValue = value / this.props.factor; ``` does not work with `value = ‘x,y’` and will return `NaN`. Solution: --------- Parser the value by calling super to fallback on `parseFloat` which takes localization into account. opw-3932813 Forward-Port-Of: odoo/odoo#166822
Original PR description
Issue: ------ In the input of a float factor field, it is not possible to use the ‘,’ as a decimal point, even if this is defined in the localization. This is because the value is calculated via: ```js let factorValue = value / this.props.factor; ``` does not work with `value = ‘x,y’` and will return `NaN`. Solution: --------- Parser the value by calling super to fallback on `parseFloat` which takes localization into account. opw-3932813 Forward-Port-Of: odoo/odoo#166822
Inspired by 8eba16db6fdf26b5a1e0a10d7f03863eb0d40632 Forward-Port-Of: odoo/odoo#167827 Forward-Port-Of: odoo/odoo#166959
Original PR description
Inspired by 8eba16db6fdf26b5a1e0a10d7f03863eb0d40632 Forward-Port-Of: odoo/odoo#167827 Forward-Port-Of: odoo/odoo#166959
Issue: ====== list doesn't appear in quick edit of html_field Steps to reproduce the issue: ============================= - Go to any sale order - Send by email - Add a list inside the email - It doesn't appear Origin of the issue: ==================== Most of the templates have hardcoded `padding = 0px`, so when we convert a `p` element to a `ul` or `ol` element it will have have the same styling and we loose the default padding for the list elements. Solution: ========= We
Original PR description
Issue: ====== list doesn't appear in quick edit of html_field Steps to reproduce the issue: ============================= - Go to any sale order - Send by email - Add a list inside the email - It doesn't appear Origin of the issue: ==================== Most of the templates have hardcoded `padding = 0px`, so when we convert a `p` element to a `ul` or `ol` element it will have have the same styling and we loose the default padding for the list elements. Solution: ========= We set the padding as null to remove any forced padding used. opw-3900433 Forward-Port-Of: odoo/odoo#165773
Before this commit, when receiving a chatter notification, clicking on notification opens chat window to the oldest message. This happens because the default scroll top for all chatter threads was 0, taking into account that a chatter thread in form view is in DESC mode (i.e. messages are ordered from top to bottom, from newest to oldest). However, chatter in chat window is displayed in ASC mode like channels (i.e. messages are ordered from top to bottom, from oldest to newest). Scrolltop
Original PR description
Before this commit, when receiving a chatter notification, clicking on notification opens chat window to the oldest message. This happens because the default scroll top for all chatter threads was 0,…
Before this commit, when receiving a chatter notification, clicking on notification opens chat window to the oldest message. This happens because the default scroll top for all chatter threads was 0, taking into account that a chatter thread in form view is in DESC mode (i.e. messages are ordered from top to bottom, from newest to oldest). However, chatter in chat window is displayed in ASC mode like channels (i.e. messages are ordered from top to bottom, from oldest to newest). Scrolltop 0 means newest in chatter form view, but this becomes oldest in chat window with ASC order. This commit fixes the issue by normalizing the storing of thread scroll positions to ASC, so that default value is "bottom" regardless of order to display. in ASC, this is handled like before, but in DESC mode it translates "bottom" to 0. opw-3891999 Before  After  Forward-Port-Of: odoo/odoo#167760
Description of the issue/feature this PR addresses: Livechat is set up with a Chatbot with a fallback to an operator. When a visitor visits a website with the Livechat and the visitor is not connected to an account, when falling back to the operator, an error occurs : `AttributeError: 'discuss.channel' object has no attribute 'livechat_visitor_id'` Current behavior before PR: When a visitor visits a website with the Livechat and the visitor is not connected to an account, when falling bac
Original PR description
Description of the issue/feature this PR addresses: Livechat is set up with a Chatbot with a fallback to an operator. When a visitor visits a website with the Livechat and the visitor is not connected to an account, when falling back to the operator, an error occurs : `AttributeError: 'discuss.channel' object has no attribute 'livechat_visitor_id'` Current behavior before PR: When a visitor visits a website with the Livechat and the visitor is not connected to an account, when falling back to the operator, an error occurs : `AttributeError: 'discuss.channel' object has no attribute 'livechat_visitor_id'` Desired behavior after PR is merged: The chatbot falls back to the human operator. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167710
For +100 on 5v: 160100 VAT credit For -100 on 4v: 260100 VAT debt task-3940102 opw-3938527 Forward-Port-Of: odoo/odoo#167731
Original PR description
For +100 on 5v: 160100 VAT credit For -100 on 4v: 260100 VAT debt task-3940102 opw-3938527 Forward-Port-Of: odoo/odoo#167731
Steps to reproduce [17.0]: - Go to website (in "Edit" mode) > Click on the "Contact Us" button - Save the page > The menu will be saved with the "oe_edited_link" class applied to it. Technical explanation (one of many scenarios causing the bug) [1]: After the website headers redesign in [2], two header navbars were added (for the desktop view and mobile). Which means that the "Contact Us" field is duplicated in the DOM. When clicking on the "Contact Us" desktop link, the `LinkPop
Original PR description
Steps to reproduce [17.0]: - Go to website (in "Edit" mode) > Click on the "Contact Us" button - Save the page > The menu will be saved with the "oe_edited_link" class applied to it. Technical…
Steps to reproduce [17.0]: - Go to website (in "Edit" mode) > Click on the "Contact Us" button - Save the page > The menu will be saved with the "oe_edited_link" class applied to it. Technical explanation (one of many scenarios causing the bug) [1]: After the website headers redesign in [2], two header navbars were added (for the desktop view and mobile). Which means that the "Contact Us" field is duplicated in the DOM. When clicking on the "Contact Us" desktop link, the `LinkPopoverWidget` will initialize a popover on it. The bootstrap code is automatically adding `data-original-title` and 'title' attributes to the targeted link (see: [3]), and as a consequence, the field observer will take in consideration the mutations and copy the DOM in the mobile version, leading to save the link in the same state when the BS popover was applied to it (with the `oe_edited_link` class). Remarks: - This behaviour was detected on 17.0, but we target 15.0 here to prevent similar issues linked to duplicated fields with links in the DOM. - The bootstrap attributes mutations (as explained in [1]) are just an example of many possible mutations (filtered by `observerUnactive()` in the main editor observer) that can cause the issue... Since we cannot set filters for all these mutations in the fields' observer, we ignore the `oe_edited_link` (and all editor's rendering classes) when copying the field content to solve the issue here. The field observer logic needs to be refactored to probably disable / enable the fields' synchronization when the editor's observer is disabled / enabled. [2]: https://github.com/odoo/odoo/pull/119650 [3]: https://github.com/odoo/odoo/blob/15.0/addons/web/static/lib/bootstrap/js/tooltip.js#L664 opw-3938383 Forward-Port-Of: odoo/odoo#167619 Forward-Port-Of: odoo/odoo#166736
Create a branch company [TEST] With [TEST] selected crete a new expense Issue: Taxes from parent company cannot be selected This occurs because we limit the domain to taxes of the current company, without considering the parent opw-3939722 Forward-Port-Of: odoo/odoo#167572
Original PR description
Create a branch company [TEST] With [TEST] selected crete a new expense Issue: Taxes from parent company cannot be selected This occurs because we limit the domain to taxes of the current company, without considering the parent opw-3939722 Forward-Port-Of: odoo/odoo#167572
The main purpose of this patch is to optimize how the location queries are generated in saas-17.2 in `stock.orderpoint`: https://github.com/odoo/odoo/blob/dd2da708bc4a42bba9670b874282a2206d8f5ffe/addons/stock/models/stock_orderpoint.py#L366-L374 The generated query is the same in 17.0. The advantage of the `any` operator is clarity and simplicity in this case. In saas-17.2 due to the presence of another branch using `location_final_id` the generated queries are much more efficient with
Original PR description
The main purpose of this patch is to optimize how the location queries are generated in saas-17.2 in `stock.orderpoint`:…
The main purpose of this patch is to optimize how the location queries
are generated in saas-17.2 in `stock.orderpoint`:
https://github.com/odoo/odoo/blob/dd2da708bc4a42bba9670b874282a2206d8f5ffe/addons/stock/models/stock_orderpoint.py#L366-L374
The generated query is the same in 17.0. The advantage of the `any` operator is
clarity and simplicity in this case.
In saas-17.2 due to the presence of another branch using
`location_final_id` the generated queries are much more efficient with
```py
dest_loc_domain = [
'|',
'&', ('location_final_id', '!=', False), ('location_final_id', 'any', paths_domain),
'&', ('location_final_id', '=', False), ('location_dest_id', 'any', paths_domain),
]
```
vs (current code in saas-17.2)
```py
dest_loc_domain = expression.OR([dest_loc_domain, [
'|',
'&', ('location_final_id', '!=', False), ('location_final_id.parent_path', '=like', location.parent_path + '%'),
'&', ('location_final_id', '=', False), ('location_dest_id.parent_path', '=like', location.parent_path + '%'),
]])
```
https://github.com/odoo/odoo/blob/88e75bb11053e3a16455f7d0e882cf2afd4b79a6/addons/stock/models/product.py#L311-L317
The version using the `any` operator is much faster: in an extreme case
with 6K replenish locations the any-based query runs in 1m50s while the
other runs in more than 3h.
In effect this is an example query generated by the ORM without the use
of `any` (3 replenish locations)
```sql
SELECT
"stock_move"."product_id",
"stock_move"."location_id",
SUM("stock_move"."product_qty")
FROM
"stock_move"
LEFT JOIN "stock_location" AS "stock_move__location_id" ON ("stock_move"."location_id" = "stock_move__location_id"."id")
LEFT JOIN "stock_location" AS "stock_move__location_final_id" ON ("stock_m ove"."location_final_id" = "stock_move__location_final_id"."id")
WHERE
(
(
(
(
(
(
(
(
(
"stock_move"."product_id" IN (16, 17, 18, 20, 21, 23, 24, 12, 13, 14, 25, 30, 26, 37, 31, 5, 8, 29, 32, 6, 28)
)
AND (
"stock_move"."state" IN ('waiting', 'confirmed', 'assigned', 'partially_available')
)
)
AND (
"stock_move"."location_final_id" IS NULL
OR (
"stock_move__location_final_id"."id" IS NULL
OR (
NOT (
(
"stock_move__location_final_id"."parent_path" :: text LIKE '1/7/8/18/%'
)
)
)
)
)
)
AND (
"stock_move"."location _final_id" IS NOT NULL
OR (
(
"stock_move"."location_dest_id" NOT IN (
SELECT
"stock_location"."id"
FROM
"stock_location"
WHERE
("stock_location"."parent_path" :: text LIKE '1/7/8/18/%')
AND (( "stock_location"."company _id" IN (1))
OR "stock_location"."company_id" IS NULL
)
)
)
OR "stock_move"."location_dest_id" IS NULL
)
)
)
AND (
"stock_move"."location_final_id" IS NULL
OR (
"stock_move__location_final_id"."id" IS NULL
OR (NOT (("stock_move__location_final_id"."parent_path" :: text LIKE '1/7/8/17/%')))
)
)
)
AND (
"stock_move"."location_final_id" IS NOT NULL
OR (
(
"stock_move"."location_dest_id" NOT IN (
SELECT
"stock_location"."id"
FROM
"stock_locati on"
WHERE
("stock_location"."parent_path" :: text LIKE '1/7/8/17/%')
AND (("stock_location"."company_id" IN (1))
OR "stock_location"."company_id" IS NULL
)
)
)
OR "stock_move"."location_dest_id" IS NULL
)
)
)
AND (
"stock_ move"."location_final_id" IS NULL
OR (
"stock_move__location_final_id"."id" IS NULL
OR (
NOT (( "stock_move__location_final_id"."parent_path" :: text LIKE '1/7/8/34/%')
)
)
)
)
)
AND (
"stock_move"."location_final_id" IS NOT NULL
OR (
(
"stock_move"."location_dest_id" NOT IN (
SELECT
"stock_location"."id"
FROM
"stock_location"
WHERE
("stock_location"."parent_path" :: text LIKE '1/7/8/34/%')
AND (
("stock_location"."company_id" IN (1))
OR " stock_location"."company_id" IS NULL
)
)
)
OR "stock_move"."location_dest_id" IS NULL
)
)
)
AND (
(
("stock_move__location_id"."parent_path" :: text LIKE '1/7/8/18/%')
OR ("stock_move__location_id"."parent_path" :: text LIKE '1/7/8/17/%')
)
OR ("stock_move__location_id"."parent_path" :: text LIKE '1/7/8/34/%')
)
)
AND (
"stock_move"."company_id" IN (1)
)
GROUP BY
"stock_move"."product_id",
"stock_move"."location_id"
ORDER BY
"stock_move"."product_id" ASC,
"stock_move"."location_id" ASC
```
vs the query using `any` variant:
```sql
SELECT
"stock_move"."product_id",
"stock_move"."location_id",
sum("stock_move"."product_qty")
FROM
"stock_move"
LEFT JOIN "stock_location" AS "stock_move__location_id" ON ("stock_move"."location_id" = "stock_move__location_id"."id")
LEFT JOIN "stock_location" AS "stock_move__location_final_id" ON ("stock_m ove"."location_final_id" = "stock_move__location_final_id"."id")
WHERE
(
(
(
(
(
"stock_move"."product_id" IN (16, 17, 18, 20, 21, 23, 24, 12, 13, 14, 25, 30, 26, 37, 31, 5, 8, 29, 32, 6, 28)
)
AND (
"stock_move"."state" IN ('waiting', 'confirmed', 'assigned', 'partially_available')
)
)
AND (
"stock_move"."location_final_id" IS NULL
OR (
"stock_move__location_final_id"."id" IS NULL
OR (
NOT (
(
(
("stock_move__location_final_id"."parent_path" :: text LIKE '1/7/8/18/%')
OR ("stock_move__location_final_id "."parent_path" :: text LIKE '1/7/8/17/%')
)
OR ("stock_move__location_final_id"."parent_path" :: text LIKE '1/7/8/34/%')
)
)
)
)
)
)
AND (
"stock_move"."location_final_id" IS NOT NULL
OR (
(
"stock_move"."location_dest_id" NOT IN (
SELECT
"stock_location"."id"
FROM
"stock_location"
WHERE
(
(
("stock_location"."parent_path" :: text LIKE '1/7/8/18/%')
OR ("stock_location"."parent_path" :: text LIKE '1/7/8/17/%')
)
OR ("stock_location"."parent_pa th" :: text LIKE '1/7/8/34/%')
)
AND (
("stock_location"."company_id" IN (1))
OR "stock_location"."company_id" IS NULL
)
)
)
OR "stock_move"."location_dest_id" IS NULL
)
)
)
AND (
(
("stock_move__location_id"."parent_path" :: text LIKE '1/7/8/18/%')
OR ("stock_move__location_id"."parent_path" :: text LIKE '1/7/8/17/%')
)
OR ("stock_move__location_id"."parent_path" :: text LIKE '1/7/8/34/%')
)
)
AND (
"stock_move"."company_id" IN (1)
)
GROUP BY
"stock_move"."product_id",
"stock_move"."location_id"
ORDER BY
"stock_move"."product_id" ASC,
"stock_move"."location_id" ASC
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#167553Current Behaviour: - Currently, if the internet is slow and the user tries to open any action, which action target='new,' it takes time to open the action form in the browser, if the user clicks multiple times during this loading process, multiple instances of the same action will be displayed to the user. Steps to produce: - Open CRM and navigate to the activity view of CRM. - Select throttling as 'Slow 3G' in your browser network setting. - Now click multiple times on any scheduled act
Original PR description
Current Behaviour: - Currently, if the internet is slow and the user tries to open any action, which action target='new,' it takes time to open the action form in the browser, if the user clicks multiple times during this loading process, multiple instances of the same action will be displayed to the user. Steps to produce: - Open CRM and navigate to the activity view of CRM. - Select throttling as 'Slow 3G' in your browser network setting. - Now click multiple times on any scheduled activity to open an action. Expected Behaviour: - Only open the dialog for the last action requested when there are multiple actions requested with target='new'. Task-3750720 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166157 Forward-Port-Of: odoo/odoo#159236
This commit fixes the issue where a traceback is shown when an order will be invoiced after paying with an online payment. Steps to reproduce: - Setup online payment and link to the pos.config. - Open a session. - Create an order that will be invoiced and pay with the online payment method. - Traceback during the download of the invoice. Forward-Port-Of: odoo/odoo#164315
Original PR description
This commit fixes the issue where a traceback is shown when an order will be invoiced after paying with an online payment. Steps to reproduce: - Setup online payment and link to the pos.config. - Open a session. - Create an order that will be invoiced and pay with the online payment method. - Traceback during the download of the invoice. Forward-Port-Of: odoo/odoo#164315
Removed a work location column in the employee list view that is not relevant when the homeworking module is installed. Task-3933447 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166020
Original PR description
Removed a work location column in the employee list view that is not relevant when the homeworking module is installed. Task-3933447 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166020
Ubuntu Noble (24.04) now provides [python3-websocket 1.7.0](https://packages.ubuntu.com/noble/python3-websocket). The websocket rate limiting tests asserts that an exception occurs when the code 1013 is returned because this code was not supported in [python3-websocket 1.2.3](https://packages.ubuntu.com/jammy/python3-websocket) provided by Ubuntu Jammy (22.04). Support was added in [websocket 1.3.0](https://github.com/websocket-client/websocket-client/commit/a28a016584f82cfca30a09a59ecd764569
Original PR description
Ubuntu Noble (24.04) now provides [python3-websocket 1.7.0](https://packages.ubuntu.com/noble/python3-websocket). The websocket rate limiting tests asserts that an exception occurs when the code 1013 is returned because this code was not supported in [python3-websocket 1.2.3](https://packages.ubuntu.com/jammy/python3-websocket) provided by Ubuntu Jammy (22.04). Support was added in [websocket 1.3.0](https://github.com/websocket-client/websocket-client/commit/a28a016584f82cfca30a09a59ecd764569c2fa3f) With this commit, presence of the status code in the lib is verified and the test is adapted accordingly. Forward-Port-Of: odoo/odoo#166899
see also: https://github.com/odoo/enterprise/pull/63708 Forward-Port-Of: odoo/odoo#167738
Original PR description
see also: https://github.com/odoo/enterprise/pull/63708 Forward-Port-Of: odoo/odoo#167738
Tour 'shop_buy_product' checks the correctness of manipulating products and their quantities in the cart and the payment step of the order. With the additional check on the payment step introduced by commit 023d549 the tour was failing due to the relatively late rpc request handling compared to immediate clicks of the tour. `shop/payment` page was rendered faster than the update cart rpc (`shop/cart/update_json`) was processed. Cart update resets the delivery method on the order causing t
Original PR description
Tour 'shop_buy_product' checks the correctness of manipulating products and their quantities in the cart and the payment step of the order. With the additional check on the payment step introduced by commit 023d549 the tour was failing due to the relatively late rpc request handling compared to immediate clicks of the tour. `shop/payment` page was rendered faster than the update cart rpc (`shop/cart/update_json`) was processed. Cart update resets the delivery method on the order causing the validation error. That is why the tour is split in 2 separate functional parts. Forward-Port-Of: odoo/odoo#166670
Steps to reproduce: - Install Time off module - Create a public holiday with Working Hours 'calendar_id' - Go to env user Time off dashboard Current behavior before PR: The public holidays that has 'calendar_id' assigned to it will not be shown in Legend when checking the dashboard of the env user. This is happening because we assign the self 'hr.employee' with the employee_id in context https://github.com/odoo/odoo/blob/c6142d9f1432cfabedcaa7264af9e5bc8e538c20/addons/hr_holidays/model
Original PR description
Steps to reproduce: - Install Time off module - Create a public holiday with Working Hours 'calendar_id' - Go to env user Time off dashboard Current behavior before PR: The public holidays that has…
Steps to reproduce:
- Install Time off module
- Create a public holiday with Working Hours 'calendar_id'
- Go to env user Time off dashboard
Current behavior before PR:
The public holidays that has 'calendar_id' assigned to it will not be shown in Legend when checking the dashboard of the env user. This is happening because we assign the self 'hr.employee' with the employee_id in context https://github.com/odoo/odoo/blob/c6142d9f1432cfabedcaa7264af9e5bc8e538c20/addons/hr_holidays/models/hr_employee.py#L313 and in '_get_contextual_employee' we just check if employee_id exists in ctx or not
https://github.com/odoo/odoo/blob/17.0/addons/hr_holidays/models/hr_employee.py#L388:L392
but we don't check the value so if ctx is like {'employee_id': None} it will return None.
Desired behavior after PR is merged:
We are now checking if the 'employee_id' in ctx
has a valid value as if it is not we need to return the employee object of the env user.
Other solution that we can add in this line https://github.com/odoo/odoo/blob/c6142d9f1432cfabedcaa7264af9e5bc8e538c20/addons/hr_holidays/models/hr_employee.py#L313 to check if the self._get_contetxtual_employee is None we assign self to self.env.user.employee_id
opw-3863947
Forward-Port-Of: odoo/odoo#166548Steps: - Install sale and editor apps. - Click on varient new button. - Add something in the description. - Discard that record. Issue: - Traceback component destroyed. Cause: - `commit_changes` does not had await on it and because of that it was performing other operations before actually commit changes and we are actully destroying record in `commit_changes` so there is no point doing other operations. Fix: - Add await and remove urgent from `commit_changes` method in-order t
Original PR description
Steps: - Install sale and editor apps. - Click on varient new button. - Add something in the description. - Discard that record. Issue: - Traceback component destroyed. Cause: - `commit_changes` does not had await on it and because of that it was performing other operations before actually commit changes and we are actully destroying record in `commit_changes` so there is no point doing other operations. Fix: - Add await and remove urgent from `commit_changes` method in-order to properly unmount component. opw-3892602 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 Forward-Port-Of: odoo/odoo#164151
This commit updates the logic to enable the modification of quantities for combo products in the cart. Task ID: 3872513 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166695
Original PR description
This commit updates the logic to enable the modification of quantities for combo products in the cart. Task ID: 3872513 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166695
Description of the issue/feature this PR addresses: Before this fix, It was not possible to issue a credit note code 61 to be applied to an invoice of type '46' when the vendor was foreign. Typically, credit notes for foreign vendors are code 112; however, code 61 is necessary to reverse a type 46 invoice. After this PR: In the validation included in this PR, we allow this credit note type 61, provided there is a reference to a code '46' invoice, included in the document reference model.
Original PR description
Description of the issue/feature this PR addresses: Before this fix, It was not possible to issue a credit note code 61 to be applied to an invoice of type '46' when the vendor was foreign. Typically, credit notes for foreign vendors are code 112; however, code 61 is necessary to reverse a type 46 invoice. After this PR: In the validation included in this PR, we allow this credit note type 61, provided there is a reference to a code '46' invoice, included in the document reference model. This PR corresponds to the odoo/enterprise PR enabling the issuance of type 46 invoices referenced below: this PR replaces: https://github.com/odoo/odoo/pull/166400 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166793
Steps to reproduce: 1. Install the planning module and open it. 2. Open events in calendar view. 3. Click on any event. 4. In the calendar popover, observe the spacing around the percentage (%). Issue: There is inconsistency in spacing around the percentage (%). Solution: Add a space before the percentage and remove the space after it in the common calendar popover. task-3908815 Forward-Port-Of: odoo/enterprise#62083
Original PR description
Steps to reproduce: 1. Install the planning module and open it. 2. Open events in calendar view. 3. Click on any event. 4. In the calendar popover, observe the spacing around the percentage (%). Issue: There is inconsistency in spacing around the percentage (%). Solution: Add a space before the percentage and remove the space after it in the common calendar popover. task-3908815 Forward-Port-Of: odoo/enterprise#62083
Before, if a bank transaction contain the sale order reference, the reconciliation model will try to reconcile with the invoices created from this sale order but ignore the payment records for those. This leads to situations where it looks like there were two payments on the invoices (one payment record and one bank transaction) while there is just one partial payment. Steps to reproduce: 0/ Have default reconciliation models 1/ Create SO for 100$ and confirm invoice 2/ Partially pay invoi
Original PR description
Before, if a bank transaction contain the sale order reference, the reconciliation model will try to reconcile with the invoices created from this sale order but ignore the payment records for those. This leads to situations where it looks like there were two payments on the invoices (one payment record and one bank transaction) while there is just one partial payment. Steps to reproduce: 0/ Have default reconciliation models 1/ Create SO for 100$ and confirm invoice 2/ Partially pay invoice for 70$ 3/ Create bank transaction with SO ref and same partner for 70$ 4/ Match transaction => will match the 30$ residual of the invoice instead of 70$ payment Now, the system will try to reconcile with the payments of those invoices first before considering invoice reconciliation. opw-3904177 Forward-Port-Of: odoo/enterprise#62972
The aim of this commit is to make the code more robust and defensive by handling a bad value for the `vat` field. Context: Partners having a `partner.vat=False` were making the compact function crash. Before the commit: The flow crash even if the value shouldn't be processed. After the commit: The flow is smooth. task-id: None Forward-Port-Of: odoo/enterprise#63865
Original PR description
The aim of this commit is to make the code more robust and defensive by handling a bad value for the `vat` field. Context: Partners having a `partner.vat=False` were making the compact function crash. Before the commit: The flow crash even if the value shouldn't be processed. After the commit: The flow is smooth. task-id: None Forward-Port-Of: odoo/enterprise#63865
Steps to reproduce: - Go to Accounting > Vendor > Payments. - Create one "Send" payment for 500 USD to Abigail Peterson and confirm. - Create one "Send" payment for 500 EUR to Abigail Peterson and confirm. - Go to Accounting > Vendor > Batch Payments. - Create a new batch payment and add the two payments. - Print the batch payment (either Print button or Action > Print Batch Payment) Issue: The sum amount in company currency is not correct Cause: We do not convert the line amount (
Original PR description
Steps to reproduce: - Go to Accounting > Vendor > Payments. - Create one "Send" payment for 500 USD to Abigail Peterson and confirm. - Create one "Send" payment for 500 EUR to Abigail Peterson and confirm. - Go to Accounting > Vendor > Batch Payments. - Create a new batch payment and add the two payments. - Print the batch payment (either Print button or Action > Print Batch Payment) Issue: The sum amount in company currency is not correct Cause: We do not convert the line amount (and we apparently don't want to use the payment amount for reconciliation) opw-3911484 Forward-Port-Of: odoo/enterprise#63857 Forward-Port-Of: odoo/enterprise#62553
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. Forward-Port-Of: odoo/enterprise#51744
Original PR description
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. Forward-Port-Of: odoo/enterprise#51744
In the Payroll app with a Belgian company, we can do Reporting > Paid Time Off Allocation. This opens a wizard and if we filled the department then the time off type, the app would crash because of a terrible sql query. Also, the query was doing unnecessary subqueries that have been removed. Task: 3878904 Forward-Port-Of: odoo/enterprise#62293
Original PR description
In the Payroll app with a Belgian company, we can do Reporting > Paid Time Off Allocation. This opens a wizard and if we filled the department then the time off type, the app would crash because of a terrible sql query. Also, the query was doing unnecessary subqueries that have been removed. Task: 3878904 Forward-Port-Of: odoo/enterprise#62293
To reproduce: ============= - create a subscription and confirm it - create the invoice for this subscription - create an upsell, add some recurring products with qty > 0 - confirm the upsell, you can see that the parent sub has been updated with the qty coming from Upsell - cancel the upsell afterward -> the parent sub has not been reverted. Problem: ======== When we cancel an upsell, the changes on the parent subscription are not reverted. The message in the chatter is improved to
Original PR description
To reproduce: ============= - create a subscription and confirm it - create the invoice for this subscription - create an upsell, add some recurring products with qty > 0 - confirm the upsell, you can see that the parent sub has been updated with the qty coming from Upsell - cancel the upsell afterward -> the parent sub has not been reverted. Problem: ======== When we cancel an upsell, the changes on the parent subscription are not reverted. The message in the chatter is improved to notify the quantities on the subscription may need to be updated. opw-3269465 Forward-Port-Of: odoo/enterprise#63805 Forward-Port-Of: odoo/enterprise#61678
Before this commit, when sending an invoice to the AFIP and that the result was accepted, it was still possible to reset the invoice the draft which caused discrepancies between the data in Odoo and the data that has already been sent to AFIP. This button to reset to draft is enabled for all users in Accounting. After an invoice is sent and validated, we cannot edit them. task-3955111 Forward-Port-Of: odoo/enterprise#63407
Original PR description
Before this commit, when sending an invoice to the AFIP and that the result was accepted, it was still possible to reset the invoice the draft which caused discrepancies between the data in Odoo and the data that has already been sent to AFIP. This button to reset to draft is enabled for all users in Accounting. After an invoice is sent and validated, we cannot edit them. task-3955111 Forward-Port-Of: odoo/enterprise#63407
In the salary configurator, we use a meal voucher amount by default: 7 .45€/worked day. It should really copy the meal voucher amount from the contract instead. Task: Forward-Port-Of: odoo/enterprise#63797 Forward-Port-Of: odoo/enterprise#61655
Original PR description
In the salary configurator, we use a meal voucher amount by default: 7 .45€/worked day. It should really copy the meal voucher amount from the contract instead. Task: Forward-Port-Of: odoo/enterprise#63797 Forward-Port-Of: odoo/enterprise#61655
Some of the records had their `groupby` set to `account_id` in previous versions That field was removed from the data file and new expressions were added. This means that the records which already have `groupby` set won't get that field updated during an upgrade, and will trigger [an error](https://github.com/odoo/odoo/blob/17.0/addons/account/models/account_report.py#L571-L578). By explicitly removing the value from the field, we ensure the field will be emptied. The change in the data fi
Original PR description
Some of the records had their `groupby` set to `account_id` in previous versions That field was removed from the data file and new expressions were added. This means that the records which already…
Some of the records had their `groupby` set to `account_id` in previous versions That field was removed from the data file and new expressions were added. This means that the records which already have `groupby` set won't get that field updated during an upgrade, and will trigger [an error](https://github.com/odoo/odoo/blob/17.0/addons/account/models/account_report.py#L571-L578). By explicitly removing the value from the field, we ensure the field will be emptied. The change in the data files comes from: https://github.com/odoo/enterprise/pull/52603 ``` odoo.tools.convert.ParseError: while parsing /home/odoo/src/enterprise/17.0/l10n_ro_reports/data/balance_sheet_short.xml:3 Groupby feature isn't supported by aggregation engine. Please remove the groupby value on 'SOLDE C | 43' ``` Note: The original change to the data file happened in saas~16.1. Given that it's not possible to upgrade to intermediate versions any more and there's no issue in standard, the PR targets 17.0. Forward-Port-Of: odoo/enterprise#62421
…on report steps to reproduce: - add new appraisal of employee and confirm it. - add new skills and update existing ones. - check the skill evaluation report issue: A newly created skill doesn't appear in the report since the previous skill level may contain null while creating new records. fix: Apply a left join on the report so that it can provide accurate results. also, add a subquery based on the last completed appraisal, since the last `appraisal_id` is updated on the pending
Original PR description
…on report steps to reproduce: - add new appraisal of employee and confirm it. - add new skills and update existing ones. - check the skill evaluation report issue: A newly created skill doesn't appear in the report since the previous skill level may contain null while creating new records. fix: Apply a left join on the report so that it can provide accurate results. also, add a subquery based on the last completed appraisal, since the last `appraisal_id` is updated on the pending state too. note: `s.skill_level_id != s.previous_skill_level_id` this condition restrict to show newly updated skills in report therefore removed it in forwardport. task-3810220 Forward-Port-Of: odoo/enterprise#60088
Before this commit, when adding an outdated activity from kanban activity widget, it crashed with the following errors: `TypeError: cannot read property of undefined (reading `mail_template_ids`)` `TypeError: Cannot read properties of undefined (reading 'toLocaleString')` Steps to reproduce: - on crm lead schedule call activity and make sure that activity is at least 1 month old - book activity and save it - try to access/edit activity This happens because when the `get_today_call_a
Original PR description
Before this commit, when adding an outdated activity from kanban activity widget, it crashed with the following errors: `TypeError: cannot read property of undefined (reading `mail_template_ids`)` `TypeError: Cannot read properties of undefined (reading 'toLocaleString')` Steps to reproduce: - on crm lead schedule call activity and make sure that activity is at least 1 month old - book activity and save it - try to access/edit activity This happens because when the `get_today_call_activities` function is called. Function fetches fields during the records formatting, but it doesn't fetch `date_deadline` and `mail_template_ids`, therefore those fields remain undefined, hence the errors rise. task-3945492 Forward-Port-Of: odoo/enterprise#63792
task-3597205 Forward-Port-Of: odoo/enterprise#59539
Original PR description
task-3597205 Forward-Port-Of: odoo/enterprise#59539
Versions -------- - 15.0e+ Steps ----- 1. If current UTC time is before 11:00, set user tz to Pacific/Niue; 2. if current UTC time is after 11:00, set user tz to Pacific/Kiritimati; 3. go to Helpdesk; 4. enable timesheets for a helpdesk team; 5. open a ticket of that helpdesk team; 6. start timer; 7. stop timer; 8. create timesheet. Issue ----- The date of the timesheet is set to the UTC date instead of the user date, which is one day off. Cause ----- The wizard creating
Original PR description
Versions -------- - 15.0e+ Steps ----- 1. If current UTC time is before 11:00, set user tz to Pacific/Niue; 2. if current UTC time is after 11:00, set user tz to Pacific/Kiritimati; 3. go to Helpdesk; 4. enable timesheets for a helpdesk team; 5. open a ticket of that helpdesk team; 6. start timer; 7. stop timer; 8. create timesheet. Issue ----- The date of the timesheet is set to the UTC date instead of the user date, which is one day off. Cause ----- The wizard creating timesheets adds a `Datetime.now()` value to `date`, which defaults to UTC time. Solution -------- Remove this line, allowing timesheets to be created with the default value, which does get adjusted for user timezone. opw-3834908 Forward-Port-Of: odoo/enterprise#63693 Forward-Port-Of: odoo/enterprise#63073
users were getting a traceback from the sdk when credentials were incorrect AttributeError: 'Response' object has no attribute '_dom' opw-3873151 Forward-Port-Of: odoo/enterprise#63735 Forward-Port-Of: odoo/enterprise#62049
Original PR description
users were getting a traceback from the sdk when credentials were incorrect AttributeError: 'Response' object has no attribute '_dom' opw-3873151 Forward-Port-Of: odoo/enterprise#63735 Forward-Port-Of: odoo/enterprise#62049
Forward-Port-Of: odoo/enterprise#63716
Original PR description
Forward-Port-Of: odoo/enterprise#63716
- Create a credit note - Add a product as a "Discount" and add the proper information - Process it under the use "devoluciones, descuentos o bonificaciones" (G02) - Check the generated XML Issue: Under description, we report "devolucion de mercancias" which wrong, as the user is not returning anything, they´re only getting a discount. opw-3902858 Forward-Port-Of: odoo/enterprise#63520
Original PR description
- Create a credit note - Add a product as a "Discount" and add the proper information - Process it under the use "devoluciones, descuentos o bonificaciones" (G02) - Check the generated XML Issue: Under description, we report "devolucion de mercancias" which wrong, as the user is not returning anything, they´re only getting a discount. opw-3902858 Forward-Port-Of: odoo/enterprise#63520
Since custom and anytime appointment types aren't visible on website pages, it makes sense to set their is_published field to False by default. The only exception when appointment types should be created with published flag is when it is being done from website page, since creating appointment from there implies their public visibility. task-3944831 Forward-Port-Of: odoo/enterprise#63441
Original PR description
Since custom and anytime appointment types aren't visible on website pages, it makes sense to set their is_published field to False by default. The only exception when appointment types should be created with published flag is when it is being done from website page, since creating appointment from there implies their public visibility. task-3944831 Forward-Port-Of: odoo/enterprise#63441
This will fix the file exported for the eco voucher with Monizze. Task: 3895296 Forward-Port-Of: odoo/enterprise#62189
Original PR description
This will fix the file exported for the eco voucher with Monizze. Task: 3895296 Forward-Port-Of: odoo/enterprise#62189
See also: https://github.com/odoo/odoo/pull/167738 Forward-Port-Of: odoo/enterprise#63708
Original PR description
See also: https://github.com/odoo/odoo/pull/167738 Forward-Port-Of: odoo/enterprise#63708
Before this PR: The 8-column report for the "current year earnings" account type (equity_unaffected) incorrectly included the previous balance. This caused inconsistencies in reports, leading to imbalances between debit/credit and debtor/creditor columns, as well as assets/liabilities. Previously, this issue could be addressed by modifying the include_initial_balance boolean in the "account.user.type" model. However, this boolean is now computed and resides in the "account.account" model, ma
Original PR description
Before this PR: The 8-column report for the "current year earnings" account type (equity_unaffected) incorrectly included the previous balance. This caused inconsistencies in reports, leading to imbalances between debit/credit and debtor/creditor columns, as well as assets/liabilities. Previously, this issue could be addressed by modifying the include_initial_balance boolean in the "account.user.type" model. However, this boolean is now computed and resides in the "account.account" model, making it uneditable. After this PR: This fix ensures the "current year earnings" account reflects only the activity for the current period, excluding the previous balance. This change eliminates the need to rely on the include_initial_balance state for this account, leading to a consistent and accurate 8-column report. Forward-Port-Of: odoo/enterprise#60713
There were translations such as "1. Gross profit/gross loss", which were translated to "1. Annoncering og reklame" That translation does not match and we have therefore identified the ones that were off and updated them Forward-Port-Of: odoo/enterprise#63564
Original PR description
There were translations such as "1. Gross profit/gross loss", which were translated to "1. Annoncering og reklame" That translation does not match and we have therefore identified the ones that were off and updated them Forward-Port-Of: odoo/enterprise#63564
Steps to reproduce: - share a workspace with more than one document and a spreadsheet - open the sharing link,(make sure you are login as internal user) - from the sharing portal page, click on the spreadsheet title to open the spreadsheet => access right error Task: 3897719 Forward-Port-Of: odoo/enterprise#63256
Original PR description
Steps to reproduce: - share a workspace with more than one document and a spreadsheet - open the sharing link,(make sure you are login as internal user) - from the sharing portal page, click on the spreadsheet title to open the spreadsheet => access right error Task: 3897719 Forward-Port-Of: odoo/enterprise#63256
Issue: =============== When a manufacturing order (MO) is created, the default components are automatically reserved and are made visible in the barcode module. However, even if these components are later unreserved, they will continue to be displayed in the barcode module. Resolution: ================ To address this issue, we've taken the step to avoid forcefully re-reserving the components when a component is unreserved. This resolves the persistent display of components in t
Original PR description
Issue: =============== When a manufacturing order (MO) is created, the default components are automatically reserved and are made visible in the barcode module. However, even if these components are…
Issue: =============== When a manufacturing order (MO) is created, the default components are automatically reserved and are made visible in the barcode module. However, even if these components are later unreserved, they will continue to be displayed in the barcode module. Resolution: ================ To address this issue, we've taken the step to avoid forcefully re-reserving the components when a component is unreserved. This resolves the persistent display of components in the barcode. Steps to Reproduce: ====================== 1. Create a manufacturing order (MO) and confirm it. 2. Navigate to the barcode module within the manufacturing order. 3. By default, the components are reserved, so they are visible in the barcode module. 4. Go to the form view of the MO in MRP and unreserve the components. 5. Check the barcode module again, and notice that the unreserved components are still visible. Expected Result: ================== After implementing the solution, When we opens the MO in the barcode module only reserved components should be visible. When a component is unreserved, it should no longer be visible in the barcode module for manufacturing order. task-3869731 Forward-Port-Of: odoo/enterprise#61827
Before this PR: When we included the ability to create "Facturas de compra" (code 46, needed mainly for the purchase of digital services to foreign vendors), we get schema errors sending these type of invoices to the SII (l10n_cl_reference_doc_type_selection == 46). The use of the tag Exportaciones for document type '46' is not correct. This tag should be used only for foreign customers on Export documents. This case is only for the following codes: '110', '111', '112'. An "Activity descr
Original PR description
Before this PR: When we included the ability to create "Facturas de compra" (code 46, needed mainly for the purchase of digital services to foreign vendors), we get schema errors sending these type of invoices to the SII (l10n_cl_reference_doc_type_selection == 46). The use of the tag Exportaciones for document type '46' is not correct. This tag should be used only for foreign customers on Export documents. This case is only for the following codes: '110', '111', '112'. An "Activity description" is mandatory, as it's not an export document. The country customs code must be included in the Nacionalidad tag as well, as the vendor is foreign. Reference: Law Nº21420, and resolution Nº46 (May 13th, 2022) https://www.bcn.cl/leychile/navegar?idNorma=1172303 https://www.sii.cl/normativa_legislacion/resoluciones/2022/reso46.pdf After this PR: These issues are fixed. Community PR: https://github.com/odoo/odoo/pull/166793 Forward-Port-Of: odoo/enterprise#63244