Merge from upstream 17 20260519 01#1220
Merged
royle-vietnam merged 28 commits intoMay 19, 2026
Merged
Conversation
- Attendance checkout
- Step to reproduce: with attendance installed and an employee checked in, archive that employee by HR user. If missing attendance rights, the employee will be archived but not checked out from its ongoing attendance.
- Cause: if no role set for Attendance (default), no permission to update the employee attendance while archiving.
- Solution: using sudo method so that any user with sufficient rights to archive an employee, can trigger check out of the corresponding attendance.
- Planning access error
- Step to reproduce: with attendance and planning installed, archive an employee having planning slots. If missing planning rights, an access error is raised
- Cause: on employee archive, the corresponding planning.slots are updated and some fields recomputed with insufficient rights.
- Solution: using sudo method for recompute.
closes odoo#260566
Task: 6131692
Signed-off-by: Krzysztof Magusiak (krma) <krma@odoo.com>
This commit will add the possibility to do an adjustment on the line 25. Useful when you start using Odoo but have a VAT credit carried forward from the previous month (which should appear in box 25 of your return). task-6072474 closes odoo#256107 Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
When merging pages with pypdf, the resulting content is uncompressed. A compression pass should be done right after to reduce the resulting file size. Additionally, this helps alleviate a memory leak in PyPDF2 where resources in the merged page are not properly released. Newer versions of pypdf (>=3.15.4) do not have this leak but still see benefits in the output file size. In practice the CPU overhead is negligible, and we actually see a speed increase in cases with high memory usage. Benchmark Printing 400 page annual report | |Print Time|Peak Memory|Output File| |------|----------|-----------|-----------| |Before|142s |3.6GB |103MB | |After |127s |0.4GB |5MB | opw-6148786 closes odoo#261879 Related: odoo/enterprise#115550 Signed-off-by: Lou Habert (loha) <loha@odoo.com>
SQL `IN %s` clause failed due to an empty tuple by causing a syntax error. By switching to `read_group`, the ORM handles empty domains gracefully. This also improves maintainability by using standard API methods instead of direct cursor execution. opw-6196166 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr closes odoo#264030 Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Issue: Report is exported only with the main company data. Steps to reproduce (require Accounting App): - create a French company - create and confirm an invoice for the previous month - create a branch in France for this company - create and confirm an invoice for the previous month in the branch - in the parent company, with both parent and branch selected - go to Reporting -> FEC - select the previous month - generate report Current behavior: - Only invoices from the parent company are in the report Expected behavior: - Invoices from the parent and branch are in the report Cause: From PR odoo#240981, the FEC report is streamed to the client. However, while creating the wizard from the request, it loses which companies the user is currently in. Therefore, the report is sent for the current company only. opw-6123080 closes odoo#260930 Signed-off-by: William André (wan) <wan@odoo.com>
If `git ls-remote origin <db_branch>` randomly fails, we assumed `db_branch` was `master`. It was useful for devs in the past, but now lead to update to Trixie on IoT Boxes 25_07 and previous, which is unwanted in such circumstances. We now skip upgrade if `db_branch` is `master`. closes odoo#264126 Signed-off-by: Yaroslav Soroko (yaso) <yaso@odoo.com>
Currently the query to get the closing difference account move is done by searching for the reference of the move, which is not very efficient. This commit optimizes this query by adding the journal to the search criteria, which allows us to benefit from the index on the journal_id field. Here is an example of the before after on a database with 39 million account_move records. Meanwhile only 10-20K account_move are linked to specific journals used in POS payment methods. All measures are performed with a warmed up cache Benchmark: # of am | Before | After 38982635 | ~17s | ~22ms closes odoo#262148 Signed-off-by: David Monnom (moda) <moda@odoo.com>
Issue: property_delivery_carrier_id on res.partner can hold an archived delivery.carrier record. Meaning that we pass an archived record to the context and that we can select the archievd delivery.carrier in the choose.delivery.carrier wizard. Solution: Only pass active records through the context opw-6125792 closes odoo#263819 Signed-off-by: Eliott Loop (oplo) <oplo@odoo.com>
This commit removes unecessary whitespace when reading qweb attributes. This result in nicer HTML output. opw-6173086
Before this commit, for DBs with a very large amount of products it was possible for the thread to run out of memory when importing an invoice or a bill. The reason is that the name on product.product is non stored and computed. This leads to tons of recomputes, which in turn leads to reads and stores in cache of the underlying `product.product`, which down the line uses up all of the available memory for the thread. The proposed method uses batches instead of a `search_fetch` as the latter would not solve the recompute problem and hence the underlying memory problem. Another alternative approach could be going straight for the `product.template.name`, but that approach might introduce a loss of precision or functionality when searching for products at invoice import. opw-6168737 closes odoo#262591 Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
Currently, after validating a transaction with a manual operation, the aml resulting from the manual operation can still be selected and matched with other transactions. Steps to reproduce: - Create a transaction for 500 dollars - Create a manual counterpart line for the bank statement line with label "test123" and validate - Create another transaction of -1000 dollars and label "test123" Issue: The manual counterpart line matched before is being suggested against the new transaction. The perfect match reconciliation model will reconcile the manual counterpart line with the new bank statement line. Analysis: During the retrieval of possible aml to match we only look at the aml reconciliation state. Manual counterpart lines created during the validation of a previous statement line are still selectable candidates, causing false positive matches in automated reconciliation models. opw-6045050 closes odoo#262295 Related: odoo/enterprise#115847 Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com>
Source: gob.mx/cms/uploads/attachment/file/151586/codigo_agrupador.pdf opw-6174385 closes odoo#262549 Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com>
…t note and original invoice
**STEP TO REPRODUCE**
1. Create an invoice and send it to jofatora.
2. Create a credit note for the invoice, send it to jofatora.
3. Sending the credit note will fail with the following error:
`Request failed: {"EINV_RESULTS":{"status":"ERROR","INFO":[],"WARNINGS":[],"ERRORS":[{"type":"ERROR","status":"ERROR","EINV_CODE":"invoice-persist","EINV_CATEGORY":"Invoice","EINV_MESSAGE":"invoice: Credit invoice buyer info does not match the original invoice"}]},"EINV_STATUS":"NOT_SUBMITTED","EINV_SINGED_INVOICE":null,"EINV_QR":null,"EINV_NUM":null,"EINV_INV_UUID":null}`
**CAUSE**
In `account_edi_xml_ubl_21_jo.py` if the document is a credit note (`is_refund`), we fill the customer party with some default value.
However, the documentation states that the credit note customer party should have the exact same values as the original invoice.
opw-6183573
closes odoo#264103
Signed-off-by: Khaled Fahmy (khfa) <khfa@odoo.com>
…computing lead_days When computing `qty_to_order` 1-3 extra queries are made by `get_lead_days()`, which can cause performance issues when computing `qty_to_order` for a large number of orderpoints. This commit aims to prevent these extra queries by returning early if the current product is not associated with a bom. The amount this commit speeds up the compute depends on how many of products passed into `_get_lead_days()` are associated with a bom. `qty_to_order` is no longer a stored field after this commit: odoo#159432 This benchmark was done in 18.0 on /stock.warehouse.orderpoint/search_panel_select_range. This call does not trigger the compute on all orderpoints in 17.0 as the field is stored but calling the compute directly on all orderpoints results in the same speed up as seen in 18.0. | Orderpoints | % of products linked to a bom | Time before | Queries before | Time after | Queries After | |-------------|-------------------------------|-------------|----------------|------------|---------------| | 800 | 50% | 2.8s | 1570 | 2.3s | 818 | | 8,000 | 0% | 28.2s | 16,698 | 15.3s | 242 | | 8,000 | 25% | 29.6s | 16,833 | 19.2s | 4497 | | 8,000 | 50% | 29.8s | 16,925 | 23.2s | 8693 | | 8,000 | 75% | 31.6s | 16,949 | 27.6s | 12827 | rebase later closes odoo#262321 Signed-off-by: William Henrotin (whe) <whe@odoo.com>
…ccount When a cash basis tax is configured with a payable/receivable transition account, tax journal items are generated on that account without a due date. Since payable/receivable accounts require a due date on journal items, this leads to the validation error during move creation. This commit adds a preventive validation to disallow configuring payable/receivable accounts as cash basis transition accounts, avoiding inconsistent accounting configurations and runtime errors. opw-6189615 closes odoo#263792 Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Issue before this commit: In the Italian Annual VAT Report, the balance (base amount) for line VF25 displays incorrect values. Instead of computing the sum of the taxable bases for the passive operations, the report erroneously mixes tax amounts into the balance column. Steps to reproduce the issue: 1. Download Accounting and l10n_it 2. Go to Tax Report and visualize the Annual Tax Report (IT) 3. Go to VF VAT Report 4. See the VF25 is mixing taxes and balances Cause of the issue: The root cause lies in the aggregation_formula definition for the tax_annual_report_line_VF25 record. The formula was incorrectly configured to aggregate the .tax expressions for lines VF1 to VF13 (VF1.tax + VF2.tax + ...) instead of their respective .balance expressions, while correctly using .balance for the remaining lines (VF17 to VF24). https://github.com/odoo/odoo/blob/878c08cf522a3278b4e6ff5f3d18444989e9998d/addons/l10n_it/data/tax_report/annual_report_sections/vf.xml#L286-L299 It's just a typo in this commit: odoo@f292ba1 Reason to introduce the fix: From documentation https://www.agenziaentrate.gov.it/portale/documents/20143/9602686/IVA_ANNUALE_2026_istr.pdf/2a42fb92-1b76-229a-d0f5-06069d79b514?t=1768504755711 : Rigo VF25, colonna 1, va indicato il totale degli imponibili determinato sommando gli importi riportati ai righi da VF1 a VF23, colonna 1, diminuito dell’importo di cui al rigo VF24. In colonna 2 va indicato il totale delle imposte determinato sommando gli importi delle colonne 2 dei righi da VF1 a VF13. opw-6172791 closes odoo#264379 Signed-off-by: Thomas Becquevort (thbe) <thbe@odoo.com>
This commit fixes two issues with upgrading from old IoT box images to 19.1+ DBs: - The IoT box would try and start checking out with git at the same time as the upgrade script rebooted the system. This would leave the git branch as the DB version (e.g. 19.2) but with the files still being at 19.1. To fix this, we sleep after the script until we reboot. - On reboot, the IoT box would then git checkout to the new version anyways. However, it would not install apt packages, leaving the Odoo service unable to start because of a missing 'geoip2' package. To fix this, we simply include this package in the upgrade script. task-6217972 closes odoo#264737 Signed-off-by: Yaroslav Soroko (yaso) <yaso@odoo.com>
We're adding new PO files for the following languages: lo
…equal Steps to produce: - Install website_sale module. - Enable `Comparison Price` from settings. - Create a product with sales price = 25 and compare price = 25. - Go to shop page and search for the product. Issue: - The strikethrough appears on the compare price (25) even when the compare price equals the sales price. - The strikethrough should only appear when the compare price is strictly greater than the sales price. Root cause: - In `_search_render_results_prices` [1], the condition only checks for the presence of `compare_list_price` in `combination_info`, without verifying that it is actually greater than the sales price. This causes the strikethrough to render even when both prices are equal. Solution: - Added a strict greater-than check on compare price against the sales price, aligning with the existing behavior already implemented for the product page [2]. [1]: https://github.com/odoo/odoo/blob/4ca059731f97d0f9bce4863cf195fd68a755717e/addons/website_sale/models/product_template.py#L831-L834 [2]: https://github.com/odoo/odoo/blob/4ca059731f97d0f9bce4863cf195fd68a755717e/addons/website_sale/views/templates.xml#L1340-L1346 opw-6178129 closes odoo#262434 Signed-off-by: Krishna Arvindkumar Patel (krip) <krip@odoo.com>
Steps to reproduce: - Install 'Accounting' module - Create a fiscal position with the configuration shown in the [attachment](https://www.awesomescreenshot.com/image/60382236?key=e3bd2a051bfd2eed3c176e1569ee7c82) - Click 'here' for creating tax Solution: This is a backport of the fix implemented in later versions (>17.0). Here, we store the failed fields, temporarily set them to False, and remove them entirely before record creation. commit-1= odoo@6c4f681 commit-2 = odoo@38a1e5d opw-6195611 closes odoo#263814 Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Why this commit: There are two instances in version 17.0 where dates use toLocaleString(), which relies on the device's local format instead of the Odoo-configured format. Since Odoo already defines a standard date format, all toLocaleString() usages should be replaced to ensure consistency. Starting from version 17.0, cash in/out receipts and the sales report use the local device time format. This commit updates those references and aligns them with the Odoo-configured date format. Other references will be updated during forward-porting. After this commit: All date references consistently use the Odoo-configured date format. closes odoo#259112 Signed-off-by: Stéphane Vanmeerhaeghe (stva) <stva@odoo.com>
The requests library uses different libraries to parse json objects depending on whether or not the simplejson library is installed (https://github.com/psf/requests/blob/dc9dbdfb3434c6e58d48fd102f93e5342308817e/src/requests/compat.py#L74). This in turn causes our try/excepts to fail if the simplejson library is installed in the env we simply re-raise the json error in case the simplejson library is installed so our try/excepts flows are not broken by the existence of a random package opw-6150349 closes odoo#264303 Signed-off-by: Loïc Leloup (lole) <lole@odoo.com>
**Problem:** In PR odoo#263425, the test uses the user group `group_account_manager` to grant write access to `bank.statement.line`. However, this write access is available through `group_account_user` which is only inherited in `account_accountant`. **Solution:** Instead, use the user group `group_account_user` directly so the test works with only `account` installed. closes odoo#265002 Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce: - Ensure Automatic Invoice setting is on - Create sales order for product with ordered quantites invoicing policy - Generate a Payment Link - Pay with the ACH Direct Debit method via a provider (e.g. Stripe) - While the payment is processing, confirm the sales order, create an invoice, confirm the invoice Current Behavior: When the payment is finished processing, the payment is not automatically linked to the corresponding invoice Expected Behavior: When the payment is finished processing, the payment should be linked to the invoice despite it being created by a user Explanation: The payment transaction's link to invoice_id is severed in PaymentTransaction._invoice_sale_orders if an invoice is created before the payment is cleared. This will eventually lead to the account.payment created automatically later on not being reconciled with the invoice. closes odoo#264800 Signed-off-by: Tyler Landivar (tylan) <tylan@odoo.com>
viinbot
added
🚀 Building
🚀 Running
|
@royle-vietnam Viindoo Test Suite has passed! |
viinbot
added
🚩 Done
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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