Syncing from upstream odoo/odoo (tmp.saas-18.1) #34172
Merged
Conversation
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
Keep the original session id that initialised the http request. task-4922056
The tests: - `test_report_stock_quantity` - `test_report_stock_quantity_with_product_qty_filter` can fail if the test class was instantiate at midnight and the tests launched at 00:01. The issue has been explained extensively in d1e11dc Here is a modest retranscription of its holy analysis: The Test class `TestReportStockQuantity` inherit from `TransactionCase`. So, once initialized, a SQL transaction is started and is the same for all the tests of the class: https://github.com/odoo/odoo/blob/d86409d93e096126b32cbb35f442db332628375d/odoo/tests/common.py#L775-L778 Also, in a SQL request, the method `now()` does not really return the current date: > Notice that NOW() and its related functions return the start time of the current transaction. In other words, the return values of the function calls are the same within a transaction. (https://www.postgresqltutorial.com/postgresql-date-functions/postgresql-now/) So, if we we start all the tests of the class `TestReportStockQuantity` at the end of D01. The SQL transaction is created and the tests are executed one by one with a NOW() corresponding to D01. However, certain indiviual tests might be launched on the following day D02 because it takes time to run the rest of the tests of the class: In particular, the python "today()" will notgive the same date as the SQL NOW and the queries of the test will simply not perform the expected. E.g: https://github.com/odoo/odoo/blob/d86409d93e096126b32cbb35f442db332628375d/addons/stock/tests/test_report_stock_quantity.py#L105-L110 runbot-226726 closes #216960 X-original-commit: 9c5e08a Signed-off-by: William Henrotin (whe) <[email protected]> Signed-off-by: Lancelot Semal (lase) <[email protected]>
When we archive an employee that is the time off responsible of another employee, the `_clean_leave_responsible_users` method will clear our cache before we set some departure related fields. This will cause us to have to recompute the relation for `employee_ids` and the domain that ensures the suggested employees in the wizard are not already archived will prevent us from finding the employee we were archiving. To ensure these fields are written properly, we save the value of `employee_ids` before archiving the employee. opw-4729600 closes #211174 Signed-off-by: Bertrand Dossogne (bedo) <[email protected]>
- Create an invoice with price 1000 in a non-company currency (e.g., CHF). - Modify the currency rate after the invoice date, then generate the payment for this invoice. - This will generate three journal entries (invoice, payment, and currency exchange difference). - Export those journal entries and include in the export the `matching_number`, `currency`, and `amount_currency` fields. - Import those three entries with the matching number and post them. - In the Journal Items, the line corresponding to the currency exchange difference is not matched with the lines from the invoice and the payment, leading to an unbalanced credit and debit. In `_prepare_reconciliation_single_partial` within `account_move_line`, the reconciliation is stopped by checking whether the debit/credit is fully matched. However, this check only considers `amount_residual_currency` and not `amount_residual`, which, in the case of an exchange difference, are different. opw-4776188 closes #217549 X-original-commit: 6a683a0 Signed-off-by: Thomas Becquevort (thbe) <[email protected]> Signed-off-by: Guillaume Teboul-Tornezy (gute) <[email protected]>
… common name to be unique per journal Previously, the company name was used as the common name when onboarding the journal. However, the common name has to be unique. The fix changes the common name to use the journal's short code, journal name, and company name to ensure uniquness. Additionally, an improvement is applied to the serial number on journals. Previously, users inputted this field manually. Now, the system uses the journal's id as the serial number to ensure uniqueness. A post-migration script was added to notify users that they need to re-onboard their journals. This is done in case users previously onboarded journals with non-unique serial numbers. task-4797124 closes #217486 X-original-commit: c4f492c Signed-off-by: Josse Colpaert (jco) <[email protected]> Signed-off-by: Khaled Fahmy (khfa) <[email protected]>
Issue: When having two lines on an invoice with the same tax and different analytic distribution, the base value is doubled on the tax report. Steps to reproduce: - Create a new taxe on sales (eg 10%) - Make sure the option "Analytic Accounting" is ticked in the settings - Create an invoice with two lines (eg both at $100), add the tax on both - Change the analytic distribution on both lines to different values - Confirm the invoice - Go to the tax report - Select the report "Group By: Account > Tax" - On the report the "Net" amount is doubled ($400), the tax amount is correct ($20) Cause: On the invoice we can see in "Journal Items" that two tax lines are created instead of one (one for each analytic distribution). The "Group By" reports are generated by [this query](https://github.com/odoo/odoo/blob/51fcbd211d2b1abf4b93becedbcbb9e03002cdd6/addons/account/models/account_move_line_tax_details.py#L92). At the [creation of the second subtable](https://github.com/odoo/odoo/blob/51fcbd211d2b1abf4b93becedbcbb9e03002cdd6/addons/account/models/account_move_line_tax_details.py#L164-L198) the move lines are linked together based among other things on the tax id. The [filter on analytic distribution](https://github.com/odoo/odoo/blob/51fcbd211d2b1abf4b93becedbcbb9e03002cdd6/addons/account/models/account_move_line_tax_details.py#L187-L191) does not apply here as `tax.analytic = False`. The result is that each tax line is linked with both base lines. The second subtable have 4 lines in this case, with each base line doubled. The result of the query have the base amount doubled. Solution: We cannot fix the query as there is no link to find the tax line origin amongst the base lines. The method `_read_generic_tax_report_amounts` in `account_reports` is made to fix the base values in report in case of duplicate. Until now it did not include the duplication caused by analytic distribution but duplication because of repartition lines for example. The fix is to use this method also for analytic distribution. So we add `tdr.analytic_distribution` in the `GROUP BY`. This value must be returned by the query in `account` so we add it. opw-4753676 closes #217550 X-original-commit: 27babd4 Related: odoo/enterprise#89559 Signed-off-by: Laurent Smet (las) <[email protected]> Signed-off-by: Mathieu Coutant (mcou) <[email protected]>
Steps to reproduce: 1. Connect IoT Box and any printer that accepts PDF 2. Turn on Reception Report option on Inventory Settings 3. Set configuration of Receipts to print out Reception Report and Label 4. Assign Reception Report and label to the printer 5. Create a PO and run through the Reception process (PO > Reception of Delivery) 6. Print the Reception Report under "Allocations" -> Result: Reception Report and label is downloaded as a PDF instead of being sent to the printer. The reason for this bug is that the report models were being constructed directly in the frontend, rather than being fetched from the backend. This didn't work with IoT printing because its override used to assign devices to reports is on the backend `ir.actions.report` model. The fix is to fetch the report from the backend when the component is loaded. This report is then passed down to the child components as well. opw-4790299 closes #217693 X-original-commit: 361d631 Related: odoo/enterprise#89617 Signed-off-by: Louis Travaux (lotr) <[email protected]> Signed-off-by: Max Whale (mawh) <[email protected]>
Steps to reproduce: - Navigate to a Project > View (Timesheets) - Open studio and add x_plan2_id for example to the view - Try creating a new timesheet and set a value for the field we added using studio - Save and notice the field doesn't keep its value Cause: This is mainly happening because when getting the plan_ids for the account we are gonna fill we just get the account in the distribution and ignore if the user is setting another value Fix: We check the create vals_list if a plan has value we set it before setting the account in the distribution opw-4716041 closes #217669 X-original-commit: 879e721 Signed-off-by: Xavier Bol (xbo) <[email protected]> Signed-off-by: Youssef Bashandy (yoba) <[email protected]>
Before this commit an error can appear if there two delivery line. Use method in delivery module to compute delivery amont. This method can compute if there are two line with delivery https://github.com/odoo/odoo/blob/18.0/addons/delivery/models/sale_order.py#L27 closes #217667 X-original-commit: 7c55bed Signed-off-by: Antoine Vandevenne (anv) <[email protected]>
Scenario: - insert the last blog posts widget in a page using Card Layout - open editor and edit (eg. Background) the cover of a post - save Result: the change is lost Cause: the content of the widget is dynamic, and we delete the content in cleanForSave (that call the destroy of the widget) before saving, so the change are not saved. Fix: make the dynamically added cover widget unselectable, the cover of the blog post can still be changed in other locations (blog post list, blog post page). Note: the issue doesn't happen in 17.0 in big picture template, because the figcaption is not a children of the cover snippet. It happens in 18.0 because the content of the cover is a children of the cover. opw-4633287 closes #214841 X-original-commit: e5ba9ac Signed-off-by: Quentin Smetz (qsm) <[email protected]> Signed-off-by: Nicolas Lempereur (nle) <[email protected]>
**Steps to reproduce:**
- Install Accounting + Inventory + Sales apps
- Enable Automatic Accounting in Settings
- Ensure two companies are available
- Set one product category (same for both companies)
- For company 1 (current) -> FIFO + automatic valuation (`'real_time'`)
- For company 2 -> FIFO + manual valuation (`'manual_periodic'`)
- Create a storable product for this category
- From company 1:
- Buy 10 products at 10$ each and receive them (Purchase + Delivery)
- Sell 15 products at 10$ each and deliver them (Sale + Delivery)
- Buy 10 products at 10$ (Purchase)
- Switch to company 2 (keep company 1 checked)
- From company 2:
- Validate the third delivery order (WH/IN)
- Go to Inventory/Reporting/Valuation
- One journal entry is missing for the last move
**Issue:**
During the processing of the SVL in `_run_fifo_vacuum`, the product used its current env context company
instead of the one provided explicitly in the parameters. This caused inconsistencies in valuation logic
when the method used differed between the given companies, which results in a missing `account_move_id`.
**Fix:**
Ensure that the product is evaluated in the correct company context by using
`self.with_company(company.id)` when looping on the products before the valuation logic.
opw-4732067
closes #216928
X-original-commit: 6731163
Signed-off-by: Steve Van Essche <[email protected]>
Signed-off-by: Florentin Delcourt (defl) <[email protected]>
This commit applies the necessary changes to make the json_activity_data field of account.journal extensible. The field computation needed to be extended in account_reports to make dashboard activities styling more dynamic. More details can be found in the enterprise PR: odoo/enterprise#89331 backport of: dce24cd task-4370133 task-4458309 closes #217785 X-original-commit: 3dcb5ec Related: odoo/enterprise#89675 Signed-off-by: Florian Gilbert (flg) <[email protected]> Signed-off-by: Hesham Saleh (hsal) <[email protected]>
closes #217694 X-original-commit: 027d07d Signed-off-by: Ruben Gomes (rugo) <[email protected]> Signed-off-by: Josse Colpaert (jco) <[email protected]>
When creating a sale order through crm, default_user_id was being passed through the context. This was causing issues when confirming the sale orders when quality checks were enabled as the user on the quality checks would be set as the user from the CRM lead. Removing this from the context before confirming and thus creating any linked records avoids this issue. opw-4658850 closes #216754 X-original-commit: 1540c30 Signed-off-by: Ryan Cen (ryce) <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
bt_gitbot