Friday, June 11, 2021
21 changes · master
Enhancements to existing features
The Buzzy website theme now uses a shared color palette location alongside other website palettes. This keeps theme styling easier to manage and helps ensure consistent visual options for website builders.
Original PR description
Description of the issue/feature this PR addresses: Add a new color palette for the new theme : "Buzzy" Current behavior before PR: The color palette was in the primary_variables.scss of the theme (theme_buzzy) Desired behavior after PR is merged: Move the palette with the others in the primary_variables.scss of website. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
Accessory products are now filtered by the current website, so shoppers only see add-ons that are available on the site they are using. This prevents products from another website appearing during checkout in multi-website setups, reducing confusion and keeping storefronts properly separated.
Original PR description
Description of the issue/feature this PR addresses: @JKE-be before this commit, some accessory from an other website can be access. And it use the generic `sale_product_domain()`. In database with 2 websites 1 and 2, create a product A, with 2 accessories product B and C. A and B are available in website 1 A and C are available in website 2 Go to website 1, add product A in the cart --> issue you see B and C in the accessories page. You should see only the product B. Note : It is a really rare case, but in custom project if you inherit `sale_product_domain()`, it is logical that it is apply everywhere. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Since this PR https://github.com/odoo/odoo/pull/71273, addresses label were no longer translated This PR adds the new translation Forward-Port-Of: odoo/odoo#71939
Original PR description
Since this PR https://github.com/odoo/odoo/pull/71273, addresses label were no longer translated This PR adds the new translation Forward-Port-Of: odoo/odoo#71939
Users can now reload event registration and track proposal confirmation pages without seeing a "Method not Allowed" error. The change redirects users to a page that can be safely reopened, improving the website event experience after form submissions.
Original PR description
PURPOSE
Currently, we found two same issue while
user reload the page and it return
"Method not Allowed".
issues :-
1) if user submitting the track proposal
and reload it again.
2) in event_track after event register
and reload the page, it gave the same
error message "Method not Allowed".
SPECIFICATION
in this commit we are fix this problem by
redirect the user on different URL with
necessary data and in other controller
fetch that data so if user reload the page
than it always render the page instead of
giving error "Method not Allowed".
Task Id: 2500573
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr…ate the edi without l10n_it_edi_sdicoop_installed 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#71948
Original PR description
…ate the edi without l10n_it_edi_sdicoop_installed 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#71948
When importing vendor credit note from an italian e-invoice xml file with a "DettaglioPagamento" section, the data import will fail and you will have the "Unsupported image format" message on top of the invoice. The use of '_compose_info_message' function is not possible on a 'account.edi.format' object and was changed to use the 'invoice' parameter. opw-2500569 Forward-Port-Of: odoo/odoo#71814
Original PR description
When importing vendor credit note from an italian e-invoice xml file with a "DettaglioPagamento" section, the data import will fail and you will have the "Unsupported image format" message on top of the invoice. The use of '_compose_info_message' function is not possible on a 'account.edi.format' object and was changed to use the 'invoice' parameter. opw-2500569 Forward-Port-Of: odoo/odoo#71814
When generating a spreadsheet from a pivot view, the values of m2o fields are added up instead of being counted. To reproduce the error: (Need point_of_sale,documents_spreadsheet) 1. Open a POS session 2. Process 3 orders 3. Close the session 4. Point of Sale > Reporting > Orders - Pivot View (Note: the number of orders is 3, which is correct) 5. Insert in Spreadsheet Error: On spreadsheet, the number of orders is incorrect (the value corresponds to the sum of the order identi
Original PR description
When generating a spreadsheet from a pivot view, the values of m2o fields are added up instead of being counted. To reproduce the error: (Need point_of_sale,documents_spreadsheet) 1. Open a POS…
When generating a spreadsheet from a pivot view, the values of m2o
fields are added up instead of being counted.
To reproduce the error:
(Need point_of_sale,documents_spreadsheet)
1. Open a POS session
2. Process 3 orders
3. Close the session
4. Point of Sale > Reporting > Orders - Pivot View
(Note: the number of orders is 3, which is correct)
5. Insert in Spreadsheet
Error: On spreadsheet, the number of orders is incorrect (the value
corresponds to the sum of the order identifier of each POS order line)
When generating the spreadsheet, here is how the operator for each field
is computed:
https://github.com/odoo/enterprise/blob/06bf2b0e2def3445cdd21d5b6fccc58e3015e0b5/documents_spreadsheet/static/src/js/o-spreadsheet/pivot_utils.js#L217-L225
If there is not any `group_operator`, the `operator` will be defined to
`sum`.
In the above case, the attribute `group_operator` is indeed not defined
for the field `order_id`:
https://github.com/odoo/odoo/blob/1ddbcb4860ee220e9f826e8b6f6b85b6c22fb2b7/addons/point_of_sale/report/pos_order_report.py#L14
However, when generating the pivot view, if the field is m2o, its
`group_operator` value is not considered and the operator is directly
defined to `count_distinct`:
https://github.com/odoo/odoo/blob/7cf8f6f40e5769d2f22620ac425208c4ad9ae80b/addons/web/static/src/js/views/pivot/pivot_model.js#L979-L987
Since the spreadsheet is based on the pivot view, this fix suggests
saving this decision so the spreadsheet will behave in the same way.
OPW-2551030
Forward-Port-Of: odoo/odoo#71960
Forward-Port-Of: odoo/odoo#71866Monitor and improve performances of the calendar module by decreasing the number of SQL requests. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#71910 Forward-Port-Of: odoo/odoo#71808
Original PR description
Monitor and improve performances of the calendar module by decreasing the number of SQL requests. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#71910 Forward-Port-Of: odoo/odoo#71808
Prior to this commit: - If a user without access to sales tries to add timesheets on a task that comes from a sale order, the following access error is raised: Access Error You are not allowed to access 'Sales Order Line' (sale.order.line) records. After this commit: - A user without access to sales will be able to add timesheets to a task that comes from a sale order without any error. task-2566750 opw-2525342 -- I confirm I have si
Original PR description
Prior to this commit:
- If a user without access to sales tries to add timesheets on a task that
comes from a sale order, the following access error is raised:
Access Error
You are not allowed to access 'Sales Order Line' (sale.order.line) records.
After this commit:
- A user without access to sales will be able to add timesheets to a task that
comes from a sale order without any error.
task-2566750
opw-2525342
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#72021
Forward-Port-Of: odoo/odoo#70510Those field are all handled by the account.tax.report.line creating the tax tag. They should never manually be changed by the user. OPW 2541071 Forward-Port-Of: odoo/odoo#72006 Forward-Port-Of: odoo/odoo#71872
Original PR description
Those field are all handled by the account.tax.report.line creating the tax tag. They should never manually be changed by the user. OPW 2541071 Forward-Port-Of: odoo/odoo#72006 Forward-Port-Of: odoo/odoo#71872
Description of the issue/feature this PR addresses: In case we register one payment on a single accounting entry, we can manually specify the bank account that will be used. In case we register one global payment for several entries, the bank account is not visible in the payment register wizard. We should use the first bank account set on the partner as a default case to allow it and not block the whole process. opw-2496440 Current behavior before PR: Desired behavior after PR i
Original PR description
Description of the issue/feature this PR addresses: In case we register one payment on a single accounting entry, we can manually specify the bank account that will be used. In case we register one global payment for several entries, the bank account is not visible in the payment register wizard. We should use the first bank account set on the partner as a default case to allow it and not block the whole process. opw-2496440 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#71603
When registering a payment on an expense, we are currently using the first bank account set on the partner if no account is set on the account move. We should use the bank account defined on the employee instead, and fallback on the partner only if it is not set. Description of the issue/feature this PR addresses: opw-2496440 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
Original PR description
When registering a payment on an expense, we are currently using the first bank account set on the partner if no account is set on the account move. We should use the bank account defined on the employee instead, and fallback on the partner only if it is not set. Description of the issue/feature this PR addresses: opw-2496440 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#71611
When demo data is installed, all request are successful by default and the proxy is not contacted. 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#71998
Original PR description
When demo data is installed, all request are successful by default and the proxy is not contacted. 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#71998
In case we register one global payment for several entries using SCT payment method, we can use the first bank account set on the partner as a default case. opw-2496440 Forward-Port-Of: odoo/enterprise#18685
Original PR description
In case we register one global payment for several entries using SCT payment method, we can use the first bank account set on the partner as a default case. opw-2496440 Forward-Port-Of: odoo/enterprise#18685
Standard SCT files generated by Odoo got refused by Austrian banks. Following xsds found here: https://zv.psa.at/en/download/xml/kunde-bank/rb-7-9/xml-schemata-1.html opw 2542386 Forward-Port-Of: odoo/enterprise#18934 Forward-Port-Of: odoo/enterprise#18845
Original PR description
Standard SCT files generated by Odoo got refused by Austrian banks. Following xsds found here: https://zv.psa.at/en/download/xml/kunde-bank/rb-7-9/xml-schemata-1.html opw 2542386 Forward-Port-Of: odoo/enterprise#18934 Forward-Port-Of: odoo/enterprise#18845
- Go to Accounting > Reporting > Trial Balance - Select 2 journals in Journals filter (i.e. Bank and Customer Invoices) - Click on an account linked to the second journal (i.e. 101200 Account Receivable) and select "Journal Items" An empty list of journal items will be displayed. When opening journal items, "search_default_account_id" is set to selected account and "search_default_journal_id" is set to selected journals. But "search_default_" with a many2one field doesn't support mult
Original PR description
- Go to Accounting > Reporting > Trial Balance - Select 2 journals in Journals filter (i.e. Bank and Customer Invoices) - Click on an account linked to the second journal (i.e. 101200 Account Receivable) and select "Journal Items" An empty list of journal items will be displayed. When opening journal items, "search_default_account_id" is set to selected account and "search_default_journal_id" is set to selected journals. But "search_default_" with a many2one field doesn't support multiple values and in case of an array, it will take the first element. In our case, journal items are filtered by the selected account (i.e Account Receivable) and the first element of the selected journals (i.e. Bank), which is an undesired combination. In case of several journals selected, domain will be used instead of "search_default_journal_id". opw-2507576 Forward-Port-Of: odoo/enterprise#18937 Forward-Port-Of: odoo/enterprise#18835
The fields l10n_mx_edi_qty_umt, l10n_mx_edi_umt_aduana_id, l10n_mx_edi_customs_number are added to account.move().invoice_line_ids but not to account.move().line_ids tree view. invoice_line_ids is a view over line_ids, and on save it is fully discarded only keeping what is inside line_ids, so if a field is in invoice_line_ids it should also be in line_ids or its value will be discarded. opw-2548375 Forward-Port-Of: odoo/enterprise#18936
Original PR description
The fields l10n_mx_edi_qty_umt, l10n_mx_edi_umt_aduana_id, l10n_mx_edi_customs_number are added to account.move().invoice_line_ids but not to account.move().line_ids tree view. invoice_line_ids is a view over line_ids, and on save it is fully discarded only keeping what is inside line_ids, so if a field is in invoice_line_ids it should also be in line_ids or its value will be discarded. opw-2548375 Forward-Port-Of: odoo/enterprise#18936
This new test ensures that the operator `count_distinct is applied on a m2o field. Test odoo/odoo#71866 Linked to OPW-2551030 Forward-Port-Of: odoo/enterprise#18913 Forward-Port-Of: odoo/enterprise#18867
Original PR description
This new test ensures that the operator `count_distinct is applied on a m2o field. Test odoo/odoo#71866 Linked to OPW-2551030 Forward-Port-Of: odoo/enterprise#18913 Forward-Port-Of: odoo/enterprise#18867
Scenario: - order timesheet list view by employee_id - sort by employee_id => no sorting is done this is because group_expand of employee_id ignores the sorting order. With this changeset, the sorting order is used. opw-2565810 Forward-Port-Of: odoo/enterprise#18908
Original PR description
Scenario: - order timesheet list view by employee_id - sort by employee_id => no sorting is done this is because group_expand of employee_id ignores the sorting order. With this changeset, the sorting order is used. opw-2565810 Forward-Port-Of: odoo/enterprise#18908
Before saas-14.4, trying to get id field of account.generic tax report returned False, and was converted to 0 when passing it as the value of the export wizard. Now, it raises an error, as this report does not have an id field (since it's an abstract model). We restore the intended behavior by simply passing 0 if the report doesn't have an id. Forward-Port-Of: odoo/enterprise#18931
Original PR description
Before saas-14.4, trying to get id field of account.generic tax report returned False, and was converted to 0 when passing it as the value of the export wizard. Now, it raises an error, as this report does not have an id field (since it's an abstract model). We restore the intended behavior by simply passing 0 if the report doesn't have an id. Forward-Port-Of: odoo/enterprise#18931
When adapting 302c7d67d that transforms `_("hello %s")` % "world to `_("hello %s", "world")` there was a small typo that would show eg. "tal 1 Activos" instead of "Total Activos". opw-2558644 Forward-Port-Of: odoo/enterprise#18821 Forward-Port-Of: odoo/enterprise#18811
Original PR description
When adapting 302c7d67d that transforms `_("hello %s")` % "world to
`_("hello %s", "world")` there was a small typo that would show eg.
"tal 1 Activos" instead of "Total Activos".
opw-2558644
Forward-Port-Of: odoo/enterprise#18821
Forward-Port-Of: odoo/enterprise#18811