Thursday, November 14, 2024
9 changes · 17.0
Resolved issues and error corrections
This fixes a display issue on manufacturing orders where very large quantity values could overlap and become unreadable. The fields can now expand or scroll when needed, helping users review production quantities accurately even with unusually large numbers.
Original PR description
Steps
---
* install mrp
* create new mo for some product
* set a huge `product_qty` ("Quantity") (e.g. 123456789123456789, we
want to take as much space as possible but not trigger exponential
notation)
* Confirm > Produce All
* The qty_producing and product_qty fields will overlap and be
illegible
(Note that the order needs to be done and locked, because
if we can still edit the qty_producing the input will be scrollable)
Fix
---
allow the `qty_producing` field to grow;
make the fields scrollable when still too large
opw-3919805
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prCompany branches can now see the currency rates defined by their main company. This prevents missing exchange-rate information when users work with a branch as the active company.
Original PR description
To reproduce the issue: 1) Create a company A, with a branch B 2) Define a currency rate for A, for currency C 3) Open currency C's form view with only B as active company ==> The rate created in 2) is not shown
Sales payments now handle cases where no payment reference type is set on the payment provider. This lets invoices generate their own payment references, making payment matching and reconciliation easier.
Original PR description
As so_reference_type can be left empty on the payment.provider, we need to handle the case in the back end and effectively allow an empty payment reference. With no payment reference defined on the sale.order (field reference), we have the possibility to let the invoice define the payment reference itself (field payment_reference) which allows an easier reconciliation of payments and invoices. opw-4282903
Invoices that have already been sent will now keep their sent status when reset to draft and sent again. This prevents resend workflows from incorrectly showing an invoice as not sent, improving tracking accuracy for accounting teams.
Original PR description
Current Behavior: When an invoice is sent via Send & Print, is_move_sent is set to True. If the move is reverted to draft, is_move_sent is set to False. After that, if the invoice is resent via Send & Print, is_move_sent is not set to True again. To reproduce: 1. Optional: add the field is_move_sent to the view, to see its value 2. Create and confirm an invoice (is_move_sent = False) 3. Send it via the Send & Print button (is_move_sent = True) 4. Reset move to draft (is_move_sent = False) 5. Confirm and send it again (is_move_sent = False) Desired behavior: is_move_sent should be set to True after being sent via Send & Print, even if it is not the first time the invoice is being sent. Fix: We don't reset the is_move_sent to False when we set the invoice to draft. opw-4245126 Backport of #170713
This fix updates the timesheet module's tests so they do not depend on demo or sample data being available. It helps keep automated checks reliable across environments, reducing the chance of false failures during releases or deployments.
Original PR description
runbot-6969211300
This update fixes an internal automated test for the mail feature so it checks actions in the correct order. It helps prevent false failures in testing and supports more stable release validation, with no direct change for end users.
Original PR description
use `assertSteps` to rather than `assert.verifySteps` to make sure the steps are executed in the correct order. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Uploading an expense document that may match more than one currency no longer causes an error when the page is refreshed. If the system cannot confidently set the detected currency, it now keeps the normal default currency so employees can continue creating expenses without interruption.
Original PR description
### Steps to reproduce: - Set a main currency and a second one. - Upload a document in the expense module for the second currency - Refresh ### Cause: In the for loop there are more than one possible currency detected so `vals['currency_id']` does not exist but the if statement tries to read this value causing an error. ### Solution: Check if the currency_id is in the vals dictionary. If not, the default currency value will be in the Expense. opw-4307845
This update ensures quality checks are only triggered for products that have actually been received into inventory. Previously, a product could trigger a quality check even if it was part of a pending order. This change corrects a bug related to backorders, improving inventory accuracy and preventing unnecessary quality check processes.
Original PR description
**Steps to reproduce the bug:** - Create a tracked product by SN: “P1.” - Create a storable product: "P2." - Create a receipt for one unit of P1 and P2. - Mark it as "To Do." - Set the done quantity of P1 to 0. - Attempt to perform the quality check. **Problem:** You must perform a quality check for P1 even though it has yet to be received. Since the move_line is set to 0 rather than deleted in the original picking, it will be linked to the backorder when it is created. Therefore, to avoid unexpected behavior we can ignore linking its quality check to the backorder. https://github.com/odoo/odoo/blob/00057f8efd3c728e13a981290a725878e058d2c6/addons/stock/models/stock_picking.py#L832 opw-4187521
Miscellaneous changes
Step to reproduce. 1. Drag and drop a Contact Us Form 2. Select the form action as : " Apply for Job" 3. Select a field Type : "Activities" or "Kanban Stage" 4. Now on other field set visibility depending on this field 5. Now set the visibility options. -> Visibility value shows ID instead actual value/name. Prior to this commit, fields with conditional visibility showed the record's ID instead of its display name when the dependent field was a checkbox or radio button. This commit
Original PR description
Step to reproduce. 1. Drag and drop a Contact Us Form 2. Select the form action as : " Apply for Job" 3. Select a field Type : "Activities" or "Kanban Stage" 4. Now on other field set visibility depending on this field 5. Now set the visibility options. -> Visibility value shows ID instead actual value/name. Prior to this commit, fields with conditional visibility showed the record's ID instead of its display name when the dependent field was a checkbox or radio button. This commit fix the issue by displaying the displayName of the record instead ID. task-4267217 Forward-Port-Of: odoo/odoo#184232