Wednesday, September 28, 2022
43 changes · master
Enhancements to existing features
Users can now start creating a payment batch directly from the payments list after selecting at least one payment. This makes batch payment creation easier to find and reduces extra navigation for finance teams.
Original PR description
Add a secondary "call to action" : Create Batch in payments tree view. Visible when min. 1 payment is selected in the list. task-2897152
Resolved issues and error corrections
This update adds coverage around how email thread messages handle escaped content when posted. It helps reduce the risk of incorrectly displayed or unsafe message text in discussions, though the change appears limited and work-in-progress.
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
Miscellaneous changes
Not only on hover - otherwise it makes it very difficult for users to find what field is missing content. Forward-Port-Of: odoo/odoo#101313
Original PR description
Not only on hover - otherwise it makes it very difficult for users to find what field is missing content. Forward-Port-Of: odoo/odoo#101313
Spreadsheet notifications were adjusted to keep working after recent changes in the underlying spreadsheet library. This helps users continue receiving the right alerts and messages while working with spreadsheets in Documents.
Original PR description
Adaptation of the notifications callbacks in the SpreadsheetComponent environment following recent changes in the o_spreadsheet lib. Task 2696839
This update corrects the alignment of text next to an icon in Helpdesk-related screens so the interface appears as intended. It is a small visual fix that improves consistency and readability without changing business workflows.
Original PR description
This commit is the enterprise counterpart of odoo/odoo#100252. After this commit, the text is aligned as expected.
Make the choice of available stock effective (previously the total quantity was always applied). Show warehouses with the most available stock first. Show quantity warning only when appropriate. task: 2985735 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#100946
Original PR description
Make the choice of available stock effective (previously the total quantity was always applied). Show warehouses with the most available stock first. Show quantity warning only when appropriate. task: 2985735 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#100946
Some payment terms with early payment cash discount weren't giving out the correct computation. Example of a problematic set up : Payment term with multiple lines (percentage X, percentage Y, balance) Cash Discount tax computation : mixed The journal items of the invoice and the total amount wouldn't correctly take into account the different discount percentages of the payment term lines. Fixed it by applying the line percentage to the epd lines computation. Forward-Port-Of: odoo/odoo
Original PR description
Some payment terms with early payment cash discount weren't giving out the correct computation. Example of a problematic set up : Payment term with multiple lines (percentage X, percentage Y, balance) Cash Discount tax computation : mixed The journal items of the invoice and the total amount wouldn't correctly take into account the different discount percentages of the payment term lines. Fixed it by applying the line percentage to the epd lines computation. Forward-Port-Of: odoo/odoo#100722
This ports the `text_emojis`, `char_emojis` and `sms_widget` fields to OWL. Enterprise PR: https://github.com/odoo/enterprise/pull/31716 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#100956
Original PR description
This ports the `text_emojis`, `char_emojis` and `sms_widget` fields to OWL. Enterprise PR: https://github.com/odoo/enterprise/pull/31716 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#100956
Current behavior before PR: when we hit shift+enter the oShiftEnter doesnot not triggered. Desired behavior after PR is merged: now when we hit shift+enter oShiftEnter gets triggered. Task id-2991164 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#100813
Original PR description
Current behavior before PR: when we hit shift+enter the oShiftEnter doesnot not triggered. Desired behavior after PR is merged: now when we hit shift+enter oShiftEnter gets triggered. Task id-2991164 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#100813
On windows OS, displayed emojis are bigger than the expected size This commit removes the horizontal scrolbar that would appear on Windows Task-2991415 Forward-Port-Of: odoo/odoo#101261
Original PR description
On windows OS, displayed emojis are bigger than the expected size This commit removes the horizontal scrolbar that would appear on Windows Task-2991415 Forward-Port-Of: odoo/odoo#101261
This PR makes it so that the button to open emojis in composer stays grey when the emoji popover view is opened. The focused behavior of the button is also disabled No tasked linked yet Forward-Port-Of: odoo/odoo#101262
Original PR description
This PR makes it so that the button to open emojis in composer stays grey when the emoji popover view is opened. The focused behavior of the button is also disabled No tasked linked yet Forward-Port-Of: odoo/odoo#101262
Adapt (part of) the `sale.order` & `purchase.order` custom javascript logic to the new OWL framework. 1) `product_configurator_widget` -> `sol_product_many2one` Impacted modules: sale, sale_product_configurator, sale_product_matrix, event_sale, event_booth_sale, sale_renting 2) `matrix_configurator` -> `pol_product_many2one` Impacted module: purchase_product_matrix 3) `product_discount` -> `sol_discount` Impacted module: sale 4) Custom js_class for SO form view is no longer necess
Original PR description
Adapt (part of) the `sale.order` & `purchase.order` custom javascript logic to the new OWL framework. 1) `product_configurator_widget` -> `sol_product_many2one` Impacted modules: sale, sale_product_configurator, sale_product_matrix, event_sale, event_booth_sale, sale_renting 2) `matrix_configurator` -> `pol_product_many2one` Impacted module: purchase_product_matrix 3) `product_discount` -> `sol_discount` Impacted module: sale 4) Custom js_class for SO form view is no longer necessary (and legacy js_class removed from the PO form view) Task-2918791 COM PR: #101304 ENT PR: odoo/enterprise#31854 Co-authored-by: Horacio Tellez Perez <hote@odoo.com> Co-authored-by: Morgane Demesmaeker <edm@odoo.com> Co-authored-by: Valentin Chevalier <vcr@odoo.com> Co-authored-by: Samuel Degueldre <sad@odoo.com> Forward-Port-Of: odoo/odoo#101304
When account.move.line are aggregated (such as in journal items) we do not want to see an aggregated value as it would either be 0 or a possible mix of currencies Signed-off-by: Julien Alardot (jual) <jual@odoo.com> Description of the issue/feature this PR addresses: - In journal item list views grouped by *any*, the amount_currency column is summed to useless data. The data is useless as it is either a 0 sum or a possible sum of several currencies amount. It makes no sense to keep it in
Original PR description
When account.move.line are aggregated (such as in journal items) we do not want to see an aggregated value as it would either be 0 or a possible mix of currencies Signed-off-by: Julien Alardot (jual) <jual@odoo.com> Description of the issue/feature this PR addresses: - In journal item list views grouped by *any*, the amount_currency column is summed to useless data. The data is useless as it is either a 0 sum or a possible sum of several currencies amount. It makes no sense to keep it in the grouped line, only the per item data is useful Current behavior before PR: - In journal item list views grouped by *any*, the **amount_currency** column **is summed** on the grouped line Desired behavior after PR is merged: - In journal item list views grouped by *any*, the **amount_currency** column **is not summed** on the grouped line --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#101333
When adding an image inside a mail composer via the /image command or 'image' button of the editor, the related attachment was never processed. This makes sense as we do not want to attach it to the resulting message(s). However as the attachment res_id and res_model were never updated from the compositor in which they originated, they would become dangling attachments and be garbage collected the next day (or the in the next pass of the GC) by _gc_lost_attachments. This commit adds a step
Original PR description
When adding an image inside a mail composer via the /image command or 'image' button of the editor, the related attachment was never processed. This makes sense as we do not want to attach it to the…
When adding an image inside a mail composer via the /image command or 'image' button of the editor, the related attachment was never processed. This makes sense as we do not want to attach it to the resulting message(s). However as the attachment res_id and res_model were never updated from the compositor in which they originated, they would become dangling attachments and be garbage collected the next day (or the in the next pass of the GC) by _gc_lost_attachments. This commit adds a step to retrieve the attachments embedded in the body by a MediaDialog and link them to the record where the message was posted. Note: These attachments will not be removed when the message is removed, it doesn't seem like they will be removed when the record is deleted either. However as they are embedded in emails as links, it's probably best to leave them for a decent period of time regardless. If not satisfactory, we could add something to autovacuum to remove really old mail attachments that are not referenced by any other record. Alternatively, the images could be added as attachments to the mail but this would probably mess with the presentation or add a bunch of useless attachments to the mail. Task-2860761 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#100952 Forward-Port-Of: odoo/odoo#95537
# Current behaviour If you have an SO, with an SOL that is a service invoiced based on Timesheet's task, with some logged hours (therefor it can be invoiced), the wizard wasn't showing the date range fields to allow user to specify a begin and end date for invoicing. # Expected behaviour You should be able to choose a date in the wizard when you have a service based on timesheet, and "normal invoice" is chosen as a radio option. # Steps to reproduce - Install Sale and Timesheet - Creat
Original PR description
# Current behaviour If you have an SO, with an SOL that is a service invoiced based on Timesheet's task, with some logged hours (therefor it can be invoiced), the wizard wasn't showing the date range…
# Current behaviour If you have an SO, with an SOL that is a service invoiced based on Timesheet's task, with some logged hours (therefor it can be invoiced), the wizard wasn't showing the date range fields to allow user to specify a begin and end date for invoicing. # Expected behaviour You should be able to choose a date in the wizard when you have a service based on timesheet, and "normal invoice" is chosen as a radio option. # Steps to reproduce - Install Sale and Timesheet - Create a Product of type service, invoiced on timesheet, on create task, chose a project (doesn't matter), unit = hours - Create an SO and sell 50 hours of the newly created service, confirm the SO - Log 20 hours on the task related to the sol - Return to the SO and click on "Create Invoice", normally 2 fields for "Date Begin" and "Date End" should be present, but it is not the case. You can test the desired behaviour in version 15.3 and before. # Reason for the problem The xml view was attaching itself after a field `deposit_taxes_id` which is inside a group that is invisible if there are no downpayment. # Fix Attach the xml view after the before mentioned group (`down_payment_specification`), in a separate group of its own, with visibility that depends on `invoicing_timesheet_enabled` field. # Affected versions - 16.0 - master --- opw-2994036 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#101020
It should be possible to quickly search by `amount_company_currency_signed` in `account.payment` view. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#100786
Original PR description
It should be possible to quickly search by `amount_company_currency_signed` in `account.payment` view. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#100786
**Description of the issue/feature this PR addresses:** The website_sale_delivery module adds the shipping method section to the payment page on the website. It checks whether there are multiple methods available to either display the full list or just the one option. **Current behavior before PR:** Before this PR, if there are no shipping methods available, the variable that should contain the len of the recordset, has an empty recordset instead, and a warning is displayed on the lo
Original PR description
**Description of the issue/feature this PR addresses:** The website_sale_delivery module adds the shipping method section to the payment page on the website. It checks whether there are multiple methods available to either display the full list or just the one option. **Current behavior before PR:** Before this PR, if there are no shipping methods available, the variable that should contain the len of the recordset, has an empty recordset instead, and a warning is displayed on the logs because it tries to compare that recordset with an integer. `WARNING test odoo.models: unsupported operand type(s) for "==": 'delivery.carrier()' == '1' (None:70)` **Desired behavior after PR is merged:** After this PR, the variable now defaults to 0 if there are no shipping methods, so the comparison below does not raise a warning. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#101217
The warning should be displayed only on sales journal Also added the fact that the warning now depends on the lock date, if there is a lock date the warning is displayed for entries post lock date, otherwise it's for all the entries Same for the color of the name of the entry, it's now red only if it's post lock date task-id: 2993833 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#101340 Forward-Port-Of: odoo/odoo#100
Original PR description
The warning should be displayed only on sales journal Also added the fact that the warning now depends on the lock date, if there is a lock date the warning is displayed for entries post lock date, otherwise it's for all the entries Same for the color of the name of the entry, it's now red only if it's post lock date task-id: 2993833 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#101340 Forward-Port-Of: odoo/odoo#100955
Since [1] it is possible to request that some blocks are not displayed on mobile devices. This commit adds a similar option to prevent blocks from being displayed on desktops (i.e. on non-mobile devices). This PR also makes the hidden blocks available in the "Invisble Elements" depending on the current display mode. [1]: https://github.com/odoo/odoo/commit/9463f0f889f9dd8da6077895c125da4998a933c0 task-2900730 Description of the issue/feature this PR addresses: Current behavior
Original PR description
Since [1] it is possible to request that some blocks are not displayed on mobile devices. This commit adds a similar option to prevent blocks from being displayed on desktops (i.e. on non-mobile devices). This PR also makes the hidden blocks available in the "Invisble Elements" depending on the current display mode. [1]: https://github.com/odoo/odoo/commit/9463f0f889f9dd8da6077895c125da4998a933c0 task-2900730 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#97495
Purpose ======= Improve the usability of the properties fields. Improve usage of properties fields, add them in project and crm. Specifications ============= Add the properties field on project and task as well as on lead and sales team. Prefetch the properties to improve performance. Allow to display an avatar widget for the relational properties, hide the move arrows if the action can not be done, show the many2many properties even if one record in the list is not accessib
Original PR description
Purpose ======= Improve the usability of the properties fields. Improve usage of properties fields, add them in project and crm. Specifications ============= Add the properties field on project and task as well as on lead and sales team. Prefetch the properties to improve performance. Allow to display an avatar widget for the relational properties, hide the move arrows if the action can not be done, show the many2many properties even if one record in the list is not accessible, improve the behavior of the relational properties when some records can not be accessed. Perform various fixes notably with onchange support and various display tweaks. Task-2965523 Forward-Port-Of: odoo/odoo#100653
This PR improves the payment terms by: - Showing "Payment terms" instead of "Due date" of the user has selected payment terms - Auto-fill the amount and date example in the dynamic preview of the payment terms if the user opens the payments terms popup. Forward-Port-Of: odoo/odoo#100735
Original PR description
This PR improves the payment terms by: - Showing "Payment terms" instead of "Due date" of the user has selected payment terms - Auto-fill the amount and date example in the dynamic preview of the payment terms if the user opens the payments terms popup. Forward-Port-Of: odoo/odoo#100735
Description of the issue/feature this PR addresses: In Bootstrap 5, the `container` class was updated to use variables for its left/right paddings. This seems to conflict with wkhtmltopdf, and no paddings are added, shifting all reports. This introduces the set paddings defined in Bootstrap 4 for the reports. Also with Bootstrap 5, the `table-borderless` class wasn't working properly on the PDFs either, as the borders were still visible. This removes all borders within a `table-borderless`.
Original PR description
Description of the issue/feature this PR addresses: In Bootstrap 5, the `container` class was updated to use variables for its left/right paddings. This seems to conflict with wkhtmltopdf, and no…
Description of the issue/feature this PR addresses: In Bootstrap 5, the `container` class was updated to use variables for its left/right paddings. This seems to conflict with wkhtmltopdf, and no paddings are added, shifting all reports. This introduces the set paddings defined in Bootstrap 4 for the reports. Also with Bootstrap 5, the `table-borderless` class wasn't working properly on the PDFs either, as the borders were still visible. This removes all borders within a `table-borderless`. Current behavior before PR: Product's dymo label : (Inventory -> Products -> Products -> Any consumable/storable product -> Print labels -> Dymo)  Product's "2x7 with price" label : (Inventory -> Products -> Products -> Any consumable/storable product -> Print labels -> 2 x 7 with price)  Reception report label : (Need to enable Reception report in Inventory settings) (Inventory -> Receipts -> Any transfer with allocation stat button available -> Print labels)  Desired behavior after PR is merged: Product's dymo label : (Inventory -> Products -> Products -> Any consumable/storable product -> Print labels -> Dymo)  Product's "2x7 with price" label : (Inventory -> Products -> Products -> Any consumable/storable product -> Print labels -> 2 x 7 with price)  Reception report label : (Need to enable Reception report in Inventory settings) (Inventory -> Receipts -> Any transfer with allocation stat button available -> Print labels)  Note: Those screenshots were taken using a temporary fix for custom paperformats currently not applying. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#101005
Opening the account move line form view from here is not useful, as most would do it only to access the move behind it. In order to display more relevant information, the move line on the analytic line form view will instead directly open the account move of the move line. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#101159
Original PR description
Opening the account move line form view from here is not useful, as most would do it only to access the move behind it. In order to display more relevant information, the move line on the analytic line form view will instead directly open the account move of the move line. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#101159
Forward-Port-Of: odoo/odoo#101203
Original PR description
Forward-Port-Of: odoo/odoo#101203
This PRs fixes an issue where an emoji stayed greyed-out when hovered, and the popover is scrolled This fix create a field to hover an emoji, and the field can only hold one emoji view at a time Task-2998153 Forward-Port-Of: odoo/odoo#101361
Original PR description
This PRs fixes an issue where an emoji stayed greyed-out when hovered, and the popover is scrolled This fix create a field to hover an emoji, and the field can only hold one emoji view at a time Task-2998153 Forward-Port-Of: odoo/odoo#101361
This PR does 2 things: 1) It renames the 'o_view_sample_data' class to 'o_legacy_view_sample_data' in legacy views to allow new views to use different sets of rules. 2) It also defines new rules to disable elements in views using sample data. Previously, this was done by setting a 'o_view_sample_data' class on the view and then setting another class 'o_sample_data_disabled' on elements which had to be disabled. Now, the logic determining which elements are disabled has been moved t
Original PR description
This PR does 2 things: 1) It renames the 'o_view_sample_data' class to 'o_legacy_view_sample_data' in legacy views to allow new views to use different sets of rules. 2) It also defines new rules to disable elements in views using sample data. Previously, this was done by setting a 'o_view_sample_data' class on the view and then setting another class 'o_sample_data_disabled' on elements which had to be disabled. Now, the logic determining which elements are disabled has been moved to each view's SCSS file to avoid polluting the templates with redundant class assignations. A mixin (o-sample-data-disabled) has been defined in the SCSS utils to have the same rules on these elements. Enterprise PR: https://github.com/odoo/enterprise/pull/31164 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#99831
For the sake of consistency with the other website content views, this commit removes the `toggle_button` widget to display the `is_published` field in the jobs list view. Forward-Port-Of: odoo/odoo#101413
Original PR description
For the sake of consistency with the other website content views, this commit removes the `toggle_button` widget to display the `is_published` field in the jobs list view. Forward-Port-Of: odoo/odoo#101413
This commit simply enables a custom prop for the Dialog component so that it can have a hand-picked background instead of the default 'white'. Will notably be useful for the social images carousel where we need a dark background. Task-2855647 Forward-Port-Of: odoo/odoo#101450
Original PR description
This commit simply enables a custom prop for the Dialog component so that it can have a hand-picked background instead of the default 'white'. Will notably be useful for the social images carousel where we need a dark background. Task-2855647 Forward-Port-Of: odoo/odoo#101450
Purpose ======= Keep iterating on the UI & Onboarding of Survey as we plan to massively distribute it with the new Saas formula (installed by default). Specs ======= * Changed the look and feel of the Action Helper inside the Surveys * Changed the Default Feedback Form: end message modified and two layers removed task-2901947 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#101263
Original PR description
Purpose ======= Keep iterating on the UI & Onboarding of Survey as we plan to massively distribute it with the new Saas formula (installed by default). Specs ======= * Changed the look and feel of the Action Helper inside the Surveys * Changed the Default Feedback Form: end message modified and two layers removed task-2901947 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#101263
Add the property fields on the knowledge.article model and display them on article items form view only (if is_article_item = True). The property panel should be hidden if no properties are configured on the article item yet. Once an article item has some properties, the property field should be displayed directly at load. Like the chatter, a toggle button can be used to hide/show the property panel. Task-2993944 Co-authored-by: adb-msyukyu-odoo <abd@odoo.com> Forward-Port-Of: odoo
Original PR description
Add the property fields on the knowledge.article model and display them on article items form view only (if is_article_item = True). The property panel should be hidden if no properties are configured on the article item yet. Once an article item has some properties, the property field should be displayed directly at load. Like the chatter, a toggle button can be used to hide/show the property panel. Task-2993944 Co-authored-by: adb-msyukyu-odoo <abd@odoo.com> Forward-Port-Of: odoo/enterprise#31726
Task-2855647 Forward-Port-Of: odoo/enterprise#31944
Original PR description
Task-2855647 Forward-Port-Of: odoo/enterprise#31944
This PR does 2 things: 1) It renames the 'o_view_sample_data' class to 'o_legacy_view_sample_data' in legacy views to allow new views to use different sets of rules. 2) It also defines new rules to disable elements in views using sample data. Previously, this was done by setting a 'o_view_sample_data' class on the view and then setting another class 'o_sample_data_disabled' on elements which had to be disabled. Now, the logic determining which elements are disabled has been moved to
Original PR description
This PR does 2 things: 1) It renames the 'o_view_sample_data' class to 'o_legacy_view_sample_data' in legacy views to allow new views to use different sets of rules. 2) It also defines new rules to disable elements in views using sample data. Previously, this was done by setting a 'o_view_sample_data' class on the view and then setting another class 'o_sample_data_disabled' on elements which had to be disabled. Now, the logic determining which elements are disabled has been moved to each view's SCSS file to avoid polluting the templates with redundant class assignations. A mixin (o-sample-data-disabled) has been defined in the SCSS utils to have the same rules on these elements. Community PR: https://github.com/odoo/odoo/pull/99831 Forward-Port-Of: odoo/enterprise#31164
This commit allows to display the favorites children in the side bar. Drag and drop of those children is not allowed. Drag and drop under or between those children is not allowed. Task-2985026 Forward-Port-Of: odoo/enterprise#31890
Original PR description
This commit allows to display the favorites children in the side bar. Drag and drop of those children is not allowed. Drag and drop under or between those children is not allowed. Task-2985026 Forward-Port-Of: odoo/enterprise#31890
Forward-Port-Of: odoo/enterprise#31819
Original PR description
Forward-Port-Of: odoo/enterprise#31819
# Current behaviour In Studio, when removing all options available from the priority widget and saving, you get a stacktrace, and subsequent access to the view also triggers a stacktrace. # Expected behaviour You shouldn't be able to save a selection widget with no default/fallback option. # Steps to reproduce - Install Project and Studio - Go to Project, choose whatever project - Select an item and activate Studio - Add a Priority Field to the form view - Select the Priority widget
Original PR description
# Current behaviour In Studio, when removing all options available from the priority widget and saving, you get a stacktrace, and subsequent access to the view also triggers a stacktrace. # Expected…
# Current behaviour
In Studio, when removing all options available from the priority widget and saving, you get a stacktrace, and subsequent access to the view also triggers a stacktrace.
# Expected behaviour
You shouldn't be able to save a selection widget with no default/fallback option.
# Steps to reproduce
- Install Project and Studio
- Go to Project, choose whatever project
- Select an item and activate Studio
- Add a Priority Field to the form view
- Select the Priority widget and select "Edit values" in the property tab
- Remove all options from the widget and save
- You will get a stacktrace and also everytime you try to access the view you added the widget to (in our case all tasks)
# Reason for the problem
If you save a selection widget with no options, no child `<li>` are appended, and when we try to retrieve them later on with a `closest('li')` and index it at `[0]`, it triggers a TypeError, since no `<li>` were found.
# Fix
Show a warning when trying to save a selection field with no options at all. This behaviour is similar to the already present warning messages when trying to save relational fields that have no relation specified.
# Affected versions
- 14.0
- 15.0
- saas-15.2
- saas-15.3
- 16.0
- master
---
opw-2993954
Forward-Port-Of: odoo/enterprise#31868
Forward-Port-Of: odoo/enterprise#31709The newly created soda importing functionality wasn t reading all the soda files given. This was because of a wrongly assigned file format This PR fixes this behaviour. Related : #30680 Forward-Port-Of: odoo/enterprise#31790
Original PR description
The newly created soda importing functionality wasn t reading all the soda files given. This was because of a wrongly assigned file format This PR fixes this behaviour. Related : #30680 Forward-Port-Of: odoo/enterprise#31790
Adapt (part of) the `sale.order` custom javascript logic to the new OWL framework. 1) `product_configurator_widget` -> `sol_product_many2one` Impacted modules: sale, sale_product_configurator, sale_product_matrix, event_sale, event_booth_sale, sale_renting 2) `matrix_configurator` -> `pol_product_many2one` Impacted module: purchase_product_matrix 3) `product_discount` -> `sol_discount` Impacted module: sale 4) Custom js_class for SO form view is no longer necessary (and legacy js_
Original PR description
Adapt (part of) the `sale.order` custom javascript logic to the new OWL framework. 1) `product_configurator_widget` -> `sol_product_many2one` Impacted modules: sale, sale_product_configurator, sale_product_matrix, event_sale, event_booth_sale, sale_renting 2) `matrix_configurator` -> `pol_product_many2one` Impacted module: purchase_product_matrix 3) `product_discount` -> `sol_discount` Impacted module: sale 4) Custom js_class for SO form view is no longer necessary (and legacy js_class removed from the PO form view) Task-2918791 COM PR: #101304 ENT PR: odoo/enterprise#31854 Co-authored-by: Horacio Tellez Perez <hote@odoo.com> Co-authored-by: Samuel Degueldre <sad@odoo.com> Forward-Port-Of: odoo/enterprise#31854
Forward-Port-Of: odoo/enterprise#31815
Original PR description
Forward-Port-Of: odoo/enterprise#31815
Before this PR, the created entries of an automatic transfer were created on the first day of the next period. This PR: - fixes this by creating the entry on the last day of the current period - fixes a bug where all automatic transfers from all companies were shown (in a multi-company environment) instead of the ones from the currently selected companies - improves the automatic transfers by having a default journal when creating a new record task-id 2276618 Forward-Port-Of: odoo/ente
Original PR description
Before this PR, the created entries of an automatic transfer were created on the first day of the next period. This PR: - fixes this by creating the entry on the last day of the current period - fixes a bug where all automatic transfers from all companies were shown (in a multi-company environment) instead of the ones from the currently selected companies - improves the automatic transfers by having a default journal when creating a new record task-id 2276618 Forward-Port-Of: odoo/enterprise#31862 Forward-Port-Of: odoo/enterprise#30701
The `Tablet` component hosts two forms (mrp.workorder and quality.check). Instead of implementing the feature of pedal_form to one of the two forms (previously in mrp.workorder), we are now implementing it on top of the `Tablet` component. For future reference, we note the following: - IoT triggers are defined in the work centers. - When the `Tablet` component is rendered, we instantiate the device controllers and start listening before the willStart hook ends. - During the operational t
Original PR description
The `Tablet` component hosts two forms (mrp.workorder and quality.check). Instead of implementing the feature of pedal_form to one of the two forms (previously in mrp.workorder), we are now…
The `Tablet` component hosts two forms (mrp.workorder and quality.check). Instead of implementing the feature of pedal_form to one of the two forms (previously in mrp.workorder), we are now implementing it on top of the `Tablet` component. For future reference, we note the following: - IoT triggers are defined in the work centers. - When the `Tablet` component is rendered, we instantiate the device controllers and start listening before the willStart hook ends. - During the operational time of the `Tablet` component, when a trigger is pressed, a corresponding barcode event, prefixed with `O-BTN.`, will be triggered and the barcode service will handle the event by automatically clicking the button with appropriate barcode_trigger. - When leaving the `Tablet` component, the listeners are stopped. - The status button is put on top of the step items and is hidden if there are no iot triggers. <img width="1512" alt="Screenshot 2022-09-27 at 15 35 07" src="https://user-images.githubusercontent.com/3245568/192541537-e818ca8e-8684-4678-bec5-8e4181c85554.png"> Forward-Port-Of: odoo/enterprise#31849
This adapts the relevant files to the OWL port of the `emojis_char` and `emojis_text` fields. Community PR: https://github.com/odoo/odoo/pull/100956 Forward-Port-Of: odoo/enterprise#31716
Original PR description
This adapts the relevant files to the OWL port of the `emojis_char` and `emojis_text` fields. Community PR: https://github.com/odoo/odoo/pull/100956 Forward-Port-Of: odoo/enterprise#31716
There was a race condition between the handlers of the blur and click events for date boxes. If the blur is handled first, the boxes are removed from the DOM and the click fails as it happens on an element which isn't present. For the other field's boxes, there was no issue as the mousedown event was prevented and the field wasn't losing focus, letting the boxes mounted. For the date fields, the mousedown event wasn't prevented as it was used to hide the calendar dropdown for UI feedback.
Original PR description
There was a race condition between the handlers of the blur and click events for date boxes. If the blur is handled first, the boxes are removed from the DOM and the click fails as it happens on an element which isn't present. For the other field's boxes, there was no issue as the mousedown event was prevented and the field wasn't losing focus, letting the boxes mounted. For the date fields, the mousedown event wasn't prevented as it was used to hide the calendar dropdown for UI feedback. In this new version, the mousedown event is always prevented and a fake ESC keypress is triggered for date fields to hide the calendar. This also has the benefit that the boxes are still displayed after a click which is better for the user experience. Original PR : #31594 Forward-Port-Of: odoo/enterprise#31853
The early payment cash discount with a mixed cash computation and multiple payment term lines was corrected. Adapted the reconciliation widget expected test results to the new and correct computation. see https://github.com/odoo/odoo/pull/100722. Forward-Port-Of: odoo/enterprise#31766
Original PR description
The early payment cash discount with a mixed cash computation and multiple payment term lines was corrected. Adapted the reconciliation widget expected test results to the new and correct computation. see https://github.com/odoo/odoo/pull/100722. Forward-Port-Of: odoo/enterprise#31766