Daily updates from Odoo
Tuesday, May 28, 2019
5 changes · master
Resolved issues and error corrections
Website configuration settings can now be saved correctly when only one language is available. The fix ensures the default website language is set properly behind the scenes, avoiding a confusing hidden-field error for users.
Original PR description
Before this commit, when you go on website config settings, you can't save. This is because the website default lang field is not set anymore (supposed to be set in onchange), and since it is hidden in the view if only one language, there is no clue about the error field. Following d0bb596f1d51b, x2many fields of new records are new records, meaning that: `self.many2one in self.x2many` is not true anymore since self.x2many is a new record. Also: `self.many2one = self.x2many[0]` is not working as before, the new record is not saved in the many2one
When users create or edit manufacturing, purchasing, repair, or stock records, unit of measure choices now stay limited to the selected product’s category. This prevents accidental selection of incompatible units after saving and reopening a record, improving data accuracy across operations.
Original PR description
Description of the issue/feature this PR addresses: show only a particular category's uom when creating on editing record. Current behavior before PR: when creating a record and select product, click to change the "UOM", you will see that only the UOM of this category is shown the first time. But after save the record and try again to set the UOM, now you will find all the UOM(s) displayed. Desired behavior after PR is merged: At the time of creating or editing a record, it will display only uom of product's category. Task: https://www.odoo.com/web#id=1886272&action=327&model=project.task&view_type=form&menu_id=4720 Pad: https://pad.odoo.com/p/r.59a96adaaef3f20a5fdc25e78f35c738 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change makes the Point of Sale customer loading process more reliable when custom modules also load customer data. It prevents the POS from using the wrong customer data setup, avoiding errors when adding a customer in affected installations.
Original PR description
When custom modules load a different partner field set for a completely unrelated purpose AND this loading takes place prior to the stock odoo one, then the load_new_partners method will infer the…
When custom modules load a different partner field set for a completely unrelated purpose AND this loading takes place prior to the stock odoo one, then the load_new_partners method will infer the wrong field set as the first in row hit is returned by _.find. It is not optimal code quality to use `res.partner` as if it was a unique identifier, while not inhibiting multiple loads of on a single model. Adding a (more) unique label and refer it in the find solves this problem and makes the code more robust. **Description of the issue/feature this PR addresses:** - `_.find` within `load_new_partners` uses _model name_ as search string - _Model name_ is not necessarily unique in the search context. - Therefore, `_.find` can return wrong results, corrupting the code. - This happens if another data load on `res.partner` _precedes_ the core odoo code (because `_.find` returns the first instance found) **Current behavior before PR:** - Under the given scenario, clicking on add customer in the POS screen returns a trace back `cannot read property of...` **Desired behavior after PR is merged:** - In the given code scenario, everything works. - core code is more reliable, by using a (truly) unique identifier for `_.find` analyzing code objects. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr @xoe-labs /cc @blaggacao
Clicking certain action links outside standard views no longer briefly opens the home screen before the intended action. This keeps the interface visually stable while preserving normal link styling for users.
Original PR description
Current behavior before PR: Defining action using `<a type="action">` outside of normal views(like qweb view) css style does not apply to it because missing the `href` tag. by defining `href` tag on a link will first open home screen then perform `do_action` thus it will do flickering. Desired behavior after PR is merged: Prevent `event` default behaviour so it will stop flickering and restore css style for action by defining `href` tag on it. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Inventory traceability reports now load their formatting correctly the first time they are printed, even when report assets are not already cached. The print option is restored, and report styling was cleaned up to reduce layout issues such as unnecessary horizontal scrolling.
Original PR description
Task Link: https://www.odoo.com/web#id=1974338&action=327&model=project.task&view_type=form&menu_id=4720 Pad Link: https://pad.odoo.com/p/r.10d2baa994bf0536744301feef6e2d18 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr