Thursday, February 15, 2024
46 changes · saas-17.1
Resolved issues and error corrections
This fix ensures localization-specific fields are available immediately when users create new records for companies in affected countries. It prevents missing country-dependent information during setup, reducing confusion and avoiding incomplete data entry.
Original PR description
Install `l10n_ar` Switch to an AR company Create a new currency => the field `l10n_ar_afip_code` is not visible Go on an existing one => it is visible The compute is not triggered before the save. We should add a default to have the fiscal_code. We can even remove the compute (and keep the store=False), to avoid duplicating the code. Linked to runbot error 45392, 45417 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
Creating a new landed cost now correctly applies the company’s fiscal country by default. This ensures the Mexican customs number field is shown when needed, helping users enter required customs information without extra workarounds.
Original PR description
To reproduce: Having installed `l10n_mx_edi_landing`, go to landed costs. Create a new one => `l10n_mx_edi_customs_number` is not visible The reason being that the `fiscal_country_code` is not computed at creation. We should add a default.
Miscellaneous changes
task-3725221 Forward-Port-Of: odoo/odoo#154006
Original PR description
task-3725221 Forward-Port-Of: odoo/odoo#154006
1. Make sure to return archived users in partner format. 2. Remove the condition to check for archived users in suggestion code. The condition made no sense since the refactoring (that's the opposite of what we want, and it didn't compare the partner records correctly). The feature is broken since https://github.com/odoo/odoo/pull/133065/ because it "fixed" the way records are compared. Making the condition we don't want in the first place actually working and excluding OdooBot (ins
Original PR description
1. Make sure to return archived users in partner format. 2. Remove the condition to check for archived users in suggestion code. The condition made no sense since the refactoring (that's the opposite of what we want, and it didn't compare the partner records correctly). The feature is broken since https://github.com/odoo/odoo/pull/133065/ because it "fixed" the way records are compared. Making the condition we don't want in the first place actually working and excluding OdooBot (instead of allowing it). 3. Since archived partners are displayed anyway since the refactoring, and nobody complained, let's consider it a wanted feature. Archived partners are given lowest priority and moved to the bottom. task-3747277 Forward-Port-Of: odoo/odoo#154078
**Steps to reproduce:** - Open any course. - Open full-screen window. - Click on exit fullscreen - The progress bar color is mixed up with the background. **Issue:** In Odoo primary color is changed from v17.0 **Solution:** Applied bg-info class to progress bar for better visibility. **Task**-3721175 Forward-Port-Of: odoo/odoo#152815
Original PR description
**Steps to reproduce:** - Open any course. - Open full-screen window. - Click on exit fullscreen - The progress bar color is mixed up with the background. **Issue:** In Odoo primary color is changed from v17.0 **Solution:** Applied bg-info class to progress bar for better visibility. **Task**-3721175 Forward-Port-Of: odoo/odoo#152815
Steps to reproduce =================== 1. Create single-line questions like numbers and single-line text. 2. Test the survey. 3. Press the 'enter' key on a single line input. The form reloads and does not submit. Technical ========== With commit https://github.com/odoo/odoo/commit/7109f480ec27e929a43c4bae78912bad42458e90, a next button is added before the submit button, so when you press enter on single-line questions the first button of the form is clicked which refreshes the page w
Original PR description
Steps to reproduce =================== 1. Create single-line questions like numbers and single-line text. 2. Test the survey. 3. Press the 'enter' key on a single line input. The form reloads and does not submit. Technical ========== With commit https://github.com/odoo/odoo/commit/7109f480ec27e929a43c4bae78912bad42458e90, a next button is added before the submit button, so when you press enter on single-line questions the first button of the form is clicked which refreshes the page without any action. Ref-https://github.com/odoo/odoo/blob/66b4e080e29551d1c74cdc4b3d9ccba92ce81dd1/addons/survey/static/src/js/survey_form.js#L116 After this PR ================= We can submit the form with the 'enter' key from single-line input. Task-3650231 Forward-Port-Of: odoo/odoo#149003
## Description When searching with a domain that contains a relational field whos comodel is `res.users`, with a *pathological* domain of `not ilike` `'some_string'`, the ORM will call a `_name_search` on `res.users` with no limit to resolve the leaf when calling `_where_calc`. The current implementation in the `web` module overrides the `_name_search` to implement a spec to propose the current user as a first suggestion, but to do that it first execute the query (the list conversion), and then
Original PR description
## Description When searching with a domain that contains a relational field whos comodel is `res.users`, with a *pathological* domain of `not ilike` `'some_string'`, the ORM will call a…
## Description When searching with a domain that contains a relational field whos comodel is `res.users`, with a *pathological* domain of `not ilike` `'some_string'`, the ORM will call a `_name_search` on `res.users` with no limit to resolve the leaf when calling `_where_calc`. The current implementation in the `web` module overrides the `_name_search` to implement a spec to propose the current user as a first suggestion, but to do that it first execute the query (the list conversion), and then manipulates the list of ids to insert the current user first. (1c2ce8c213754aa47c51d68b6a8acd4770588864) On large databases with many `res.users`, where the condition matches all users besides 1, this is a probably Seq.Scan on the `res_users` table. Then this gigantic list of `ids` will be injected by the ORM into the main query to satisfy the original domain. This incurs not only bandwidth costs, but also usually leads to bad plans, ending up most likely into a Seq.Scan on the original table. The worse of it, in the case of a `web_search_read`, there is a `search_count`, so this whole fiasco is repeated once more. The nail in the coffin, is that the result isn't even needed, when resolving a comodel's `_name_search`, we care about the subset, the internal order is irrelevant. ## Solution The ORM calls the `_name_search` without a limit, while in general the `name_search` is called with a limit from the front-end, therefor we can use it as a discriminant -> If no limit, don't suggest `uid` first. ## Affected versions saas-16.3 -> master (saas-17.2) ## Reference task-3610657 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#152488
This fixes a bug where trying to set the default name value of an expense report when created from the expense tree view would traceback. Step to reproduce: - Create 2+ new expenses having the same payment_mode (E.G. 'own_account') - Clear the date field of an expense so at least one of the expense has a date and one has no date - Press the 'Create Report' button on the expense tree view Current behaviour: Traceback due to bool > Date comparison Expected behaviour: We don't set a d
Original PR description
This fixes a bug where trying to set the default name value of an expense report when created from the expense tree view would traceback. Step to reproduce: - Create 2+ new expenses having the same payment_mode (E.G. 'own_account') - Clear the date field of an expense so at least one of the expense has a date and one has no date - Press the 'Create Report' button on the expense tree view Current behaviour: Traceback due to bool > Date comparison Expected behaviour: We don't set a default report name, as it is required the user will be forced to set one manually. 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#153943 Forward-Port-Of: odoo/odoo#152852
**[FIX] web: fix text color of popover and badge light if dark background** Steps to reproduce the first bug (popover): - Install the e-commerce on your website. - Go to the "Customizable Desk" product page. - Click on "Edit" to go in edit mode. - Click on the "Theme" tab. - Click on the 4th color of the theme colors and choose "black". - Save the page to leave edit mode. - Click on the "Add to cart" button. - Hover over the cart in the navbar to make the popover appear. - Bug: All t
Original PR description
**[FIX] web: fix text color of popover and badge light if dark background** Steps to reproduce the first bug (popover): - Install the e-commerce on your website. - Go to the "Customizable Desk"…
**[FIX] web: fix text color of popover and badge light if dark background** Steps to reproduce the first bug (popover): - Install the e-commerce on your website. - Go to the "Customizable Desk" product page. - Click on "Edit" to go in edit mode. - Click on the "Theme" tab. - Click on the 4th color of the theme colors and choose "black". - Save the page to leave edit mode. - Click on the "Add to cart" button. - Hover over the cart in the navbar to make the popover appear. - Bug: All the popover texts are not visible because they are white and the background is white. Steps to reproduce the second bug (badge light): - Install the e-commerce on your website. - Go to the "Customizable Desk" product page. - Click on "Edit" to go in edit mode. - Click on the "Theme" tab. - Click on the 4th color of the theme colors and choose "black". - Save the page to leave edit mode. - Bug: The text of the "extra price" badge is not visible because both text and background are white. These two issues existed because the text color of those elements depended on the body's background color. With this commit, the text color for those elements is now determined by their respective backgrounds. This commit is a follow-up to this commit [1]. We also add the handling of the text-muted color to ensure it remains visible if a modal has a dark background while the body background color is light. Before this commit, we only handled the opposite case (dark body and light modal). This commit also fixes the text color of the button in a file input of a form when the background color of the <body> is dark. Similar to the other elements fixed in this commit, the text color of this button could be invisible because it was the same color as its background. [1]: https://github.com/odoo/odoo/commit/308b91c58b00300fd8dc52b9b4e2f7d1ab31f7b7 opw-3570774 _______________________________________________ **[FIX] web, website_sale: fix products page with a dark body background** Steps to reproduce the bugs: - Install the e-commerce on your website. - Go to the "/shop" page. - Click on "Edit" to enter edit mode. - Click on the "Customize" tab. - Choose "Cards" for the "Style" option. - Enable the "Product Description" toggle. - Click on the "Theme" tab. - Click on the 4th color of the theme colors and choose "black". - Save the page to exit edit mode. - Bug 1: The product description and the price in the product cards are not visible. - Bug 2: The scrollbar below the category buttons has the same color as its background. - Click on the "Mobile Preview" button in the backend navbar. - Click on the "Filters" button on the page to show the offcanvas. - Bug 3: The text color in the offcanvas is not visible and the background color of the inputs is the "body" background color instead of the "offcanvas" background color. opw-3570774 Forward-Port-Of: odoo/odoo#153930 Forward-Port-Of: odoo/odoo#150420
**Current behavior before PR:** - When coupen code template is selected and we drag text block then text will not be visible because of bg color as the background color and text color are same. - When selecting multiple blocks, the link button sometimes fails to disappear, and sometimes, after selection clicking on a line, the link button does not reappear because the code resides within the `_updateEditorUi` function, and this function is not invoked upon a selection change
Original PR description
**Current behavior before PR:** - When coupen code template is selected and we drag text block then text will not be visible because of bg color as the background color and text color are same. -…
**Current behavior before PR:** - When coupen code template is selected and we drag text block then text will not be visible because of bg color as the background color and text color are same. - When selecting multiple blocks, the link button sometimes fails to disappear, and sometimes, after selection clicking on a line, the link button does not reappear because the code resides within the `_updateEditorUi` function, and this function is not invoked upon a selection change. Therefore, after modifying the selection, the user must wait for the `_updateEditorUi` function to be triggered, which happens upon a click or keydown event. **Desired behavior after PR is merged:** - Now in coupen code we can see text in text block. - Now the link button will disappear on multiple block selection and it will be reappear on single block. as we moved code to updateToolbar which is triggered on selection change. task-3514347 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153914 Forward-Port-Of: odoo/odoo#136099
**Desired behavior after PR is merged:** Enhancing the job posting with an XML tag for the title of the position so it can be used for the google rich search. opw-3713519 Forward-Port-Of: odoo/odoo#153682
Original PR description
**Desired behavior after PR is merged:** Enhancing the job posting with an XML tag for the title of the position so it can be used for the google rich search. opw-3713519 Forward-Port-Of: odoo/odoo#153682
Steps to reproduce ================== - Install account_accountant - Go to settings - Enable Budget Management - Go to Accounting > Reporting > Management > Budgets Analysis - Switch to the graph view - Change the measure to "Planned amount" and then back to "Practical amount" => The practical_amount measure is undefined, The theoritical_amount measure is missing. Cause of the issue ================== The view is defined as follows: ```xml <graph string="Budget Lines"
Original PR description
Steps to reproduce ================== - Install account_accountant - Go to settings - Enable Budget Management - Go to Accounting > Reporting > Management > Budgets Analysis - Switch to the graph…
Steps to reproduce
==================
- Install account_accountant
- Go to settings
- Enable Budget Management
- Go to Accounting > Reporting > Management > Budgets Analysis
- Switch to the graph view
- Change the measure to "Planned amount" and then back to "Practical amount"
=> The practical_amount measure is undefined,
The theoritical_amount measure is missing.
Cause of the issue
==================
The view is defined as follows:
```xml
<graph string="Budget Lines" sample="1">
<field name="crossovered_budget_id" type="row"/>
<field name="planned_amount" type="measure" string="Planned amount"/>
<field name="theoritical_amount" type="measure" string="Theoretical amount"/>
<field name="practical_amount" type="measure" string="Practical amount"/>
</graph>
```
The theoritical_amount and practical_amount are non stored fields and thus are skipped inside `computeReportMeasures` unless they are passed in `activeMeasures | additionalMeasures`. [0]
When parsing the graph view, the last field of type measure is passed to the graph model and is the one that will be used initially. [1]
This is why the practical_amount is initially defined.
Solution
========
We simply need to keep track of fields of type measure. This was the case in 14.0 but got lost in the conversion.
---
[0]: https://github.com/odoo/odoo/blob/e7a9ebec3176c37485643fcda2381e489a1df86f/addons/web/static/src/views/helpers/utils.js#L49-L60
[1]: https://github.com/odoo/odoo/blob/0fb64bef16914937cf4a1d1618fb58ade6d16f14/addons/web/static/src/views/graph/graph_arch_parser.js#L63
opw-3713613
Forward-Port-Of: odoo/odoo#153967
Forward-Port-Of: odoo/odoo#153599Issue: ====== Some templates that contains an image have wrong width and it can't be updated. Steps to reproduce the issue: ============================= - Use a view with width < 1135px - Go to email marketing - Create a new mailing - Use the welcome message template - The size of the signature is wrong and you can't update it Origin of the issue: ==================== There is an applied style which fixed the minimum width to 100% if the img is alone inside the parent element (h
Original PR description
Issue: ====== Some templates that contains an image have wrong width and it can't be updated. Steps to reproduce the issue: ============================= - Use a view with width < 1135px - Go to email marketing - Create a new mailing - Use the welcome message template - The size of the signature is wrong and you can't update it Origin of the issue: ==================== There is an applied style which fixed the minimum width to 100% if the img is alone inside the parent element (has no siblings) https://github.com/odoo/odoo/blob/749133f3170f795c9deabc6ad6f7684baa76db59/addons/mass_mailing/data/mailing_data_templates.xml#L98 Solution: ========= Add `img-fluid` class to some `img` elements to keep the layout correct. task-3718618 Forward-Port-Of: odoo/odoo#153304 Forward-Port-Of: odoo/odoo#152837
Currently, links in the website editor always open in the iframe except for a few exceptions defined in `_isTopWindowURL` As the enable_editor parameter is only valid for the parent window containing the iframe clicking a link with `<a href="?enable_editor=1" has no effect. To fix this for the two cases we do have this message, we add `@` as the root of the path of the url. Which indicated we want to open a "back-end" route, which will be set in the parent window. We also fix the exhibi
Original PR description
Currently, links in the website editor always open in the iframe except for a few exceptions defined in `_isTopWindowURL` As the enable_editor parameter is only valid for the parent window containing the iframe clicking a link with `<a href="?enable_editor=1" has no effect. To fix this for the two cases we do have this message, we add `@` as the root of the path of the url. Which indicated we want to open a "back-end" route, which will be set in the parent window. We also fix the exhibitor version of this pop-up not showing up. task-3607615 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#143162
### Steps to reproduce * install `l10n_ch_reports` * switch to a Swiss company * enable "QR Codes" in Settings > Accounting > Customer Payments * create and confirm two invoices for a Swiss partner * on the invoice list view, select and attempt to print the two invoices at once You should be met with traceback. opw-3697569 Forward-Port-Of: odoo/odoo#153903 Forward-Port-Of: odoo/odoo#153461
Original PR description
### Steps to reproduce * install `l10n_ch_reports` * switch to a Swiss company * enable "QR Codes" in Settings > Accounting > Customer Payments * create and confirm two invoices for a Swiss partner * on the invoice list view, select and attempt to print the two invoices at once You should be met with traceback. opw-3697569 Forward-Port-Of: odoo/odoo#153903 Forward-Port-Of: odoo/odoo#153461
Description of the issue/feature this PR addresses: The dropdown was overflowing below the chatter, making it unusable under some circumstances. Current behavior before PR: https://github.com/odoo/odoo/assets/973709/b91a4282-a70e-4c67-b57f-f7a3385dfa11 Particularly, these artifacts:    Desired behavior after PR is merged: https://github.com/odoo/odoo/assets/973709/9026c0d5-f977-473b-895b-5555fbdbd672 Artifacts fixed:   --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr @moduon MT-4598 OPW-3684703 Forward-Port-Of: odoo/odoo#150395
**Issue Description**: From versions 16.3 to the master branch, a sub-task should never be assigned to a project automatically. However, when accessing `Sub-tasks` through the smart button and creating a new one, the context pass variable such as `'default_project_id': 4`. This leads to the sub-task being created with an assigned project immediately. **Steps to Reproduce**: 1. Open `Project` app. 2. Enter any project, then navigate to any task. 3. Within the task, go to `sub-task` tab. 4
Original PR description
**Issue Description**: From versions 16.3 to the master branch, a sub-task should never be assigned to a project automatically. However, when accessing `Sub-tasks` through the smart button and…
**Issue Description**: From versions 16.3 to the master branch, a sub-task should never be assigned to a project automatically. However, when accessing `Sub-tasks` through the smart button and creating a new one, the context pass variable such as `'default_project_id': 4`. This leads to the sub-task being created with an assigned project immediately. **Steps to Reproduce**: 1. Open `Project` app. 2. Enter any project, then navigate to any task. 3. Within the task, go to `sub-task` tab. 4. At the top center of the page, click on 'Sub-task' smart button. 5. Then, create a new sub-task using the 'New' button. 6. You will observe that the sub-task is immediately assigned to a project, which should not happen. **Proposed Solution**: By removing the passing of the default_project_id variable from the context when open a sub-task action, we ensure that sub-tasks are not automatically assigned to a project, as intended. opw-3708537 Forward-Port-Of: odoo/odoo#154101 Forward-Port-Of: odoo/odoo#153349
[FIX] membership : Members module is not visible without Accounting Steps to reproduce: 1- Install Members module while Accounting is uninstalled Current behavior before PR: When you install Members module without having Accounting module you will not be able to access Members module as it will be hidden on the dashboard. This happens because of the access rights that the Member module has as it is having the access right group of the Accounting module `group_account_user`. Desired be
Original PR description
[FIX] membership : Members module is not visible without Accounting Steps to reproduce: 1- Install Members module while Accounting is uninstalled Current behavior before PR: When you install Members module without having Accounting module you will not be able to access Members module as it will be hidden on the dashboard. This happens because of the access rights that the Member module has as it is having the access right group of the Accounting module `group_account_user`. Desired behavior after PR is merged: Now the Members module has the access right group of Invoicing module `group_account_invoice` which is the only dependency module that Members need. So it will be visible and accessible from the dashboard once installed opw-3627010 Forward-Port-Of: odoo/odoo#153938 Forward-Port-Of: odoo/odoo#146373
Steps to reproduce: - Install `event_crm` module - Create an Event with a company - Go to `Events > Configuration > Event Lead Rules` - Create a new rule and set no company - Try to set the event created above for Event field Issue: Event created not displayed as possible value for the Event field. Cause: Because we have `check_company=True` set on `event_id` field, the field will be filtered based on the `company_id` field, and since no company is set on t
Original PR description
Steps to reproduce: - Install `event_crm` module - Create an Event with a company - Go to `Events > Configuration > Event Lead Rules` - Create a new rule and set no company - Try to set the event created above for Event field Issue: Event created not displayed as possible value for the Event field. Cause: Because we have `check_company=True` set on `event_id` field, the field will be filtered based on the `company_id` field, and since no company is set on the rule, events with company will not be listed. Commit that introduced the issue: https://github.com/odoo/odoo/commit/0479b2b59466ae1d6d74165345aa3a7dc5de24ed Solution: Revert to the previous behavior (remove `check_company=True` from `event_id` field and use a domain instead). opw-3715864 Forward-Port-Of: odoo/odoo#153906
Steps: - Install `mrp` - Install `web_studio` - Open `Inventory` - Click on `Toggle Studio` button - Click on `Reports` tab - Remove default filter - Try to open `MO Overview` report via reports view - Traceback When loading the `MO Overview` report, `_get_report_qweb` is called and builds the context rendering here https://github.com/odoo/enterprise/blob/b7d0d3034d53cdab831f42f8b37a14cf50f3720e/web_studio/controllers/report.py#L549 We therefore call _get_rendering_conte
Original PR description
Steps: - Install `mrp` - Install `web_studio` - Open `Inventory` - Click on `Toggle Studio` button - Click on `Reports` tab - Remove default filter - Try to open `MO Overview` report via reports view…
Steps: - Install `mrp` - Install `web_studio` - Open `Inventory` - Click on `Toggle Studio` button - Click on `Reports` tab - Remove default filter - Try to open `MO Overview` report via reports view - Traceback When loading the `MO Overview` report, `_get_report_qweb` is called and builds the context rendering here https://github.com/odoo/enterprise/blob/b7d0d3034d53cdab831f42f8b37a14cf50f3720e/web_studio/controllers/report.py#L549 We therefore call _get_rendering_context with `[0]` in `docids`, which will call `_get_report_values` in `mrp/report/mrp_report_mo_overview`. https://github.com/odoo/odoo/blob/6e8e62db1fa2010c3e6696baacaedf997fd8fa89/addons/mrp/report/mrp_report_mo_overview.py#L29-L30 https://github.com/odoo/odoo/blob/6e8e62db1fa2010c3e6696baacaedf997fd8fa89/addons/mrp/report/mrp_report_mo_overview.py#L53-L54 `_get_report_data` performs a `browse(0)` on `mrp.production`. BaseModels::browse replaces falsy values with empty tuples `()`. https://github.com/odoo/odoo/blob/5d726c933b591468bcef85a4e14b183278a00e5b/odoo/models.py#L5441-L5442 This implies the return of an empty model record. `mrp_report_mo_overview` will therefore use a record containing null values in its operations, for example division, which causes a division by 0 error, or a log10(0) in `_get_uom_precision` because `product_uom.rounding` is 0. https://github.com/odoo/odoo/blob/6e8e62db1fa2010c3e6696baacaedf997fd8fa89/addons/mrp/report/mrp_report_mo_overview.py#L105-L106 This commit corrects these incorrect defaults with fallbacks opw-[3725827](https://www.odoo.com/web#id=3725827&view_type=form&model=project.task) Forward-Port-Of: odoo/odoo#153919 Forward-Port-Of: odoo/odoo#153594
When invoicing public administrations, they expect the facturae electronic invoice to contain the optional `<PaymentDetails>` node that contains e.g. the bank account number to which they need to issue the payment. We didn't provide these details. This commit adds the necessary `<Installment>` nodes in the `<PaymentDetails>` node for each installment in Odoo according to the payment terms of the invoice. Since we are fixing this in stable, we only add the payment details for inbound paymen
Original PR description
When invoicing public administrations, they expect the facturae electronic invoice to contain the optional `<PaymentDetails>` node that contains e.g. the bank account number to which they need to…
When invoicing public administrations, they expect the facturae electronic invoice to contain the optional `<PaymentDetails>` node that contains e.g. the bank account number to which they need to issue the payment. We didn't provide these details. This commit adds the necessary `<Installment>` nodes in the `<PaymentDetails>` node for each installment in Odoo according to the payment terms of the invoice. Since we are fixing this in stable, we only add the payment details for inbound payments and fix the `<PaymentMeans>` to `04` (Credit Transfer). We also removed the stripping of whitespace for the signature, since it turned out not necessary after introduced in [1] [1] e5d69a73e2e781d00f67c0590a8fc13b09a06ebf [task-3734341](https://www.odoo.com/web#id=3734341&cids=1&menu_id=4720&action=333&active_id=967&model=project.task&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153931 Forward-Port-Of: odoo/odoo#153692
The string value of an empty array is `""` which is falsy. Prior to this commit, if all optional columns headers were disabled in a list view, it would result in a reset of those when the view is mounted the next time, instead of keeping them disabled like in prior versions. task-3692178 Forward-Port-Of: odoo/odoo#153831 Forward-Port-Of: odoo/odoo#153407
Original PR description
The string value of an empty array is `""` which is falsy. Prior to this commit, if all optional columns headers were disabled in a list view, it would result in a reset of those when the view is mounted the next time, instead of keeping them disabled like in prior versions. task-3692178 Forward-Port-Of: odoo/odoo#153831 Forward-Port-Of: odoo/odoo#153407
Steps to reproduce: - Switch to a language where removal strategy name is translated (FR in 17.0) - Edit product category and set a translated removal strategy - Update on hand quantity Bug: User error removal strategy not implemented the removal strategy name is used in the code to identify them when changing the name through translation it is not recognized anymore Fix: use the untranslated term when checking the strategy type opw-3697462 Forward-Port-Of: odoo/odoo#152928
Original PR description
Steps to reproduce: - Switch to a language where removal strategy name is translated (FR in 17.0) - Edit product category and set a translated removal strategy - Update on hand quantity Bug: User error removal strategy not implemented the removal strategy name is used in the code to identify them when changing the name through translation it is not recognized anymore Fix: use the untranslated term when checking the strategy type opw-3697462 Forward-Port-Of: odoo/odoo#152928
In https://github.com/odoo/odoo/commit/e0491c1a623ffec19ed563679f853cc6d1c56d03 we changed the spacing of the activity button to dissociate it from buttons that are "message/communication" oriented. This spacing was unwanted so we need to revert it back. task-3730089 | Before | After | | --- | --- | | |
Original PR description
In https://github.com/odoo/odoo/commit/e0491c1a623ffec19ed563679f853cc6d1c56d03 we changed the spacing of the activity button to dissociate it from buttons that are "message/communication" oriented. This spacing was unwanted so we need to revert it back. task-3730089 | Before | After | | --- | --- | | | | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153100
Current behavior: When printing the bill before the order has been paid, the QRCode to get the invoice shouldn't be shown. Steps to reproduce: - Activate the option "Show QR Code" in the POS settings - Create a new order - Add some products - Click on "Bill" button - The QRCode is shown opw-3703720 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#152918
Original PR description
Current behavior: When printing the bill before the order has been paid, the QRCode to get the invoice shouldn't be shown. Steps to reproduce: - Activate the option "Show QR Code" in the POS settings - Create a new order - Add some products - Click on "Bill" button - The QRCode is shown opw-3703720 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#152918
New point of sale for the Peruvian localization. Forward-Port-Of: https://github.com/odoo/odoo/pull/143487 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Original PR description
New point of sale for the Peruvian localization. Forward-Port-Of: https://github.com/odoo/odoo/pull/143487 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
pos*: point_of_sale, pos_restaurant The current approach to book/release a table isn't so intuitive, knowing that when selecting an empty table from the floor plan: - an empty order is created on that table, displaying it as booked on the floor plan - as long as the order remains empty, we display a "Release table" button in order to delete the related empty order and display the table as free on the floor plan Here is the change brought by this commit: - Change the "Release table" butt
Original PR description
pos*: point_of_sale, pos_restaurant The current approach to book/release a table isn't so intuitive, knowing that when selecting an empty table from the floor plan: - an empty order is created on that table, displaying it as booked on the floor plan - as long as the order remains empty, we display a "Release table" button in order to delete the related empty order and display the table as free on the floor plan Here is the change brought by this commit: - Change the "Release table" button to "Book table" - Don't create an empty order on the table until User either: - hits "Book table" - starts adding products to the cart - Table can be released by deleting the order - Deleting the last order on the table, redirects User to the floor plan task-id: 3624323 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#145896
Install website, knowledge and website_knowledge, open any knowledge article and publish it to website visitor, then as a visitor access the public link of that article. In case the article had a emoji on top, that emoji and the title overlaps. This is a partial revert of commit 7a8fde881229 which introduced those changes in the layout to correct this same bug, also in 16.4, about the title icon and the title text overlapping. Reading the history, it seems that a generic frontend layout pr
Original PR description
Install website, knowledge and website_knowledge, open any knowledge article and publish it to website visitor, then as a visitor access the public link of that article. In case the article had a emoji on top, that emoji and the title overlaps. This is a partial revert of commit 7a8fde881229 which introduced those changes in the layout to correct this same bug, also in 16.4, about the title icon and the title text overlapping. Reading the history, it seems that a generic frontend layout problem arose in 16.4 in july, that 7a8fde881229 fixed the bug but in knowledge only and that since then the generic frontend layout problem got resolved, obsoleting 7a8fde881229 here in december. References: 7a8fde881229 ([FIX] (website_)knowledge: fix various layout issues) Task-3525618 Forward-Port-Of: odoo/enterprise#56439 Forward-Port-Of: odoo/enterprise#52315
In odoo/odoo@7e012dd, `_get_custom_rendering_context_values` was refactored and renamed `_get_extra_payment_form_values`. `sale_order_id` was mainly used for reconciliation in the transaction route and was removed from the extra payment form values as it was not needed anymore. Unfortunately, Stripe still needs `sale_order_id` for subscriptions, to compute whether the tokenization is required. This commit adds `sale_order_id` back in the extra payment form values when the Subscription app
Original PR description
In odoo/odoo@7e012dd, `_get_custom_rendering_context_values` was refactored and renamed `_get_extra_payment_form_values`. `sale_order_id` was mainly used for reconciliation in the transaction route and was removed from the extra payment form values as it was not needed anymore. Unfortunately, Stripe still needs `sale_order_id` for subscriptions, to compute whether the tokenization is required. This commit adds `sale_order_id` back in the extra payment form values when the Subscription app is installed. --- Steps to reproduce: 1. Configure Stripe; 2. Create a subscription with at least one recurrent product; 3. Generate a payment link and try to pay. Forward-Port-Of: odoo/enterprise#56623
The previous implementation returned data based on record computation order, and not the actual model `_order`. This is confusing for the user, and inconsistent with the`_order` defined on the model. Moreover the `product.product` model isn't ordered by `sequence`, but rather by [priority, default_code, name, etc](https://github.com/odoo/odoo/blob/99bcda76fbffe804eeb974cc225daa5324fb9418/addons/product/models/product.py#L80). In any case, by ordering by product_id the actual order will be ta
Original PR description
The previous implementation returned data based on record computation order, and not the actual model `_order`. This is confusing for the user, and inconsistent with the`_order` defined on the model. Moreover the `product.product` model isn't ordered by `sequence`, but rather by [priority, default_code, name, etc](https://github.com/odoo/odoo/blob/99bcda76fbffe804eeb974cc225daa5324fb9418/addons/product/models/product.py#L80). In any case, by ordering by product_id the actual order will be taken from the related model, which makes more sense that an incorrect hardcoded one. ping @amoyaux Forward-Port-Of: odoo/enterprise#30093
Purpose ======= defaultdict.get(key) returns None if the key doesn't exist instead of default factory value This could lead to traceback in rules like result = categories.get("BASIC") + categories.get("ALW") Easily fixed with result = categories.get("BASIC", 0) + categories.get("ALW", 0) or better result = categories["BASIC"] + categories["ALW"] But could be more robust, find a way to override get or use try catch to return default value instead of None Forward-Port-Of: odoo
Original PR description
Purpose
=======
defaultdict.get(key) returns None if the key doesn't exist instead of default factory value
This could lead to traceback in rules like
result = categories.get("BASIC") + categories.get("ALW")
Easily fixed with
result = categories.get("BASIC", 0) + categories.get("ALW", 0) or better
result = categories["BASIC"] + categories["ALW"]
But could be more robust, find a way to override get or use try catch to return default value instead of None
Forward-Port-Of: odoo/enterprise#56384**Steps to reproduce:** 1- Install Documents module 2- Go to documents list view 3- Click on the dropdown menu for additional fields selection **Current behavior before PR:** The dropdown menu for additional fields selection in documents list view is interfered with the table cells so the user will not be able to select the wanted option. This is happening because the table row in this list is having a css value for position property which is relative.  **Desired behavior after PR is merged:** The view has been adjusted by removing the css style for the data-row in document list view.  opw-3682703 Forward-Port-Of: odoo/enterprise#56104 Forward-Port-Of: odoo/enterprise#54854
Allow user with accountant rights but not admin rihgts to set Addenda in contact view. The addenda is an ir.ui.view instance. This commit allows read access to this model to group_account_invoice group. Task: opw-3504839 Forward-Port-Of: odoo/enterprise#56575 Forward-Port-Of: odoo/enterprise#51384
Original PR description
Allow user with accountant rights but not admin rihgts to set Addenda in contact view. The addenda is an ir.ui.view instance. This commit allows read access to this model to group_account_invoice group. Task: opw-3504839 Forward-Port-Of: odoo/enterprise#56575 Forward-Port-Of: odoo/enterprise#51384
Rental search bar filtering didn't properly consider the website warehouse: * fetching all SOLs of the company regardless of their warehouse * computing the available quantity of products with the wrong contextual key, not restricting the quantities to the website warehouse. (correct context key is warehouse, not warehouse_id, cf `_get_domain_locations` in stock/models/product.py) Forward-Port-Of: odoo/enterprise#43224
Original PR description
Rental search bar filtering didn't properly consider the website warehouse: * fetching all SOLs of the company regardless of their warehouse * computing the available quantity of products with the wrong contextual key, not restricting the quantities to the website warehouse. (correct context key is warehouse, not warehouse_id, cf `_get_domain_locations` in stock/models/product.py) Forward-Port-Of: odoo/enterprise#43224
When the user tries to sync all the templates from `WhatsApp Business Account` the number of templates in the stat button is not updated. Steps to produce: - Create a `WhatsApp Business Account` - Click on `Sync Templates` Problem: The compute function `_compute_templates_count` is responsible for updating the `templates_count` field. But this compute function has no dependencies on it. So it will be called when the page is reloaded. Solution: The function `button_sync_wha
Original PR description
When the user tries to sync all the templates from `WhatsApp Business Account` the number of templates in the stat button is not updated. Steps to produce: - Create a `WhatsApp Business Account` - Click on `Sync Templates` Problem: The compute function `_compute_templates_count` is responsible for updating the `templates_count` field. But this compute function has no dependencies on it. So it will be called when the page is reloaded. Solution: The function `button_sync_whatsapp_account_templates` returns a `display_notification` for displaying the Template Created and Updated count. After this, we will reload the page using `soft_reload`. Task - 3619128 Forward-Port-Of: odoo/enterprise#51460
When we use the mode `on_validation` for deferred entries, the first entry that puts the total amount on the deferred account is happening at the end of the month of the move. When we have a vendor bill on Feb 1, 2024, and the amount is deferred from Feb 1, 2024 to Mar 31, 2024, we will have the following moves: [Feb 29, 2024] $1000 from Expenses to Deferred Expenses [Feb 29, 2024] $500 from Deferred Expenses to Expenses [Mar 31, 2024] $500 from Deferred Expenses to Expenses That me
Original PR description
When we use the mode `on_validation` for deferred entries, the first entry that puts the total amount on the deferred account is happening at the end of the month of the move. When we have a vendor…
When we use the mode `on_validation` for deferred entries, the first entry that puts the total amount on the deferred account is happening at the end of the month of the move. When we have a vendor bill on Feb 1, 2024, and the amount is deferred from Feb 1, 2024 to Mar 31, 2024, we will have the following moves: [Feb 29, 2024] $1000 from Expenses to Deferred Expenses [Feb 29, 2024] $500 from Deferred Expenses to Expenses [Mar 31, 2024] $500 from Deferred Expenses to Expenses That means that during the whole month of February we have the total amount on our Expenses account, except on the last day. In order to improve this, we now defer the original move on the same accounting date of the move, such that during that month at most the deferred part is on the Revenue/Expense account (on the last day). [task-3725621](https://www.odoo.com/web#id=3725621&cids=1&menu_id=4720&action=333&active_id=967&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#56554 Forward-Port-Of: odoo/enterprise#56052
How to reproduce: 1. Select a file/doc. 2. Move to trash ( by trash bin icon). 3. Go to trash workspace. 4. Preview the file/doc. 5. Restore the file. 6. Now, try to preview it from the inspector. 7. It throws an error Technical Reason: Before version 17.0, Inside `_toggleArchive`, we were triggering the event to close the preview, but In 17.0 `_toggleArchive` is removed after this [commit](https://github.com/odoo-dev/enterprise/commit/2254eb07fd42ec88341d9d7ac92f09a379c6fa55#diff-78
Original PR description
How to reproduce: 1. Select a file/doc. 2. Move to trash ( by trash bin icon). 3. Go to trash workspace. 4. Preview the file/doc. 5. Restore the file. 6. Now, try to preview it from the inspector. 7. It throws an error Technical Reason: Before version 17.0, Inside `_toggleArchive`, we were triggering the event to close the preview, but In 17.0 `_toggleArchive` is removed after this [commit](https://github.com/odoo-dev/enterprise/commit/2254eb07fd42ec88341d9d7ac92f09a379c6fa55#diff-78d9f8faf609f35072d4b2617a9e13b3f137a679efb2c46c84acf29da4edfe46L426), So the preview remains open. After this commit: No traceback will appear, and the preview will be closed, after clicking on the restore button. Task-3619214 Forward-Port-Of: odoo/enterprise#52226
When making a cross_report aggregation expression, its date_scope is going to be enforced on all expressions used in its computation. Because of that, if an expression of the current report is referenced by such an aggregation, and if this forced date_scope is different from that expression's, this expression will be computed twice, once for each date_scope. However, the modelling of the report makes it so that the second of these computations will overwrite the result of the first one (because
Original PR description
When making a cross_report aggregation expression, its date_scope is going to be enforced on all expressions used in its computation. Because of that, if an expression of the current report is…
When making a cross_report aggregation expression, its date_scope is going to be enforced on all expressions used in its computation. Because of that, if an expression of the current report is referenced by such an aggregation, and if this forced date_scope is different from that expression's, this expression will be computed twice, once for each date_scope. However, the modelling of the report makes it so that the second of these computations will overwrite the result of the first one (because the expression totals dict uses expressions directly as its keys). For now, this case is considered unsupported, as its is not common at all, and an easy workaround exist (just use multiple aggregation expressions, and only reference other reports in cross_report expressions). We hence add an exception in the report computation to crash when it occurs instead of displaying potentially wrong amounts. We also fix the NDays expression of the Executive Summary, as they were facing this situation, and hence raised the new exception we introduce here when the report was tested. Though it was a bit useless to compute them twice like that, their custom engine was made in such a way that the result of the computation was unchanged, so we can safely change the date_scope here so that it matches the one used on the aggregations calling them. Forward-Port-Of: odoo/enterprise#55560 Forward-Port-Of: odoo/enterprise#55212
We revert the PRs below because it generates issues in the accounting application when the ocr is detecting someone else as contact, and it cannot overrule the one we detected in Documents: In odoo/enterprise#39292, we have implemented: If not explicitly defined on the documents.share, when receiving a document by email, we set the contact to the partner corresponding to the email sender. If no partner exists with that email, a new one is created. In odoo/enterprise#50379, we have partial
Original PR description
We revert the PRs below because it generates issues in the accounting application when the ocr is detecting someone else as contact, and it cannot overrule the one we detected in Documents: In…
We revert the PRs below because it generates issues in the accounting application when the ocr is detecting someone else as contact, and it cannot overrule the one we detected in Documents: In odoo/enterprise#39292, we have implemented: If not explicitly defined on the documents.share, when receiving a document by email, we set the contact to the partner corresponding to the email sender. If no partner exists with that email, a new one is created. In odoo/enterprise#50379, we have partially reverted the change: When receiving a document from an unknown contact, we no longer create a new partner. However, if the contact is known, we assign the already existing partner to the document. We revert here the last part that is to assign the author of the message to the document if the author is a known partner. However, we keep the tests introduced in odoo/enterprise#39292 with some minor adaptations. How to reproduce: - install documents with demo data - send an email with an attachment to the inbox alias (that create a document when receiving an email) from an email of an existing partner. It can be simulated using odoo_mail_gate.py. - find the document received and select it - in the document inspector, the contact should be empty but it is not Task-3672520 Forward-Port-Of: odoo/enterprise#56138 Forward-Port-Of: odoo/enterprise#55035
Commit https://github.com/odoo/odoo/commit/fd294f9a44f3e029fc83d2bf8610cf286abe017a did not choose the right solution, so our tests fail on Feb 12 and 13 We therefore unlink the leaves before running our tests. Forward-Port-Of: odoo/enterprise#56476
Original PR description
Commit https://github.com/odoo/odoo/commit/fd294f9a44f3e029fc83d2bf8610cf286abe017a did not choose the right solution, so our tests fail on Feb 12 and 13 We therefore unlink the leaves before running our tests. Forward-Port-Of: odoo/enterprise#56476
Avatax doesn't allow all state transitions. For example, if an invoice is committed it can't be committed again. If an invoice is voided, it can't be committed. These state transitions shouldn't happen in Odoo when things go well, but bugs and concurrent access errors can stop any of our normal flows at any point. For example, a subscription gets automatically charged, does the payment, generates the invoice and commits the invoice in Avatax. However, the transaction fails to commit in Odoo b
Original PR description
Avatax doesn't allow all state transitions. For example, if an invoice is committed it can't be committed again. If an invoice is voided, it can't be committed. These state transitions shouldn't…
Avatax doesn't allow all state transitions. For example, if an invoice is committed it can't be committed again. If an invoice is voided, it can't be committed. These state transitions shouldn't happen in Odoo when things go well, but bugs and concurrent access errors can stop any of our normal flows at any point. For example, a subscription gets automatically charged, does the payment, generates the invoice and commits the invoice in Avatax. However, the transaction fails to commit in Odoo because of a concurrent access error. Next time an invoice with the same Avatax Code is generated the tax calculation will fail with this error: odoo.exceptions.UserError: Odoo could not fetch the taxes related to Draft Invoice (* 123456) (M123456). Please check the status of `Journal Entry 123456` in the AvaTax portal. DocStatus is invalid for this operation. Errors like this can then break the automatic subscription renewal. Since there's many reasons a flow can crash it's better to make Avatax as idempotent as possible. The source of truth for invoice state is Odoo, regardless of what's in Avatax. To achieve this we'll fully switch to the createoradjust [1] endpoint that was previously introduced for test environments [2]. This endpoint allows almost all state transitions and should avoid the majority of blocking errors. [1] https://developer.avalara.com/api-reference/avatax/rest/v2/methods/Transactions/CreateOrAdjustTransaction [2] 12039763a3a8f27a1d69bebb6d661ad20ce3537b cc @tfr-odoo Forward-Port-Of: odoo/enterprise#56573
Records added via a .csv file should always have an ID set, otherwise, they will not have a corresponding xmlid created for them (issue reproducible in standard). This change probably requires a local migration script and thus the increase of subversion (I'll work on it if this gets approved). Updating a db with this module already installed, results in duplicated entries in `l10n_at_saft_account`. A simple script would match the existing records with newly created xmlids. This issue is al
Original PR description
Records added via a .csv file should always have an ID set, otherwise, they will not have a corresponding xmlid created for them (issue reproducible in standard). This change probably requires a…
Records added via a .csv file should always have an ID set, otherwise, they will not have a corresponding xmlid created for them (issue reproducible in standard). This change probably requires a local migration script and thus the increase of subversion (I'll work on it if this gets approved). Updating a db with this module already installed, results in duplicated entries in `l10n_at_saft_account`. A simple script would match the existing records with newly created xmlids. This issue is also raising an error during upgrades because our scripts expect all csv data to have the `id` field: https://github.com/odoo/upgrade/blob/d861ce33eef5c51996005664353021be779121bd/migrations/base/0.0.0/pre-models-load-csv.py#L44 Here's the [traceback group](https://upgrade.odoo.com/web#id=1073&cids=1&menu_id=107&action=178&model=upgrade.request.traceback.group&view_type=form). Tests conducted on [upg-1289502](https://upgrade.odoo.com/web#id=1289502&cids=1&menu_id=107&action=150&model=upgrade.request&view_type=form). <s>I have also taken the liberty to remove quotation marks to be more in line with the current standard in Odoo repos.</s> Forward-Port-Of: odoo/enterprise#56212
Currently, when a lock date is set, all default expressions in the db are evaluated, causing some issues when there are different localizations installed. This commit limits the computation to only those expressions that exist on reports that are available to the current company. Forward-Port-Of: odoo/enterprise#56519
Original PR description
Currently, when a lock date is set, all default expressions in the db are evaluated, causing some issues when there are different localizations installed. This commit limits the computation to only those expressions that exist on reports that are available to the current company. Forward-Port-Of: odoo/enterprise#56519
Problem: When a user books an appointment, whose up-front payment is enabled, and provides answers to the questions from the website,the user is unable to remove the booking because a ValidationError occurs due to the answers not getting deleted before the booking gets deleted. Solution: When a booking gets deleted, its answers should also get deleted to prevent errors. Steps to reproduce on Runbot: 1. Install Appointments and ecommerce 2. For the dental care appointment, edit and ena
Original PR description
Problem: When a user books an appointment, whose up-front payment is enabled, and provides answers to the questions from the website,the user is unable to remove the booking because a ValidationError occurs due to the answers not getting deleted before the booking gets deleted. Solution: When a booking gets deleted, its answers should also get deleted to prevent errors. Steps to reproduce on Runbot: 1. Install Appointments and ecommerce 2. For the dental care appointment, edit and enable "Up-front payment" 3. On the website, book an appointment for dental care and proceed to payment 4. Attempt to remove the booking and a ValidationError occurs "The operation cannot be completed: The answer inputs must be linked to a meeting or to a booking." opw-3671511 Forward-Port-Of: odoo/enterprise#55387
Steps to reproduce: - In the Barcode app - Create a new transfer - Scan a product and validate the picking - Select the picking again (remove the ready filter to see it) - "This picking is already done is displayed" and the validate btn isn't displayed but it's still possible to scan products and validate using barcode command Fix: prevent validate if the picking is already done opw-3547770 Forward-Port-Of: odoo/enterprise#56440 Forward-Port-Of: odoo/enterprise#52764
Original PR description
Steps to reproduce: - In the Barcode app - Create a new transfer - Scan a product and validate the picking - Select the picking again (remove the ready filter to see it) - "This picking is already done is displayed" and the validate btn isn't displayed but it's still possible to scan products and validate using barcode command Fix: prevent validate if the picking is already done opw-3547770 Forward-Port-Of: odoo/enterprise#56440 Forward-Port-Of: odoo/enterprise#52764
runbot task: 55516 Forward-Port-Of: odoo/enterprise#56168 Forward-Port-Of: odoo/enterprise#55732
Original PR description
runbot task: 55516 Forward-Port-Of: odoo/enterprise#56168 Forward-Port-Of: odoo/enterprise#55732