Wednesday, November 9, 2022
39 changes · master
Enhancements to existing features
This update tightens internal code quality rules so unused error details are handled more cleanly across several Odoo apps. It helps keep the codebase easier to maintain and reduces avoidable inconsistencies, with no expected change for end users.
Original PR description
We removed the option that allowed the non-used argument on the catch block (they musted have its name begining with '_'). Now, if the argument on the catch block is not needed, we can simply use the optional catch binding.
This update strengthens automated quality checks for Google Calendar and website sale loyalty test code by detecting duplicate keys, arguments, and conditional branches. It helps prevent avoidable coding mistakes from entering the product, improving maintainability with no direct user-facing change.
Original PR description
*: google_calendar, website_sale_loyalty
rules enabled :
- no-dupe-keys
- no-dupe-args
- no-dupe-else-ifThe Documents app now shows a more helpful message when a workspace configuration would create a circular setup. This helps users understand what to avoid and correct the issue faster instead of seeing a vague recursion error.
Original PR description
…ror message
This update standardizes how unused error details are handled in background code across several Odoo Enterprise apps. It is an internal code quality improvement that helps keep the codebase consistent and easier to maintain, with no expected change for end users.
Original PR description
We removed the option that allowed the non-used argument on the catch block (they musted have its name begining with '_'). Now, if the argument on the catch block is not needed, we can simply use the optional catch binding. Comunity : https://github.com/odoo/odoo/pull/105433
This update enables an automated check that prevents duplicate settings in several Odoo Enterprise modules. It helps reduce small code mistakes and improves long-term reliability without changing day-to-day user workflows.
Original PR description
*: account_accountant, documents_spreadsheet, hr_payroll,
pos_blackbox_be, sign
Community : https://github.com/odoo/odoo/pull/105398Resolved issues and error corrections
This fixes an issue where settings form labels could fail when they already had custom styling applied. It improves reliability for users and administrators configuring settings pages without changing the visible behavior.
Original PR description
Before this commit when compiling a label with an existing class parameter it didn't pass the validation props since class isn't expected. This commit fix this by adding the doNotCopyAttributes. We add a custom class in the test that will crash without this fix. Task-3044750 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
To Reproduce ============ - enable QR code on Accounting settings - with a customer who has a bank account create a credit note for him/her - in other info tab, make sure that the qr code method is empty - send or print the credit note The Problem =========== the qr code method field will be filled with SEPA, and a QR code will be added to the PDF Solution ======== Generating a QR code for a credit note doesn't make any sense, so the qr code method field must be hidden and n
Original PR description
To Reproduce ============ - enable QR code on Accounting settings - with a customer who has a bank account create a credit note for him/her - in other info tab, make sure that the qr code method is empty - send or print the credit note The Problem =========== the qr code method field will be filled with SEPA, and a QR code will be added to the PDF Solution ======== Generating a QR code for a credit note doesn't make any sense, so the qr code method field must be hidden and no QR code should be generated. opw-3010649 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#105281 Forward-Port-Of: odoo/odoo#104496
Prevent the PowerBox command bar to open in the website navigation bar. task-3040872 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#104414
Original PR description
Prevent the PowerBox command bar to open in the website navigation bar. task-3040872 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#104414
Purpose ======= In the case a time off is created: - In the past - Using support documents An invalid user error is raised in the interface, because the webclient is sending values for the field 'supported_attachment_ids' (Example: [(6, 0, [])]) which is writing by inverse relationship on the field 'attachment_ids'. On the other hand, it should be possible for an employee to add attachment on the time off after it has begun. TaskID: 3032232 Description of the issue/feature this
Original PR description
Purpose ======= In the case a time off is created: - In the past - Using support documents An invalid user error is raised in the interface, because the webclient is sending values for the field 'supported_attachment_ids' (Example: [(6, 0, [])]) which is writing by inverse relationship on the field 'attachment_ids'. On the other hand, it should be possible for an employee to add attachment on the time off after it has begun. TaskID: 3032232 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#104842 Forward-Port-Of: odoo/odoo#104803
Before this commit ================== When we post a Customer Invoice by adding 2 products first one has a positive unit value and the second one has a negative unit value than the wrong JSON is generated. The issue happens because of abs method converts the negative value into a positive. After this commit ================== In this commit, we are using the sign amount instead of the abs method. Effected from this PR https://github.com/odoo/odoo/pull/99401 Forward-Port-Of: odoo/odoo
Original PR description
Before this commit ================== When we post a Customer Invoice by adding 2 products first one has a positive unit value and the second one has a negative unit value than the wrong JSON is generated. The issue happens because of abs method converts the negative value into a positive. After this commit ================== In this commit, we are using the sign amount instead of the abs method. Effected from this PR https://github.com/odoo/odoo/pull/99401 Forward-Port-Of: odoo/odoo#104736
**Description of the issue/feature this PR addresses:** Create option is currently available in the Apps many2many field in the export translation wizard. 1. In Developer Mode 2. Settings -> Translations -> Import/Export -> Export Translation 3. In the "Apps To Export" field, enter some raw values and click create and edit, a new record will be created. **Current behavior before PR:** From the Apps many2many field a new app(raw) can be created. ![Screenshot from 2022-10-24 21-26-57]
Original PR description
**Description of the issue/feature this PR addresses:** Create option is currently available in the Apps many2many field in the export translation wizard. 1. In Developer Mode 2. Settings -> Translations -> Import/Export -> Export Translation 3. In the "Apps To Export" field, enter some raw values and click create and edit, a new record will be created. **Current behavior before PR:** From the Apps many2many field a new app(raw) can be created.  Created app:  **Desired behavior after PR is merged:** Create option will be removed from the Apps field. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#103998
Current behavior: When you open the order list, the orders are displayed in UTC. Steps to reproduce: - Be sure you are in a timezone different than UTC - Start a PoS restaurant session - Go on a table and make and order - Go on the order list - Go back on the table, then go back on the order list - The time showed for the order is not correct (it's in UTC) This bug was happening because `moment(order.validation_date)` consider that the date is already in the local timezone, so it d
Original PR description
Current behavior: When you open the order list, the orders are displayed in UTC. Steps to reproduce: - Be sure you are in a timezone different than UTC - Start a PoS restaurant session - Go on a table and make and order - Go on the order list - Go back on the table, then go back on the order list - The time showed for the order is not correct (it's in UTC) This bug was happening because `moment(order.validation_date)` consider that the date is already in the local timezone, so it doesn't apply the timezone offset. So we have to apply the offset manually. opw-3002417 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#103667
**Issue:** When creating a custom filter for a selection field, the selected value is not properly displayed. Note however that applying the filter still works. The problem is only in the displayed value. This is caused by setting the "value" attribute of the selection element which is always an empty string (because formatField doesn't properly work for selection field). However, the empty string is not the issue because it doesn't matter what "formatted value" is returned, it is not needed.
Original PR description
**Issue:** When creating a custom filter for a selection field, the selected value is not properly displayed. Note however that applying the filter still works. The problem is only in the displayed…
**Issue:** When creating a custom filter for a selection field, the selected value is not properly displayed. Note however that applying the filter still works. The problem is only in the displayed value. This is caused by setting the "value" attribute of the selection element which is always an empty string (because formatField doesn't properly work for selection field). However, the empty string is not the issue because it doesn't matter what "formatted value" is returned, it is not needed. The selection field's value is based on the value of the selected option. **Solution:** To properly show the display text of the selection item, we need to make sure that value of the selection field is not overridden during its onChange event. As a result, the selected option will become the value of the selection field, displaying the proper text. Therefore, in the onValueChange event handler, if the field type is selection, we don't reset the value of the the selection element. **Illustrations:** Before: <img width="1154" alt="Screenshot 2022-11-03 at 10 30 07" src="https://user-images.githubusercontent.com/3245568/199687662-e0c1c46f-1dc3-4f48-a471-ef2b86ff6a78.png"> After: <img width="1171" alt="Screenshot 2022-11-03 at 10 31 19" src="https://user-images.githubusercontent.com/3245568/199687690-7e29a41d-1adc-4611-bb7d-b255cf9684da.png"> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#104804
The search bar had a trace back when searching on a name, and searching on the code prefix did not work. This was not working because using str(self) does not work in v16, str is not defined in filter domain. By removing the str and adapting the filter domain logic, it now works as it should. And the behavior of version 15 is restored. task-id: 3058778 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#105325
Original PR description
The search bar had a trace back when searching on a name, and searching on the code prefix did not work. This was not working because using str(self) does not work in v16, str is not defined in filter domain. By removing the str and adapting the filter domain logic, it now works as it should. And the behavior of version 15 is restored. task-id: 3058778 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#105325
Website themes make customizations to the default snippets. In particular, some are applying shapes on default images. To do that, the customization is not applied on the image directly but by changing its src to a special web_editor route in charge of automatically adding the shape on whatever default image the configurator chose for this snippet. Typically, in a snippet with an image whose src is: /web/image/website.my_snippet_default_image The src is replaced by the theme with: /w
Original PR description
Website themes make customizations to the default snippets. In particular, some are applying shapes on default images. To do that, the customization is not applied on the image directly but by changing its src to a special web_editor route in charge of automatically adding the shape on whatever default image the configurator chose for this snippet. Typically, in a snippet with an image whose src is: /web/image/website.my_snippet_default_image The src is replaced by the theme with: /web_editor/image_shape/website.my_snippet_default_image/website/some_shape.svg That controller/route crashed since [1], making those images blank areas in pages generated by the configurator. Indeed, the image from the filestore was accessed via `file_open` which only allows reading inside the addons_paths. [1]: https://github.com/odoo/odoo/commit/da8def8e410de68256ba4ab09ebf7a8b699355ac Co-authored-by: Julien Castiaux <juc@odoo.com> Forward-Port-Of: odoo/odoo#104860
**Description of the issue/feature this PR addresses:** typo mistake for quantites in purchase_requisition **Current behavior before PR:** typo mistake for quantites **Desired behavior after PR is merged:** typo issue resolved --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#104958
Original PR description
**Description of the issue/feature this PR addresses:** typo mistake for quantites in purchase_requisition **Current behavior before PR:** typo mistake for quantites **Desired behavior after PR is merged:** typo issue resolved --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#104958
Before in a legacy client action, using a link to change view and going back to the client action with the breadcrumb does not restore the scroll position. Now with this commit, the scroll position is restored Steps to reproduce: - Install Accounting - Go to `Accounting -> Reporting -> Balance Sheet` - Unfold the tree to make the window scrollable - Click on a link at the bottom of the window - Go back to Balance Sheet  Forward-Port-Of: odoo/odoo#105273
### Steps to reproduce * go to Accounting > Settings and activate 'Cash Basis' * got to Chart of Accounts and create a new account of type `Current Assets`. We'll call it `A`. * create a new tax, we'll call it `T`, with the following parameters: * Tax type: Purchases * Tax computation: Percentage of Price * Amount: 22% * Distribution of invoices: * add a line with the following parameters: % = 40, Based On = 'of tax' and Account = the tax paid account. * add a second li
Original PR description
### Steps to reproduce * go to Accounting > Settings and activate 'Cash Basis' * got to Chart of Accounts and create a new account of type `Current Assets`. We'll call it `A`. * create a new tax,…
### Steps to reproduce
* go to Accounting > Settings and activate 'Cash Basis'
* got to Chart of Accounts and create a new account of type `Current Assets`. We'll call it `A`.
* create a new tax, we'll call it `T`, with the following parameters:
* Tax type: Purchases
* Tax computation: Percentage of Price
* Amount: 22%
* Distribution of invoices:
* add a line with the following parameters: % = 40, Based On = 'of tax' and Account = the tax paid account.
* add a second line with the following parameters: %= 60, Based On = 'of tax'
* Distribution of Credit Notes: Add the same lines as 'Distribution of invoices'
* In the Advanced Options tab, set :
* Tax Eligibility = 'Based on Payment'
* Cash Basis Transition Account = `A`
* create a new vendor bill and add a product line to it and set Taxes = `T` on that line
* confirm and register payment
Now go to Accounting > Journal Items, group by Journal. Look through the 'Cash Basis Taxes' group and find the entries related to the vendor bill you just made. One of the debit lines on account `A` is not correct. Here, the account should be the one specified on the invoice line.
opw-2796727
Forward-Port-Of: odoo/odoo#105284
Forward-Port-Of: odoo/odoo#103631Description of the issue/feature this PR addresses: - If you have a UoM (ex: kg) with rounding of more than 4 digits it will be seen as 1e-5 instead of 0.00001 (in case of 5 digits) for example and cause a crash when you try to print the package barcode (Inventory -> products -> packages -> choose any one -> print "Package Barcode with Content") Current behavior before PR: - Traceback when you want to print the package barcode Desired behavior after PR is merged: - Be able to prin
Original PR description
Description of the issue/feature this PR addresses: - If you have a UoM (ex: kg) with rounding of more than 4 digits it will be seen as 1e-5 instead of 0.00001 (in case of 5 digits) for example and cause a crash when you try to print the package barcode (Inventory -> products -> packages -> choose any one -> print "Package Barcode with Content") Current behavior before PR: - Traceback when you want to print the package barcode Desired behavior after PR is merged: - Be able to print the package barcode -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#94958
**Description of the issue/feature this PR addresses:** adding name search for the ir_module_module (apps) model. **Current behavior before PR:** From Settings -> Translations -> Import/Export Translation wizard, if you search with an app using the technical_name, no results are returned.  **Desired behavior after PR is merged:** searching wit
Original PR description
**Description of the issue/feature this PR addresses:** adding name search for the ir_module_module (apps) model. **Current behavior before PR:** From Settings -> Translations -> Import/Export Translation wizard, if you search with an app using the technical_name, no results are returned.  **Desired behavior after PR is merged:** searching with technical name and summary field will return the result, as it work with tree view search.  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#105395
This commit fixes premature usage of `purchase_price` field on sale.order.line model, before its definition in sale_margin module. Since this test requires both sale_mrp and sale_stock_margin to pass, this commit adds an auto-install bridge module that solely address this issue. Steps to reproduce: - Install sale_mrp module - Run tests (at least .test_kit_cost_calculation) Problem: Traceback: AttributeError: 'sale.order.line' object has no attribute 'purchase_price' See odoo/o
Original PR description
This commit fixes premature usage of `purchase_price` field on sale.order.line model, before its definition in sale_margin module. Since this test requires both sale_mrp and sale_stock_margin to pass, this commit adds an auto-install bridge module that solely address this issue. Steps to reproduce: - Install sale_mrp module - Run tests (at least .test_kit_cost_calculation) Problem: Traceback: AttributeError: 'sale.order.line' object has no attribute 'purchase_price' See odoo/odoo#100126 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#105304 Forward-Port-Of: odoo/odoo#104891
Before this commit, when uploading an attachment then delete then re-upload attachment again, the reupload was unsuccessful. This happens because it should clear the `<input>` of type `file`, but the condition was wrong and therefore `<input>` was not cleared, thus keeping same value as before so input was not detected as changed. A change on this file input is necessary to detect user interaction file upload. This commit fixes trigger for clearing the `<input>` of type file, so that any f
Original PR description
Before this commit, when uploading an attachment then delete then re-upload attachment again, the reupload was unsuccessful. This happens because it should clear the `<input>` of type `file`, but the condition was wrong and therefore `<input>` was not cleared, thus keeping same value as before so input was not detected as changed. A change on this file input is necessary to detect user interaction file upload. This commit fixes trigger for clearing the `<input>` of type file, so that any file upload is properly detected, including uploading same attachment. Task-3060429 Forward-Port-Of: odoo/odoo#105422
Only server wide modules are being taken into account when calculating translations hash. So user probably can't get translations of new installed modules unless it is forced by hard page reload (Ctrl+Shift+R). Problem exists since https://github.com/odoo/odoo/commit/80d74e7ee0eab83dc5100e0776df09d04b882fec and the cause in that `mods = odoo.conf.server_wide_modules or []` string was unpaired with the following `if` statement during refactoring. This commit restores computation of hash bas
Original PR description
Only server wide modules are being taken into account when calculating translations hash. So user probably can't get translations of new installed modules unless it is forced by hard page reload (Ctrl+Shift+R). Problem exists since https://github.com/odoo/odoo/commit/80d74e7ee0eab83dc5100e0776df09d04b882fec and the cause in that `mods = odoo.conf.server_wide_modules or []` string was unpaired with the following `if` statement during refactoring. This commit restores computation of hash based on all loaded modules. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#105432 Forward-Port-Of: odoo/odoo#104861
When editing a m2m avatar field in the list view, keyboard navigation, e.g. pressing arrow-left when the focus is on the right-most item, results to a crash. Also, the "delete" button when in edit mode is not there anymore so the user is unable to remove items. This is because we are not building the proper list of tags. More specifically, we fail to provide `onKeydown` and `onDelete` handler to the tags, thus, it crashes and no delete button. This proposed change fixes both issues.
Original PR description
When editing a m2m avatar field in the list view, keyboard navigation, e.g. pressing arrow-left when the focus is on the right-most item, results to a crash. Also, the "delete" button when in edit…
When editing a m2m avatar field in the list view, keyboard navigation, e.g. pressing arrow-left when the focus is on the right-most item, results to a crash. Also, the "delete" button when in edit mode is not there anymore so the user is unable to remove items. This is because we are not building the proper list of tags. More specifically, we fail to provide `onKeydown` and `onDelete` handler to the tags, thus, it crashes and no delete button. This proposed change fixes both issues. **Bug report:** > [aju] open the list view of tasks > group by assignees > try editing the assignees in batch > it's not possible to remove an assignee because the x icon is not displayed, before: https://nimb.ws/1UPLDt after: https://nimb.ws/kfxuWm > also, there is a traceback when navigating in the cell using the keyboard arrows https://watch.screencastify.com/v/wYOXJ5dmAJeLcGuL9Avf, https://pastebin.com/evLv1rQ2 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#105435
Before this commit, following this flow in the Website Builder: - Enter edit mode, - Drop a snippet with text, - Paste a youtube video link, - Click on the "Embed Youtube Video" option of the powerbox, => There is a traceback. This is coming from the bad function calls in the Wysiwyg to create a video node. When [1] reworked the MediaDialog in owl, a first implementation was done exporting some utils (saveVideos, videoSpecificMediaClasses). But this implementation was not kept and later
Original PR description
Before this commit, following this flow in the Website Builder: - Enter edit mode, - Drop a snippet with text, - Paste a youtube video link, - Click on the "Embed Youtube Video" option of the…
Before this commit, following this flow in the Website Builder: - Enter edit mode, - Drop a snippet with text, - Paste a youtube video link, - Click on the "Embed Youtube Video" option of the powerbox, => There is a traceback. This is coming from the bad function calls in the Wysiwyg to create a video node. When [1] reworked the MediaDialog in owl, a first implementation was done exporting some utils (saveVideos, videoSpecificMediaClasses). But this implementation was not kept and later changed to use static methods and properties on the VideoSelector class (createElements and mediaSpecificClasses). Unfortunately, the outdated util methods used in the Wysiwyg were not changed, and it was breaking the youtube video instertions. This commit changes the Wysiwyg to use the existing VideoSelector.createElements and VideoSelector.mediaSpecificClasses static method and property to fix this flow. [1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b task-2687506 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#105166
Before this commit, we had an issue with the width calculated for data cell (see. sizeOfDataCell). In some case, the width was 50% instead of taking 100% of the available space. This was because some elements of the inner groups that should not have been visible were computed as if they were, taking an effective slot in an innergroup's row. E.g. with two labels: Before: "invisible label" and "label" on the same line with `style="width: infinite"` "data field" on a second line wit
Original PR description
Before this commit, we had an issue with the width calculated for data cell (see. sizeOfDataCell). In some case, the width was 50% instead of taking 100% of the available space. This was because some…
Before this commit, we had an issue with the width calculated for data cell (see. sizeOfDataCell). In some case, the width was 50% instead of taking 100% of the available space. This was because some elements of the inner groups that should not have been visible were computed as if they were, taking an effective slot in an innergroup's row. E.g. with two labels: Before: "invisible label" and "label" on the same line with `style="width: infinite"` "data field" on a second line with `style="width: 50%"` After this commit: "label" and "data field" on the same line with `style="width: 100%"` Note that as `infinite` is not a valid value, this wasn't interpreted and style attribute was empty. Thanks to grid for still aligning elements even if they are technically in different rows. It's why we only saw this issue because of the width of the data cell. Steps to reproduce: - Go to Accounting - Customer -> Invoice - Create a new invoice -> See Customer field Thx to @kebeclibre Forward-Port-Of: odoo/odoo#105450
**Description of the issue/feature this PR addresses:** For the modules which is available in the community edition, account_sale_timesheet, project_account, project_hr_expense, sale_project_account, currently the license is OEEL-1. **Current behavior before PR:** OEEL-1 license for modules in the community edition. **Desired behavior after PR is merged:** LGPL-3 license for the modules. If the OEEL-1 license is fine to keep for the community modules, we can close this PR. Creating t
Original PR description
**Description of the issue/feature this PR addresses:** For the modules which is available in the community edition, account_sale_timesheet, project_account, project_hr_expense, sale_project_account, currently the license is OEEL-1. **Current behavior before PR:** OEEL-1 license for modules in the community edition. **Desired behavior after PR is merged:** LGPL-3 license for the modules. If the OEEL-1 license is fine to keep for the community modules, we can close this PR. Creating this PR thinking that the license is missed to change while moving the module to CE from EE or wrongly added here. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#105474 Forward-Port-Of: odoo/odoo#104956
This commit fixes a traceback when changing the attributes when the current page has no products to display TaskId-3045085 Forward-Port-Of: odoo/odoo#105473
Original PR description
This commit fixes a traceback when changing the attributes when the current page has no products to display TaskId-3045085 Forward-Port-Of: odoo/odoo#105473
Steps to reproduce: - Install website_sale_coupon - Load demo data - Create a promotion program that applies on the order - Go to the webshop and add 2 different products to the cart Bug: The line of promotion is in second place, instead of at the end. Fix: move the old sale order line after recomputing the discount to the end of the SO opw-2985632 Forward-Port-Of: odoo/odoo#105258 Forward-Port-Of: odoo/odoo#102700
Original PR description
Steps to reproduce: - Install website_sale_coupon - Load demo data - Create a promotion program that applies on the order - Go to the webshop and add 2 different products to the cart Bug: The line of promotion is in second place, instead of at the end. Fix: move the old sale order line after recomputing the discount to the end of the SO opw-2985632 Forward-Port-Of: odoo/odoo#105258 Forward-Port-Of: odoo/odoo#102700
Steps to reproduce: - Install module account_accountant - Create a tax that has settings `Included in Price` and `Include in Analytic Cost` - Create a bank statement and a transaction with any amount - Click on `Post`, then `Reconcile` - Select Manual Operations Tab - Add an account (ex: 600000 Expenses) - Add tax created before - Add an analytic account (ex: Administrative) - Validate and go back to the bank statement - Click on stat button `Jounal Entries`
Original PR description
Steps to reproduce: - Install module account_accountant - Create a tax that has settings `Included in Price` and `Include in Analytic Cost` - Create a bank statement and a transaction with any amount…
Steps to reproduce:
- Install module account_accountant
- Create a tax that has settings `Included in Price` and
`Include in Analytic Cost`
- Create a bank statement and a transaction with any amount
- Click on `Post`, then `Reconcile`
- Select Manual Operations Tab
- Add an account (ex: 600000 Expenses)
- Add tax created before
- Add an analytic account (ex: Administrative)
- Validate and go back to the bank statement
- Click on stat button `Jounal Entries`
Issue:
The move line for taxes hasn't the analytic account set.
(same issue of analytic tags)
Cause:
When adding analytic account/tag on main move line, we did not
recompute the lines with taxes. Also, when recomputing the tax props,
it wasn't setting the analytic account/tag at all.
Solution:
Recompute the lines with taxes when adding analytic account/tag on
main move line and when recomputing the tax props, set the analytic
account/tag only if the tax has the flag `analytic`.
Also, the value of analytic_tag_ids is already formatted in the right
format to save it to DB (`[{'id':..., 'display_name':...}]`) when
adding an analytic tag through the quick create, so we don't need to
format it again (therefore we can remove `_formatMany2ManyTags`
function since only used in this case).
opw-3010800
Forward-Port-Of: odoo/enterprise#33819
Forward-Port-Of: odoo/enterprise#33190Before this commit, we were taking the first found currency that resembles to what the OCR found. This may cause an issue with currencies that have the same symbol or the same name. For example with the Danish Krone/Norwegian Krone or the Australian dollars/American dollars. With this commit, the currency is chosen by order of priority. We still try to find the correct matches depending on what the OCR found, but amongst those results, we first choose the one that was used in the last
Original PR description
Before this commit, we were taking the first found currency that resembles to what the OCR found. This may cause an issue with currencies that have the same symbol or the same name. For example with…
Before this commit, we were taking the first found currency that resembles to what the OCR found. This may cause an issue with currencies that have the same symbol or the same name. For example with the Danish Krone/Norwegian Krone or the Australian dollars/American dollars. With this commit, the currency is chosen by order of priority. We still try to find the correct matches depending on what the OCR found, but amongst those results, we first choose the one that was used in the last invoice with the same customer, then the one that is linked to our company, and finally the first item of the list if none of the former ones were found. Also, the usage of `ilike` does not seem appropriate in this currency selector: - If the OCR returns "kr" as the currency, we could select by mistake the Pakistani rupee as it has the "PKR" currency code. However, to avoid breaking anything, or changing the current behavior, after using `=ilike`, if no `possible_currency` was found, we still use `ilike`. task-3048098 Forward-Port-Of: odoo/enterprise#33513
Untill now, in order to have the HMRC button visible on the tax report, we had to set the `availability_condition` to `always`. Which does not make much sense. So this condition is removed here, along with a check on the `account_fiscal_country_id.code` that has become useless since `_custom_options_initializer()` is now located in the `l10n_uk.tax.report.handler`. Forward-Port-Of: odoo/enterprise#33792
Original PR description
Untill now, in order to have the HMRC button visible on the tax report, we had to set the `availability_condition` to `always`. Which does not make much sense. So this condition is removed here, along with a check on the `account_fiscal_country_id.code` that has become useless since `_custom_options_initializer()` is now located in the `l10n_uk.tax.report.handler`. Forward-Port-Of: odoo/enterprise#33792
The `^` and `$` at the beginning/end of the regex were actually unnecessary and would prevent the detection if the purchase order number was inside a sentence. Forward-Port-Of: odoo/enterprise#33777
Original PR description
The `^` and `$` at the beginning/end of the regex were actually unnecessary and would prevent the detection if the purchase order number was inside a sentence. Forward-Port-Of: odoo/enterprise#33777
Since the recent css change, the wizard used for generate 1099 reports was a bit broken, the list view was way too small for the wizard. By adding a colspan the issues is corrected. Forward-Port-Of: odoo/enterprise#33793
Original PR description
Since the recent css change, the wizard used for generate 1099 reports was a bit broken, the list view was way too small for the wizard. By adding a colspan the issues is corrected. Forward-Port-Of: odoo/enterprise#33793
It would throw an error when trying to delete a folder with archived documents. Forward-Port-Of: odoo/enterprise#33787
Original PR description
It would throw an error when trying to delete a folder with archived documents. Forward-Port-Of: odoo/enterprise#33787
Previously, the boxes were re-created upon clicking on the "Reload AI Data" button. This caused a traceback when clicking on a box in the interface as it wasn't aware of the new boxes and the ID linked to it belonged to a record that has been unlinked. Now, the boxes are kept so that the IDs are still the same. This has the downside that there might be a mismatch between was has been fetched during the reload and the old boxes, but it is very unlikely to occur. Forward-Port-Of: odoo/enter
Original PR description
Previously, the boxes were re-created upon clicking on the "Reload AI Data" button. This caused a traceback when clicking on a box in the interface as it wasn't aware of the new boxes and the ID linked to it belonged to a record that has been unlinked. Now, the boxes are kept so that the IDs are still the same. This has the downside that there might be a mismatch between was has been fetched during the reload and the old boxes, but it is very unlikely to occur. Forward-Port-Of: odoo/enterprise#33729
Description: Properly render the no content helper of the web_studio actions. Issue: Open odoo studio in any list view and click the Automations tab. The UI shows a raw string of the "no content helper". Illustration:  Solution: Since the studio action doesn't go thru the _loadAction of the action service, the "help" props of the action is
Original PR description
Description: Properly render the no content helper of the web_studio actions. Issue: Open odoo studio in any list view and click the Automations tab. The UI shows a raw string of the "no content helper". Illustration:  Solution: Since the studio action doesn't go thru the _loadAction of the action service, the "help" props of the action is not properly marked up. The simple fix is to markup the "help" props of the action right after fetching it from the server. TASK-ID: 2924243 Forward-Port-Of: odoo/enterprise#33261
When clicking the Internal Link of a many2one field from the FormViewDialog, the dialog should close because the view has changed to the form view of the linked record. Bug report: > [aju] https://watch.screencastify.com/v/ZJlZNSt9n3HwXiYHfW1S open the planning gantt view > open a shift > click on an internal link > the form view modal should close Forward-Port-Of: odoo/enterprise#33775
Original PR description
When clicking the Internal Link of a many2one field from the FormViewDialog, the dialog should close because the view has changed to the form view of the linked record. Bug report: > [aju] https://watch.screencastify.com/v/ZJlZNSt9n3HwXiYHfW1S open the planning gantt view > open a shift > click on an internal link > the form view modal should close Forward-Port-Of: odoo/enterprise#33775
Currently, there is a miscalculation of the unaffected earnings. In particular with account '129000 Resultado del ejercicio', one could post a journal entry in the previous fiscal year. And that was not handeled correctly and lead to inaccurate reports. This PR is the combination of internal bug reports, and this ticket: opw-2950285 Forward-Port-Of: odoo/enterprise#33644 Forward-Port-Of: odoo/enterprise#33089
Original PR description
Currently, there is a miscalculation of the unaffected earnings. In particular with account '129000 Resultado del ejercicio', one could post a journal entry in the previous fiscal year. And that was not handeled correctly and lead to inaccurate reports. This PR is the combination of internal bug reports, and this ticket: opw-2950285 Forward-Port-Of: odoo/enterprise#33644 Forward-Port-Of: odoo/enterprise#33089