Wednesday, August 21, 2024
24 changes · saas-17.1
Miscellaneous changes
This PR aims at improving batch generation support in mail -- Add / Improve configuration parameters support for email queue Ease email queue configuration with better support of two parameters * 'mail.mail.queue.batch.size' which is the email queue size that will be used to search for outgoing emails (matching optional filters and IDs) and then given to 'send'; * 'mail.session.batch.size' which is the batch size of a given segment of email to send using a specific s
Original PR description
This PR aims at improving batch generation support in mail -- Add / Improve configuration parameters support for email queue Ease email queue configuration with better support of two parameters *…
This PR aims at improving batch generation support in mail
-- Add / Improve configuration parameters support for email queue
Ease email queue configuration with better support of two parameters
* 'mail.mail.queue.batch.size' which is the email queue size that will
be used to search for outgoing emails (matching optional filters and IDs)
and then given to 'send';
* 'mail.session.batch.size' which is the batch size of a given segment of
email to send using a specific server, used when splitting emails to send
based on configuration (see '_split_by_mail_configuration');
-- Better email queue usage for mail composer
Current situation
* post a message on a document
* emails are sent in the same transaction if less than 50 followers and
are postponed otherwise (using post-commit hook);
* emails are generated by batch of 50;
* use composer in mass mailing mode
* emails are always sent in the same transaction;
* emails are generated by batch of 500 (configurable using configuration
parameter "mail.batch_size");
What we want: mass mail mode should have the same kind of behavior and force
usage of email queue if number of recipients is more than a threshold, and
use the same parameter for emails generation batch.
Changes
* force_send threshold is now set to 100, and configurable using
"mail.mail.force.send.limit" configuration parameter. It is used in both
main flows: posting a message (and notifying followers), and sending a
mailing.
* emails generation in both flows is done by batches of 50, configurable
using "mail.batch_size" configuration parameter.
-- Performance
When possible create mails in batch, using configurable parameters when
iterating on large number of records.
Task-3768123: Mail: Configurable cron queue size
Task-3164278: Mail: Batch send: ensure limit, avoid force
Part of Task-3084943: Event: Improve communication scheduler scalability
Forward-Port-Of: odoo/odoo#177046This fix add a verification check to ir.filter and ir.default. This aims at preventing user to put such record out of their own reach This behaviour is usually valid in Odoo, however in this case, it is not normal that the user cannot delete the filter and default that he created himself. Forward-Port-Of: odoo/odoo#176740 Forward-Port-Of: odoo/odoo#174227
Original PR description
This fix add a verification check to ir.filter and ir.default. This aims at preventing user to put such record out of their own reach This behaviour is usually valid in Odoo, however in this case, it is not normal that the user cannot delete the filter and default that he created himself. Forward-Port-Of: odoo/odoo#176740 Forward-Port-Of: odoo/odoo#174227
Steps to reproduce: /!\ on mobile - Sale > Any Product > Sales tab - Add an optional product - Website > Shop > Select product - Add to cart Columns are misaligned with their data, the style that dictates which elements should display depending on screen width only applied to the table body, meaning we had 4 columns with only three data points to fill them, hence why everything is shifted over to the left. opw-4067850 --- I confirm I have signed the CLA and read the PR guidelines
Original PR description
Steps to reproduce: /!\ on mobile - Sale > Any Product > Sales tab - Add an optional product - Website > Shop > Select product - Add to cart Columns are misaligned with their data, the style that dictates which elements should display depending on screen width only applied to the table body, meaning we had 4 columns with only three data points to fill them, hence why everything is shifted over to the left. opw-4067850 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175350
### Description of the issue/feature this PR addresses: Ensure that credit and debit notes in the Uruguayan localization select the correct document type based on the originating document. This update ensures alignment with regulatory requirements: electronic invoices, electronic tickets, export invoices, electronic boletas, and non-electronic documents each dictate the corresponding document type for credit and debit notes created from them ### Steps to reproduce: 1. Install l10n_uy mo
Original PR description
### Description of the issue/feature this PR addresses: Ensure that credit and debit notes in the Uruguayan localization select the correct document type based on the originating document. This…
### Description of the issue/feature this PR addresses: Ensure that credit and debit notes in the Uruguayan localization select the correct document type based on the originating document. This update ensures alignment with regulatory requirements: electronic invoices, electronic tickets, export invoices, electronic boletas, and non-electronic documents each dictate the corresponding document type for credit and debit notes created from them ### Steps to reproduce: 1. Install l10n_uy module 2. Create and validate an invoice of tyoe "(121) Export e-Invoice"  3. Create Credit Note clicking the button on the invoice form.  ### Current behavior before PR: 1. The new Credit Note document type suggested is `(0) Credit None` (a different type of the original invoice) 2. Also the domain show all the document types of type Credit, so the user can select a wrong document  ### Desired behavior after PR is merged: 1. The new credit Note document type will match the original invocie 2. The domain will be restricted to the possible credit note subtypes  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173979
After this commit, the following stat buttons from the project updates panel have been fixed: - Vendor Bills: Add the possibility to create new vendor bills from the stat button and link the new vendor bill to the AA of the current project. Also fix the "Upload" button (no more error "The journal in which to upload the invoice is not specified"). - Invoices: Same as for Vendor Bills (link the AA to the newly created invoice). - Manufacturing Orders: Same fix as above. - Expenses (access vi
Original PR description
After this commit, the following stat buttons from the project updates panel have been fixed: - Vendor Bills: Add the possibility to create new vendor bills from the stat button and link the new vendor bill to the AA of the current project. Also fix the "Upload" button (no more error "The journal in which to upload the invoice is not specified"). - Invoices: Same as for Vendor Bills (link the AA to the newly created invoice). - Manufacturing Orders: Same fix as above. - Expenses (access via the "Expenses" link from the profitability table): Same fix as above. - Sales Orders: Before this commit, we could only create new SOs from the project form view stat button, we can now do it from the stat button of the project updates panel. And again, same fix as above for the AA. version-17.0 task-3973206 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171476
This commit restores the context passing that was lost in the rework of `calendar.event` quick create #114827. Current behavior before PR: Action context is not passed to the `calendar.event` form view when accessed via the calendar popover `View` button. The `New` button above the calendar view passes the context as expected. For example: this button opens the calendar view but the keys `example_context`, `active_id` and `active_model` are not available in the context when an existing cal
Original PR description
This commit restores the context passing that was lost in the rework of `calendar.event` quick create #114827.
Current behavior before PR:
Action context is not passed to the `calendar.event` form view when accessed via the calendar popover `View` button. The `New` button above the calendar view passes the context as expected.
For example: this button opens the calendar view but the keys `example_context`, `active_id` and `active_model` are not available in the context when an existing calendar event is then viewed in a form. `<button name="calendar.action_calendar_event" type="action" context="{'example_context': True}"/>`
Desired behavior after PR is merged:
Action context is available in the `calendar.event` form view when the form is accessed via the calendar popover form.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#176130When using a non parsable ODOO_MAX_HTTP_THREADS value, take into account max_cron_threads. When a lot of xmlrpc or jsonrpc calls are made, 2 cursor are used per call due to the authentification so it maxes out and the pool limit. If the cron_thread are using a cursor we end up with a "Pool Is Full" error. Forward-Port-Of: odoo/odoo#172902
Original PR description
When using a non parsable ODOO_MAX_HTTP_THREADS value, take into account max_cron_threads. When a lot of xmlrpc or jsonrpc calls are made, 2 cursor are used per call due to the authentification so it maxes out and the pool limit. If the cron_thread are using a cursor we end up with a "Pool Is Full" error. Forward-Port-Of: odoo/odoo#172902
__Current behavior before commit:__ When a mega menu has the class `o_mega_menu_container_size`, it is translated by 50% to the left because of this line [1]. However it shouldn't be if it is displayed inside a dropdown menu. __Description of the fix:__ Unset `transform` of `.o_mega_menu_container_size` when it is inside an `.o_extra_menu_items` element. __Steps to reproduce the issue on runbot:__ 1. Add a mega menu to the website 2. In the Editor, set Mega Menu > Size to `Narrow` a
Original PR description
__Current behavior before commit:__ When a mega menu has the class `o_mega_menu_container_size`, it is translated by 50% to the left because of this line [1]. However it shouldn't be if it is displayed inside a dropdown menu. __Description of the fix:__ Unset `transform` of `.o_mega_menu_container_size` when it is inside an `.o_extra_menu_items` element. __Steps to reproduce the issue on runbot:__ 1. Add a mega menu to the website 2. In the Editor, set Mega Menu > Size to `Narrow` and save 3. Resize the window just enough that a dropdown menu appear 4. Open the dropdown menu -> The mega menu is offset to the left opw-4021738 [1]: https://github.com/odoo/odoo/blob/9835632/addons/website/static/src/scss/website.scss#L1294 Forward-Port-Of: odoo/odoo#172438
As mentioned in this [comment](https://github.com/odoo/odoo/pull/164295#issuecomment-2139764771), the `stardard_price` field in product was being recomputed even if this product had no negative layers to fix. Since standard_price is already recomputed before calling `_run_fifo_vacuum` (in `product_price_update_before_done`, for example), there's no need to recompute it again, especially with a different logic. Please refer to the comment I linked for more details. --- I confirm I have si
Original PR description
As mentioned in this [comment](https://github.com/odoo/odoo/pull/164295#issuecomment-2139764771), the `stardard_price` field in product was being recomputed even if this product had no negative layers to fix. Since standard_price is already recomputed before calling `_run_fifo_vacuum` (in `product_price_update_before_done`, for example), there's no need to recompute it again, especially with a different logic. Please refer to the comment I linked for more details. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176924 Forward-Port-Of: odoo/odoo#167604
When a blog cover is edited, a tag option is displayed while there is no `tag_ids` inside the `blog.blog` model because the `o_wblog_post_page_cover` appears on both the `blog.blog` covers and on the `blog.post` covers. This commit hides the blog tags option if the model of the cover is `blog.blog`. Steps to reproduce: - Go to blogs. - Select the "Travel" blog. - Edit. - Select the blog's cover. => A tag option could be specified. opw-4107748 Forward-Port-Of: odoo/odoo#177077 Fo
Original PR description
When a blog cover is edited, a tag option is displayed while there is no `tag_ids` inside the `blog.blog` model because the `o_wblog_post_page_cover` appears on both the `blog.blog` covers and on the `blog.post` covers. This commit hides the blog tags option if the model of the cover is `blog.blog`. Steps to reproduce: - Go to blogs. - Select the "Travel" blog. - Edit. - Select the blog's cover. => A tag option could be specified. opw-4107748 Forward-Port-Of: odoo/odoo#177077 Forward-Port-Of: odoo/odoo#176510
Description of the issue/feature this PR addresses: When change date_planned field of a confirmed PO, some times can happen if there more than one line_section or line_note, these lines is seen as product_lines. Current behavior before PR: Before Assertion failure for round digits for precision digits on method https://github.com/odoo/odoo/blob/16.0/odoo/tools/float_utils.py#L25 So we can't change the date_planned values. Desired behavior after PR is merged: I can change the date_pl
Original PR description
Description of the issue/feature this PR addresses: When change date_planned field of a confirmed PO, some times can happen if there more than one line_section or line_note, these lines is seen as product_lines. Current behavior before PR: Before Assertion failure for round digits for precision digits on method https://github.com/odoo/odoo/blob/16.0/odoo/tools/float_utils.py#L25 So we can't change the date_planned values. Desired behavior after PR is merged: I can change the date_planned field More Note: I see the problem for version 14.0 15.0 e and 16.0 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168676
This will add rules for the payroll in Alabama, Nevada, Washington and Colorado. Task: 3923285 Forward-Port-Of: odoo/odoo#175563
Original PR description
This will add rules for the payroll in Alabama, Nevada, Washington and Colorado. Task: 3923285 Forward-Port-Of: odoo/odoo#175563
It is necessary to check access rights when linking a post to another forum, so that the user linked to the post always has access to it. task-4116016 Forward-Port-Of: odoo/odoo#176804 Forward-Port-Of: odoo/odoo#176744
Original PR description
It is necessary to check access rights when linking a post to another forum, so that the user linked to the post always has access to it. task-4116016 Forward-Port-Of: odoo/odoo#176804 Forward-Port-Of: odoo/odoo#176744
At the moment, JP is added at the start of the tax scheme vals. In Japan and after 2023-10-01, the expected value in the company_id is the "Registration Number for Qualified Invoice purpose in Japan" which starts with a T and does not want JP prepended to it. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177144
Original PR description
At the moment, JP is added at the start of the tax scheme vals. In Japan and after 2023-10-01, the expected value in the company_id is the "Registration Number for Qualified Invoice purpose in Japan" which starts with a T and does not want JP prepended to it. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177144
before this commit: Service type `FEDEX_INTERNATIONAL_CONNECT_PLUS` was not available the list 'fedex_service_type'. After this commit: Missing service type is added in the list. reference fedex doc: https://developer.fedex.com/api/en-us/guides/api-reference.html#servicetypes opw-4061797 Forward-Port-Of: odoo/enterprise#64250
Original PR description
before this commit: Service type `FEDEX_INTERNATIONAL_CONNECT_PLUS` was not available the list 'fedex_service_type'. After this commit: Missing service type is added in the list. reference fedex doc: https://developer.fedex.com/api/en-us/guides/api-reference.html#servicetypes opw-4061797 Forward-Port-Of: odoo/enterprise#64250
Before this commit: Generating return label on delivery was disabled intentionally. After this commit: Option to select return label on delivery is enabled. A warning is added in `sendcloud_product_selection_widget` for customers befroe selecting return product. opw-4008265 Forward-Port-Of: odoo/enterprise#68447
Original PR description
Before this commit: Generating return label on delivery was disabled intentionally. After this commit: Option to select return label on delivery is enabled. A warning is added in `sendcloud_product_selection_widget` for customers befroe selecting return product. opw-4008265 Forward-Port-Of: odoo/enterprise#68447
### Steps to reproduce the issue: 1. Create a Batch of Payments 2. Create a Bank Statement Line and reconcile it with one of the Payments in the Batch 3. Go on any other Bank Statement Line and go to the Batch section 4. The amount shown on the line of the batch did not change ### Explanation: If a Batch is partially reconciled with Bank Statement Lines, `_compute_from_payment_ids_`, which would recalculate `amount_residual`, is not called. ### Fix reasoning: `is_matched` updat
Original PR description
### Steps to reproduce the issue: 1. Create a Batch of Payments 2. Create a Bank Statement Line and reconcile it with one of the Payments in the Batch 3. Go on any other Bank Statement Line and go to the Batch section 4. The amount shown on the line of the batch did not change ### Explanation: If a Batch is partially reconciled with Bank Statement Lines, `_compute_from_payment_ids_`, which would recalculate `amount_residual`, is not called. ### Fix reasoning: `is_matched` updates on every reconciliation between a Bank Statement Line and a Payment. Adding it to the dependencies of `_compute_from_payment_ids` will make reconciliations trigger the method. opw-4062387 Forward-Port-Of: odoo/enterprise#68547 Forward-Port-Of: odoo/enterprise#67519
Commit fixes appointment description styling task-3446959 Forward-Port-Of: odoo/enterprise#65897
Original PR description
Commit fixes appointment description styling task-3446959 Forward-Port-Of: odoo/enterprise#65897
Steps to reproduce: - Create a partner with a ref "PARTNER01" - Import a FEC with the same partner ref Issue: You will 2 same contacts Cause: During the refactor, the check existing partner has been taken out https://github.com/odoo/enterprise/commit/f60263a105717a7e00b1996b2b2e7b89e514ca54#diff-0c2b1931af025d6a908eea7d818a8858c6e9b03b436757b3c49ffa9857e55ae1L208-L227 Solution: The flow has slightly changed. To make sure the records already existing have an xml_id, we update them
Original PR description
Steps to reproduce: - Create a partner with a ref "PARTNER01" - Import a FEC with the same partner ref Issue: You will 2 same contacts Cause: During the refactor, the check existing partner has been taken out https://github.com/odoo/enterprise/commit/f60263a105717a7e00b1996b2b2e7b89e514ca54#diff-0c2b1931af025d6a908eea7d818a8858c6e9b03b436757b3c49ffa9857e55ae1L208-L227 Solution: The flow has slightly changed. To make sure the records already existing have an xml_id, we update them opw-3932234 Forward-Port-Of: odoo/enterprise#63895
During aea506700d9a3253c02f46f587a3e360a89cce0b, we forgot to adapt the model that was inheriting `account.generic.tax.report.handler` to make it inherit the new `account.tax.report.handler` model. Because of that, we never passed into the `_get_vat_closing_entry_additional_domain` method, leading to wrong lines being included in the closing entry. Steps: - Install l10n_lu and l10n_eu_oss_reports - Create and confirm two invoices, one with tax 17% S and the other with tax 20.0% FR VAT - Go t
Original PR description
During aea506700d9a3253c02f46f587a3e360a89cce0b, we forgot to adapt the model that was inheriting `account.generic.tax.report.handler` to make it inherit the new `account.tax.report.handler` model. Because of that, we never passed into the `_get_vat_closing_entry_additional_domain` method, leading to wrong lines being included in the closing entry. Steps: - Install l10n_lu and l10n_eu_oss_reports - Create and confirm two invoices, one with tax 17% S and the other with tax 20.0% FR VAT - Go to LU Tax Report, select the same month as the invoices - Click on Closing Entry button -> There are lines from tax 20.0% FR VAT, they should not be there opw-4015752 Forward-Port-Of: odoo/enterprise#67815
## Issue: When validating a stock picking, in a Mondial relay delivery, if the partner created for it has no parent_id, the code will raise an error. ## Steps to reproduce: - Create a sendcloud delivery method (mondial relay) - go to website and order a product, go to checkout - pick sendcloud delivery method - select a relay location - go to odoo backend, go the sale order created by the website - click the SO deliveries smart button - change the quantity to the same as demand - cli
Original PR description
## Issue: When validating a stock picking, in a Mondial relay delivery, if the partner created for it has no parent_id, the code will raise an error. ## Steps to reproduce: - Create a sendcloud delivery method (mondial relay) - go to website and order a product, go to checkout - pick sendcloud delivery method - select a relay location - go to odoo backend, go the sale order created by the website - click the SO deliveries smart button - change the quantity to the same as demand - click on the delivery address - remove the partner's parent_id - add an email and phone number to the partner and save - go back to the picking page and click validate - a traceback will appear ## Solution: - in the `_prepare_parcel_common_data` method, raise a user error if the SO has `access_point_data` and the partner has no parent_id. OPW-4042529 Forward-Port-Of: odoo/enterprise#67074
This will add rules for the payroll in Alabama, Nevada, Washington and Colorado. Task: 3923285 Forward-Port-Of: odoo/enterprise#63481
Original PR description
This will add rules for the payroll in Alabama, Nevada, Washington and Colorado. Task: 3923285 Forward-Port-Of: odoo/enterprise#63481
As per section 34(2) of CGST Act 2017, credit notes for invoices from the financial year cannot be included in GSTR after November 30th. With this PR, if a credit note is created after November 30th of the financial year, an alert will be displayed to remind users to exclude the tax, as it cannot be included in GSTR. POT file also added for `l10n_in_gstr_reports` **task**-3915664 Forward-Port-Of: odoo/enterprise#66713
Original PR description
As per section 34(2) of CGST Act 2017, credit notes for invoices from the financial year cannot be included in GSTR after November 30th. With this PR, if a credit note is created after November 30th of the financial year, an alert will be displayed to remind users to exclude the tax, as it cannot be included in GSTR. POT file also added for `l10n_in_gstr_reports` **task**-3915664 Forward-Port-Of: odoo/enterprise#66713
Versions: ------------ 17.0 Steps to reproduce: ------------------------- 1. Send a sign request with 2 signers, setting a reminder to be sent every day. 2. Two emails will be sent to different signers. 3. Change the local date to 2 days ahead. 4. Run the "Send: Sign Reminder" cron. - Two more emails will be received, and one signer will complete their sign request. 5. Change the dates again and run the cron job. - One email will be sent to the remaining signer. 6. From the
Original PR description
Versions:
------------
17.0
Steps to reproduce:
-------------------------
1. Send a sign request with 2 signers, setting a reminder to be sent every day.
2. Two emails will be sent to different signers.
3. Change the local date to 2 days ahead.
4. Run the "Send: Sign Reminder" cron.
- Two more emails will be received, and one signer will complete their sign request.
5. Change the dates again and run the cron job.
- One email will be sent to the remaining signer.
6. From the old sign request email, copy the link and try to resend it.
- The user should not be able to resend the new link.
Issue:
-------
Resending the link does not check the state of the sign request and items, allowing multiple sends.
Solution:
-----------
Resending the link is only possible if the request and items are not already completed, canceled, or refused.
task: 4002440
Forward-Port-Of: odoo/enterprise#65853