Daily updates from Odoo
Monday, December 2, 2024
15 changes
9 changes
Resolved issues and error corrections
When tasks or applicants are created by email, stage update messages now include the original sender instead of incorrectly excluding them as the message author. This ensures customers, portal users, or applicants receive expected status notifications after their email creates a record.
Original PR description
The issue occurs when an email is sent to create a `project.task`. If the sender of the email is an existing user, this user is later set as the author of any outgoing emails related to that task. Since the system is configured to skip sending emails to the author, no email is delivered to the sender in this scenario. Reproduce --- - -i project,contacts - add `example.com` to domains in the settings - create new project with an alias: `project@example.com` - Have a stage with some "Email Template" set - send email creating project tasks as a portal user - BUG: email about stage update is NOT sent (even tho task appeared in stage) opw-3941928
This fix stops embedded action data from carrying over when users open a normal action from an embedded one. It prevents the wrong action bar from appearing and avoids crashes caused by using records from the wrong business object.
Original PR description
Before this commit, when executing a regular action from an embedded one, the context wasn't cleared, so all the embedded action feature related keys were propagated to the regular action. As a consequence, the embedded actions bar was displayed on that action as well. Clicking on an item most certainly led to a crash, because a wrong active id (referring to anothe res_model) would be used. For instance 1) Go to Project 2) Open "AGR - S00080 - Sales Order" 3) Add Sales order embedded action 4) Click Sales order 5) Enter a sales order that has tasks or a service product 6) Click the Tasks smart button 7) The embedded actions bar is displayed and, it crashes if an item is clicked opw~4253958 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
OAuth login routes are no longer treated as read-only because they may need to create a user account or record a login event. This prevents failed sign-ins caused by the system blocking required database updates during authentication.
Original PR description
Follow-up of #186319 and #186786 These routes are auth=none but aren't technically read-only, as they can create the user record and need to record the login event anyway. The signin one even as a broad catch for Exception, which would prevent the readonly->read-write fallback to work, leading to a failed login.
This fix prevents payment post-processing from failing when a journal has more than one payment method line. It helps ensure online or point-of-sale payments can complete reliably instead of being blocked by a configuration-related error.
Original PR description
Currently, an exception is generated at the time of the post-processing payment transaction. error: ``` ValueError: Expected singleton: account.payment.method.line(11, 12) File…
Currently, an exception is generated at the time of the post-processing payment transaction.
error:
```
ValueError: Expected singleton: account.payment.method.line(11, 12)
File "addons/payment/models/payment_transaction.py", line 852, in _cron_post_process
tx._post_process()
File "addons/pos_online_payment/models/payment_transaction.py", line 29, in _post_process
super()._post_process()
File "addons/website_payment/models/payment_transaction.py", line 14, in _post_process
super()._post_process()
File "addons/sale/models/payment_transaction.py", line 91, in _post_process
super(PaymentTransaction, done_tx)._post_process() # Post the invoices.
File "addons/account_payment/models/payment_transaction.py", line 122, in _post_process
tx.with_company(tx.company_id)._create_payment()
File "addons/account_payment/models/payment_transaction.py", line 163, in _create_payment
'payment_method_line_id': payment_method_line.id,
File "odoo/fields.py", line 5287, in __get__
raise ValueError("Expected singleton: %s" % record)
```
The above exception was generated because we got multiple payment method lines in a single journal.
This commit fixes the above issue by accessing the first payment method line.
sentry-6007333118New databases now include a second default follow-up reminder level, so overdue invoices can receive a gradual sequence of reminders instead of only one. Demo cleanup also prevents deleted snailmail follow-up records from being recreated during module updates.
Original PR description
The second level already configured in demo has been moved in data because having only one follow-up level in a new database is a bit weird. Not only does it look weird, but in practice it also leads to a weird situation that by default the invoices will only be reminded once and never after. + we're failing to convey the usefuleness of the feature of building gradually harded reminders for the partner. Also added forcecreate="False" in snailmail demo data, because we don't waznt to recreate the missing xml ids (if people deleted it) in every module's update. task-4334758
Project managers can now create document folders from project settings without hitting an access error in demo scenarios. Project document links also open the more useful folder document view, making it easier to manage centralized project documents.
Original PR description
Commit 1: Reproduce: 1. Open a project's settings as Admin/Demo (project managers) 2. Make sure "Use Documents" is checked 3. Try quick creating a folder 4. Access Error This occurs because you are not allowed to create in the restricted "Projects" folder. This commit adapts demo data so that flows can easily be demonstrated and tested without requiring extra configuration steps for a common flow. Commit 2: Quick create folders instead of requests to centralize projects' documents. Also, the `documents_folder_many2one` widgets links to the documents kanban view of the folder instead of the less useful form view, as it is done in the other apps and bridges. Task-4344434
This update fixes several issues in Documents, including preventing employees from being automatically granted access to employee-related documents, improving the My Documents and Shared With Me filters, and avoiding crashes when shortcuts point to inaccessible files. It also reduces clutter from frozen spreadsheet folders in Home, making document navigation faster and clearer for users.
The point of sale quantity control now correctly changes a product quantity to a negative value when the +/- button is pressed. This prevents unexpected zero quantities and supports more accurate adjustments such as returns or corrections.
Original PR description
Before this commit ------------------------ Previously, when adding a product and clicking the "+/-" button, the quantity would change to "0" instead of becoming negative. After this commit ---------------------- After implementing this commit, pressing the +/- button now results in the quantity value changing to negative instead of changing it to 0. task- 4281516 Related PR: https://github.com/odoo/odoo/pull/185441/
WhatsApp conversations that have been inactive are now automatically unpinned after 5 days instead of 2 weeks. This helps prevent teams with high WhatsApp message volumes from hitting conversation limits that can slow down Discuss.
Original PR description
Follow-up of https://github.com/odoo/enterprise/pull/74131 PR above attempts to solve an issue of every-growing unpinned whatsapp conversations that make it harder to use Discuss for performance reasons, due to reaching the technical limit of around 2000 pinned conversations. To do so, it automatically forces unpinning whatsapp conversation after 2 weeks of inactivity, even if the conversation was unread. While this is an improvement, if there are around 150 whatsapp new whatsapp conversations made every day, then the 2 week force unpin is not enough, because the 2000 pinned conversation limit is reached. This commit fixes the problem by reducing the force unpin of whatsapp conversation to 5 days. The architecture of Discuss should scale better, but this is hardly achievable in short manner, hence why the current solution to this problem is prevent reaching a high amount of pinned conversations. opw-4330847
6 changes
Resolved issues and error corrections
This update fixes a bug where the POS system would unexpectedly start clocking in users even if a cashier wasn't selected. The change ensures a cashier is selected before clocking in, preventing errors and ensuring the POS remains usable. This improves the overall reliability of the Point of Sale experience.
Original PR description
Behavior before commit: When opening the POS and selecting a cashier, if the user decides to go back without selecting any cashier, the clock-in function gets called anyways. This leads to pos_blacbox trying to clock in an undefined cashier, which in turn leads to more errors down the line (including an unusable pos). With the modification proposed in this commit, we check that a cashier has indeed been selected and only then proceed with the clocking in. opw-4293988 opw-4182434
This update corrects a problem where multiple cancellation requests for Mexican tax documents (CFDI) could lead to errors. When a customer rejects a cancellation, a new cancellation request is created. When the SAT approves the second request, the original cancellation request is automatically removed, preventing data inconsistencies. This ensures accurate tax reporting and avoids potential issues with the Mexican tax authority.
Original PR description
In a production setup: - Create an invoice and sign it - Ask for a cancellation rejected by the customer => an invoice_request_cancel document is created - Ask for another cancellation request => another invoice_request_cancel document is created - Trigger the SAT to approve the second cancellation request => The first invoice_request_cancel document is unlink.
This update resolves issues with Mexican CFDI invoice generation related to rounding calculations. Specifically, it corrects an error in how taxes are calculated during global invoice creation, ensuring compliance with Mexican tax regulations. The fix improves the accuracy of CFDI invoices for Mexican businesses.
Original PR description
## Steps to reproduce the issue 1. Activate Mexican Localization 2. In Mexican Company, create two Invoices with one product line: - Price Unit of 3.47, 16% Tax - Activate CFDI to Public 3. Select…
## Steps to reproduce the issue
1. Activate Mexican Localization
2. In Mexican Company, create two Invoices with one product line:
- Price Unit of 3.47, 16% Tax
- Activate CFDI to Public
3. Select both Invoices and create Global Invoice ("Actions" drop menu)
4. Check the CFDI tab in one of the Invoices
5. One of those errors pops up depending on your rounding method:
#### Round per line:
> Code : 301
> Message : Error de validaciones adicionales [Error #CFDI40108] El TipoDeComprobante es I,E o N, el importe registrado en el campo no es igual al redondeo de la suma de los importes de los conceptos registrados. Folio: 2. Serie: GINV/. El valor del atributo SubTotal (6.95) no coincide con la suma de los importes (3.47 + 3.47 = 6.94)
#### Round globally:
> Code : CFDI40205
> Message : El valor del campo TotalImpuestosTrasladados no es igual a la suma de los importes registrados en el elemento hijo Traslado.
## Explanation
#### Round per line:
With commit odoo/enterprise@933864a38af21a70b219d2824c64fff488acb15f, base and tax amounts were tweaked in order to satisfy some CFDI constraints. This change calculates amounts in an incorrect order: instead of calculating `tax_amount` with the formula `base_amount * tax_rate`, it calculates the base using `total / (1 + tax_rate)` then subtracts the base from the total to obtain the tax amount.
In our example, with a total of `6.94 + 1.12 = 8.06`, the base is calculated as such: `8.06 / 1.16 = 6.94827586207`, rounded to `6.95`, and the tax as such : `8.06 - 6.95 = 1.11`. The difference between the tweaked base `6.95` and the addition of the base of all invoice lines `3.47 + 3.47 = 6.94` is not accepted.
#### Round globally:
During a Global Invoice creation, we will first calculate the values of the Invoices separately. During this calculation, `total_impuestos_trasladados` is rounded with `precision_digits=2` while values in `traslados_list` are rounded with `precision_digits=6`. https://github.com/odoo/enterprise/blob/800378bfd3fe198647c9b418def3bd36066d9cd7/l10n_mx_edi/models/l10n_mx_edi_document.py#L583-L590 https://github.com/odoo/enterprise/blob/800378bfd3fe198647c9b418def3bd36066d9cd7/l10n_mx_edi/models/l10n_mx_edi_document.py#L950-L961 https://github.com/odoo/enterprise/blob/800378bfd3fe198647c9b418def3bd36066d9cd7/l10n_mx_edi/models/l10n_mx_edi_document.py#L963-L964 https://github.com/odoo/enterprise/blob/800378bfd3fe198647c9b418def3bd36066d9cd7/l10n_mx_edi/models/l10n_mx_edi_document.py#L1000-L1001
In the example, `3.47 * 0.16 = 0.552`, is rounded to `0.56`. The addition of every rounded value gives `1.12` or `1.110400`, which gives the difference between `total_traslados_impuestos` and `traslados_list`.
## Fix reasoning
#### Round per line:
We will add a hack in `_get_post_fix_tax_amount_map`: CFDI accepts a difference of `1e-<precision_digits>`, which means that `precision_digits=2` would allow a difference of `0.01`. If the difference is lower, we will not perform the operation and only round the values.
In our example, the obtained tax amount is `1.12` and the expected tax amount `6.94 * 0.16 = 1.1104`. The difference between the two is lower than `0.01` and is accepted by the CFDI.
#### Round globally:
We will use the calculated values in `_get_global_invoice_cfdi_values` to compute the total price and totals of taxes at the end of the method instead of using the rounded values received from `cfdi_values_list` at the start.
opw-4085403This update fixes an issue with Odoo's report engines, specifically the account_codes engine, that caused incorrect data display when using LIMIT and OFFSET. The fix ensures consistent behavior across report types by adding an explicit ORDER BY clause, addressing a PostgreSQL requirement for reliable LIMIT/OFFSET functionality. This resolves data discrepancies and ensures accurate report results.
Original PR description
[FIX] account_reports, l10n_*_reports: add explicit ORDER BY to report engines for consistent LIMIT and OFFSET behavior As stated here https://www.postgresql.org/docs/current/queries-limit.html ,…
[FIX] account_reports, l10n_*_reports: add explicit ORDER BY to report engines for consistent LIMIT and OFFSET behavior
As stated here https://www.postgresql.org/docs/current/queries-limit.html , postgresql requires an explicit ORDER by within the query for LIMIT and OFFSET to work properly and consistently between query executions. We hence add one to each engine not having one already.
=======================================
[FIX] account_reports: properly handle groupby in account_codes engine for grouping keys used with multiple accounts
// TO REPRODUCE
1) Create a report with a single line, whose computation uses the account_codes engine, with formula "1". Set "partner_id" as the groupby value for that line. Setup a "load more limit" of 2 on your report.
2) Create 3 accounts, with codes 11, 12, 13
3) Create 3 partners: A, B, and C
4) Create journal entries, with the following lines (all balancing lines must use other accounts as the ones defined in 2) ), in that order:
- on account 11, with partner A, debit=10
- on account 11, with partner A, debit=20
- on account 12, with partner A, debit=25
- on account 11, without partner, debit=30
- on account 11, without partner, debit=40
- on account 12, with partner B, debit=50
- on account 13, with partner C, debit=60
5) Open the report for a period covering all the created journal entries, and have a look at the sublines generated for the groupby.
=> With the limit being 2, you'd expect to see "A", "B", and a "Load more..." line allowing to visualize the rest (namely a line for "C", and "Unknown"). Instead of that, you see no "Load more ...", and line "A"'s amount is wrong.
// EXPLANATION
The SQL query of the account_codes engine is grouping not only by groupby key (here, partner_id), but also by account_id, to be able to process the "C" and "D" suffixes of the formula later on. Because of that, the LIMIT passed by the load_more_limit is applied on that grouping.
With a load_more_limit of 2, we try to load 3 lines. If we manage to load 3, we only display 2, but know we need to display the "Load more..." line. Else, we know there are no more results, so no need for that additional line.
So, with our example, the query runs with a LIMIT of 3, returning
- 30 for A on account 11
- 25 for A on account 12
- 70 for no partner on account 11
Then, another issue happens:
The results returned by the SQL query (hence, by the engine) contain two times the same partner_id. From an engine perspective, the grouping key is only partner_id, not account_id (which is only used for an inner computation, with the SQL query). So that means the same grouping key has two different values. This is not legit, and causes one of them to shadow the other.
The report computation then receives 1 result for A, and 1 for "Unknown", so it renders them, and since there is no third result, it does not display the "Load more ...".
Forward-Port-Of: odoo/enterprise#74784This update optimizes the performance of reports displaying large amounts of asset data. By passing currency and expression values directly, the system avoids redundant data retrieval, resulting in faster report generation. This change significantly reduces processing time, especially with a large number of assets.
Original PR description
### Description When opening a report with a lot of data to display, getting some values can be very costly. In this case, for the depreciation schedule, we are retrieving the column expression and currency symbol each time if not found in `_build_column_dict`. To avoid retrieving a value that was already fetched, we can pass the currency and the expression directly. This reduces unnecessary `__get__` calls. ### Benchmark (made in 17.0) | N° of assets | Before | After | |--------------|---------|--------| | 500 | 2 s | 1.55 s | | 7k | 20 s | 19 s | | 17k | 50 s | 41 s | ### Reference opw-4287192
This update fixes an issue where sales order line subtotals were incorrectly displaying tax-included prices when orders were synchronized from Amazon with Avatax. The change ensures that the subtotal accurately reflects the amount before tax by intentionally excluding the Amazon's tax information, which Avatax is best positioned to handle.
Original PR description
When synchronizing orders from Amazon with Avatax enabled, sales order lines currently show no taxes and incorrectly set the tax included price as being the subtotal. This occurs because the fiscal position used does not include any tax, which is the expected behavior for Avatax. The recomputation then uses the full amount of the line (which is tax included), and in the absence of tax, consider this is also the subtotal. We now intentionally do not consider the tax amount from Amazon on the order lines, because the distribution of the Amazon's given tax amount is unknown. The multiple real taxes across that line is not an information that Amazon gives us, and needs to be seen from Avatax. This setup ensures that the subtotal on sales order lines remain accurate. opw-4214775