Daily updates from Odoo
Thursday, September 19, 2024
10 changes
3 changes
Resolved issues and error corrections
The stock forecast report now correctly identifies customer-bound moves when multi-step delivery routes use push rules. This helps businesses see more reliable outgoing stock quantities and avoid misleading inventory forecasts.
Original PR description
Following #156437, the new default setup for multi-step deliveries is through the new push rules. This means that when you trigger a delivery to a customer, it will first create the PICK before creating the delivery. This means that now we need to check on the `location_final_id` if it exists before checking the `location_dest_id`, as it holds the real destination of the move to consider it as an 'out' move or not. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix restores the ability to choose a specific journal when creating a debit note from an invoice. It ensures the debit note wizard correctly determines the journal type, so valid journals are shown instead of an empty selection.
Original PR description
Steps to reproduce: - Install Accounting and account_debit_note - Accounting > Customers > Invoices > Select any - Gear Icon > Debit note - Try to select an entry in 'Use Specific Journal' No journal…
Steps to reproduce:
- Install Accounting and account_debit_note
- Accounting > Customers > Invoices > Select any
- Gear Icon > Debit note
- Try to select an entry in 'Use Specific Journal'
No journal is available to pick from, this happens because 'Use specific journal' filters journal_id with the domain [('type', '=', journal_type)], and journal_type mistakenly has the value False.
The root cause of this issue is the strengthened recompuation protection added in 20c2e5996651168db3a6d75ace6a8907c1661792. The ORM will no longer allow recomputation of fields without a default if they share a compute method with another field which has a default value. (In an onchange flow).
At the time of the wizard's creation we update the cache in onchange() to contain False for each value without a default. In 17.0 and earlier we used to invalidate that cached value, leading to the computation of journal_type, but that behavior has changed since.
To avoid uncessary recomputation of 'move_type' (which is given a default value) we protect its compute method. However 'move_type' shares its compute method with journal_type, so we also prevent the computation of journal_type in the process.
We end up with our debit note wizard which has never made a call to _compute_from_moves (meaning is has no journal_type) and thus filter journal_id by [('type', '=', False)], which is forbidden as journal_id.type is a required field, preventing us from selecting a journal.
opw-4124278
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fix keeps the connection between sales orders and their related purchase orders when products are received through multiple warehouse steps. It helps ensure make-to-order purchases remain traceable and correctly linked throughout the receipt process.
Original PR description
With the old pull rules, pickings were created up to the last step before reception (i.e. Input in multi-step reception) which would be all in the procurement group. Then, once the purchase order is validated, then reception move would be the orig of that last step move. In this case, the link would work properly. However, with the new push rules, the move that trigget the creation of the purchase order is no longer Input -> Stock, but the first step of delivery. This still works correctly until the first reception step is completed, but then the move_orig of the Stock -> Output is no longer Vendor -> Input, but Input -> Stock, which doesn't contain the link to the purchase order. This means we have to rollup the orig of the move to get to the actual purchase order, regardless of the number of extra steps in between. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
1 change
Resolved issues and error corrections
This update improves Australian Single Touch Payroll finalisation and year-to-date zeroing so businesses can correctly update key employee or company reporting indicators. It helps ensure compliant submissions when prior payroll reporting needs to be reset or corrected.
Original PR description
This commit is a follow up to the previous PR# 65395. This commit updates the Finalisation and Zeoring of the YTD for a number of cases. This will allow users to submit a zeroed YTD to change the key indicators for the employee or the company.
6 changes
Resolved issues and error corrections
This fix resolves an issue where the postage cost calculation for SnailMail follow-up letters was not being computed correctly. Previously, when sending follow-up notices to customers with multiple contacts, the system would incorrectly show only 1 stamp regardless of the actual number of letters being sent. This update ensures the cost calculation properly reflects the actual number of follow-up letters being processed.
Original PR description
Problem: The `snailmail_cost` field was not being computed because the compute method was not being called. Steps to reproduce: - Enable "SnailMail" in Settings. - Navigate to Accounting > Follow-up Reports. - Open a report. - Follow up on the report. - Observe that the stamps count is 1, even if the partner has multiple follow-up contacts. opw-4160083 Forward-Port-Of: odoo/enterprise#70236
Fixed a technical error that occurred when generating bank reconciliation reports for accounts with zero balances. The system was attempting an invalid mathematical calculation that caused the report to fail. This fix ensures the report generates successfully in all scenarios.
Original PR description
The issue: When we have entries that are linked to a bank statement with a balance of 0, this will lead to a division by zero error when generating a reconciliation report The Fix: check for the suspense balance value, if it is zero, then there is no need to compute the rate since zero divided by anything = 0 opw-3990116 Forward-Port-Of: odoo/enterprise#66603 Forward-Port-Of: odoo/enterprise#65095
This fix resolves an issue where manually changing a line's parent category in Account Reports would not update its position in the report display. The parent_id field has been removed from the editing interface since the hierarchy is already properly managed by the system's display widget, preventing confusion and incorrect report layouts.
Original PR description
### Steps to reproduce issue: 1. Go to _Accounting > Configuration > Account Reports_ 2. Select Balance Sheet and Add a line in it 3. Select the new line and give it ASSETS as parent_id 4. Go to Reporting > Balance Sheet 5. The new line is still at the end of the report ### Explanation: Lines have a `sequence` to sort them in the report. It is not computed to change along with `parent_id`, since the lines are supposed to be arranged through the `AccountReportListRenderer` widget. Because of it a line whose `parent_id` changes will not be placed correctly. ### Fix reasoning: The `parent_id` field will be removed from the view, the hierarchy is already shown in the widget. opw-4101282
Users were unable to upload image files when creating invoices in the Kenya EDI system due to a technical error. This fix resolves the issue by properly handling image file uploads, allowing users to attach images to invoices without encountering errors.
Original PR description
Currently, an exception is generated when the user tries to upload an image file for creating an invoice. error: `UnicodeDecodeError: 'utf-8' codec can't decode byte 0x89 in position 0: invalid start byte` This is because below code line tries to load image context of uploaded image file. https://github.com/odoo/enterprise/blob/799b80d12680153a5ba42ee97501723ba38052b1/l10n_ke_edi_oscu/models/account_move.py#L567 This commit fixes the above issue by handling `UnicodeDecodeError` in `contextlib.suppress.` sentry-5757745777
Users with restricted access permissions were unable to download planning reports due to permission errors when accessing related sales order and project information. This fix grants the system temporary elevated access to retrieve the necessary data for report generation, allowing all authorized users to successfully download their planning reports.
Original PR description
- 17.0 ### Steps to reproduce: - Install sale_planning and project_forecast app. - Create a sale order with the planning product (e.g. Developer (Plan services)) and confirm it. - Create planning for that sale order and set resource (e.g. Marc demo) to it. - Click 'Publish & Send' button. - Set 'User: Own Documents Only' rights for the sales and 'User' or 'none' for the project and planning for Marc demo. - Login from that user and open the planning app. - Open assigned planning form view. - Print planning. ### Issue: - Traceback occurs of access right. ### Cause: - While downloading the report, it goes to access the "display_name" and "name" field of sale order line and project respectively that is computed in the _compute_display_name, but the user cannot access "sale.order.line" and "project" due to record rule. ### Solution: - Give access to the record by using sudo(). task-3978552
This fix prevents users from accidentally mismatching products when creating quality checks. Previously, if a user selected a quality point from a different product, the system would silently change the product instead of alerting them to the error. Now the system properly validates that the quality point and quality check must belong to the same product, protecting data integrity.
Original PR description
Steps to Reproduce the Bug: - Create two storable products, "P1" and "P2". - Create a Quality Point: - Product: P1 - Type: Manufacturing - Create a Quality Check: - Product: P2 - Select the Quality Point of P1 Problem: The product is updated to P1 instead of triggering a user error. opw-4030133 Forward-Port-Of: odoo/enterprise#69362