Daily updates from Odoo
Navigate
Branch
Tuesday, July 9, 2019
12 changes
Enhancements to existing features
Warehouse users now receive an activity alert when a linked stock move is rescheduled and may affect the next transfer. This helps teams spot delays or outdated planned dates earlier, reducing the risk of missed handoffs in inventory flows.
Original PR description
In a move chain, if the scheduled date of a move N is updated, we would
like to create an alert on the move N+1.
This commit adds a boolean field on stock.rule that, if set to True, will
create a next activity on the stock.picking of the move that are created
from this rule, in case the previous move has its scheduled date changed.
The message will depends on the propagation of the schedule date between
the two moves:
- If the date is propagated, the message informs the picking user that
the transfer is delayed.
- If the date is not propagated and the new date of move N is after the
schedule date of move N+1, the message says that the scheduled date
will be outdated.
Task: 2001643
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-prInventory operations can now record receipts and deliveries with a zero value while still keeping a traceable valuation record. This helps businesses handle common cases like free products or samples without losing audit visibility.
Original PR description
We still create a valuation layer for the traceability of what happened though. The rationale is that receiving free products is often requested by our customers. task-1985424
Users can now enter simple calculations directly in numeric fields by starting with an equals sign, such as =20+3*2. This reduces manual calculation outside Odoo and respects local number formatting, while invalid formulas are clearly marked as errors.
Original PR description
Add a new behavior to numeric fields, possibility to enter value manually or to use a simple arithmetic expression that will be evaluated. Example: =20+3*2 In order for the computation of the arithmetic expression to be done, the value needs to starts with = and then an expression can be entered. We only support the basics mathematical operations + - * / ( ) ^ User locale and digits separator are taken into account. If the value entered can't be evaluated to a numeric, the field will be displayed in error. Task: 2031253 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This change ensures sales invoices use the actual delivered product cost for stock valuation whenever deliveries exist, regardless of the product invoicing policy. This prevents accounting imbalances in Anglo-Saxon accounting and makes dropshipping and stock valuation results more consistent.
Original PR description
The invoice status of a sale order line depends on its product's `invoice_policy` and `qty_delivered` fields. `invoice_policy` is also used to compute the "anglo saxon price unit" which is, once…
The invoice status of a sale order line depends on its product's `invoice_policy` and `qty_delivered` fields. `invoice_policy` is also used to compute the "anglo saxon price unit" which is, once multipled by the invoiced quantity, the amount we will take from the stock delivered account to put into the cost of goods sold account if we are in anglo saxon mode. The default `invoice_policy` is set as "ordered". In this mode and in anglosaxon, the "anglo saxon price unit" will always be standard price of the product, resulting in unbalanced accounts. In this task, we chose to use the real delivered price if something was delivered, whatever the value of `invoice_policy`. We fallback on the standard price if nothing or not enough things were delivered. [REF] sale_mrp [REF] stock_dropshipping test_dropship_fifo_perpetual_anglosaxon_ordered and test_dropship_fifo_perpetual_anglosaxon_delivered do have the same result now. task-2003196 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
This fix prevents the web interface from crashing when a user clicks an editable list row that contains only read-only fields and then presses Tab. It improves day-to-day form navigation reliability without changing business workflows or adding new features.
Original PR description
Let's assume an editable list with a row containing only readonly fields. Before this rev., if the user clicked on this row and then pressed TAB, it crashed. The crash occurred in historical code that now seems to be useless, so we simply removed it. 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
This update brings forward a set of bug fixes that improve reliability across CRM, Sales, Mail, Point of Sale, Website Sales, Units of Measure, and core user/form handling. It addresses crashes, incorrect notifications, POS employee login issues, sales dashboard errors, website product link behavior, and form editing problems so day-to-day operations are smoother.
This fixes a crash that could happen when users changed customer phone numbers in CRM. It also restores the expected timing for sending notification emails, helping ensure messages are sent reliably after related changes are saved.
This fixes the visual appearance of tags on payment records so they display as intended. The change removes styling that made the tags look incorrect, improving clarity for users reviewing payments.
Original PR description
**Description of the issue/feature this PR addresses**:
- Task: https://www.odoo.com/web#id=2033286&action=333&active_id=1278&model=project.task&view_type=form&menu_id=4720
- Pad: https://pad.odoo.com/p/r.ce7c1e77cbc551b17068f56edcd0b9bd
**Description:**
- Tags didn't look the way they were supposed to. Fixed that.
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fix prevents existing dialogs from closing unnecessarily when a new pop-up action is opened. It improves mobile sales flows such as product configuration, where closing the previous dialog too early could interrupt the user journey and prevent updates from applying correctly.
Original PR description
Rev. ee44d23 fixed a usability issue: when a doAction is performed from a dialog, it automatically closes the dialog (as the action is rendered in the background, behind the dialog). However, it also…
Rev. ee44d23 fixed a usability issue: when a doAction is performed from a dialog, it automatically closes the dialog (as the action is rendered in the background, behind the dialog). However, it also closes dialogs when the action has target='new', i.e. when it also opens in a dialog, which is not strictly necessary in this case. This is problematic in mobile for the product configurator widget: in the sale.order form view, the order_line field is displayed as a kanban, and in its form view, the product_(template_)id field has widget product_configurator. When a value is set, it performs a doAction (target="new") to configure the product. The widget listens to the dialog's 'closed' event to update itself. However, with what is done in ee44d23, the x2many form dialog is closed by the DoAction, so the flow doesn't work. This rev. reverts the attempt done in ee44d23, and does something a bit more brutal: as soon as an action is pushed in target 'current' (in the main part of the interface), all dialogs are automatically closed. 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
This fix prevents an error when stock accounting entries are created with an unexpected default setting in the background. It helps ensure inventory valuation and related accounting postings complete reliably without disrupting users.
Original PR description
Default "type" key in the context leads to a traceback. task-2033390
This update fixes several issues in field service, project planning, and localization. Users get missing map views, smoother invoicing and worksheet access, corrected forecast behavior on non-working days, and a Mexico external trade data correction.
This update ensures PDF files added through the Documents workflow can correctly create new invoices after recent accounting changes. It supplies the required invoice defaults so users avoid errors when attaching PDFs to draft invoices.
Original PR description
Following the refactor of accounting, giving the default type and default journal is required when adding a PDF attachment to a new invoice ( https://github.com/odoo/odoo/commit/bc131c0cfb51c953de8ec41fb820c8c7831eefb5#diff-7fb614c57de345cbe8f907c7237020bfR65 ) This commit fixes this issue when adding a PDF in documents' workflow.