Thursday, August 22, 2024
51 changes · saas-17.4
Enhancements to existing features
Self-ordering QR codes are now generated as PNG images with transparent backgrounds instead of white ones. This makes them easier to place on different menu designs, signs, or branded materials without a visible white box.
Original PR description
Previously, the qr codes for `pos_self_order` were created with a white bg. We now change this such that they are of type `png` and have a transparent bg. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This fixes an internal mail test setup so it can run successfully even when sample demo data is not installed. It helps keep automated quality checks reliable across more deployment and testing configurations, with no direct change for end users.
Original PR description
runbot-70915
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 fix makes inbox notification processing happen in a consistent order every time. It reduces random test failures and helps ensure message notifications behave predictably for users.
Original PR description
Adding sort to always process the partners in the same order. Confirmed to resolve the issue as adding reverse=True makes the test crash systematically instead. runbot-70612 runbot-74125
Opening Customer Ratings from a project could crash when customer ratings were enabled. This corrects the filter used by that menu so users can access project rating information reliably.
Original PR description
Issue ----- [project, sale_timesheet] 1. Activate "Customer ratings" in Project settings. 2. On Project kanban view > Open dropdown of a project > Customer Ratings > Traceback. Change ----- Small correction of 72f98a5925512a19fc084f1fc207f221e47e856e, the correct filter is the one defined here: https://github.com/odoo/odoo/blob/72f98a5925512a19fc084f1fc207f221e47e856e/addons/project/views/rating_rating_views.xml#L141 opw-4111790
This fix restores the expected spacing in quick create cards within kanban views. It improves readability and visual consistency for users adding new records from a kanban board.
Original PR description
This commit's purpose is to fix the display of quick create card in the kanban view. Due to this commit : https://github.com/odoo/odoo/commit/206f3d4856a3da8c12088b49df6a01675a0c3c62 a lot of space were missing. This fix set the spacing back. task - 4038168 version saas-17.4-master
This fixes a missed internal import in the HR module after a previous cleanup changed what mail tools expose. It helps prevent errors when loading or using HR functionality, with no expected change to day-to-day workflows.
Original PR description
Followup of 5057ea17fef0, update missed import --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Vendor bills created from multiple selected documents now open with normal navigation between the generated bills. This fixes a case where users were stuck on a single bill because a duplicate-check view took priority over the standard bill view.
Original PR description
Steps to reproduce: - Install the documents_account module - Documents > Finance - Select multiple documents - Create vendor bills - On a bill's form view pager is 1/1 We should be able to use the pager to navigate between the bills here, but the default view is an override meant to show potential duplicates. Since duplicates can be of different record types, it isn't technically possible to use the pager on them. This behavior is overly specific for a default view hence why the priority is taken down so low. opw-4104435 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a small scheduling issue where planned shift times could incorrectly show or calculate as 60 minutes instead of staying within valid minute values. It helps avoid edge-case errors when using planning templates with start or end times very close to the next hour.
Original PR description
round() on the fractional part of shift_template.end_time/start_time can lead to problems when the result is very close to 1.0 (e.g., anything greater than 0.994). Specifically, round() can cause the fractional part to round up to 1.0 (so 60 minutes), which is not wanted. We can either set it to 59 as done here, or 0 and add 1 hour to the hours.
When customers submit helpdesk tickets with attachments through the website, the system will no longer change the message visibility setting behind the scenes. This preserves the intended communication behavior and avoids unintended changes to how ticket updates are classified.
Original PR description
Before this commit, when the helpdesk ticket is created by the website form and need to insert an attachment, the subtype used is altered to be able to let the portal user to see it instead of a using a non internal subtype. This commit reverts the changes made in d9b06557baf692f707ff8b75106df6b67c6bc523 to avoid altering the subtype.
This fix ensures WhatsApp-related automated checks can run successfully even when sample demo data is not installed. It helps keep validation reliable across more deployment and testing setups, reducing false failures in the release process.
Original PR description
runbot-70776
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 500, configurable
using "mail.batch_size" configuration parameter. For notification emails
it was done by batches of 50 but 500 seems acceptable, behaving like
the mail composer;
-- 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#177505
Forward-Port-Of: odoo/odoo#177046**Versions:** 17.0 **Steps to reproduce:** 1. Enable debug mode. 2. Go to the calendar. 3. Create an event using the quick create form. 4. Click on the Odoo meeting link. 5. Try to clear the meeting. **Issue:** A traceback occurs when attempting to clear a meeting in debug mode. **Cause:** The 'CopyButton' component expects the content to be a string but receives `false`. **Solution:** In the form controller, set `videocall_location` to an empty string instead of `false
Original PR description
**Versions:** 17.0 **Steps to reproduce:** 1. Enable debug mode. 2. Go to the calendar. 3. Create an event using the quick create form. 4. Click on the Odoo meeting link. 5. Try to clear the meeting. **Issue:** A traceback occurs when attempting to clear a meeting in debug mode. **Cause:** The 'CopyButton' component expects the content to be a string but receives `false`. **Solution:** In the form controller, set `videocall_location` to an empty string instead of `false` in `beforeExecuteActionButton`. Task-4091314 Forward-Port-Of: odoo/odoo#177447 Forward-Port-Of: odoo/odoo#175496
This commit ensures that creating an invoice PDF always uses the invoice company paperformat. Invoice PDF could be generated in one of 2 ways (after clicking the invoice `send & print` button): 1. Non-cron: Either use a single invoice, or multiple invoices with the `download` option checked. 2. Cron: Create PDFs for multiple invoices with no `download` option. The 2 ways would generate differently styled PDFs if the default company had a different paperformat from that of the invoice com
Original PR description
This commit ensures that creating an invoice PDF always uses the invoice company paperformat. Invoice PDF could be generated in one of 2 ways (after clicking the invoice `send & print` button): 1. Non-cron: Either use a single invoice, or multiple invoices with the `download` option checked. 2. Cron: Create PDFs for multiple invoices with no `download` option. The 2 ways would generate differently styled PDFs if the default company had a different paperformat from that of the invoice company. This happened because the paperformat for cron-generated PDFs would be retrieved from the default company and not from the invoice company. task-4046055 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176947
Steps to reproduce: - Open website menu editor - Add a child menu to a menu - Delete the parent menu - Save Old behavior: a traceback appears New behavior: no traceback, parent and children menus are correctly deleted. This commit fixes the issue by properly deleting children menus recursively before deleting the parent. opw-4119441 Forward-Port-Of: odoo/odoo#177491 Forward-Port-Of: odoo/odoo#177243
Original PR description
Steps to reproduce: - Open website menu editor - Add a child menu to a menu - Delete the parent menu - Save Old behavior: a traceback appears New behavior: no traceback, parent and children menus are correctly deleted. This commit fixes the issue by properly deleting children menus recursively before deleting the parent. opw-4119441 Forward-Port-Of: odoo/odoo#177491 Forward-Port-Of: odoo/odoo#177243
It was possible to upload a file and decode it by attaching it to a message in the chatter (factur-x, ulb...), but not by attaching it directly to the invoice. This commit allows for the same behaviour in both ways. task-3997526 Forward-Port-Of: odoo/odoo#171393
Original PR description
It was possible to upload a file and decode it by attaching it to a message in the chatter (factur-x, ulb...), but not by attaching it directly to the invoice. This commit allows for the same behaviour in both ways. task-3997526 Forward-Port-Of: odoo/odoo#171393
Summary ----- Normally, in the load.py method, when there is an error in creating the recordset to be imported, the records are then created one by one. The following commit prevents this behavior in case of a failure to create the recordset in one go: https://github.com/odoo/odoo/pull/173094/commits/ced1ec251d361d8a3ca32ad51e8516668447ca0e. Steps to reproduce ----- Create a module that redefines the create method of the res.users model to throw an error if vals_list contains at least 2
Original PR description
Summary ----- Normally, in the load.py method, when there is an error in creating the recordset to be imported, the records are then created one by one. The following commit prevents this behavior in case of a failure to create the recordset in one go: https://github.com/odoo/odoo/pull/173094/commits/ced1ec251d361d8a3ca32ad51e8516668447ca0e. Steps to reproduce ----- Create a module that redefines the create method of the res.users model to throw an error if vals_list contains at least 2 elements. Import a file containing at least 2 users (by adding the suffix /web#model=res.users&action=import to the URL). Cause ----- The global error message has been logged since the commit cited in the summary. However, a rollback is performed if there are error messages. Fix ----- If we see that there are no errors when creating the records one by one, we then remove the logged error messages. opw-4102745 Forward-Port-Of: odoo/odoo#176901
Export routes ('/web/export/csv' and '/web/export/xlsx') are marked as read-only, but the _export_rows() can actually create ir_model_data rows in the database. If import-compatible export is enabled and you export a row without an external ID, you will get a traceback if the readonly replica feature is enabled. The fallback mechanism of the readonly transaction to retry the current request doesn't work because the `except Exception as exc` in export routes changes the exception type (=> trac
Original PR description
Export routes ('/web/export/csv' and '/web/export/xlsx') are marked as read-only, but the _export_rows() can actually create ir_model_data rows in the database. If import-compatible export is enabled and you export a row without an external ID, you will get a traceback if the readonly replica feature is enabled.
The fallback mechanism of the readonly transaction to retry the current request doesn't work because the `except Exception as exc` in export routes changes the exception type (=> traceback).
=> Remove the readonly flag from export routes.
Forward-Port-Of: odoo/odoo#177262The technical refactor in [1] renamed the tax amount in currency from `amount_tax` to `tax_amount_currency`. However, in some instances, it was mistakenly renamed to `tax_amount`, including in the commit description. This commit corrects this minor oversight. [1]: https://github.com/odoo/odoo/commit/68fbdc96 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177318
Original PR description
The technical refactor in [1] renamed the tax amount in currency from `amount_tax` to `tax_amount_currency`. However, in some instances, it was mistakenly renamed to `tax_amount`, including in the commit description. This commit corrects this minor oversight. [1]: https://github.com/odoo/odoo/commit/68fbdc96 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177318
Currently `_run_fifo_vacuum` can be a performance bottleneck when confirming a large IN transfer. This is especially true for anglo_saxon accounting companies. To fix that, this commit introduces batch versions of `_run_fifo_vacuum` and `_create_fifo_vacuum_anglo_saxon_expense_entry`. The idea of these batch versions is to batch records creation, moves posting, search, etc. Stuff that cannot be batched/don't need to be batched are left as is. #### Speedup 15.0 customer database with 476 0
Original PR description
Currently `_run_fifo_vacuum` can be a performance bottleneck when confirming a large IN transfer. This is especially true for anglo_saxon accounting companies. To fix that, this commit introduces…
Currently `_run_fifo_vacuum` can be a performance bottleneck when confirming a large IN transfer. This is especially true for anglo_saxon accounting companies. To fix that, this commit introduces batch versions of `_run_fifo_vacuum` and `_create_fifo_vacuum_anglo_saxon_expense_entry`. The idea of these batch versions is to batch records creation, moves posting, search, etc. Stuff that cannot be batched/don't need to be batched are left as is. #### Speedup 15.0 customer database with 476 000 account.moves, 1M account.move.lines, 8400 products, 700 000 stock.moves, 650 000 stock.move.lines, 500 000 svls All categories have Inventory Valuation set to real_time. Benchmark validation of IN transfers, changing the number of products + total number of svls | Number of products | Total number of svls | Before PR | After PR | |:----------------:|:-------------------:|:-----------:|:-----------:| | 1 | 112 | 3.88s | 3.78s | | 2 | 607 | 548ms | 524ms | | 5 | 2561 | 2.27s | 1.10s | | 3 | 8956 | 15min | 2min | | 32 | 43310 | 7min | 50s | Some pickings are not directly impacted by the PR, most probably because these pickings don't have candidates svls/svls to vacuum to begin with. Still for the fourth and fith picking, the batch version performs way better than the iterative one. Validating an IN transfer with stock_account and real-time inventory valuation is a complex process so it's a bit difficult to pinpoint tables cardinalities that correlate with the validation time. Here it's the Before vs After time that is relevant, more than the validation time growth. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170131 Forward-Port-Of: odoo/odoo#157558
This feature is not available in mobile OS at the time of this commit [1]: - Safari on iOS 17.5 - Chrome for Android 127 - Firefox for Android 127 Therefore the button should not be shown, otherwise it mistakenly gives the impression that user could make it work by enabling screen-sharing permission which is not possible on mobile OS. opw-4108833 [1]: https://caniuse.com/mdn-api_mediadevices_getdisplaymedia <img width="333" alt="Screenshot 2024-08-21 at 13 26 13" src="https://gi
Original PR description
This feature is not available in mobile OS at the time of this commit [1]: - Safari on iOS 17.5 - Chrome for Android 127 - Firefox for Android 127 Therefore the button should not be shown, otherwise it mistakenly gives the impression that user could make it work by enabling screen-sharing permission which is not possible on mobile OS. opw-4108833 [1]: https://caniuse.com/mdn-api_mediadevices_getdisplaymedia <img width="333" alt="Screenshot 2024-08-21 at 13 26 13" src="https://github.com/user-attachments/assets/ead3281d-2ef4-412e-8d4f-edab4a85b1e9"> Forward-Port-Of: odoo/odoo#177371
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#176896
Forward-Port-Of: odoo/odoo#176130### 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
_**New fix, cf commit**_
Original PR description
_**New fix, cf commit**_
- Intall website_sale_product_configurator - Create a product A with price 3 999.00 € - Add an optional product on product A - Go to shop page - Go to product A - Add to cart - A modal popup appear - Finelize cart --> Issue the price send to datalayer is 3. Because "3 999,00" is send in the json, endead 3999.00. Co-Authored-By: "Louis (loti)" <loti@odoo.com> Forward-Port-Of: odoo/odoo#177387 Forward-Port-Of: odoo/odoo#167962
Original PR description
- Intall website_sale_product_configurator - Create a product A with price 3 999.00 € - Add an optional product on product A - Go to shop page - Go to product A - Add to cart - A modal popup appear - Finelize cart --> Issue the price send to datalayer is 3. Because "3 999,00" is send in the json, endead 3999.00. Co-Authored-By: "Louis (loti)" <loti@odoo.com> Forward-Port-Of: odoo/odoo#177387 Forward-Port-Of: odoo/odoo#167962
Currently, the editor uses the bootstrap grid system for the column layouts and the editor CSS rules changes the paddings and the margins of the columns. When the user prints a document, the columns can go one under the other but the paddings and margins set are still applied. As a result, the columns appear off-centered on printing devices. To fix that issue, we will scope the CSS rules that adjust the paddings and margins of the columns to the screen devices. This way, the rules won't be ap
Original PR description
Currently, the editor uses the bootstrap grid system for the column layouts and the editor CSS rules changes the paddings and the margins of the columns. When the user prints a document, the columns can go one under the other but the paddings and margins set are still applied. As a result, the columns appear off-centered on printing devices. To fix that issue, we will scope the CSS rules that adjust the paddings and margins of the columns to the screen devices. This way, the rules won't be applied when printing the document. task-3664950 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168814
Steps to reproduce: - Install module 'France - Adding Mandatory Invoice Mentions' - Switch to FR company - Contacts > Create french company - Sales & Purchase tab > set SIRET value - Create an invoice for this company > Print it The SIRET number does not show up anywhere on the invoice, despite the conditions being met. The SIRET number has been mandatory since July 1st 2024 in France This sometimes happens because the xpath only edits one of the 3 possible address tags added in 16.
Original PR description
Steps to reproduce: - Install module 'France - Adding Mandatory Invoice Mentions' - Switch to FR company - Contacts > Create french company - Sales & Purchase tab > set SIRET value - Create an invoice for this company > Print it The SIRET number does not show up anywhere on the invoice, despite the conditions being met. The SIRET number has been mandatory since July 1st 2024 in France This sometimes happens because the xpath only edits one of the 3 possible address tags added in 16.0. There is no need to edit the margin because the address already has mb-0 in its classes. opw-3865644 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177060
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#177363 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#177363 Forward-Port-Of: odoo/odoo#174227
Ticket: 1239 Adhoc-task: 41734 Description of the issue/feature this PR addresses: This task was created to modify the demo data for Uruguay, to avoid using real partner information. 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#176807
Original PR description
Ticket: 1239 Adhoc-task: 41734 Description of the issue/feature this PR addresses: This task was created to modify the demo data for Uruguay, to avoid using real partner information. 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#176807
Steps to reproduce the issue: ============================= - Install website and events - Go to events page and enable editor - Click on customize and enable sidebar - enable Follow us option - Select a social media icon and enable open in a new window option - Save - Click on the updated icon, it still opens in the same page => the changes aren't saved. Origin of the issue: ==================== The `target` attribute was ignored when saving and `arch_section`. Solution =======
Original PR description
Steps to reproduce the issue: ============================= - Install website and events - Go to events page and enable editor - Click on customize and enable sidebar - enable Follow us option - Select a social media icon and enable open in a new window option - Save - Click on the updated icon, it still opens in the same page => the changes aren't saved. Origin of the issue: ==================== The `target` attribute was ignored when saving and `arch_section`. Solution ======== Add `target` attribute to the allowed root attrs. opw-4077657 Forward-Port-Of: odoo/odoo#177269 Forward-Port-Of: odoo/odoo#177035
Before this commit, the user would get a UserError when multiple attachments are merged for export and one of them is corrupted. The error message did not contain information helping the user identify the problematic records. After this commit, the user will get a RedirectWarning stating the number of corrupted files and a link to a form view (if single) or a list view (if multiple) of problematic record(s). ### Example workflow: 1. Go to Accounting > Vendors > Bills. 2. Create a bill wi
Original PR description
Before this commit, the user would get a UserError when multiple attachments are merged for export and one of them is corrupted. The error message did not contain information helping the user…
Before this commit, the user would get a UserError when multiple attachments are merged for export and one of them is corrupted. The error message did not contain information helping the user identify the problematic records. After this commit, the user will get a RedirectWarning stating the number of corrupted files and a link to a form view (if single) or a list view (if multiple) of problematic record(s). ### Example workflow: 1. Go to Accounting > Vendors > Bills. 2. Create a bill with a corrupted attachment. 3. Select the corrupted bill amongst other bills with valid attachments. 4. Click on Print > Original Bills. 5. The error is: "Odoo is unable to merge the generated PDFs." ### Cause: Errors raised by instantiating a PdfFileReader of a corrupted file were handled with a UserError with a static error message. ### Solution: In `_merge_pdfs` method signature, add an optional callback to define the way errors are handled. The default callback reproduces the default behavior. In `_render_qweb_pdf`, a custom callback is defined to keep track of the corrupted streams and log them in the RedirectWarning popup. opw-4067992 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177228 Forward-Port-Of: odoo/odoo#174701
### Steps to reproduce: - Activate developer mode - Go in Accounting > Configuration > Accounting > Account Groups - Create 4 account groups in a specific λ configuration, for example: ``` 2 \ 21 / \ 210 211 ``` - Go in Accounting > Reporting > Audit Reports > Trial Balance - In options, select "Hierarchy and Subtotals" to see the hierarchy - The hierarchy might be wrong or not, but each time recreating the 211 group, the hierarchy will switch between these two tre
Original PR description
### Steps to reproduce: - Activate developer mode - Go in Accounting > Configuration > Accounting > Account Groups - Create 4 account groups in a specific λ configuration, for example: ``` 2 \ 21 / \…
### Steps to reproduce:
- Activate developer mode
- Go in Accounting > Configuration > Accounting > Account Groups
- Create 4 account groups in a specific λ configuration, for example:
```
2
\
21
/ \
210 211
```
- Go in Accounting > Reporting > Audit Reports > Trial Balance
- In options, select "Hierarchy and Subtotals" to see the hierarchy
- The hierarchy might be wrong or not, but each time recreating the 211 group, the hierarchy will switch between these two trees:
```
2 2
\ / \
21 <--> 210 21
/ \ \
210 211 211
```
### Cause:
The way the `parent_id` field is computed is by doing a [SQL query](https://github.com/odoo/odoo/blob/5c39004a1e37b35a47ed95933060c0aa5dd83803/addons/account/models/account_account.py#L954C9-L975C33) that will:
1. retrieve all combinations of (parent group, child group) for each child, for example [(2, 210), (21, 210)]
2. sort them in decreasing order of parent code_prefix_start length, for example [(21, 210), (2, 210)]
3. select only the first one : [(21, 210)]
4. change the `parent_id` field of the child according to the values retrieved
But a [performance improvement](https://github.com/odoo/odoo/commit/82714afa463adda2b404b4dae81a27423880e499) was applied that only selected the combinations that had `child.parent_id IS DISTINCT FROM parent.id` to avoid updating if nothing changed. This caused the retrieve combinations at step 2 to only be [(2, 210)] in the example. So when updating it breaks the hierarchy.
### Solution:
Filter the records to be updated in the UPDATE.
opw-4066976
Forward-Port-Of: odoo/odoo#176945Fix query counters for event mail schedulers and mail template performance tests. Use warmup decorator to remove queries linked to cold state, in order to have results closer to real life scenario. Prepares Task-3084943: Event: Improve communication scheduler scalability Forward-Port-Of: odoo/odoo#177205 Forward-Port-Of: odoo/odoo#177099
Original PR description
Fix query counters for event mail schedulers and mail template performance tests. Use warmup decorator to remove queries linked to cold state, in order to have results closer to real life scenario. Prepares Task-3084943: Event: Improve communication scheduler scalability Forward-Port-Of: odoo/odoo#177205 Forward-Port-Of: odoo/odoo#177099
Backport of odoo/odoo#166532 Forward-Port-Of: odoo/odoo#177090 Forward-Port-Of: odoo/odoo#177052
Original PR description
Backport of odoo/odoo#166532 Forward-Port-Of: odoo/odoo#177090 Forward-Port-Of: odoo/odoo#177052
Steps to reproduce the bug: - Enable by-porduct option in manufacturing settings - Create a storable product “P1” with a BoM: - Components: C1 - by-product: C2 tracked by serial number - Create a manufacturing order (MO) to produce one unit of P1. - Confirm the MO. - Click on the detailed operation to select the serial number for C2. Problem: the field "lot_id" should be displayed instead of "lot_name". because we should be able to create and use existing SN with byproduct mov
Original PR description
Steps to reproduce the bug: - Enable by-porduct option in manufacturing settings - Create a storable product “P1” with a BoM: - Components: C1 - by-product: C2 tracked by serial number - Create a manufacturing order (MO) to produce one unit of P1. - Confirm the MO. - Click on the detailed operation to select the serial number for C2. Problem: the field "lot_id" should be displayed instead of "lot_name". because we should be able to create and use existing SN with byproduct moves. opw-[4113887](https://www.odoo.com/web#id=4113887&view_type=form&model=project.task) Forward-Port-Of: odoo/odoo#177361 Forward-Port-Of: odoo/odoo#177061
Simple patch that prevent the prefetch of the oauth token Forward-Port-Of: odoo/odoo#177259
Original PR description
Simple patch that prevent the prefetch of the oauth token Forward-Port-Of: odoo/odoo#177259
A Factur-X XML generated in Germany should not falsely claim to be compliant to the KoSIT XRechnung. Forward-Port-Of: odoo/odoo#177330
Original PR description
A Factur-X XML generated in Germany should not falsely claim to be compliant to the KoSIT XRechnung. Forward-Port-Of: odoo/odoo#177330
Improving tax scopes and EC sales tax report tags for `l10n_at` Old PR: odoo/odoo#171606 Info: @wt-io-it Ticket link: https://www.odoo.com/odoo/project.task/3916300 opw-3916300 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177074 Forward-Port-Of: odoo/odoo#171702
Original PR description
Improving tax scopes and EC sales tax report tags for `l10n_at` Old PR: odoo/odoo#171606 Info: @wt-io-it Ticket link: https://www.odoo.com/odoo/project.task/3916300 opw-3916300 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177074 Forward-Port-Of: odoo/odoo#171702
Version: 17.0+ Current behavior: The default account for Deferred Expense on res.config.setting is "inappropriate". A new account should be established according to account codes by SAT mexico, http://omawww.sat.gob.mx/fichas_tematicas/buzon_tributario/Documents/codigo_agrupador.pdf Purpose of this PR: To introduce an appropriate account to be used for Deferred expenses and automatically selected upon l10n_mx installation. Steps to reproduce on Runbot: 1) install l10n_mx 2) Accoun
Original PR description
Version: 17.0+ Current behavior: The default account for Deferred Expense on res.config.setting is "inappropriate". A new account should be established according to account codes by SAT mexico, http://omawww.sat.gob.mx/fichas_tematicas/buzon_tributario/Documents/codigo_agrupador.pdf Purpose of this PR: To introduce an appropriate account to be used for Deferred expenses and automatically selected upon l10n_mx installation. Steps to reproduce on Runbot: 1) install l10n_mx 2) Accounting Settings > incorrect account selected for Deferred Expense opw-4105993 Forward-Port-Of: odoo/odoo#176681
Steps to reproduce the bug: - Create a storable product “P1” & “P2”, tracked by lot - Create a quant: - Product: “P1” - Lot: “Lot A” - Go to inventory adjustment, import a quant with: - Product: “P2” - Lot: “Lot A” Problem: A quant is created but linked with the record of “Lot A” of product “P1”, which is incorrect. An existing lot with product “P2” should be used, or a new one created if none is available. Unfortunately, in the ORM, the Load function performs a s
Original PR description
Steps to reproduce the bug:
- Create a storable product “P1” & “P2”, tracked by lot
- Create a quant:
- Product: “P1”
- Lot: “Lot A”
- Go to inventory adjustment, import a quant with:
- Product: “P2”
- Lot: “Lot A”
Problem:
A quant is created but linked with the record of “Lot A” of product
“P1”, which is incorrect. An existing lot with product “P2” should be
used, or a new one created if none is available. Unfortunately, in the
ORM, the Load function performs a simple name_search and takes the first
one founded, and it does not link the lot name with the related product.
opw-[4028709](https://www.odoo.com/web#id=4028709&view_type=form&model=project.task)
Forward-Port-Of: odoo/odoo#177179
Forward-Port-Of: odoo/odoo#173696It was missed in 481bfa74a89595df7434a9523e0afc1813b8a774 but added back in master Forward-Port-Of: odoo/odoo#176931
Original PR description
It was missed in 481bfa74a89595df7434a9523e0afc1813b8a774 but added back in master Forward-Port-Of: odoo/odoo#176931
Duplicating a pricelist would copy over the price rules, but not the time-based rules. Adding copy to this field allows that to work. opw-4088788 Forward-Port-Of: odoo/enterprise#68426 Forward-Port-Of: odoo/enterprise#68066
Original PR description
Duplicating a pricelist would copy over the price rules, but not the time-based rules. Adding copy to this field allows that to work. opw-4088788 Forward-Port-Of: odoo/enterprise#68426 Forward-Port-Of: odoo/enterprise#68066
Commit fixes appointment description styling task-3446959 Forward-Port-Of: odoo/enterprise#68652 Forward-Port-Of: odoo/enterprise#65897
Original PR description
Commit fixes appointment description styling task-3446959 Forward-Port-Of: odoo/enterprise#68652 Forward-Port-Of: odoo/enterprise#65897
**Before this PR:** The style of some knowledge templates was broken when attempting to export or print, lacking proper formatting as per the templated structure. It seemed like there was an issue with the template's responsiveness. **After this PR:** Now, the issue has been addressed, and now the template is appropriately formatted and styled, ensuring correctness during export. **Task**-3664950 Forward-Port-Of: odoo/enterprise#56221
Original PR description
**Before this PR:** The style of some knowledge templates was broken when attempting to export or print, lacking proper formatting as per the templated structure. It seemed like there was an issue with the template's responsiveness. **After this PR:** Now, the issue has been addressed, and now the template is appropriately formatted and styled, ensuring correctness during export. **Task**-3664950 Forward-Port-Of: odoo/enterprise#56221
Steps to reproduce 1. Go to the users, click on Marc Demo 2. apply empty groups for documents 3. Create an activity from the chatter of a document 4. Assign it to Marc Demo for instance 5. As Marc Demo, click on the "view document" button in the notification email 6. The user will arrive on AppSwitcher Technical Reason: With commit https://github.com/odoo/enterprise/commit/8e13e68d8a6dcff3da61c60b108e4583860cfcbe, the user clicks on the link will redirect them to the document preview u
Original PR description
Steps to reproduce 1. Go to the users, click on Marc Demo 2. apply empty groups for documents 3. Create an activity from the chatter of a document 4. Assign it to Marc Demo for instance 5. As Marc Demo, click on the "view document" button in the notification email 6. The user will arrive on AppSwitcher Technical Reason: With commit https://github.com/odoo/enterprise/commit/8e13e68d8a6dcff3da61c60b108e4583860cfcbe, the user clicks on the link will redirect them to the document preview using 'ir.actions.act_url'. This later appears on the AppSwitcher because the user does not have access to the document group. After this Commit: Users who have no document groups will access the form view of the document via the link. Task-4052827 Forward-Port-Of: odoo/enterprise#66966
Steps to reproduce: - Create a project and a task - Attach a file to the task - Share the task with Joel Willis (portal user) - DO NOT share the project with him - Log in as Joel Willis (portal user) - Click Tasks > '1 Document' button next to project name This redirects back to portal home menu. This happens because the button leads to projects/id/documents, which Joel Willis has not been granted access to. The expectation would be a redirection to tasks/id/documents instead, as por
Original PR description
Steps to reproduce: - Create a project and a task - Attach a file to the task - Share the task with Joel Willis (portal user) - DO NOT share the project with him - Log in as Joel Willis (portal user) - Click Tasks > '1 Document' button next to project name This redirects back to portal home menu. This happens because the button leads to projects/id/documents, which Joel Willis has not been granted access to. The expectation would be a redirection to tasks/id/documents instead, as portal > projects handles this use case, and we curently do not have a way to share documents attached to a specific task through portal. opw-4009258 Forward-Port-Of: odoo/enterprise#67849
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
Purpose: ------- Currently, clicking several times quickly on the caret to unfold an article in the sidebar may throw an error and show the child articles several times in the sidebar. This commit fixes the issue by preventing to make a new request to load the child articles if one has already been made. Task-4099133 Forward-Port-Of: odoo/enterprise#68013
Original PR description
Purpose: ------- Currently, clicking several times quickly on the caret to unfold an article in the sidebar may throw an error and show the child articles several times in the sidebar. This commit fixes the issue by preventing to make a new request to load the child articles if one has already been made. Task-4099133 Forward-Port-Of: odoo/enterprise#68013
Steps to reproduce: - open consolidation - Select one of the consolidation - Smart button > Consolidated balance - Change the unit currency and put e.g. `In K€` Issue: Keyerror Cause: When opening the consolidated balance, the line does not take into account all the keys ghenerally present in other reports https://github.com/odoo/enterprise/blob/saas-17.2/account_consolidation/report/builder/abstract.py#L272-L278 Solution: Using get to be more defensive. No change is made in the
Original PR description
Steps to reproduce: - open consolidation - Select one of the consolidation - Smart button > Consolidated balance - Change the unit currency and put e.g. `In K€` Issue: Keyerror Cause: When opening the consolidated balance, the line does not take into account all the keys ghenerally present in other reports https://github.com/odoo/enterprise/blob/saas-17.2/account_consolidation/report/builder/abstract.py#L272-L278 Solution: Using get to be more defensive. No change is made in the consolidation module as it will be deperecated in 18.0. opw-4089130 Forward-Port-Of: odoo/enterprise#68436
Purpose of this PR: CoA Report trial balance test adjusted to accommodate for the new account, 173.01 Deferred expenses Community PR that adds new account: #176681 opw-4105993 Forward-Port-Of: odoo/enterprise#68578
Original PR description
Purpose of this PR: CoA Report trial balance test adjusted to accommodate for the new account, 173.01 Deferred expenses Community PR that adds new account: #176681 opw-4105993 Forward-Port-Of: odoo/enterprise#68578
When auofilling towards the right the last colmn of a pivot whose column are grouped by date, we got a traceback. This was due to the fact that we were trying to use the measure string as argument of `increment_date`. Task: [4045799](https://www.odoo.com/web#id=4045799&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#68568 Forward-Port-Of: odoo/enterprise#68358
Original PR description
When auofilling towards the right the last colmn of a pivot whose column are grouped by date, we got a traceback. This was due to the fact that we were trying to use the measure string as argument of `increment_date`. Task: [4045799](https://www.odoo.com/web#id=4045799&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#68568 Forward-Port-Of: odoo/enterprise#68358
Step to reproduce: - Activate analytic accounting in the Accounting settings - Create an analytic account - Create an invoice with this new analytic account - Create a horizontal group, for example on the product_id field. - Enable the Profit and Loss report on the horizontal group - Open the P&L report and activate both the analytical and the horizontal groupby filters. => no result is displayed in the column of the analytical filter. Cause of the issue: When activating the an
Original PR description
Step to reproduce: - Activate analytic accounting in the Accounting settings - Create an analytic account - Create an invoice with this new analytic account - Create a horizontal group, for example…
Step to reproduce: - Activate analytic accounting in the Accounting settings - Create an analytic account - Create an invoice with this new analytic account - Create a horizontal group, for example on the product_id field. - Enable the Profit and Loss report on the horizontal group - Open the P&L report and activate both the analytical and the horizontal groupby filters. => no result is displayed in the column of the analytical filter. Cause of the issue: When activating the analytic groupby, it creates a shadowing of the move lines based on the analytic lines. This shadowing loses most of the data of the move lines, which can therefore no longer be of use to create more advanced filters. Proposed solution: When doing the shadowing, if the account.analytic.line does not have the column present in the account.move.line, then takes the value of the related move line, instead of setting the value to NULL as it was done before. opw-4048157 Forward-Port-Of: odoo/enterprise#67291 Forward-Port-Of: odoo/enterprise#66980