Wednesday, November 27, 2024
21 changes · saas-17.2
Miscellaneous changes
Oversight of odoo/enterprise#73209. Service invoices don't use the reason field at all (hidden in view) and thus will always fail the constraint. To fix it, disable the constraint for service invoices. opw-4354637 Forward-Port-Of: odoo/enterprise#74552
Original PR description
Oversight of odoo/enterprise#73209. Service invoices don't use the reason field at all (hidden in view) and thus will always fail the constraint. To fix it, disable the constraint for service invoices. opw-4354637 Forward-Port-Of: odoo/enterprise#74552
Apply [this fix] to templates introduced with [this commit]. The purpose is to prevent images that are the only child of their parent from taking too much space. Furthermore, fix the src path for some of these templates. [this fix]: https://github.com/odoo/odoo/commit/d5297a75f50022b406b226ebf4c300f4bd033c3d [this commit]: https://github.com/odoo/enterprise/commit/fd98660e352512e0b74d91958707687978154833 task-4178640 Forward-Port-Of: odoo/enterprise#74192
Original PR description
Apply [this fix] to templates introduced with [this commit]. The purpose is to prevent images that are the only child of their parent from taking too much space. Furthermore, fix the src path for some of these templates. [this fix]: https://github.com/odoo/odoo/commit/d5297a75f50022b406b226ebf4c300f4bd033c3d [this commit]: https://github.com/odoo/enterprise/commit/fd98660e352512e0b74d91958707687978154833 task-4178640 Forward-Port-Of: odoo/enterprise#74192
Steps ----- - Subscriptions > Configuration > Alerts. - Create an alert triggered when the stage goes from 'Initial' (placeholder) to 'In Progress', set 'Create next activity', chose Email as activity. - Create a subscription, confirm it. ** Multiple activities created in the chatter (1 would be expected) ** Cause ----- The `pre_domain_filter` of the `base.automation` is not set, leading to an activity being created every time a write happens on the sale order while it is in the `s
Original PR description
Steps ----- - Subscriptions > Configuration > Alerts. - Create an alert triggered when the stage goes from 'Initial' (placeholder) to 'In Progress', set 'Create next activity', chose Email as activity. - Create a subscription, confirm it. ** Multiple activities created in the chatter (1 would be expected) ** Cause ----- The `pre_domain_filter` of the `base.automation` is not set, leading to an activity being created every time a write happens on the sale order while it is in the `stage_to_id` stage. Change ----- Add a pre-domain/domain filter to only trigger actions when the stage changes. opw-4273625 Forward-Port-Of: odoo/enterprise#74292 Forward-Port-Of: odoo/enterprise#73601
In the test I added in 16ad0830fd71d4dbf719471c8f303372da3f7e09, the id should be the one of the item and not the request. The test only works if the request and item have the same id, breaking nightly runbot builds. Forward-Port-Of: odoo/enterprise#74508
Original PR description
In the test I added in 16ad0830fd71d4dbf719471c8f303372da3f7e09, the id should be the one of the item and not the request. The test only works if the request and item have the same id, breaking nightly runbot builds. Forward-Port-Of: odoo/enterprise#74508
Otherwise the patches remain in place, and it's possible for other modules to just assume things work if they happen to run after `test_website`. Forward-Port-Of: odoo/odoo#188608
Original PR description
Otherwise the patches remain in place, and it's possible for other modules to just assume things work if they happen to run after `test_website`. Forward-Port-Of: odoo/odoo#188608
This commit fixes two issues with the editable grouped list view. In a group, click on a row to switch it into edition and edit an input field (e.g. a char). Do not blur the input. From this state, - clicking on the group header to close the group, or - clicking on "Add a line" to add a new record would both lead to the change being lost. This commit ensures the keep the change in those flows by correctly calling `leaveEditMode` before closing the group or adding the new record. opw~41
Original PR description
This commit fixes two issues with the editable grouped list view. In a group, click on a row to switch it into edition and edit an input field (e.g. a char). Do not blur the input. From this state, - clicking on the group header to close the group, or - clicking on "Add a line" to add a new record would both lead to the change being lost. This commit ensures the keep the change in those flows by correctly calling `leaveEditMode` before closing the group or adding the new record. opw~4174315 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#188611
Release notes: https://github.com/odoo/owl/releases/tag/v2.5.0 https://github.com/odoo/owl/releases/tag/v2.5.1 Forward-Port-Of: odoo/odoo#188406
Original PR description
Release notes: https://github.com/odoo/owl/releases/tag/v2.5.0 https://github.com/odoo/owl/releases/tag/v2.5.1 Forward-Port-Of: odoo/odoo#188406
In a previous commit [1], we reduced the number of call to the getter `editedRecord` which does a heavy operation. In `DynamicList.leaveEditMode` we saved the edited record but it could become outdated so we need to compute at some point. [1]: b1191a7b99d5e374f92b62c541ac058cff26d4d7 Forward-Port-Of: odoo/odoo#188610
Original PR description
In a previous commit [1], we reduced the number of call to the getter `editedRecord` which does a heavy operation. In `DynamicList.leaveEditMode` we saved the edited record but it could become outdated so we need to compute at some point. [1]: b1191a7b99d5e374f92b62c541ac058cff26d4d7 Forward-Port-Of: odoo/odoo#188610
Steps to reproduce: - create two workcenters, one having a shift with a lunch pause (WC A) (i.e. the default 40hours week will do the job), the other having no lunch pause (WC B). - create a MO with a work order of a sufficient duration to be splitted in two part (before and after lunch) (6h for instance) and add it on the WC A. - plan the MO - go to the planning by workcenter view - move the WO from WC A to WC B (in the same day) - move it back to WC A (in the same day) - move the WO a
Original PR description
Steps to reproduce: - create two workcenters, one having a shift with a lunch pause (WC A) (i.e. the default 40hours week will do the job), the other having no lunch pause (WC B). - create a MO with…
Steps to reproduce: - create two workcenters, one having a shift with a lunch pause (WC A) (i.e. the default 40hours week will do the job), the other having no lunch pause (WC B). - create a MO with a work order of a sufficient duration to be splitted in two part (before and after lunch) (6h for instance) and add it on the WC A. - plan the MO - go to the planning by workcenter view - move the WO from WC A to WC B (in the same day) - move it back to WC A (in the same day) - move the WO a day later (on the same WC) Problem: The duration displayed changes from 6h (correct one) to 7h on the first step, which is incorrect. Moving the MO back to it's original WC will change the time to 5h which is also incorrect, but moving it a day later fixes the issue (6h) The problem is that computing the date_finished in the write method is incorrect when `workcenter_id` is in vals, as calling `_calculate_date_finished` will return the value computed with the non-modified yet workcenter opw-4321104 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187864
The issue: In the mobile view of the website page /profile/users, the ranking table's content overflows the screen. How to reproduce the issue: -Install the website_profile and website_slides_survey modules. -Go to the /profile/users page in the website view. -Switch to mobile view. Explanation: Table overflowed on smaller screens due to missing responsive wrapper. opw-4120453 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of
Original PR description
The issue: In the mobile view of the website page /profile/users, the ranking table's content overflows the screen. How to reproduce the issue: -Install the website_profile and website_slides_survey modules. -Go to the /profile/users page in the website view. -Switch to mobile view. Explanation: Table overflowed on smaller screens due to missing responsive wrapper. opw-4120453 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183291
Steps to reproduce: - go to Employees>Configuration>Skill Types - create new skill or edit an existing one - change name or progress percentage of levels or add a new level - toggle default level - The fields revert to their original state, and only the toggle switch cause: it does not save other fields and just saves the default button when clicked solution: add this.props.record.model.root.save(); so it saves the record and not just the toggle button only. task-4223036 Forwa
Original PR description
Steps to reproduce: - go to Employees>Configuration>Skill Types - create new skill or edit an existing one - change name or progress percentage of levels or add a new level - toggle default level - The fields revert to their original state, and only the toggle switch cause: it does not save other fields and just saves the default button when clicked solution: add this.props.record.model.root.save(); so it saves the record and not just the toggle button only. task-4223036 Forward-Port-Of: odoo/odoo#183369
Issue: ====== `enter` command doesnt work properly for `pre` element inside list element. Steps to reproduce the issue: ============================= - Add a list - Add a code block with `/code` - Add sone text - Put the cursor at the end of the text - click `enter` - It adds a `br` element and puts the selection at the start. Origin of the issue: ==================== The `oEnter` function of the `pre` element is triggered which adds a `p` element just after the `pre` element in
Original PR description
Issue: ====== `enter` command doesnt work properly for `pre` element inside list element. Steps to reproduce the issue: ============================= - Add a list - Add a code block with `/code` - Add sone text - Put the cursor at the end of the text - click `enter` - It adds a `br` element and puts the selection at the start. Origin of the issue: ==================== The `oEnter` function of the `pre` element is triggered which adds a `p` element just after the `pre` element inside the same `li` element. Now in sanitiwe we unwrap the p elements inside `li` which leaves us with only a `br` after the `pre`. Since we put the selection at the start of the newly added then removed `p` element, the final selection will not behave correctly. Solution: ========= We single out the case when the parent element of the `pre` is a `li` and treat it as a break inside a `li`. task-4187676 Forward-Port-Of: odoo/odoo#188056 Forward-Port-Of: odoo/odoo#180268
Currently, customers are unable to invoice orders through a pos session if they use the Bulgarian localization. Steps to reproduce: ------------------- * Install **point_of_sale** and **l10n_bg** * Change the current company to the Bulgarian one * Set up a shop and open it * Make an order, select any customer * Select payment * Select the invoice option * Select payment method and validate > Observation: Traceback appears psycopg2.errors.CheckViolation: new row for relation "accou
Original PR description
Currently, customers are unable to invoice orders through a pos session if they use the Bulgarian localization. Steps to reproduce: ------------------- * Install **point_of_sale** and **l10n_bg** *…
Currently, customers are unable to invoice orders through a pos session if they use the Bulgarian localization. Steps to reproduce: ------------------- * Install **point_of_sale** and **l10n_bg** * Change the current company to the Bulgarian one * Set up a shop and open it * Make an order, select any customer * Select payment * Select the invoice option * Select payment method and validate > Observation: Traceback appears psycopg2.errors.CheckViolation: new row for relation "account_move_line" violates check constraint "account_move_line_check_accountable_required_fields" Why the fix: ------------ The constraints is violated because the value for account_id does not exist. https://github.com/odoo/odoo/blob/4601acea15feea4780269b4a333f18435904b684/addons/point_of_sale/models/pos_payment.py#L115-L117 We observe that `self.company_id.account_default_pos_receivable_account_id.id` is not set. This field belogns to the `account` module but can only be modified if the module `account_accountant` because of the group `group_account_readonly`. https://github.com/odoo/odoo/blob/4601acea15feea4780269b4a333f18435904b684/addons/point_of_sale/views/res_config_settings_views.xml#L163-L167 Other localizations do not have the issue as they set the default account through the data in `account`module. https://github.com/odoo/odoo/blob/4601acea15feea4780269b4a333f18435904b684/addons/l10n_au/data/account_chart_template_data.xml#L14 https://github.com/odoo/odoo/blob/4601acea15feea4780269b4a333f18435904b684/addons/l10n_au/data/account.account.template.csv#L8 opw-4279804 Forward-Port-Of: odoo/odoo#188018 Forward-Port-Of: odoo/odoo#186551
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#188190
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#188190
**Problem**: This commit: https://github.com/odoo/odoo/commit/655e1ea63cf469937c53762e93f93da40b6b9099 breaks the behavior of the `list_renderer` when an autocomplete is present in the same view. Specifically, it prevents discarding a row when clicking outside the input. **Solution**: Revert the commit, as the issue it aimed to fix (opw-3180055) is now resolved by the addition of the "Search more" functionality, rendering the commit unnecessary. **Steps to reproduce**: 1. Open the *Pu
Original PR description
**Problem**: This commit: https://github.com/odoo/odoo/commit/655e1ea63cf469937c53762e93f93da40b6b9099 breaks the behavior of the `list_renderer` when an autocomplete is present in the same view. Specifically, it prevents discarding a row when clicking outside the input. **Solution**: Revert the commit, as the issue it aimed to fix (opw-3180055) is now resolved by the addition of the "Search more" functionality, rendering the commit unnecessary. **Steps to reproduce**: 1. Open the *Purchase* tab on a product form. 2. Add a vendor line (with or without selecting a vendor). 3. Focus on the vendor line, then click to add *Vendor Taxes*. 4. After selecting a tax, observe that the focus incorrectly shifts back to the vendor line instead of remaining on the *Vendor Taxes* input. opw-4263276 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187872
Basic user can close a PoS session that they did not open if the user logged on the DB is the same as the one linked to the cashier Steps to reproduce: ------------------- * Setup Mitchell Admin as advanced right user on PoS * Setup Marc Demo as basic right user on PoS * Open PoS as Mitchell Admin and login as cashier Marc Demo > Observation: You are not able to close the session * Log out of the Db and log back in as Marc Demo * Open the same PoS > Observation: You are able to close
Original PR description
Basic user can close a PoS session that they did not open if the user logged on the DB is the same as the one linked to the cashier Steps to reproduce: ------------------- * Setup Mitchell Admin as advanced right user on PoS * Setup Marc Demo as basic right user on PoS * Open PoS as Mitchell Admin and login as cashier Marc Demo > Observation: You are not able to close the session * Log out of the Db and log back in as Marc Demo * Open the same PoS > Observation: You are able to close the session Why the fix: ------------ To check if a user was able to close the session we were checking if the user logged in the Db was the same as the one in the cashier. But we need to check who opened the PoS not the current logged in user. opw-4215083 Forward-Port-Of: odoo/odoo#188121
*: web_editor, website For some reason, the tour introduced by [1] started failing on the runbot for its 17.0 version, showcasing turnstile errors. Not sure why but this tour should never have been making external calls to video URL anyway and solving that seems to solve the main issue. Specific turnstile problems will be investigated later. [1]: https://github.com/odoo/odoo/commit/2789b50bc72cc801fbd5005f74e2cd2655040cbb runbot-107885
Original PR description
*: web_editor, website
For some reason, the tour introduced by [1] started failing on the
runbot for its 17.0 version, showcasing turnstile errors. Not sure why
but this tour should never have been making external calls to video URL
anyway and solving that seems to solve the main issue.
Specific turnstile problems will be investigated later.
[1]: https://github.com/odoo/odoo/commit/2789b50bc72cc801fbd5005f74e2cd2655040cbb
runbot-107885
Forward-Port-Of: odoo/odoo#188214### Description of the issue/feature this PR addresses: On selecting multiple cells in a table and applying formatting commands like (Bold, Italic, Underline, and Strikethrough) resulted in the loss of selection. The root cause of this issue was identified in the `cleanForSave()` function, which triggered `deselectTable()` during command execution, removing the entire selection from the table results in collapsing the selection to start. ### Approach: This PR addresses the issue by rest
Original PR description
### Description of the issue/feature this PR addresses: On selecting multiple cells in a table and applying formatting commands like (Bold, Italic, Underline, and Strikethrough) resulted in the loss…
### Description of the issue/feature this PR addresses: On selecting multiple cells in a table and applying formatting commands like (Bold, Italic, Underline, and Strikethrough) resulted in the loss of selection. The root cause of this issue was identified in the `cleanForSave()` function, which triggered `deselectTable()` during command execution, removing the entire selection from the table results in collapsing the selection to start. ### Approach: This PR addresses the issue by restoring selection using `historyResetLatestComputedSelection()` after executing the command, ensuring that the selection is preserved as intended. Additionally, a specific issue related to applying heading tags was encountered, stemming from the call to `getDeepRange()` within the `formatSelection()` function, disrupting proper selection restoration, particularly in the case of headings. ### Desired behavior after PR is merged: We maintain the selection after applying formatting commands (Bold, Italic, Underline, and Strikethrough) in table. task-3822527 Forward-Port-Of: odoo/odoo#188452 Forward-Port-Of: odoo/odoo#165089
Before this commit, all fields of product tags were loaded into PoS, which was unnecessary. For example, product templates field and product variants field, which contain all products with that tag, were loaded. This caused performance issues when there were a high number of products using tags. This commit fixes the issue by only loading the name field, which is needed in PoS. opw-4343131 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Po
Original PR description
Before this commit, all fields of product tags were loaded into PoS, which was unnecessary. For example, product templates field and product variants field, which contain all products with that tag, were loaded. This caused performance issues when there were a high number of products using tags. This commit fixes the issue by only loading the name field, which is needed in PoS. opw-4343131 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188405
Issue ===== When a GS1 barcode is scanned, if it starts with a FNC1, it can't be parsed. How to reproduce ================ - In Inventory Settings, select "Default GS1 Nomenclature" as the used nomenclature; - Create a product with a valid EAN13 as barcode (eg. 1234567891231); - Open the Barcode app, then the Inventory Adjustments; - Scan a GS1 barcode for the created product who start with the FNC1 (eg. "\x1D0101234567891231") -> The product's barcode is not decoded. Solution
Original PR description
Issue ===== When a GS1 barcode is scanned, if it starts with a FNC1, it can't be parsed. How to reproduce ================ - In Inventory Settings, select "Default GS1 Nomenclature" as the used nomenclature; - Create a product with a valid EAN13 as barcode (eg. 1234567891231); - Open the Barcode app, then the Inventory Adjustments; - Scan a GS1 barcode for the created product who start with the FNC1 (eg. "\x1D0101234567891231") -> The product's barcode is not decoded. Solution ======== To fix this issue, before to be parsed, the given barcode will be cleaned and if it starts with a FNC1, it will be removed from the string. opw-4118637 Forward-Port-Of: odoo/odoo#187925 Forward-Port-Of: odoo/odoo#187875
This commit fixes a bug introduced in the PR ( https://github.com/odoo/odoo/pull/186434 ). This PR aims to batch operations on svls by grouping based on products. However, it didn't take into account the possibility where svls could belong to different companies. This would lead to a singleton error upon referencing the field "anglo_saxon_accounting". To fix the problem, grouping svls must be done based on a composite key based on product and value of "anglo_saxon_accounting". --- I con
Original PR description
This commit fixes a bug introduced in the PR ( https://github.com/odoo/odoo/pull/186434 ). This PR aims to batch operations on svls by grouping based on products. However, it didn't take into account the possibility where svls could belong to different companies. This would lead to a singleton error upon referencing the field "anglo_saxon_accounting". To fix the problem, grouping svls must be done based on a composite key based on product and value of "anglo_saxon_accounting". --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188680