Friday, September 13, 2024
16 changes · 17.0
Resolved issues and error corrections
Manufacturing orders are now filtered more accurately when users search by component availability. This helps teams find the right production orders and avoid misleading search results caused by partial component matches.
Original PR description
the search logic for productions by component availability is currently incorrect: it matches productions for which at least one bom line has the requested availability. We align it with the compute method's logic Note: at the current time we have to perform a search within the search method, which will hurt performance if we have many MO, but it is not possible to compute the domain without accessing the records because the relevant product fields are compute and non-searchable opw-4055859
Fixed an issue that prevented Argentine branch companies from sending electronic invoices when they shared tax details and certificates with their parent company. This avoids a traceback during invoice confirmation and helps branches continue compliant e-invoicing operations.
Original PR description
With an AR setup Create a branch company with: - Tax ID: same as in the parent company - Address: same as in the parent company - Certificate/Private key: same as parent company Create an invoice in Journal "Factura electrónica (FE)" Set customer "ADHOC SA" Confirm When the system attempt to send the e-invoice raceback pops up "ValueError: External ID not found in the system: account.5_tax_group_percepcion_ganancias" This occurs because the sytem looks for an xmlid which is only present in the parent company opw-4151003
Payment links for subscriptions could fail when multiple companies were configured because the payment follow-up used the wrong company context. The fix ensures the correct company is applied during post-processing, helping Stripe subscription payments complete reliably.
Original PR description
Steps to reproduce: - Install Subscription, Stripe and Intercompany rules (to have multiple company) - Set the company of the first website to Chicago - Setup stripe for the provider - Make a new subscription with Monthly template for "Joel Willis" - Generate a payment link Issues: "Expected a singleton error" in the `ensure_one` this is due to us having the wrong company during the `post_processing`. Fix is to set the right company during the creation of the `monitored_tx` if we have a public user. Local solution is to just set the with_company lower in the stack however it's the second time since this problem was met so a general solution might be more appropriate. Link to the commit that fixed the first issue: 7c35302bf61b429e52989df6f5eb9d0401433f74 opw-3999546
This fixes a problem where appointment types that use resources instead of staff members could become unbookable when connected to Microsoft Calendar. Odoo now skips an organizer-attendee validation in that specific resource-only case, preventing false booking errors.
Original PR description
Added condition on check that ensured the organizer was an attendee on the event on create. This was added in a change that allowed the organizer to be changed on the Odoo side. However, this caused issues with the appointments app when creating an appointment that only used resources. The "organizer" who in this case is the creator of the appointment type would not be an attendee and therefore would cause an error and make the appointment type unbookable. Adding this condition allows the appointment to bypass the check if the appointment type uses resources instead of users. opw-3841495 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix makes Odoo reduce reserved stock lines in the correct order when a delivery quantity is lowered, keeping lot reservations aligned with the chosen removal strategy such as LIFO. This helps prevent the wrong lots from being unreserved and improves accuracy for warehouse operations using tracked products.
Original PR description
### Steps to reproduce: - Create a product tracked by lot and register 4 lots of 10 units in stock : LOT001, LOT002, LOT003, LOT004 - Inventory > Configuration > Products > Product Categories -…
### Steps to reproduce: - Create a product tracked by lot and register 4 lots of 10 units in stock : LOT001, LOT002, LOT003, LOT004 - Inventory > Configuration > Products > Product Categories - Change the Removal strategy of the "All" category to LIFO - Create and confirm a delivery order for 40 units of your product > Move lines are created for reservation in order LOT003, LOT002, LOT001 - Do not click on the detailed operation to see these LOTS and decrease the quantity of the move to 15 units ### Expected behavior: Since the lines were created respecting the removal strategy, they should be removed accordingly from the last one created to the first created > LOT001 and LOT002 should be removed and 5 units should be decreased from LOT003 ### Current behavior: LOT004 and LOT004 are removed and 5 units is removed from LOT002 ### Cause of the issue: On qty decrease, the `_process_decrease` of the `set_quantity` is called to decrease the qties on the associated sml and to unlink the one resulting with a 0 qty. However, the loop used to make this action is not based on the reversed order of creation of the lines but on their order itself. #### Note: This doe snot solve the issue for complex removal strategy that would require a complete recompute of the reservation on qty decrease such as "use the minimal amount of packages". ### Note 2: An other issue exists when you increase the demand of the move instead of decreasing it: while the qty done is increased no assignments are done so that a move line without lot id would be created to fulfill the increase of qty. This is because the `_action_assign` can not be triggered again in this process increase since the stockpocalypse the line was even commented here: https://github.com/odoo/odoo/blob/9f364cde276b8b3be73c30617515bd55a9f25aba/addons/stock/models/stock_move.py#L376-L378 he reason is that if an `_action_assign` was performed instead and if the units were not in stock to fulfill it the qty would only be increased by the available qty and the desired flow would be bloqued. THe behavior is being improved in master (18.0+) but the required change of the `_process_increase` is to risky to be applied in stable. co-authored by @naja628 opw-4074174 and opw-4071479 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue where pressing the Alt key in form views did not show available keyboard shortcuts. The editor toolbar was incorrectly treated as the active screen element even when hidden, which blocked shortcut hints from appearing for users.
Original PR description
Steps to reproduce ================== - Install project - Open any task in a form view - Press the alt key => The hotkeys are not displayed. Cause of the issue ================== Since a6876ac03799c1e0626bac54129493155d9eb637 , the toolbar makes use of the useActiveElement() This is not correct since the toolbar is always attached to the DOM, only it's visibility is toggled when we need to show it. Solution ======== Revert the commit since the feature wasn't well supported anyway and there is no easy workaround. opw-4175689
Keyboard shortcuts now work correctly when a form contains a rich text HTML field. This prevents editor toolbar focus from blocking normal shortcut behavior, making data entry and navigation more reliable for users.
Original PR description
before this commit: The hotkey functionality is not working as expected when an HTML field is present in the form view. This issue arises because the useActiveElement method sets the target to the editor toolbar in this [commit](https://github.com/odoo/odoo/pull/178189/commits/2c40feca689d6050f746393b28d1238c9ba891ad), which interferes with the hotkey's intended ActiveElement behavior and causes it to break. after this commit: The hotkey will work as expected in the form view Task-4181924
This fix prevents Odoo-generated spreadsheet files from being automatically deleted by the system's cleanup process. When users upload certain file types, Odoo converts them to spreadsheet format, but these converted files were being incorrectly removed after 24 hours. This update ensures converted spreadsheets are preserved and not lost.
Original PR description
Problem: Auto-vacuum is incorrectly archiving reformatted spreadsheet documents that were generated from unsupported file uploads. Specifically, when an .xlsx file is uploaded, Odoo creates a new, compatible spreadsheet document. However, this newly generated document is mistakenly deleted during the auto-vacuum process if it is older than 24 hours. Purpose: Add a domain to prevent Odoo created spreadsheets from uploads being caught by autocron vacuum from improvement to 17.0 last year Steps to reproduce bug: 1.) Upload an xlsx file 2.) Click on the xlsx file 3.) It will generate an Odoo file of the same type 4.) Set the date of the new file to older than 24 hours 5.) The formatted file will be deleted when the autocron hits opw-4087851
This fix resolves an issue where PDF attachments were not being included when exporting financial data to Datev format from the general ledger. The system now correctly selects and includes the main attachment from invoices in the exported zip file, ensuring all necessary documents are available for accounting purposes.
Original PR description
Take a demo invoice, print it. Go to general ledger, print Datev ATCH, the pdf is not attached. We should select the message_main_attachment_id, as it's the one we want to have in the zip anyway. opw-4162604
This fix corrects how subscription orders display their invoice status. Previously, subscription orders were incorrectly showing as "fully invoiced" even when there were future invoices still pending. The system now properly checks the next invoice date to accurately reflect whether there are more invoices to generate, ensuring users have the correct visibility into their subscription billing status.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Create a subscription SO w/ a subscription product; 2. set recurrence to monthly; 3. set start date to 3+ months ago; 4. confirm & create invoice. Issue ----- In the Other Info tab, the Invoice Status is displayed as fully invoiced, despite there still being several months to invoice. Cause ----- The `_compute_invoice_status` method doesn't doesn't check `next_invoice_date` to decide whether a line's status should be `invoiced` or `to invoice`. Solution -------- Modify the override for `_compute_invoice_status` in sale_subscription, to change the `invoice_status` from `invoiced` to `to invoice` if the `next_invoice_date` is today or earlier. Also change compute dependency from `order_id.is_subscription` to `order_id.next_invoice_date`. This maintains a transitive dependency to `order_id.is_subscription`. opw-3849059
Fixed an issue where the bank reconnection button was not appearing when a bank connection's expiration date was set for today. This fix ensures users can promptly reconnect their bank accounts when needed, improving the user experience for online banking synchronization.
Original PR description
The aim of this commit is fixing the connected until widget to show the reconnect bank button when the expiration date is for today. The right to fix that, is doing the fix in the view but to avoid breaking the stable policy, we decide to make the change in the JS widget. task-4058051
This fix resolves an issue where appointment types that use only resources (instead of staff members) were becoming unbookable. A recent change to allow organizer modifications in Microsoft Calendar was incorrectly requiring the appointment creator to be listed as an attendee, which doesn't apply to resource-based appointments. The fix adds a condition to skip this check for resource-only appointment types, restoring their functionality.
Original PR description
Added condition on a check in microsoft calendar that ensured the organizer was an attendee on the event on create. This was added in a change that allowed the organizer to be changed on the Odoo side. However, this caused issues with the appointments app when creating an appointment that only used resources. The "organizer" who in this case is the creator of the appointment type would not be an attendee and therefore would cause an error and make the appointment type unbookable. Adding this condition allows the appointment to bypass the check if the appointment type uses resources instead of users. This change adds the necessary override in enterprise. See change in community here: https://github.com/odoo/odoo/pull/162927 opw-3841495
This update fixes a bug that was preventing users from closing the share panel in the Knowledge module. A previous change inadvertently broke this functionality, and this fix reverts that problematic change to restore the ability to close the share panel properly.
Original PR description
This reverts commit a80633d9f713884f3bda063de21c080bc062f6af.
This fix resolves an issue where partially completed production orders would create confusing duplicate component lines when creating backorders. Now when you partially complete a production using barcode scanning and then create a backorder, the remaining components will be consolidated into a single line per product, making inventory tracking clearer and more intuitive.
Original PR description
**Current behavior:** If you have a production opened in barcode and consume part of a component line to produce part of the final product, leave the transfer, then re-open it and confirm -> create…
**Current behavior:**
If you have a production opened in barcode and consume part of a
component line to produce part of the final product, leave the
transfer, then re-open it and confirm -> create the backorder,
the resulting backorder will have split the remaining raw moves
in an unintuitive manner.
**Expected behavior:**
The backorder should have one move for the remaining component
quantity.
**Steps to reproduce:**
1. Create a production for 10 of some final product consuming 10
some component -> Confirm
2. Open the production in barcode, add 5 of the final product to
its line and 5 of the component to its line -> exit the
transfer view
3. Reopen the production and validate it -> create backorder
4. Open the backorder to see the odd split of the component
product's moves
**Cause of the issue:**
When creating the backorder we normally expect each component
product to be encapsulated by a single line- so the split that
occurs when we leave the transfer initially without validating
which creates 2 moves for the same product means we get 2 moves
for the component for half of the remaining quantity for that
component.
**Fix:**
Incomplete barcode lines for production transfers should get
split into additional move lines as opposed to moves.
opw-4148050A bug in the UK tax reporting system has been corrected where important data (previous options) was not being properly passed through to the underlying system. This fix ensures tax reports are generated correctly without data loss or unexpected behavior.
Original PR description
Not passing the previous_options can have bad consequences, and was clearly not wanted here. Forward-Port-Of: odoo/enterprise#69913
This fix ensures that invoices from Northern Irish customers are now properly included in the EC Sales Report. Previously, these invoices were being excluded from the report, which could lead to incomplete sales data for businesses operating in Northern Ireland.
Original PR description
### Steps to reproduce * install `account_intrastat` * create and confirm an invoice for a Northern Irish customer * open the EC Sales Report You will see that your invoice is not included in the report opw-4123375 Forward-Port-Of: odoo/enterprise#69501