Daily updates from Odoo
Tuesday, July 9, 2019
9 changes · master
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.